Estoy tratando de aplicar ingeniería inversa a una comunicación en serie entre microcontroladores (1 dispositivo y 1 microcontrolador en una placa). Una MCU valida la otra MCU y quiero descifrar la validación e imitar la MCU validada. Quiero averiguar qué protocolo se está utilizando para dar sentido a los datos. Capturé la comunicación con un analizador lógico y aquí hay una captura de pantalla de PulseView:
PulseView tiene una función de decodificación, pero no sé por dónde empezar. La comunicación ocurre a través de 1 solo cable. Pero no estoy seguro de si el protocolo es "de un solo cable". ¿Existen métodos estándar conocidos para identificar un protocolo de comunicación desconocido? ¿O tengo que identificarlo simplemente mirándolo?
Escribí un script para convertir los datos en el tiempo necesario para cambiar de un estado a otro (de mayor a menor o de menor a mayor) para comparar mediciones repetidas y la ausencia de la MCU validada. Cada vez que los patrones se ven ligeramente diferentes. Hubiera sido genial saber decodificar esto en una matriz de bytes o para lo que sea.
El primer período bajo largo de cada ciclo es a veces de 90 μs, a veces de 30 μs. Cada ciclo tiene 14 interruptores en total. Los largos períodos altos entre ciclos pueden diferir en longitud (~270-330 μs).
PD: el tiempo mínimo requerido para un cambio es de 30 μs, como se ve en la tercera fila de la imagen (120 μs = 4 estados).
¡Gracias!
Editar: Aquí hay ejemplos de señales, que no obedecen la regla general.
Edit2: Distribución de períodos altos entre ciclos:
Edición 3: en la primera fase (ampliada en la fila superior), hay 4 cuadros que comienzan con 90 μs de baja, seguidos de 23 cuadros que comienzan con 30 μs de baja y finalmente un cuadro que comienza con 90 μs de baja nuevamente.
Edit4: Aquí está el archivo de sesión sigrok .
Dada la cantidad de alternancias, sospecho que se trata de algún tipo de codificación de línea inusual. Creo que necesitaríamos ver más primeros planos de cada cuadro (lo que llamas un "ciclo") para adivinar. Mientras tanto, aquí hay algunos consejos para descifrar la codificación.
Las codificaciones de línea comunes, como NRZ y Manchester, representan bits como transiciones de nivel, no como niveles en sí mismos. En algunas codificaciones (como Manchester), la dirección de la transición es significativa:
En otros (como NRZ), la presencia o ausencia de una transición es significativa.
A veces hay dos transiciones por tiempo de bit, a veces solo una. El artículo de código de línea en Wikipedia tiene mucha más información con ejemplos de varias codificaciones. Las implementaciones de protocolos asincrónicos a menudo usan relleno de bits (por ejemplo, CAN y USB), pero eso no parece estar presente aquí. El relleno de bits generalmente se realiza después de una ejecución de ~ 6 bits, pero no veo ninguna ejecución de más de 3-4 bits en sus datos.
El hecho de que siempre veas 14 transiciones por cuadro parece significativo, pero no estoy seguro de cómo interpretarlo. Parece que hay tiempos de 15 bits por cuadro, por lo que si uno es un bit de inicio, tendría 14 tiempos de bits de datos. En una codificación de estilo Manchester, serían 7 bits, que podrían contener un carácter ASCII.
alguna realización en hardware simple puede ser compatible con un UART tal vez con paridad después de correlacionar y sincronizar con patrones repetitivos.
Aquí hay un estándar no necesariamente de Nikon
https://www.basecamelectronics.com/files/SimpleBGC_2_6_Serial_Protocol_Specification.pdf
preámbulo Todos los 1 están inactivos Luego 00 1010 1010 1010 Sincronización de reloj 33.0kHz
1111 1111 1111 ignorar.
xxxx xxxx informe esto para cada secuencia.
Repetir.
Utilice el reloj de 30 us y la muestra central sincronizadas Ignore la fluctuación en el histograma pero corrija el eje x en /10. Parece ser 30us no 300us.
Los picos de +40 -60 son causados por la distorsión de retardo del grupo de canales en diferentes patrones de datos llamados Interferencia entre símbolos (ISI) que se puede evitar pero no es necesario para esta ruta corta y estable. Podría hacer una conferencia de 3 horas sobre este tema solo sobre cómo identificar las fuentes de error de señal y cómo se corrige para alta velocidad.
Tony Estuardo EE75
Saren Tasciyán
Tony Estuardo EE75
W5VO
Saren Tasciyán
Adán Haun
Saren Tasciyán
Tony Estuardo EE75
Saren Tasciyán
Saren Tasciyán
Tony Estuardo EE75
Tony Estuardo EE75
Saren Tasciyán
jsotola
Saren Tasciyán
jsotola
jsotola
Saren Tasciyán
jsotola