Cómo descifrar el código hexadecimal para datos de tiempo en un dispositivo de puerto serie más antiguo

Estoy usando un viejo sensor Draeger PAC III para medir las concentraciones de gas, con el objetivo de transmitir los datos de forma remota a través de Arduino. En consecuencia, no puedo usar el software propietario para generar información/datos del sistema. Aunque el sistema ha sido "retirado" por la empresa y ya no se vende/distribuye, sus técnicos no proporcionarán la hoja de datos para la comunicación en el dispositivo.

Para eludir esto, intento usar un monitor de puerto serie para leer la comunicación entre el dispositivo y la PC. La PC se comunica a través de un puerto RS-232, pero usa solo conexión a tierra y una línea Tx/Rx combinada para obtener datos del dispositivo. Para activar las comunicaciones, todos los datos escritos comienzan con un alto (01). Todos los datos leídos duplican los datos escritos y luego se agregan a los datos del dispositivo. El primer comando siempre es "iniciar comunicaciones por identificación", también conocido como los primeros 4 fragmentos de datos. Solo puedo suponer que los datos restantes comunican el tiempo, pero no entiendo cómo descifrarlo. Si se usa/necesita endian, ¿cómo puedo hacer esto? ¡Gracias de antemano!

Según los valores informados del programa propietario:

  • Hora (probablemente reloj de 24 horas): 1:13
  • Fecha (mm/dd/aaaa): 4/9/2008
  • Número de serie: ERXL-0162
  • Número de pieza: 4530011
  • Versión de software: v3.50
[03/08/2019 16:44:22] Written data (COM4)   
    01 01 01 02 00 05                                          ......           
[03/08/2019 16:44:22] Read data (COM4)  
    01 01 01 02 00 05 01 01 01 26 02 34 35 33 30 30     .........&.45300    
    31 31 20 20 20 45 52 58 4c 2d 30 31 36 32 20 20     11   ERXL-0162      
    20 20 34 35 33 30 32 37 30 76 33 2e 35 30 07 3b         4530270v3.50.;  
[03/08/2019 16:44:23] Written data (COM4)   
    01 01 01 02 00 05                                             ......            
[03/08/2019 16:44:23] Read data (COM4)  
    01 01 01 02 00 05 01 01 01 26 02 34 35 33 30 30     .........&.45300    
    31 31 20 20 20 45 52 58 4c 2d 30 31 36 32 20 20     11   ERXL-0162      
    20 20 34 35 33 30 32 37 30 76 33 2e 35 30 07 3b         4530270v3.50.;  
[03/08/2019 16:44:23] Written data (COM4)   
    01 01 02 02 00 06                                       ......              
[03/08/2019 16:44:23] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01     ..........‰(..8.    
    02                                                  .                   
[03/08/2019 16:44:23] - Close port COM4

Editar: dos marcas de tiempo más según lo solicitado

Time: 1:02 4/9/2008
[03/08/2019 20:04:30] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 02 28 00   ..........‰(..(.  
    e7                                                ç                 
Time: 1:04 4/9/2008
[03/08/2019 20:05:50] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 04 00 00   ..........‰(....  
    c1                                                Á
Estoy un poco confundido por la pregunta, siempre se usa endianness (en comunicaciones de más de 8 bits). La pregunta debería ser "¿cómo determinar qué endianness se usa?" ¿bien?
Tal cosa como "combinado TX/RX RS232" no existe. ¿Qué tipo de cable de monitor usas? Hay aquellos que permiten que el lado TX del host se "sangre" en el lado RX del host y creo que eso es lo que estamos viendo aquí. Funciona de alguna manera si la comunicación es siempre semidúplex pero añade una complicación extra a la hora de analizar el protocolo. Utilice un monitor RS232 adecuado con dos cables de monitor, uno para cada TX.
La pregunta en un sentido más general es, ¿cómo obtengo una marca de tiempo que coincida con el valor informado de esta línea "01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01". No sé mucho acerca de cómo se comunica el dispositivo, ¡así que cualquier cosa que ayude a ese objetivo sería apreciada!
¿Qué te hace pensar que el dispositivo integrado tiene algún conocimiento de la fecha o la hora? ¿Y por qué te importa? ¿Dónde están las lecturas reales de concentración de gas? Si realmente cree que una marca de tiempo significativa está codificada, capture dos intercambios donde difieren y vea cómo los datos son diferentes...
Janka, en el puerto serie solo se usan los pines 1, 3 y 4 y luego se empujan a través de algún tipo de circuito inversor en la estación de carga para que el dispositivo obtenga una señal siempre alta de 2.95v (como lo ve el dispositivo) para apagar y en. Digo esto no para agravar el problema, sino para tratar de ayudar a explicar el posible esquema de comunicación que necesita el bit de inicio y probablemente un bit final, ya que el dispositivo solo ve una línea de comunicación.
Chris, el software patentado tiene un botón de actualización para mostrar la hora actual en el dispositivo. Quiero saber la hora porque esta es una forma de obtener valores conocidos que coincidan entre la lectura en serie y el dispositivo. He intentado comparar varios puntos de tiempo, pero no he podido dar sentido a la tercera a la última línea.
Actualice su pregunta con datos para dos marcas de tiempo y muestre las marcas de tiempo impresas correspondientes. ¿Sus datos son realmente de 2008 o se transfirieron, posiblemente dando una pista sobre la codificación? También considere construir una versión falsa con un emulador Arduino o Port o un gancho/depurador API y cambie uno o dos bytes para ver qué hace.
Sí, la fecha es de 2008, esa fue la última vez que se usaron. Probaré esa idea del emulador de puerto.

Respuestas (1)

Aquí hay una hipótesis de la parte de tiempo de los datos:

  • De la captura de datos original:01 0d 38 01 02

    Sabemos que la hora se mostró como 01:13. Ese es el 01 0dy creo que el siguiente byte 38es probablemente el valor de los segundos, pero eso no se muestra.

    Estoy considerando que los últimos 2 bytes en cada "paquete" enviado desde el dispositivo pueden ser una suma de verificación (es un enfoque común). Eso explica por qué los últimos 2 bytes de los primeros dos paquetes son iguales ( 07 3b), ya que los datos en ambos paquetes son los mismos. Luego, el siguiente paquete (el primer ejemplo de datos y tiempo) tiene valores diferentes para los últimos 2 bytes.

  • De una de las capturas adicionales de fecha/hora:01 02 28 00 e7

    Siguiendo mi primera interpretación anterior, sabiendo que el tiempo que se muestra es 01:02, eso es (como era de esperar) 01 02y también 40 segundos (hexadecimal 28) con una 00 e7suma de verificación para todo el "paquete".

Aquí hay una hipótesis de alto nivel de la decodificación de paquetes:

Usando el paquete de fecha/hora original como ejemplo:

01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01 02

El comando original es el líder 01 01 02 02 00 06donde está el comando real 01 01 02, luego el número de bytes que siguen (incluida la suma de verificación) es 02y luego hay una suma de verificación para ese "comando" - 00 06.

La respuesta comienza con los siguientes bytes: 01 01 02(quizás nos dice a qué comando responde, para que el maestro/PC verifique la cordura). Luego están 07los siguientes bytes (incluida la suma de comprobación) - 89 28 01 0d 38 01 02.

Como ya sugerí, sospecho que los valores 01 0d 38son hh mm ssen hexadecimal. El seguimiento 01 02es una suma de comprobación.

Eso significa que la fecha real solo se puede codificar en los dos bytes restantes 89 28en ese paquete de datos.

Mi hipótesis en esta etapa es que esos dos bytes 89 28pueden ser un valor de contador de días little-endian, lo que significa que realmente podría ser 28 89(hex), es decir, 10377 días (decimales). Si eso fuera cierto, entonces el 9 de abril de 2008 - 10377 días parece ser el 11 de noviembre de 1979. No es una "época" irrazonable.

(Eso es mucho más razonable que si trato los bytes como big-endian, convierto 89 28hexadecimal a decimal (35112) y resto esa cantidad de días desde el 9 de abril de 2008, lo que parece sugerir un inicio de contador de días (época) del 21 de febrero de 1912, eso es mucho menos sensato para una pieza de equipo moderno.)

Si puede esperar a que la fecha (es decir, el día) cambie en el reloj interno del dispositivo, entonces podemos ver si el valor de la fecha realmente cambia en esos bytes de respuesta de a , lo que confirmaría que es 89 28un 8a 28contador de días little-endian. valor enviado desde el dispositivo, e interpretado para convertirse en una fecha de visualización en formato normal, por el software de PC.

O podría intentar alimentar un conjunto modificado de datos al software de la PC y cambiar esos dos bytes que creo que codifican la fecha, y ver qué muestra el software de la PC. El problema es la suma de comprobación (lo que creo que es) en cada paquete. Eso hace que sea difícil (probablemente imposible) enviar datos modificados al software de la PC, hasta que tenga el algoritmo de suma de verificación y pueda modificar correctamente los bytes de suma de verificación, cuando modifique los bytes de datos.

Encontrar el algoritmo de suma de comprobación resultó más fácil de lo que esperaba.

  • Los últimos 2 bytes de cada paquete, tanto los paquetes de datos "enviados" de 6 bytes como los paquetes de datos "recibidos" más largos (pero solo los datos reales "recibidos", que comienzan con el 7.º byte en esa captura de datos mixtos enviados + recibidos ) son de hecho una suma de comprobación .

  • Es literalmente la suma de todos los bytes (pero excluyendo la suma de comprobación, obviamente) en formato big-endian (es decir, MSB y luego LSB).

    (Todos los ejemplos a continuación están en hexadecimal).

  • Por ejemplo, en los paquetes de datos enviados, es fácil ver esto:

    01 01 01 02 00 05=> 01+ 01+ 01+ 02= 0005
    01 01 02 02 00 06=> 01+ 01+ 02+ 02=0006

    En el primer paquete de fecha y hora (ignorando los 6 bytes de "datos enviados" al principio):

    01 01 02 07 89 28 01 0d 38 01 02=> 01+ 01+ 02+ 07+ 89+ 28+ 01+ 0d+ 38=0102

Con esta información, ahora es posible crear un paquete de datos modificado y enviarlo al software de la PC, con una suma de verificación válida, para ver cómo se muestran esos datos. Como se mencionó anteriormente, los bytes que se deben concentrar en cambiar (para ayudarlo a comprender su significado y confirmar o negar mi hipótesis de que son un contador de días) son los que contienen 89 28los paquetes de fecha y hora reales.

En efecto. Pero ahora realmente necesitamos ver otra fecha. Como los valores actuales no parecen tener sentido desglosados ​​o como días totales desde un punto de partida lógico, ya sea big o little endian. Idealmente otro año. O para comenzar a alimentar el programa con valores falsos con los bytes anteriores cambiados por un conteo. ¿Cargar los datos en un Arduino y sustituirlos? ¿O simplemente conectarse a otra PC o puerto? Probablemente ni siquiera necesite tener el tonto serial medio dúplex siempre que se vea igual en el software.
Chris: creo que tener la fecha y la hora de un día diferente sería casi tan útil como esperar otro año, pero veremos qué datos podemos obtener del OP. Ahora confirmé y realicé la ingeniería inversa de la suma de verificación de 2 bytes (es literalmente una suma). Entonces, como usted dice, usar un Arduino o similar para enviar datos sustitutos a la PC ahora es una opción, ya que se puede calcular y enviar la suma de verificación correcta para los datos manipulados. PD Gracias por pedirle al OP los ejemplos adicionales de la información de fecha y hora, que ayudaron a identificar qué bytes no cambiaron, lo que sugiere que podrían ser los bytes relacionados con la fecha.
¡Gracias! Sí, tienes razón en todas las cuentas. El tiempo es exactamente como usted dice, siendo la suma de verificación los últimos 2 bytes. También tenía razón en el dinero de los bytes que contienen datos relacionados con la fecha. Lo descubrí con mucho jugueteo, pero la respuesta simple es 89 (137) es el día con mod32 aplicado. El año se divide en 'subaños' por lo que un aumento de 2 por cada 1 año. ¡Gracias a todos por su ayuda, realmente lo aprecio! Los mantendré informados con cualquier dilema para los otros datos.
@ Research8472 - ¡De nada! Gracias por la actualización y por avanzar en la interpretación de esos dos "bytes de fecha". ¡Buena suerte con el proyecto!
Cómo descifrar el código hexadecimal para datos de tiempo en un dispositivo de puerto serie más antiguo
RespuestasAquíPolítica de privacidad1y, 0v