Quale codifica viene utilizzata in questo segnale?

Ho un termometro per piscina wireless economico (AcuRite 617 1 ) e vorrei intercettare i dati di temperatura sul ricevitore e usarli con un sistema di registrazione dei dati computerizzato.

Convenientemente, all'interno del ricevitore è presente una piccola scheda breakout che è collegata all'antenna e ha pin digitali "V", "G", "D" e "SH":

Ecco un segmento di dati acquisiti dal pin "D" durante una trasmissione (questi si verificano una volta al minuto). Prima di questo segmento, ci sono quelli che sembrano essere dati di frequenza molto più elevata, ma credo che potrebbe essere rumore - questo è l'inizio dei dati di 1,36 kHz / 680 Hz.

Ho cercato su Google un po 'e non riesco a trovare una codifica simile a questa, ma se dovessi indovinare cosa sta succedendo, ecco cosa sto pensando:

• i 4 cicli iniziali di 680 Hz servono per sincronizzare gli orologi ma non contengono dati
• i 13 cicli di 1,36 kHz (il doppio della frequenza iniziale) che seguono sembrano avere una delle due forme: cadono in basso prima del punto medio del ciclo o dopo - suppongo che una forma sia logica e l'altra è uno zero.
• dopo ciò, sembra esserci uno strano divario, ma se si scontra la parte del minimo che fa parte del precedente "1", il divario rimanente è 735 µs, che è una continuazione (corretta in fase!) del Preambolo 680 Hz.

Sto guardando questo correttamente? C'è un nome per questa codifica?

Alcune ulteriori note sulla scheda di approfondimento:

• la scheda è marcata "RF211" e ha un aspetto straordinariamente coerente con il ricevitore 3w QwikRadio MICRF211 "3V per uso generale che funziona a 433,92 MHz" 3
• la scheda tecnica MICRF211 ha la seguente figura (con pochissime spiegazioni), che assomiglia in modo allettante a quello che sto vedendo, tranne per l'onda quadra a doppia velocità di dati rispetto alla mia acquisizione:
  

14/02/2016 Aggiornamento: ho rivisitato questo progetto e sembra che stia ottenendo un flusso pulito a 64 bit tra un preambolo a 4 cicli e un "postamble" a 1 ciclo, dopo di che il tabellone spegne il modulo RF di tirando ^ SH basso (linea superiore):

Secondo lo schema "33/66% PWM" di Micrel (che non appare da nessun'altra parte su Google), questo è vero

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Quindi ora devo iniziare a manipolare la temperatura per decodificare i bit. Qui ("x") sono i bit che sembrano cambiare senza alcun apparente cambiamento nel display:

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

Presumo che questi siano bit meno significativi o livello della batteria (che viene visualizzato come "Basso" solo quando diminuisce in modo significativo).

15/02/2016 Aggiornamento: sto portando lo spettacolo sulla strada per dare al nuovo stack "Reverse Engineering" uno scambio per determinare il significato: /reverseengineering/12048/what-is-contained -questa trasmissione -in-rf-pool-temperatura-sensore-base-unità-re

Micrel si riferisce ad esso come uno schema PWM 33/66%. Sembra essere un protocollo abbastanza semplice, ma ad hoc.

PWM è l'acronimo di modulazione di larghezza di impulso. C'è una pagina di Wikipedia che va più in dettaglio, ma in breve, PWM è dove mantieni un periodo fisso, quindi qui è il tempo dal fronte di salita al fronte di salita successivo, ma tu vari la percentuale di tempo trascorso in alto stato cambiando quando si verifica il fronte di discesa. Per questo, puoi vedere che è alto del 33% per uno '1' e alto del 66% per uno '0'.

Le serie iniziali di impulsi sono uguali per i tempi alti e bassi. Questo di solito viene fatto per consentire al ricevitore di sincronizzarsi prima di ricevere i dati effettivi.

Vedi http://www.micrel.com/_PDF/App-Notes/an-22.pdf per qualche dettaglio in più su cosa si aspettano dal modulo.

Un modo tipico per essere in grado di ricevere questo tipo di codifica sarebbe quello di inserirlo in un pin di acquisizione con ingresso timer di un microcontrollore. Oppure, puoi semplicemente collegarti a un input generale e farlo campionare a 4-5 volte il periodo PWM. L'algoritmo per la decodifica non è troppo difficile da lì.

In alternativa, come suggerito da markt, è possibile tornare al sensore di temperatura stesso. Ma, se si tratta di un segnale di uscita analogico, dovrai convertirlo in digitale e potresti avere numeri leggermente diversi nella tua registrazione rispetto all'uscita originale.

Le persone che conosco di solito chiamano quella tecnica di codifica "PWM", che suppongo sia una descrizione ragionevole.

Il mio primo pensiero, guardando il tuo flusso di dati, e supponendo che tu stia indovinando correttamente la polarità dei bit, è che si tratta di una lettura ADC a 12 bit, prima LSB, con un '1' iniziale come bit di partenza. Vado prima con LSB perché l'inizio di quella che è presumibilmente la prossima lettura mostra una variazione a bit singolo ed è improbabile che una lettura ADC della temperatura (pool) varierebbe di un secondo o terzo MSB in quel breve lasso di tempo.

Vorrei scavare un po 'più a fondo nel sistema, tornando a tutto ciò che sta generando i dati (invece di trasmetterlo), vedere se è possibile identificare il sensore di temperatura e cercare una correlazione tra i dati trasmessi e la temperatura.

Quasi tutti gli schemi di trasmissione RF dovranno avere diverse caratteristiche nei loro protocolli di codifica dei dati. Questi includono:

1. Preambolo di formato coerente utilizzato per bloccare un ricevitore sulla frequenza
2. Un indicatore di impulso di sincronizzazione per contrassegnare l'inizio se l'indicazione del frame
3. Un metodo per codificare i dati 1 e 0 con una sorta di clock codificato per il recupero dei dati.

L'impulso di palla dispari che hai notato è sicuramente l'indicatore di impulso di sincronizzazione.

La codifica dei dati sembra seguire quella che ho visto indicata come codifica della larghezza degli impulsi. Questa è una tecnica abbastanza comune in cui una direzione di transizione segue una frequenza costante che porta a tempi di celle di bit a larghezza costante. Durante la cella di bit l'impulso attivo viene presentato come 25% del tempo della cella di bit o 75% del tempo della cella di bit. Questo schema non è uno schema di codifica bilanciata DC da impulso a impulso come offre la codifica Manchester. È una tecnica comune con codifica a larghezza di impulso per fornire il bilanciamento CC nel protocollo del messaggio inviando bit aggiuntivi per creare un bilancio complessivo nell'intero messaggio. Nella sua forma più semplice i dati vengono inviati due volte con la seconda copia logicamente invertita.

Nel tuo esempio è strano vedere i dati modulati della larghezza di impulso prima dell'impulso di sincronizzazione. Tuttavia è ancora uno schema fattibile se l'algoritmo di decodifica dei dati è progettato per accettare i dati ricevuti con la sincronizzazione in questa posizione. È possibile che l'unità stia inviando un tipo di dati prima della sincronizzazione e uno dopo. La suddivisione potrebbe essere tra l'indirizzo del sensore / dati temporanei O dati reali / dati invertiti.

Modificare:

È interessante notare che sembra quasi che l'unità trasmettitore stia utilizzando un algoritmo software diverso per formulare le larghezze d'impulso positive per le celle di dati prima del pattern di sincronizzazione che per l'ampiezza dell'impulso in corrispondenza e dopo il pattern di sincronizzazione. Ciò implica che potrebbe esserci un pezzo separato di software che genera il modello precedente rispetto a quello per la parte successiva del modello. Questa differenza di modello potrebbe implicare che l'origine dati in ogni caso richiedesse una gestione diversa in termini di accesso a bit a bit. La differenza osservata nel diagramma di temporizzazione potrebbe essere semplicemente una temporizzazione dell'istruzione o due differenze nei cicli di generazione del modello.

Ho iniziato a decodificare l'Acurite 617 ed ecco le mie osservazioni iniziali. Posso dirti che l'ultimo byte è una sorta di byte "check" e che gli ultimi tre byte contengono la temperatura. Questi byte vengono inoltre inviati utilizzando il 7 ° bit per rendere uniforme la parità e viene utilizzato solo il nibble inferiore di ciascun byte. Ho scritto un programma Arduino per acquisire i dati e ho visto i seguenti messaggi / temperature.

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

Altri dati / temp che ho visto sono:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Usando questo dovresti essere in grado di fare la conversione "linea retta" (presupposto).

Dal momento che non ho una buona portata (e il fatto che i dati vengano inviati una volta al minuto) non sono sicuro del mio tempismo. Vedo la sincronizzazione HI e LO come 720 usec e i bit di dati 240 e 480 usec.

Spero di avere più informazioni in seguito. Ne ho un sacco. Non appena iniziano a perdere, li rimuovo dalla piscina e li asciugo per l'uso in casa. I successivi 617 moduli (con il fondo avvitato e l'O-ring) sembrano durare più a lungo.

Ho fatto qualche altra decodifica. L'ultimo byte (check byte) rende lo XOR di tutti e otto i byte uguale a 0FFH. Ad esempio per "40 CE C0 00 00 8D 0C 30", 40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 è uguale a 0FF.

Inoltre, ho portato la temperatura a 34F e il conteggio era di 10 decimali (cioè, 00 00 0A) e a 80F il conteggio era di 264 decimali (cioè 81 00 88 o 108H).

Da questo sto usando Temp (F) = 0.1811 * Count + 32.1889. Potrei ottenere un intervallo maggiore per ottenere dati migliori se vedo qualche errore.

Guardando la corda di Rob Starling il 14-02-2016:

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

XOR = FF

Count = 0E4 o 228

Temp = 73.5F