Datos indescifrables en el monitor serie

Navega tus respuestas
1

Ya tengo listo el producto electrónico de trabajo. Estoy aplicando ingeniería inversa en él. El módulo WiFi está conectado a un microcontrolador a través de UART (RX & TX). La aplicación de Android envía el comando a WiFi y el microcontrolador funciona de acuerdo con el comando. He adjuntado un cable USB a TTL en RX y TX, también comando tierra del módulo WiFi. El cable está conectado al monitor serie en la PC. Cuando la aplicación envía datos a WiFi, el monitor de serie muestra un valor indescifrable. He comprobado todos los baudios posibles. En lugar de un cable USB a TTL, también usé el módulo Bluetooth HC05. Pero muestra datos indescifrables. ¿Cómo puedo obtener los valores legibles en mi monitor de serie? ¿Necesito desconectar el microcontrolador de WiFi?

No se utiliza RS232 en todo el diseño.

Las dos primeras imágenes tienen datos similares pero con diferente velocidad de transmisión. Los datos de la primera imagen se establecen en 4800 y el segundo en 9600 sin paridad, datos de 8 bits, el bit de parada 1. "0D" es solo un comando de ingreso (para facilitar la lectura).

    
pregunta Embedded Geek

2 respuestas

5

Parece que 4800 bps es la velocidad correcta. Los datos de 9600 son obviamente (!) Los mismos datos muestreados dos veces más a menudo. Aquí es cómo se hace ese análisis:

Aquí están los datos de 9600 baudios como aparecerían como una secuencia de bits. Los datos se escriben primero en LSB, y he representado los bits de inicio y finalización como minúsculas o (cero) y i (uno), respectivamente. 

|06      ||3F      ||60      ||0C      ||FE      ||80      ||60      ||CC      |
o01100000io11111100io00000110io00110000io01111111io00000001io00000110io00110011i

Aquí están los datos de 4800 baudios, extendidos a la misma escala de tiempo: 

| 71               | | 24              || 0F              | | A4               |
o 1 0 0 0  1 1 1 0 io 0 0 1 0  0 1 0 0 io 1 1 1 1 0 0 0 0 i o 0 0 1 0  0 1 0 1 i

Tenga en cuenta que cada bit en el flujo inferior corresponde a dos bits del mismo valor en el flujo superior. Tenga en cuenta que cuando se ejecuta a 9600, su escucha telefónica se vuelve a sincronizar en una transición de alto a bajo, por lo que hay un poco de "pendiente" alrededor de los límites de bytes a esa velocidad.

También está claro que una velocidad aún más lenta NO sería correcta: hay datos únicos aislados y ceros en los datos de 4800, lo que significa que esta es la tasa de muestreo mínima para estos datos.

    
respondido por el Dave Tweed
4

El primer screengrab hexadecimal (a 4800 baudios) parece prometedor:

Lo que estás viendo es un mensaje de 4 bytes. El mensaje no está en ASCII , por lo que no es legible para los humanos. El mensaje está codificado en binario (o hexadecimal, si lo prefiere), por lo que necesitamos verlo e interpretarlo de esa manera. El binario generalmente produce mensajes más cortos que ASCII.

Figura 1. La tabla ASCII puede ayudar en algunos casos. 'OD', que aparece en tus mensajes de pantalla, es el carácter 'CR' (retorno de carro)

  • Cada línea comienza con el carácter ASCII 'q' (0h71). Probablemente sea un preámbulo.
  • El segundo carácter en las respuestas que ha publicado es ASCII '$' (0h23) o '#' (0h24).
  • El tercer carácter se fija como 0h0F.
  • El cuarto carácter parece ser una suma de comprobación. Puede confirmarlo utilizando la calculadora de su computadora en el modo Programador . Seleccione el tipo de datos 'byte' (para truncar a 8 bits):
    • 0h71 + 0h24 + 0h0F = 0hA4.
    • 0h71 + 0h23 + 0h0F = 0hA3.

No has proporcionado ninguna información sobre lo que hiciste para generar los símbolos $ y # , por lo que no puedo ayudarte más en este momento.

    
respondido por el Transistor

Lea otras preguntas en las etiquetas

El convertidor Buck funcionó en más de 1000 ciclos de arranque / parada con alimentación de la fuente de alimentación de CC regulada, falló con la batería de li-ion Problema con los conectores molex