¿Qué codificación se usa en esta señal?

Tengo un termómetro inalámbrico de piscina económico (AcuRite 617 1 ) y me gustaría interceptar los datos de temperatura en el receptor y usarlos con un sistema de registro de datos computarizado.

Convenientemente, dentro del receptor hay una pequeña placa de conexión que está conectada a la antena y tiene pines digitales "V", "G", "D" y "SH":

Aquí hay un segmento de datos capturados del pin "D" durante una transmisión (estos ocurren una vez por minuto). Antes de este segmento, hay lo que parece ser una tasa de datos mucho más alta, pero creo que podría ser ruido: este es el comienzo de los datos de 1.36kHz / 680Hz.

Busqué en Google un poco y no puedo encontrar una codificación que se parezca a esto, pero si tuviera que adivinar qué está pasando, esto es lo que estoy pensando:

• los 4 ciclos iniciales de 680 Hz son para sincronizar los relojes pero no contienen datos
• Los 13 ciclos de 1.36 kHz (2 veces la velocidad inicial) que siguen parecen tener una de dos formas: caen bajos antes del punto medio del ciclo o después de él; supongo que una forma es lógica y la otra es un cero
• después de eso, parece haber una brecha extraña, pero si descontas la parte del mínimo que forma parte del "1" anterior, entonces la brecha restante es de 735 µs, que es una continuación (¡fase correcta!) Preámbulo de 680 Hz.

¿Estoy mirando esto correctamente? ¿Hay un nombre para esta codificación?

Algunas notas adicionales sobre el tablero de trabajo:

• la placa está marcada como "RF211" y se ve notablemente consistente con el receptor QwikRadio 3V de propósito general MICRF211 "que opera a 433.92MHz" 3
• la hoja de datos MICRF211 tiene la siguiente figura (con muy poca explicación), que se ve tentadoramente como lo que estoy viendo, excepto por la onda cuadrada de doble tasa de datos en comparación con mi captura:
  

Actualización del 14/02/2016: He revisado este proyecto y parece que estoy obteniendo un flujo limpio de 64 bits entre un preámbulo de 4 ciclos y un "postamble" de 1 ciclo, después de lo cual la pantalla apaga el módulo RF tirando ^ SH bajo (línea superior):

Según el esquema "33/66% PWM" de Micrel (que no aparece en ningún otro lugar en Google), eso es

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Así que ahora tengo que comenzar a manipular la temperatura para decodificar los bits. Aquí ("x") están los bits que parecen cambiar sin ningún cambio aparente en la pantalla:

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

Supongo que estos son bits menos significativos o nivel de batería (que solo se muestra como "Bajo" cuando cae significativamente).

Actualización del 15/02/2016: Estoy tomando el show en el camino para darle una nueva oportunidad al nuevo intercambio de "Ingeniería inversa" al determinar el significado: /reverseengineering/12048/what-is-contained -en-esta-transmisión-rf-piscina-sensor-temperatura-base-unidad-re

Micrel se refiere a él como un esquema PWM de 33/66%. Parece ser un protocolo bastante simple, pero ad-hoc.

PWM significa modulación de ancho de pulso. Hay una página de Wikipedia que entra en más detalles, pero en resumen, PWM es donde mantiene un período fijo, por lo que aquí es el tiempo desde el borde ascendente hasta el siguiente borde ascendente, pero varía el porcentaje de tiempo pasado en el estado cambiando cuando se produce el borde descendente. Para este, puede ver que tiene un 33% de alto para un '1' y un 66% de alto para un '0'.

La serie inicial de pulsos es igual de tiempos altos y bajos. Esto generalmente se hace para permitir que el receptor se sincronice antes de recibir los datos reales.

Consulte http://www.micrel.com/_PDF/App-Notes/an-22.pdf para obtener más detalles sobre lo que esperan del módulo.

Una forma típica de poder recibir este tipo de codificación sería ingresar esto en un pin de captura de entrada de temporizador de un microcontrolador. O simplemente puede conectarse a una entrada general y hacer que muestree a 4-5 veces el período PWM. El algoritmo para decodificar no es demasiado difícil a partir de ahí.

Alternativamente, como lo sugiere markt, puede volver al sensor de temperatura. Pero, si se trata de una señal de salida analógica, deberá convertirla a digital usted mismo y puede tener números ligeramente diferentes en su registro de la salida original.

Las personas que conozco suelen llamar a esa técnica de codificación "PWM", que supongo que es una descripción razonable.

Mi primer pensamiento al mirar su flujo de datos, y suponer que está adivinando correctamente la polaridad de los bits, es que es una lectura ADC de 12 bits, LSB primero, con un '1' inicial como bit de inicio. Primero voy con LSB porque el comienzo de lo que presumiblemente es la siguiente lectura muestra una variación de un solo bit y es poco probable que una lectura de ADC de la temperatura (de la piscina) varíe en un segundo o tercer MSB en ese corto período de tiempo.

Me gustaría profundizar un poco más en el sistema, volviendo a lo que sea que esté generando los datos (en lugar de transmitirlos), ver si puede identificar el sensor de temperatura y buscar alguna correlación entre los datos transmitidos y la temperatura.

Casi todos los esquemas de transmisión de RF necesitarán tener varias características en sus protocolos de codificación de datos. Estos incluirían:

1. Preámbulo de formato consistente utilizado para bloquear un receptor en frecuencia
2. Un indicador de pulso de sincronización para marcar el inicio si la indicación de cuadro
3. Un método para codificar datos de 1 y 0 con algún tipo de reloj codificado para la recuperación de datos.

El extraño pulso de bola que notó es seguramente el indicador de pulso de sincronización.

La codificación de datos parece seguir lo que he visto referido como codificación de ancho de pulso. Esta es una técnica bastante común en la que la dirección de transición sigue una frecuencia constante que conduce a tiempos de celda de bit de ancho constante. Durante la celda de bits, el pulso activo se presenta como el 25% del tiempo de la celda de bits o el 75% del tiempo de la celda de bits. Este esquema no es un esquema de codificación balanceada de pulso a pulso DC como las ofertas de codificación Manchester. Es una técnica común con codificación de ancho de pulso para proporcionar equilibrio de CC dentro del protocolo de mensaje mediante el envío de bits adicionales para crear un equilibrio general en todo el mensaje. En su forma más simple, los datos se envían dos veces con la segunda copia invertida lógicamente.

En su ejemplo, es extraño ver datos modulados de ancho de pulso antes del pulso de sincronización. Sin embargo, sigue siendo un esquema factible si el algoritmo de decodificación de datos está diseñado para aceptar los datos recibidos con la sincronización en esta posición. Es posible que la unidad esté enviando un tipo de datos antes de la sincronización y uno después. La división podría ser entre dirección del sensor / datos temporales O datos verdaderos / datos invertidos.

Editar:

Es interesante observar que casi parece que la unidad transmisora ​​está utilizando un algoritmo de software diferente para formular los anchos de pulso positivos para las celdas de datos antes del patrón de sincronización que para el ancho de pulso en y después del patrón de sincronización. Esto implica que puede haber un trozo separado de software que genera el patrón anterior que el de la parte posterior del patrón. Esta diferencia de patrón podría implicar que la fuente de datos en cada caso requirió un manejo diferente en términos de cómo se accedió poco a poco. La diferencia observada en el diagrama de temporización podría ser simplemente una temporización de instrucción o dos diferencias en los bucles de generación de patrones.

Comencé a decodificar el Acurite 617 y aquí están mis observaciones iniciales. Puedo decirle que el último byte es una especie de "cheque" y los siguientes tres bytes contienen la temperatura. Estos bytes también se envían con el uso del séptimo bit para hacer una paridad uniforme y solo se utiliza el mordisco inferior de cada byte. He escrito un programa Arduino para capturar los datos y he visto los siguientes mensajes / 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

Otros datos / temperaturas que he visto son:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Con esto, debería poder hacer la conversión de "línea recta" (suposición).

Dado que no tengo un buen alcance (y el hecho de que los datos se envían una vez por minuto) no estoy seguro de mi momento. Veo la sincronización HI y LO como 720 usec y los bits de datos 240 y 480 usec.

Espero tener más información más tarde. Tengo un montón de estos. Tan pronto como comienzan a gotear, los quito de la piscina y los seco para usarlos en la casa. Los últimos módulos 617 (con la parte inferior del tornillo y la junta tórica) parecen durar más.

Hice un poco más de decodificación. El último byte (check byte) hace que el XOR de los ocho bytes sea igual a 0FFH. Por ejemplo para "40 CE C0 00 00 8D 0C 30", 40 xo CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 es igual a 0FF.

Además, bajé la temperatura a 34F y el recuento fue de 10 decimales (es decir, 00 00 0A) y a 80F el recuento fue de 264 decimales (es decir, 81 00 88 o 108H).

De esto estoy usando Temp (F) = 0.1811 * Count + 32.1889. Podría obtener un lapso mayor para obtener mejores datos si veo algún error.

Mirando la cadena de Rob Starling el 14/02/2016:

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

XOR = FF

Cuenta = 0E4 o 228

Temp = 73.5F