Qual codificação é usada neste sinal?

Eu tenho um termômetro de piscina sem fio barato (AcuRite 617 1 ) e gostaria de interceptar os dados de temperatura no receptor e usá-los com um sistema computadorizado de registro de dados.

Convenientemente, dentro do receptor, há uma pequena placa de interrupção conectada à antena e possui pinos digitais "V", "G", "D" e "SH":

Aqui está um segmento de dados capturados do pino "D" durante uma transmissão (eles acontecem uma vez por minuto). Antes desse segmento, existem dados que parecem com taxas muito mais altas, mas acredito que possam haver ruídos - este é o começo dos dados de 1,36kHz / 680Hz.

Pesquisei um pouco no Google e não consigo encontrar uma codificação que se parece com isso, mas se eu adivinhar o que está acontecendo, eis o que estou pensando:

• os 4 ciclos iniciais de 680 Hz são para sincronizar os relógios, mas não contêm dados
• os 13 ciclos de 1,36 kHz (2x a taxa inicial) a seguir parecem ter uma de duas formas: eles caem antes do ponto médio do ciclo ou depois dele - eu assumiria que uma forma é lógica e a outra é um zero.
• depois disso, parece haver uma lacuna estranha, mas se você descontar a parte da baixa que faz parte do "1" anterior, a lacuna restante será de 735 µs, que é uma continuação (correta de fase!) do Preâmbulo de 680 Hz.

Estou olhando isso corretamente? Existe um nome para esta codificação?

Algumas notas adicionais no quadro de discussão:

• a placa está marcada como "RF211" e parece notavelmente consistente com o receptor QwikRadio de 3V de uso geral MICRF211 "que opera a 433,92 MHz" 3
• a folha de dados do MICRF211 tem a seguinte figura (com muito pouca explicação), que se parece com o que estou vendo, exceto pela onda quadrada de taxa de dados dupla em comparação com a minha captura:
  

14-02-2016 atualização: Revisitei este projeto e parece que estou conseguindo um fluxo limpo de 64 bits entre um preâmbulo de 4 ciclos e um "pós-ambar" de 1 ciclo, após o qual a placa de vídeo desliga o módulo de RF puxando ^ SH baixo (linha superior):

De acordo com o esquema "33/66% PWM" da Micrel (que não aparece em nenhum outro lugar no Google), isso é

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Então agora eu tenho que começar a manipular a temperatura para decodificar os bits. Aqui ("x") estão os bits que parecem mudar sem nenhuma mudança aparente na tela:

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

Presumo que sejam bits menos significativos ou o nível da bateria (que é mostrado apenas como "Baixo" quando cai significativamente).

15-02-2016 atualização: Estou participando do programa para dar à nova pilha "Engenharia Reversa" uma brecha no sentido de determinar o significado: /reverseengineering/12048/what-is-contained -nesta-transmissão-rf-piscina-sensor de temperatura-unidade-base-re

Micrel refere-se a ele como um esquema de PWM de 33/66%. Parece ser um protocolo bastante simples, mas ad-hoc.

PWM significa modulação por largura de pulso. Há uma página da Wikipedia que entra em mais detalhes, mas, em resumo, o PWM é onde você mantém um período fixo; portanto, aqui é o tempo da borda ascendente para a próxima borda ascendente, mas você varia a porcentagem de tempo gasto na alta alterando quando a borda em queda ocorre. Para este, você pode ver que é 33% alto para um '1' e 66% alto para um '0'.

As séries iniciais de pulsos são iguais aos tempos alto e baixo. Isso geralmente é feito para permitir que o receptor sincronize antes que os dados reais sejam recebidos.

Consulte http://www.micrel.com/_PDF/App-Notes/an-22.pdf para obter mais detalhes sobre o que eles esperam para o módulo.

Uma maneira típica de poder receber esse tipo de codificação seria inseri-la em um pino de captura de entrada de timer de um microcontrolador. Ou você pode simplesmente conectar-se a uma entrada geral e fazer uma amostra de 4-5x o período PWM. O algoritmo para decodificação não é muito difícil a partir daí.

Como alternativa, como sugerido por markt, você pode voltar ao próprio sensor de temperatura. Mas, se for um sinal de saída analógica, você precisará convertê-lo para digital e poderá ter números ligeiramente diferentes no registro da saída original.

As pessoas que eu conheço costumam chamar essa técnica de codificação de "PWM", que suponho ser uma descrição razoável.

Meu primeiro pensamento ao analisar seu fluxo de dados e supondo que você esteja adivinhando corretamente a polaridade dos bits é que é uma leitura ADC de 12 bits, primeiro LSB, com um '1' inicial como bit de início. Vou usar o LSB primeiro, porque o início do que é presumivelmente a próxima leitura mostra uma variação de bit único e é improvável que uma leitura ADC da temperatura (da piscina) varie de um segundo ou terceiro MSB nesse curto espaço de tempo.

Eu me aprofundaria um pouco mais no sistema, voltando ao que está gerando os dados (em vez de transmiti-los), ver se você consegue identificar o sensor de temperatura e procurar alguma correlação entre os dados transmitidos e a temperatura.

Quase todos os esquemas de transmissão de RF precisarão ter várias características em seus protocolos de codificação de dados. Estes incluem:

1. Preâmbulo de formato consistente usado para bloquear um receptor na frequência
2. Um indicador de pulso de sincronização para marcar o início se a indicação do quadro
3. Um método para codificar dados 1 e 0 com algum tipo de relógio codificado para recuperação de dados.

O pulso ímpar da bola que você anotou é certamente o indicador de pulso de sincronização.

A codificação de dados parece seguir o que eu vi referido como codificação de largura de pulso. Essa é uma técnica bastante comum, em que a única direção de transição segue uma frequência constante, levando a tempos de célula de bit de largura constante. Durante a célula bit, o pulso ativo é apresentado como 25% do tempo da célula bit ou 75% do tempo da célula bit. Esse esquema não é um esquema de codificação balanceada DC de pulso para pulso, como as ofertas de codificação Manchester. É uma técnica comum com a codificação de largura de pulso para fornecer equilíbrio DC dentro do protocolo de mensagens, enviando bits extras para criar um equilíbrio geral em toda a mensagem. Na sua forma mais simples, os dados são enviados duas vezes com a segunda cópia invertida logicamente.

No seu exemplo, é estranho ver dados modulados na largura do pulso ocorrendo antes do pulso de sincronização. No entanto, ainda é um esquema viável se o algoritmo de decodificação de dados for projetado para aceitar os dados recebidos com a sincronização nesta posição. É possível que a unidade esteja enviando um tipo de dados antes da sincronização e um depois. A divisão pode ser entre o endereço do sensor / dados temporários OU dados verdadeiros / dados invertidos.

Editar:

É interessante notar que quase parece que a unidade transmissora está usando um algoritmo de software diferente para formular as larguras de pulso positivas para células de dados antes do padrão de sincronização do que para a largura de pulso no e após o padrão de sincronização. Isso implica que pode haver um pedaço separado de software gerando o padrão anterior que o da parte subsequente do padrão. Essa diferença de padrão poderia implicar que a fonte de dados em cada caso exigisse tratamento diferente em termos de como foi acessada pouco a pouco. A diferença vista no diagrama de tempo pode ser simplesmente um tempo de instrução ou duas diferenças nos loops de geração de padrões.

Comecei a decodificar o Acurite 617 e aqui estão minhas observações iniciais. Posso dizer que o último byte é algum tipo de "check" e o próximo aos últimos três bytes contém a temperatura. Esses bytes também são enviados com o sétimo bit para igualar a paridade e somente a menor mordida de cada byte é usada. Eu escrevi um programa Arduino para capturar os dados e vi as seguintes mensagens / temperatura.

40 ce c0 00 00 0c 03 be
(00 0C 03) => 0C3 => 67F

40 ce c0 00 00 0c 84 39
(00 0C 04) => 0C4 => 67F

40 ce c0 00 00 0c 05 b8
(00 0C 05) => 0C5 => 67F

Outros dados / temperaturas que eu vi são:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Com isso, você poderá fazer a conversão "linha reta" (suposição).

Como não tenho um bom escopo (e o fato de os dados serem enviados uma vez por minuto), não tenho certeza do meu tempo. Vejo a sincronização HI e LO como sendo 720 usec e os bits de dados 240 e 480 usec.

Espero ter mais informações mais tarde. Eu tenho um monte deles. Assim que eles começam a vazar, eu os retiro da piscina e os seco para uso em casa. Os módulos 617 posteriores (com o parafuso fora do fundo e o anel em O) parecem durar mais tempo.

Eu fiz mais um pouco de decodificação. O último byte (check byte) torna o XOR de todos os oito bytes igual a 0FFH. Por exemplo, para "40 CE C0 00 00 8D 0C 30", 40 xou CE xou C0 xou 00 xor 00 xou 8D xou 0C xou 30 é igual a 0FF.

Além disso, reduzi a temperatura para 34F e a contagem era 10 decimal (ie, 00 00 0A) e, a 80F, a contagem era 264 decimal (ou seja, 81 00 88 ou 108H).

A partir disso, estou usando Temp (F) = 0,1811 * Count + 32.1889. Talvez eu consiga um espaço maior para obter dados melhores se houver algum erro.

Olhando para a sequência de Rob Starling em 14/02/2016:

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

Contagem = 0E4 ou 228

Temp = 73.5F