Olá.
O comando do meu próprio split fechou-se em copas. Velho que se farta, ainda por cima.
Precisao de encontrar um comando destes ou o acesso a um que funcione para poder copiar os códigos a fazer outro comando. Tenho um leitor de códigos de infra-vermelho mas o remoto morreu.
Pertence a um conjunto Sanyo SAP-FT186QHS5 + SAP-C186QH5
Se alguém souber onde posso encontrar os códigos do comando, também serve.
Abraço a todos
Henrique Martins
Remoto Sanyo RCS-6HPS3E
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Deixo aqui uma imagem do remoto. Posso alternativamente deslocar-me algures para ler os códigos (levo comigo o leitor).
Abraço
Henrique Martins
Abraço
Henrique Martins
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
O remoto resolveu trabalhar de vez em quando. Neste momento está a funcionar. Já se ‘desligou’ um par de vezes e, sendo assim, retiram-se as pilhas, espera-se pelo dia seguinte e voltam a colocar-se.
Para ler os códigos tenho um leitor de códigos mas os testes que fiz indicam que os dados que o remoto emite são mais do que os que o leitor consegue ler. Na verdade, os códigos lidos para algumas funções são sempre os mesmos, portanto, é de se supor que há algo mais no processo que o leitor não lê. Além do mais há a possibilidade do leitor estar a ler algo que não entende de todo pelo que há que procurar saber que coisa emite o remoto.
Na bancada de testes tratei de ligar o osciloscópio aos LEDs de infra-vermelhos. Os LEDs são alimentados directamente pelos +3V das pilhas e a comutação faz-se pelo lado negativo da alimentação (coisa muito comum).
Atenção que o que se vê nas imagens não são os bits dos dados mas apenas são uma espécie de bits da portadora dos dados (que desta forma não se conseguem topar).
A primeira coisa a saber-se é a frequência de emissão infra-vermelha. O habitual é 36, 38 ou 40KHz. Uma leitura inicial indicava ser de 37.5KHz mas uma outra leitura mais cuidada indica tratar-se de 38KHz.
Por causa da forma como os leds estão ligados no circuito, a emissão de infra-vermelho dá-se quando o sinal é mais negativo (mais abaixo no ecrâ do osciloscípio). Os LEDs acendem apenas na zona assinalada a vermelho.
Os leds são, portanto, ligados durante 12us (micro-segundos) e ficam desligados 14.3us.
Vou agora recorrer a um analisador digital (barato) e software apropriado para ler um conjunto de bits da portadora (chamemos-lhes assim) e tentar perceber que verdadeiros bits estão lá dentro (que a estão a modular).
No osciloscópio vê-se a verdadeira forma de onda emitida, daí a onda ter um formato que pode parecer bizarro. No software que vou de seguida usar só se identificam bits sem quaisquer valores de voltagens associados. Daí a necessidade de se saber o que se vai aplicar a esse software para não se obter gato por lebre. O analisador que tenho pode ver tensões de 3 a 5V, mas aquilo que o sistema aplica aos LEDs não passa de 1,2V. Terei, portanto, que amplificar umas 4x, aproximadamente, para poder utilizar o analisador. É a fase que se segue.
Alternativamente, se adquirir um receptor de infra-vermelhos (menos de 1.5€) não preciso do amplificador e obtenho logo os verdadeiros bits mas, se o sistema, sendo muito antigo, não for o habitual, o receptor pode não dar o que se espera (pouco provável, mas gato escaldado ...).
Para ler os códigos tenho um leitor de códigos mas os testes que fiz indicam que os dados que o remoto emite são mais do que os que o leitor consegue ler. Na verdade, os códigos lidos para algumas funções são sempre os mesmos, portanto, é de se supor que há algo mais no processo que o leitor não lê. Além do mais há a possibilidade do leitor estar a ler algo que não entende de todo pelo que há que procurar saber que coisa emite o remoto.
Atenção que o que se vê nas imagens não são os bits dos dados mas apenas são uma espécie de bits da portadora dos dados (que desta forma não se conseguem topar).
Os leds são, portanto, ligados durante 12us (micro-segundos) e ficam desligados 14.3us.
Vou agora recorrer a um analisador digital (barato) e software apropriado para ler um conjunto de bits da portadora (chamemos-lhes assim) e tentar perceber que verdadeiros bits estão lá dentro (que a estão a modular).
No osciloscópio vê-se a verdadeira forma de onda emitida, daí a onda ter um formato que pode parecer bizarro. No software que vou de seguida usar só se identificam bits sem quaisquer valores de voltagens associados. Daí a necessidade de se saber o que se vai aplicar a esse software para não se obter gato por lebre. O analisador que tenho pode ver tensões de 3 a 5V, mas aquilo que o sistema aplica aos LEDs não passa de 1,2V. Terei, portanto, que amplificar umas 4x, aproximadamente, para poder utilizar o analisador. É a fase que se segue.
Alternativamente, se adquirir um receptor de infra-vermelhos (menos de 1.5€) não preciso do amplificador e obtenho logo os verdadeiros bits mas, se o sistema, sendo muito antigo, não for o habitual, o receptor pode não dar o que se espera (pouco provável, mas gato escaldado ...).
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Pois é. A coisa afigura-se bastante mais complicada do que eu estava a prever,
Eu já tinha dado uma vista de olhos por esta coisada dos remotos por infre-vermelhos e, grosso modo, tinha percebido que a coisa andava pelo envio de 32 bits. Parece que no ar-condicionado a coisa é mais gorda.
Voltei a olhar pormenorizadamente o sinal que chega aos LEDs do remoto e suspeitei que tinha hipóteses de ler aquele sinal com o analisador lógico sem ter que meter mais tralha ao barulho. Nem tudo é mau, a coisa funcionou.
Comecei por registar o sinal para ligar e desligar. No entanto, vamos ver a história dos bits de portadora e dos bits reais.
Os bits da portadora seriam alvez melhor chamados de impulsos (luminosos) de portadora.
La linha D0 (à esquerda a preto) aparecem 20 impulsos. São os impulsos que apareciam no osciloscóprio e NÃO correspondem a bits. Esses 20 impulsos mais o espaço sem impulsos que se lhe segue (mais ou menos da mesma duração) corresponde a 1 bit, neste caso um 0 (zero), representado na linha verde logo a seguir. O resto para já não interessa.
As 3 linhas chamadas (à esquerda) IR NEC são a descodificação do sinal D0 (a ponta número zero do meu analizador). Essa descodificação é a tradução daquilo que está contido no sinal (neste caso apenas um zero).
Chama-se a isto, partir pedra.
Nesta outra imagem aparecem os mesmos 20 impulsos seguidos de um espaço muito maior, que talvez dure 2.5x mais que os 20 impulsos. Estes impulsos e aquele espaço muito maior representa 1 bit com valor 1.
Porque é que isto é assim? Porque estamos perante o protocolo NEC (Nippon Electric Company) que se reconhece mais ou menos a olho e é muito usado em controlos remotos. Há duas variantes, parecidas, mas é outra conversa.
E agora é que a coisa se complica. Temos agora o D0, o IR (infra-red) NEC a verde (protocolo normal) e IR NEC na versão especial. Podem ver-se os bits a 0 e a 1 correspondentes ao 32 bits que normalmente aparecem. A gaita é que neste caso, depois dos 32 bits da praxe, aparecem mais 40. Esses bits podem ser lidos “à mão” mas o protocolo instalado neste software de leitura não os reconhece.
Entretanto descobri alguma coisa sobre o ar condicionado da Panasonic onde dá para ver que eles usam muito mais bits. Parece-me que a Sanyo e a Panasonic pertencem ao mesmo grupo fabricante.
https://www.analysir.com/blog/2014/12/2 ... -protocol/
Vou ainda tentar encontrar um descodificador para esta variante do protocolo NEC e, se não encontrar, tenho que descascar a bitalhada à mão.
Eu suponho que isto é assim porque quando se liga o split o comando não envia apenas a ordem de ligar. Suspeito que envia igualmente a temperatura ‘set point’, a temperatura ambiente medida no comando (tem um sensor no comando), o modo (frio, calor, deshumidificador, ou comutação automática entre modos) o modo de ‘flap’ da ventilação e a velocidade de ventilação. Para isto tudo ele precisa muito mais que 42 bits, daí emitir mais de 64 bits (não sei exactamente quantos).
Vou tentar perceber para que serve cada grupo de bits enviando um ON alterando um dos parâmetros para topar a diferença.
Eu já tinha dado uma vista de olhos por esta coisada dos remotos por infre-vermelhos e, grosso modo, tinha percebido que a coisa andava pelo envio de 32 bits. Parece que no ar-condicionado a coisa é mais gorda.
Voltei a olhar pormenorizadamente o sinal que chega aos LEDs do remoto e suspeitei que tinha hipóteses de ler aquele sinal com o analisador lógico sem ter que meter mais tralha ao barulho. Nem tudo é mau, a coisa funcionou.
Comecei por registar o sinal para ligar e desligar. No entanto, vamos ver a história dos bits de portadora e dos bits reais.
Os bits da portadora seriam alvez melhor chamados de impulsos (luminosos) de portadora.
- 08.05.2023_20.55.44_REC.png (31.7 KiB) Visto 1474 vezes
As 3 linhas chamadas (à esquerda) IR NEC são a descodificação do sinal D0 (a ponta número zero do meu analizador). Essa descodificação é a tradução daquilo que está contido no sinal (neste caso apenas um zero).
Chama-se a isto, partir pedra.
- 08.05.2023_20.56.58_REC.png (18.75 KiB) Visto 1474 vezes
Porque é que isto é assim? Porque estamos perante o protocolo NEC (Nippon Electric Company) que se reconhece mais ou menos a olho e é muito usado em controlos remotos. Há duas variantes, parecidas, mas é outra conversa.
Entretanto descobri alguma coisa sobre o ar condicionado da Panasonic onde dá para ver que eles usam muito mais bits. Parece-me que a Sanyo e a Panasonic pertencem ao mesmo grupo fabricante.
https://www.analysir.com/blog/2014/12/2 ... -protocol/
Vou ainda tentar encontrar um descodificador para esta variante do protocolo NEC e, se não encontrar, tenho que descascar a bitalhada à mão.
Eu suponho que isto é assim porque quando se liga o split o comando não envia apenas a ordem de ligar. Suspeito que envia igualmente a temperatura ‘set point’, a temperatura ambiente medida no comando (tem um sensor no comando), o modo (frio, calor, deshumidificador, ou comutação automática entre modos) o modo de ‘flap’ da ventilação e a velocidade de ventilação. Para isto tudo ele precisa muito mais que 42 bits, daí emitir mais de 64 bits (não sei exactamente quantos).
Vou tentar perceber para que serve cada grupo de bits enviando um ON alterando um dos parâmetros para topar a diferença.
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Penso já ter descascado a coisa. O comando foi-se aguentando e ainda está a funcionar. Nesta altura já devo conseguir enjorcar outro sem ajuda daquele.
Deixo aqui (lá em baixo) a folha de Excel com o protocolo da coisa. Se tiverem alguma dúvida, disponham.
Não tentei sequer descascar funções como a programação de arranque e afins. Nunca usei essas funções acho que não vale a pena perder tempo com elas. Apesar disso ainda descasquei a função “1H timer”.
O sinal emitido é composto por 318 impulsos de AGC (para ajuste automático de recepção de sinal), um intervalo de 4.2ms, 9 bytes e 1 stop bit.
Coisas a ter em atenção:
1 – Os bits das palavras são emitidos por ordem inversa. Primeiro os menos significativos e depois os mais significativos. Em tempos idos era comum ser assim mas esta forma de fazer a coisa parece (felizmente) ter caído em desuso.
Se escrevermos 1234, o ‘1’ significa 1000, o ‘2’ significa 200, etc. Estamos, portanto, a escrever do mais para o menos significativo (o normal). No caso deste sistema, 1234 escrever-se-ia ao contrário: 4321. No caso do sistema escreve-se em binário e não em decimal mas a coisa é idêntica.
2 – Há uma série de bits que nunca mudam. Talvez alguns deles sejam usados pelas funções que não descasquei. De qualquer forma estão assinalados a vermelho. Apesar de não serem eventualmente usados têm que ser enviados.
3 – De cada vez que algo se passa no comando é enviado à unidade interior a colecção completa de parâmetros.
4 – A cada 3 minutos a colecção de parâmetros é enviada automaticamente. Para evitar a produção do ‘beep’ o fabricante teve o cuidado de colocar a 1 o bit que trata deste envio espontâneo.
----
No 1º byte (8 bits) são, suponho eu, para envio do identificativo no modelo da máquina com que o comando trabalha. Deverá servir para evitar maus entendidos caso o comando seja usado com a maquina errada. Neste caso o modelo é o ‘106’e nunca o vi mudar enquanto testei.
----
No 2º byte, os primeiros 5 bits são para o SetPoint (temperatura que se pretende). O valor que é enviado à máquina não é o que se escolhe mas 4 graus menos. Desta forma em 5 bits entrariam temperaturas de +4grC a +35rC (o caso da temperatura real ambiente). O SetPoint só varia entre 16 e 30.
----
No 3º byte os 1ºs 5 bits são usados com a temperatura ambiente no remoto (ele tem um sensor), codificados como o SetPoint podendo enviar temperaturas entre +4 e +30grC.
O 6º bit, se estiver a 1 será usado o sensor de temperatura ambiente da unidade interior, se estiver a 0 será usado o sensor do comando.
0 7º bit é usado caso o envio de dados seja espontâneo (envia a cada 3 minutos). Desta forma a unidade interior não produz o ‘beep’.
----
No 4º byte, o 1º bit corresponde à selecção “1 Hour Timer”. Este bit estará a 1 caso a função seja seleccionada. Não sei se o fim desta função é processada no comando se na unidade interior se em ambos os locais (o mais provável).
----
No 5º byte, os primeiros 2 bits são usados para a selecção da velocidade de ventilação de acordo com a tabela.
Os bits 5, 6 e 7 são usados para seleccionar o tipo de função que a máquina vai desempenhar. Só precisaria de 2 bits mas usa 3. Talvez haja algo mais relacionado com a programação do tempo de funcionamento.
----
No 6º byte, se o bit 4 estiver a 1 o ‘flap’ entra em funcionamento.
Os bits 7 e 8 determinam a ligar e desligar da máquina. Usa 2 bits, só precisaria de 1.
----
No âmbito referido não encontrei qualquer utilidade para os bytes 7 e 8.
----
O byte 9 é usado para envio de paridade para atenuar a possibilidade da máquina receber dados erróneos. Caso a paridade não corresponda aos dados enviados, a máquina ignora o respectivo comando.
----
... finalmente 1 Stop Bit para permitir que se perceba se o bit anterior é um 0 ou um 1.
==============
Vou agora passar à fase de programar um Arduino Nano para que se comporte como o comando, no que respeita às referidas funções fundamentais.
Por hoje já chega de partir pedra.
Abraço a todos,
H. Martins
Deixo aqui (lá em baixo) a folha de Excel com o protocolo da coisa. Se tiverem alguma dúvida, disponham.
Não tentei sequer descascar funções como a programação de arranque e afins. Nunca usei essas funções acho que não vale a pena perder tempo com elas. Apesar disso ainda descasquei a função “1H timer”.
O sinal emitido é composto por 318 impulsos de AGC (para ajuste automático de recepção de sinal), um intervalo de 4.2ms, 9 bytes e 1 stop bit.
Coisas a ter em atenção:
1 – Os bits das palavras são emitidos por ordem inversa. Primeiro os menos significativos e depois os mais significativos. Em tempos idos era comum ser assim mas esta forma de fazer a coisa parece (felizmente) ter caído em desuso.
Se escrevermos 1234, o ‘1’ significa 1000, o ‘2’ significa 200, etc. Estamos, portanto, a escrever do mais para o menos significativo (o normal). No caso deste sistema, 1234 escrever-se-ia ao contrário: 4321. No caso do sistema escreve-se em binário e não em decimal mas a coisa é idêntica.
2 – Há uma série de bits que nunca mudam. Talvez alguns deles sejam usados pelas funções que não descasquei. De qualquer forma estão assinalados a vermelho. Apesar de não serem eventualmente usados têm que ser enviados.
3 – De cada vez que algo se passa no comando é enviado à unidade interior a colecção completa de parâmetros.
4 – A cada 3 minutos a colecção de parâmetros é enviada automaticamente. Para evitar a produção do ‘beep’ o fabricante teve o cuidado de colocar a 1 o bit que trata deste envio espontâneo.
----
No 1º byte (8 bits) são, suponho eu, para envio do identificativo no modelo da máquina com que o comando trabalha. Deverá servir para evitar maus entendidos caso o comando seja usado com a maquina errada. Neste caso o modelo é o ‘106’e nunca o vi mudar enquanto testei.
----
No 2º byte, os primeiros 5 bits são para o SetPoint (temperatura que se pretende). O valor que é enviado à máquina não é o que se escolhe mas 4 graus menos. Desta forma em 5 bits entrariam temperaturas de +4grC a +35rC (o caso da temperatura real ambiente). O SetPoint só varia entre 16 e 30.
----
No 3º byte os 1ºs 5 bits são usados com a temperatura ambiente no remoto (ele tem um sensor), codificados como o SetPoint podendo enviar temperaturas entre +4 e +30grC.
O 6º bit, se estiver a 1 será usado o sensor de temperatura ambiente da unidade interior, se estiver a 0 será usado o sensor do comando.
0 7º bit é usado caso o envio de dados seja espontâneo (envia a cada 3 minutos). Desta forma a unidade interior não produz o ‘beep’.
----
No 4º byte, o 1º bit corresponde à selecção “1 Hour Timer”. Este bit estará a 1 caso a função seja seleccionada. Não sei se o fim desta função é processada no comando se na unidade interior se em ambos os locais (o mais provável).
----
No 5º byte, os primeiros 2 bits são usados para a selecção da velocidade de ventilação de acordo com a tabela.
Os bits 5, 6 e 7 são usados para seleccionar o tipo de função que a máquina vai desempenhar. Só precisaria de 2 bits mas usa 3. Talvez haja algo mais relacionado com a programação do tempo de funcionamento.
----
No 6º byte, se o bit 4 estiver a 1 o ‘flap’ entra em funcionamento.
Os bits 7 e 8 determinam a ligar e desligar da máquina. Usa 2 bits, só precisaria de 1.
----
No âmbito referido não encontrei qualquer utilidade para os bytes 7 e 8.
----
O byte 9 é usado para envio de paridade para atenuar a possibilidade da máquina receber dados erróneos. Caso a paridade não corresponda aos dados enviados, a máquina ignora o respectivo comando.
----
... finalmente 1 Stop Bit para permitir que se perceba se o bit anterior é um 0 ou um 1.
==============
Vou agora passar à fase de programar um Arduino Nano para que se comporte como o comando, no que respeita às referidas funções fundamentais.
Por hoje já chega de partir pedra.
Abraço a todos,
H. Martins
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
- 10.05.2023_18.40.42_REC.png (25.73 KiB) Visto 1419 vezes
Falta ainda ligar o sensor de temperatura ao Arduino e escrever o código (tenho umas NTCs minúsculas de 10K).
Este tipo de sistema pode trabalhar a pilhas mas vai gasta-las muito depressa. É provável que deixe a coisa simplesmente ligada a uma fonte (carregador) USB. Não será mesmo portátil, mas no meu caso interessa pouco. Posso usar outro micro-controlador que consuma muito menos corrente, mas é capaz de não valer a pena.
A emissão de infra-vermelhos consegue-se com um díodo emissor, uma resistência e um MOS-FET. Tenho aqui um comando de um aparelho que já foi às urtigas, deve ser suficiente. Depois deixo o esquema.
Podia usar um mostrador maior mas para o que é, serve.
Cold / Heat / Auto / Dehumidifier - fazer frio
TR - Temperatura que se pretende
TA - Temperatura ambiente medida no comando
VA / V1 / V2 / V3 - Velocidade de ventilação
OH / 1H / Temporizador de 1 hora (não sei bem para que serve)
SC / SM - Se usa sensor do comando ou da máquina.
Este mostrador permite que se programem uns quantos bonecos gráficos, mas fica para o fim (se valer a pena).
Quando estiver pronto deixo aqui o código.
Abraço
H. Martins
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Estive em silêncio porque tive que partir muito mais pedra do que suspeitava.
Nestas coisa do envio de dados (aquilo que o comando faz) uma das coisas que importa ter em atenção é como garantir que os comandos (dados) que são enviados à máquina por infra-vermelhos chegam lá sem sofrerem alteração. A forma mais comum de fazer a coisa recorre a uso de paridade.
A paridade consiste em enviar-se juntamente com a lista de números (os comandos) a soma desses números. À chegada desses números faz-se, já no destino, uma soma idêntica àquela que foi feita à partida e compara-se essa soma com a soma enviada juntamente com a listagem. Se as somas não forem iguais é porque qualquer coisa correu mal durante o percurso, e, se for o caso, tipicamente, ignora-se o que foi recebido. No caso do comando de ar-condicionado, se, por exemplo, ligarmos a máquina e ela não reagir, não se ouve o ‘beep’ e ficamos a saber que ou a máquina não recebeu de todo ou recebeu mas os dados chegaram danificados. Nessa altura repetimos a operação procurando apontar melhor o comando.
Já tinha percebido que o comando enviava uma paridade e estava farto der saber que a questão é saber-se que contas há a fazer para gerar essa paridade. A paridade pode ser calculada de muitas maneiras diferentes.
Acontece que os processos mais simples de se gerar paridade permitem ‘buracos’ ou seja, permitem que na recepção de dados defeituosos possa ocorrer um cálculo de paridade cujo resultado seja o correcto. Neste caso muita coisa esquisita pode acontecer. Os fabricantes procuram um ponto de equilíbrio entre complexidade que garanta bons resultados (mas difícil e/ou caro) de implementar e simplicidade que não permita muitos ‘buracos’. Uma coisa é um simples comando de um ar-condicionado outra coisa é o comando das portas de um carro (e mesmo assim...).
Analisando o sinal, tudo indicava tratar-se do último byte. Assim era. A questão era saber-se como seria ela calculada.
Foi dar uma vista de olhos à Internet e topei que a generalidade dos comandos de ar-condicionado usam um processo que consiste em somar-se simplesmente todos os bytes a enviar (nalguns casos sem o cabeçalho porque é sempre o mesmo), e aproveitar apenas os 8 bits menos significativos. Tudo bem, peguei numa folha de cálculo, coloquei lá os dados que o comando envia, coloquei lá o byte de paridade recolhido da análise ao comando e tratei de somar os dados para ver se batiam certo com os do comando. E à primeira bateram certo. Fiquei satisfeito e continuei com o hardware.
Acabado o hardware, testei e não funcionava. Voltei a dar uma vista de olhos à paridade e descobri que tinha tido a sorte, mais azar que sorte, de ter testado o algoritmo para um conjunto de dados em que o resultado dava certo apenas no caso daquela particular configuração inicial. O azar dos Távoras.
E agora? É o cenário com que poucos gostam de se entreter: como adivinhar?
Foi novamente à Internet e as hipóteses, mesmo as mais simples, eram milhentas, tanto mais que há fabricantes que parecem ter um gosto manhoso em complicar a vida aos clientes, apenas por complicar.
Dois dias andei nisto e finalmente percebi que bastava partir cada byte em 2x 4 bits (o sistema usa 8 bytes) e somar todos esses 16 grupos de 4 bits. Simples, não é? Tão simples que até dói ... depois de se saber.
Aqui fica o que espero ser a versão final do protocolo.
Depois conto o resto. Se alguém precisar de alguma explicação, disponha.
Nestas coisa do envio de dados (aquilo que o comando faz) uma das coisas que importa ter em atenção é como garantir que os comandos (dados) que são enviados à máquina por infra-vermelhos chegam lá sem sofrerem alteração. A forma mais comum de fazer a coisa recorre a uso de paridade.
A paridade consiste em enviar-se juntamente com a lista de números (os comandos) a soma desses números. À chegada desses números faz-se, já no destino, uma soma idêntica àquela que foi feita à partida e compara-se essa soma com a soma enviada juntamente com a listagem. Se as somas não forem iguais é porque qualquer coisa correu mal durante o percurso, e, se for o caso, tipicamente, ignora-se o que foi recebido. No caso do comando de ar-condicionado, se, por exemplo, ligarmos a máquina e ela não reagir, não se ouve o ‘beep’ e ficamos a saber que ou a máquina não recebeu de todo ou recebeu mas os dados chegaram danificados. Nessa altura repetimos a operação procurando apontar melhor o comando.
Já tinha percebido que o comando enviava uma paridade e estava farto der saber que a questão é saber-se que contas há a fazer para gerar essa paridade. A paridade pode ser calculada de muitas maneiras diferentes.
Acontece que os processos mais simples de se gerar paridade permitem ‘buracos’ ou seja, permitem que na recepção de dados defeituosos possa ocorrer um cálculo de paridade cujo resultado seja o correcto. Neste caso muita coisa esquisita pode acontecer. Os fabricantes procuram um ponto de equilíbrio entre complexidade que garanta bons resultados (mas difícil e/ou caro) de implementar e simplicidade que não permita muitos ‘buracos’. Uma coisa é um simples comando de um ar-condicionado outra coisa é o comando das portas de um carro (e mesmo assim...).
Analisando o sinal, tudo indicava tratar-se do último byte. Assim era. A questão era saber-se como seria ela calculada.
Foi dar uma vista de olhos à Internet e topei que a generalidade dos comandos de ar-condicionado usam um processo que consiste em somar-se simplesmente todos os bytes a enviar (nalguns casos sem o cabeçalho porque é sempre o mesmo), e aproveitar apenas os 8 bits menos significativos. Tudo bem, peguei numa folha de cálculo, coloquei lá os dados que o comando envia, coloquei lá o byte de paridade recolhido da análise ao comando e tratei de somar os dados para ver se batiam certo com os do comando. E à primeira bateram certo. Fiquei satisfeito e continuei com o hardware.
Acabado o hardware, testei e não funcionava. Voltei a dar uma vista de olhos à paridade e descobri que tinha tido a sorte, mais azar que sorte, de ter testado o algoritmo para um conjunto de dados em que o resultado dava certo apenas no caso daquela particular configuração inicial. O azar dos Távoras.
E agora? É o cenário com que poucos gostam de se entreter: como adivinhar?
Foi novamente à Internet e as hipóteses, mesmo as mais simples, eram milhentas, tanto mais que há fabricantes que parecem ter um gosto manhoso em complicar a vida aos clientes, apenas por complicar.
Dois dias andei nisto e finalmente percebi que bastava partir cada byte em 2x 4 bits (o sistema usa 8 bytes) e somar todos esses 16 grupos de 4 bits. Simples, não é? Tão simples que até dói ... depois de se saber.
Aqui fica o que espero ser a versão final do protocolo.
Depois conto o resto. Se alguém precisar de alguma explicação, disponha.
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Acabei de conseguir ligar e desligar o split usando o comando, ainda em forma de pré-protótipo (não passará de protótipo, evidentemente).
Entretanto deixo aqui o esquema da coisa e a placa de circuito impresso (PCB). Atenção que esta placa não existe exactamente assim porque eu usei simplesmente o projecto de PCB para me orientar no que respeita à melhor colocação dos componentes e execução das interligações usando arames. Deixo também o projecto em Kicad (em RAR).
Já agora, eu uso regularmente placas de esferovite ou poliuretano para colocar sobre elas as plaquinhas que compõem este tipo de projectos e fixo-as usando palitos (dos dentes) cortados ao meio (vejam a foto). Isto facilita imenso a vida.
Vou agora acabar o código. Ainda faltam 4 coisas: o envio automático dos dados do comando a cada 3 minutos, o anular do “1H timer” ao fim de 1 hora, a leitura da sonda de temperatura do comando e a leitura mais precisa da tensão de alimentação do sistema (com implicações na precisão de leitura da temperatura – eu depois explico melhor).
Já agora, eu uso regularmente placas de esferovite ou poliuretano para colocar sobre elas as plaquinhas que compõem este tipo de projectos e fixo-as usando palitos (dos dentes) cortados ao meio (vejam a foto). Isto facilita imenso a vida.
Vou agora acabar o código. Ainda faltam 4 coisas: o envio automático dos dados do comando a cada 3 minutos, o anular do “1H timer” ao fim de 1 hora, a leitura da sonda de temperatura do comando e a leitura mais precisa da tensão de alimentação do sistema (com implicações na precisão de leitura da temperatura – eu depois explico melhor).
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Acabei agora a versão teoricamente final do software, faltando apenas calibrar a segunda temperatura da sonda. Par ter uma sonda calibrada, sem se estar a falar em ciência de foguetões, basta calibrar a duas temperaturas suficientemente distantes. A primeira (já calibrada), deve ser (é mais fácil) a temperatura a que a sonda tem a resistência que anuncia, neste caso 10KOhm a 20grC.
Só sondas escolhidas ou muito caras têm desvios muito pequenos. Esta sonda é das mais baratas e tem um desvio um pouco maior.
Pior que uma sonda ter um desvio de resistência em relação à temperatura seria ela não ter um valor estável mas, um valor estável ela tem, portanto, basta calibrar a sonda por software. Não ter um valo estável seria ela variar significativamente a uma mesma temperatura.
Neste caso eu pude ajustar a 20grC comparando com o comando original, que continua a funcionar. Se não continuasse usaria um termómetro de confiança. Para ajustar basta somar (ou subtrair) à temperatura que a sonda originalmente lê, um valor que, somado, dê 20grC. Falta agora calibrar a um valor distante, por exemplo a 30grC. Para conseguir ter a sonda do comando original e esta nova sonda à mesma temperatura, o mais fácil para mim será aquecer a sala onde estou usando o próprio split. Vou fazer isso ainda hoje ou amanhã.
Só sondas escolhidas ou muito caras têm desvios muito pequenos. Esta sonda é das mais baratas e tem um desvio um pouco maior.
Pior que uma sonda ter um desvio de resistência em relação à temperatura seria ela não ter um valor estável mas, um valor estável ela tem, portanto, basta calibrar a sonda por software. Não ter um valo estável seria ela variar significativamente a uma mesma temperatura.
Neste caso eu pude ajustar a 20grC comparando com o comando original, que continua a funcionar. Se não continuasse usaria um termómetro de confiança. Para ajustar basta somar (ou subtrair) à temperatura que a sonda originalmente lê, um valor que, somado, dê 20grC. Falta agora calibrar a um valor distante, por exemplo a 30grC. Para conseguir ter a sonda do comando original e esta nova sonda à mesma temperatura, o mais fácil para mim será aquecer a sala onde estou usando o próprio split. Vou fazer isso ainda hoje ou amanhã.
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Quanto ao interface na imagem ...
... a coisa explica-se olhando o esquema:
O Arduino Nano é alimentado por 5V via cabo USB mas, por haver um díodo de protecção no próprio Arduino, apenas 4.5V chegam ao microcontrolador propriamente dito (ATmega328). É com essa tensão (voltagem) que temos que contar (não há qualquer problema, podia ser ainda menos).
Tanto o LCD (Liquid Christal Display) como o interface que desenhei (a zona à direita de J5) trabalham, como convém, à mesma tensão que o microcontrolador.
No software eu gosto, antes de mais, de saber que tensão alimenta os circuitos. Não tem que ser assim mas trabalha-se menos na corda bamba. Para isso o IC (Integrated Circuit - Circuito Integrado) TL431LP é usado. Da forma como está ligado gera, onde assinalado, 2,5V a uma precisão de poucas milésimas de Volt. A partir daí alguma matemática simples permite saber que tensão alimenta o circuito e, portanto, que tensão se espera obter no sensor a 20grC. Esta tensão é lida no pino A1 do microcontrolador.
R5 e o sensor NTC TH1, de 10KOhm, configuram um divisor te tensão. A tensão deste divisor é lida pelo microcontrolador no pino A7.
O pino A3 do microcontrolador gera o impulso que liga o LED de infravermelhos através do MOS-FET Q1. O microcontrolador era capaz de poder atacar o LED directamente mas, por um lado ficaria a trabalhar ao máximo e, por outro, não permitiria filtrar a alimentação no LED. Se o filtro L1 e C1 não estivesse lá, podia muito bem acontecer que a alimentação do próprio microcontrolador viesse a sofrer flutuações por causa do ligar/desligar do LED, que, ligado, consome 10mA aproximadamente. Se for preciso ligar mais um LED basta colocá-lo em série com o primeiro baixando R1 de 330R para 270R (Ohm). Atenção que o indutor L1 tem igualmente uma resistência interna a DC de 32R (neste caso até dá jeito).
Quanto ao resto, R3, R4 e C2 e C3 servem para aumentar a estabilidade em U1 (uma mania minha). R6 serve para limitar a corrente de pico à saída do microcontrolador (outra mania). R2 serve para evitar que Q1 comece a conduzir mal se ligue a alimentação ao conjunto. Acontece que o microcontrolador demora à volta de 1 a 2 segundos a arrancar e, antes de arrancar o pino 2 do Q1 ficaria completamente flutuante (nesse período os pinos do microcontrolador permanecem completamente isolados de tudo). Bastaria, por exemplo, a emissão de um telemóvel ou a proximidade de qualquer coisa eléctrica para o fazer entrar em condução o transístor Q1.
O microcontrolador comunica com o LCD através dos pinos A4 e A5 usando o protocolo I2C (apenas funciona nestes pinos). SCL é o clock, SDA é o pino por onde circulam os dados.
Os interruptores dos botões ligam às entradas D5 a D12.
Logo que tenha o software mais testado, deixo-o aqui. Aponto que ainda há bugs.
Abraço
H. Martins
... a coisa explica-se olhando o esquema:
Tanto o LCD (Liquid Christal Display) como o interface que desenhei (a zona à direita de J5) trabalham, como convém, à mesma tensão que o microcontrolador.
No software eu gosto, antes de mais, de saber que tensão alimenta os circuitos. Não tem que ser assim mas trabalha-se menos na corda bamba. Para isso o IC (Integrated Circuit - Circuito Integrado) TL431LP é usado. Da forma como está ligado gera, onde assinalado, 2,5V a uma precisão de poucas milésimas de Volt. A partir daí alguma matemática simples permite saber que tensão alimenta o circuito e, portanto, que tensão se espera obter no sensor a 20grC. Esta tensão é lida no pino A1 do microcontrolador.
R5 e o sensor NTC TH1, de 10KOhm, configuram um divisor te tensão. A tensão deste divisor é lida pelo microcontrolador no pino A7.
O pino A3 do microcontrolador gera o impulso que liga o LED de infravermelhos através do MOS-FET Q1. O microcontrolador era capaz de poder atacar o LED directamente mas, por um lado ficaria a trabalhar ao máximo e, por outro, não permitiria filtrar a alimentação no LED. Se o filtro L1 e C1 não estivesse lá, podia muito bem acontecer que a alimentação do próprio microcontrolador viesse a sofrer flutuações por causa do ligar/desligar do LED, que, ligado, consome 10mA aproximadamente. Se for preciso ligar mais um LED basta colocá-lo em série com o primeiro baixando R1 de 330R para 270R (Ohm). Atenção que o indutor L1 tem igualmente uma resistência interna a DC de 32R (neste caso até dá jeito).
Quanto ao resto, R3, R4 e C2 e C3 servem para aumentar a estabilidade em U1 (uma mania minha). R6 serve para limitar a corrente de pico à saída do microcontrolador (outra mania). R2 serve para evitar que Q1 comece a conduzir mal se ligue a alimentação ao conjunto. Acontece que o microcontrolador demora à volta de 1 a 2 segundos a arrancar e, antes de arrancar o pino 2 do Q1 ficaria completamente flutuante (nesse período os pinos do microcontrolador permanecem completamente isolados de tudo). Bastaria, por exemplo, a emissão de um telemóvel ou a proximidade de qualquer coisa eléctrica para o fazer entrar em condução o transístor Q1.
O microcontrolador comunica com o LCD através dos pinos A4 e A5 usando o protocolo I2C (apenas funciona nestes pinos). SCL é o clock, SDA é o pino por onde circulam os dados.
Os interruptores dos botões ligam às entradas D5 a D12.
Logo que tenha o software mais testado, deixo-o aqui. Aponto que ainda há bugs.
Abraço
H. Martins
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Olá.
Para resolver o problema da falta de alcance (não mais que 1.5m) foi à PtRobotics buscar alguns LEDs de 100mA para substituir o de 10mA inicialmente usado. Coloquei dois LEDs de 100mA em série, implicando a substituição de C1 para 1000uF e de R1 para 15R. Funciona de forma análoga ao comando original. Substituí igualmente L1 porque o anterior tinha uma resistência interna demasiado alta. Embora este outro tenha menos reactância, o novo valor de C1 permite que se obtenha o mesmo efeito.
Entretanto o comando original voltou a fechar-se em copas mas agora já não há problema de maior. Ainda não fiz a segunda calibração do sensor (de 30gr, a de 20 já está feita), mas isso também não é problema de monta. Se ele não ressuscitar, faço a calibração com outro termómetro.
Já corrigi uns tantos bugs sem grande importância e tudo agora parece estar bem. Ainda vou escrever umas linhas para que a iluminação do LCD se apague ao fim de algum tempo.
Entretanto vou procurando uma caixa para meter aquilo tudo.
Aqui ficai o novo esquema.
Abraço a todos,
Para resolver o problema da falta de alcance (não mais que 1.5m) foi à PtRobotics buscar alguns LEDs de 100mA para substituir o de 10mA inicialmente usado. Coloquei dois LEDs de 100mA em série, implicando a substituição de C1 para 1000uF e de R1 para 15R. Funciona de forma análoga ao comando original. Substituí igualmente L1 porque o anterior tinha uma resistência interna demasiado alta. Embora este outro tenha menos reactância, o novo valor de C1 permite que se obtenha o mesmo efeito.
Entretanto o comando original voltou a fechar-se em copas mas agora já não há problema de maior. Ainda não fiz a segunda calibração do sensor (de 30gr, a de 20 já está feita), mas isso também não é problema de monta. Se ele não ressuscitar, faço a calibração com outro termómetro.
Já corrigi uns tantos bugs sem grande importância e tudo agora parece estar bem. Ainda vou escrever umas linhas para que a iluminação do LCD se apague ao fim de algum tempo.
Entretanto vou procurando uma caixa para meter aquilo tudo.
Aqui ficai o novo esquema.
Abraço a todos,
-
HMartins
- Curioso
- Mensagens: 14
- Registado: 06 mai 2023, 19:14
- Profissão: tec. electrónica
- Localização: Sintra
- Enviou: 1 vez
- Agradecimento recebido: 1 vez
Re: Remoto Sanyo RCS-6HPS3E
Olá a todos.
Tive uma sorte dos diabos. Quando já não precisava do comando, ele fechou-se mais uma vez em copas. Retirei as pilhas, esperei um dia, voltei a colocá-las, ele arrancou uns minutos e foi-se novamente embora.
Entretanto, acrescentei mais duas funcionalidades:
- Desligar o LCD (de noite a luz é bastante forte)
- De 10 em 10 segundos, no local onde é mostrada a temperatura ambientem, aparece, durante 1 segundo, a tensão de alimentação
Esta coisa pode ser alimentada por um cabo USB vindo de uma qualquer fonte USB (vulgo carregador) mas pode também ser alimentada por um ‘power pack’. Acontece que eu tenho dois power packs e ambos se desligam ao fim de algum tempo aparentemente porque o circuito consome demasiado pouca corrente.
Eu tentei manter o código tão simples quanto me pareceu razoável.
Aqui fica o código que deu origem à coisa. Em caso de dúvida, disponham.
Atenção que se o código for aplicado a um processador mais rápido que Arduino Nano, terão que ser feitas adaptações aos timmings que geram os impulsos. É improvável que funcione em processadores mais lentos.
Não esquecer que no ambiente do IDE Arduino o ficheiro fonte aqui enviado tem que estar dentro de uma pasta com o mesmo nome (ou adaptando o nome do ficheiro ao nome da pasta).
Abraço a todos,
H. Martins
Tive uma sorte dos diabos. Quando já não precisava do comando, ele fechou-se mais uma vez em copas. Retirei as pilhas, esperei um dia, voltei a colocá-las, ele arrancou uns minutos e foi-se novamente embora.
Entretanto, acrescentei mais duas funcionalidades:
- Desligar o LCD (de noite a luz é bastante forte)
- De 10 em 10 segundos, no local onde é mostrada a temperatura ambientem, aparece, durante 1 segundo, a tensão de alimentação
Esta coisa pode ser alimentada por um cabo USB vindo de uma qualquer fonte USB (vulgo carregador) mas pode também ser alimentada por um ‘power pack’. Acontece que eu tenho dois power packs e ambos se desligam ao fim de algum tempo aparentemente porque o circuito consome demasiado pouca corrente.
Eu tentei manter o código tão simples quanto me pareceu razoável.
Aqui fica o código que deu origem à coisa. Em caso de dúvida, disponham.
Atenção que se o código for aplicado a um processador mais rápido que Arduino Nano, terão que ser feitas adaptações aos timmings que geram os impulsos. É improvável que funcione em processadores mais lentos.
Não esquecer que no ambiente do IDE Arduino o ficheiro fonte aqui enviado tem que estar dentro de uma pasta com o mesmo nome (ou adaptando o nome do ficheiro ao nome da pasta).
Abraço a todos,
H. Martins
-
MPaulo
- Faça a sua apresentação
- Mensagens: 1
- Registado: 18 set 2023, 19:52
- Profissão: Eng
- Localização: Lisboa
Re: Remoto Sanyo RCS-6HPS3E
Olá. Eu tenho igual, caso precise dos códigos. Tenho três, um avariou.
Será que o 2ghr1 é compatível?
Será que o 2ghr1 é compatível?