El receptor Xbee genera caracteres de basura cuando no transfiere datos

Recientemente tuve un problema similar con un dispositivo XBee que recibió una secuencia inesperada de seis caracteres mientras no recibía nada mientras estaba en modo transparente. No es demasiado fácil rastrear esto porque el "modo de tono" de diagnóstico no se menciona en la hoja de datos, pero después de las discusiones con el soporte de Digi, una vez que me di cuenta del nombre que rastreé en este artículo de la base de conocimientos:

enlace

Estaba usando un Sparkfun XBee Explorer Regulated y, como se mencionó, la línea RSSI se conectó a un LED para conectar a tierra. línea baja que hizo que entrara en ese modo. Quité la resistencia de límite R4 conectada en serie con el pin 6 y resolví el problema. Pero, por supuesto, si está utilizando un producto diferente, los designadores de referencia serán diferentes, así que verifique los esquemas de la placa en particular que está usando.

No dice cómo enviar datos al dispositivo XBee. Si envía datos directamente a la línea serie del dispositivo XBee usando un hiperterminal, es probable que no funcione porque su dispositivo está configurado en modo API (lo que puedo decir porque cada paquete en modo API comienza con 0x7e , que es ~ en ASCII) .

Para que se envíen sus datos, necesita usar una biblioteca que maneje la comunicación del modo API xbee en su idioma favorito. He escrito una biblioteca de este tipo en mientras volvía a C ++ (lo que puede no ser el mejor , ese es más nuevo y ciertamente mejor), o en python o ...

Otra solución sería reconfigurar su XBee usando X-CTU para usar el firmware del comando AT para que pueda enviar datos fácilmente usando un terminal simple. Aunque el conjunto de comandos AT es menos completo que el conjunto de comandos del modo API.

Aunque si sí se comunica en modo API con su XBee, y aún ve ese tipo de basura, entonces es porque puede haber ruido en su señal y todos los paquetes que vienen se desplazan unos pocos bytes que hacen imposible leer desde. Verifique los esquemas, el cableado, etc. Eso me sucedió con un chip que tiene un pin de tierra roto que hizo un contacto falso si el dispositivo se está moviendo / tocando cuando se transmite. Los bytes aleatorios se leyeron en medio de un datagrama, haciendo que el CRC fallara, y todos los siguientes datagramas son imposibles de leer ...

HTH

Puede ser mucho más fácil de lo que he dicho inmediatamente a continuación si Xbee admite la transmisión y recepción de datos "sin problemas", pero si no es así, a continuación es probablemente la línea de fondo.

Es probable que no transmitas un cuadro de datos reconocible. Necesita formatear sus datos (empaquetarlos) en un marco con un encabezado y muy probablemente un campo de verificación de error. Entonces es posible que tenga que enviar un preámbulo (antes del marco) que permita al receptor reconocer que un marco está a punto de comenzar y alinearse correctamente. Puede enviar un marco de longitud fija o puede incrustar la longitud del marco en un encabezado (generalmente inmediatamente después del preámbulo). Ahora, su receptor sabrá cuándo comienzan los datos y cuándo terminan. Consigue escribiendo algún código. Si la trama tiene un error (bits de verificación de error), entonces deberá desarrollar un sistema de mecanismo de reintento.

Alternativamente, y no soy un experto en Xbee, busque un modo de operación que lo haga por usted. Un montón de transceptores de RF ofrecen modos de comunicación "sin interrupciones" y el paquete se ha reducido para usted: lea la hoja de datos para averiguar qué ofrece xbee en esta área.