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

19

Tengo un termómetro inalámbrico para piscinas (AcuRite 617 1 ) y me gustaría interceptar la temperatura datos en el receptor y utilícelos con un sistema computarizado de registro de datos.

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

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

señalcapturadade"D" pin

He buscado un poco en Google y no puedo encontrar una codificación que se vea así, 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: o bien disminuyen antes del punto medio del ciclo o después de él: asumiría que una forma es lógica y el otro es un cero.
  • después de eso, parece haber una brecha extraña, pero si descuenta la parte de la baja que forma parte del "1" anterior, la brecha restante es de 735 µs, que es una (¡fase correcta!) continuación del preámbulo de 680 Hz.

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

Algunas notas adicionales en el panel de desglose:

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

2016-02-14Actualización:Reviséesteproyectoyparecequeobtengounatransmisiónde64bitsentreunpreámbulode4ciclosyun"postámbulo" de 1 ciclo, después de en el que el panel de visualización apaga el módulo de RF tirando ^ SH bajo (línea superior):

Segúnelesquema"33/66% PWM" de Micrel (que no aparece en ninguna otra parte de Google), eso es

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Así que ahora tengo que empezar 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).

2016-02-15 Actualización: Estoy llevando el programa a la carretera para darle un nuevo impulso a la nueva "Ingeniería inversa" al determinar el significado: enlace

    
pregunta Rob Starling

4 respuestas

8

Micrel se refiere a él como un esquema de 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 se mantiene un período fijo, por lo que aquí es el momento desde el flanco ascendente hasta el siguiente flanco ascendente, pero varía el porcentaje de tiempo pasado en el alto. Estado cambiando cuando se produce el flanco descendente. Para este, puedes ver que es 33% alto para un '1' y 66% alto para un '0'.

La serie inicial de pulsos es igual de alta y baja. Esto generalmente se hace para permitir que el receptor se sincronice antes de que se reciban los datos reales.

Consulte enlace 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 del temporizador de un microcontrolador. O bien, simplemente puede conectarse a una entrada general y hacer que muestre a 4-5 veces el período PWM. El algoritmo para decodificar no es demasiado difícil desde allí.

Como alternativa, 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 y puede tener números ligeramente diferentes en su registro de la salida original.

    
respondido por el caveman
3

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 analizar su flujo de datos, y suponiendo que está adivinando correctamente la polaridad de los bits, es que es una lectura de ADC de 12 bits, LSB primero, con un '1' inicial como bit de inicio. Primero voy a utilizar 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, volver a lo que está generando los datos (en lugar de transmitirlos), ver si se puede identificar el sensor de temperatura y buscar alguna correlación entre los datos transmitidos y la temperatura .

    
respondido por el markt
2

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 coherente utilizado para bloquear un receptor en la frecuencia
  2. Un indicador de pulso de sincronización para marcar el inicio si la indicación de trama
  3. Un método para codificar los datos 1 y 0 con algún tipo de temporización codificada para la recuperación de datos.

El pulso de bola impar que notaste es seguramente el indicador de pulso de sincronización.

La codificación de datos parece seguir lo que he visto como codificación de ancho de pulso. Esta es una técnica bastante común donde la dirección de una transición sigue una frecuencia constante que conduce a tiempos de celda de bit de ancho constante. Durante la celda de bit, el pulso activo se presenta como el 25% del tiempo de celda de bit o el 75% del tiempo de celda de bit. Este esquema no es un esquema de codificación balanceada DC pulso a pulso como las ofertas de codificación Manchester. Es una técnica común con codificación de ancho de pulso para proporcionar un balance de DC dentro del protocolo de mensaje al enviar bits adicionales para crear un balance 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 que los datos modulados por ancho de pulso se produzcan antes del pulso de sincronización. Sin embargo, aún es 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 la 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 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 de software separado que genere el patrón anterior al de la parte posterior del patrón. Esta diferencia de patrón podría implicar que la fuente de datos en cada caso requería un manejo diferente en términos de cómo se accedía bit a bit. La diferencia observada en el diagrama de tiempo podría ser simplemente una instrucción de tiempo o dos diferencias en los ciclos de generación de patrones.

    
respondido por el Michael Karas
2

Empecé a decodificar el Acurite 617 y aquí están mis observaciones iniciales. Puedo decirles que el último byte es una especie de byte de "comprobación" y el siguiente a los últimos tres bytes contiene la temperatura. Estos bytes también se envían utilizando el séptimo bit para lograr una paridad uniforme y solo se utiliza el mordisco más bajo 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 / temps que he visto son:

E2 = > 73F

F5 = > 76F

108 = > 80F (81 00 88)

109 = > 80F

Al usar 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 sincronización. 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 adelante. Tengo un montón de estos Tan pronto como empiezan a gotear, los saco de la piscina y los dejo secar para usarlos en la casa. Los últimos 617 módulos (con el tornillo de la parte inferior 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.

También, bajé la temperatura a 34F y el conteo fue de 10 decimales (i, e., 00 00 0A) y a 80F el conteo fue de 264 decimal (es decir, 81 00 88 o 108H).

A partir de esto estoy usando Temp (F) = 0.1811 * Count + 32.1889. Es posible que obtenga un intervalo mayor para obtener mejores datos si veo algún error.

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

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

    
respondido por el Ken S

Lea otras preguntas en las etiquetas