XBee deja caer paquetes y la tasa de datos real es más baja de lo esperado

Estoy transmitiendo continuamente a 9600 bps usando las configuraciones predeterminadas para mis XBees XB24-B. La comunicación es unidireccional, el transmisor está conectado a la UART ATMega328 y el receptor está conectado a la PC a través de USB (FTDI). Aquí está la velocidad de datos real para un programa dado:

  • Conexión por cable (sin XBee): 7694 bps
  • desde el enrutador ZNET 2.5/dispositivo final AT al coordinador ZNET 2.5 AT: 6800 bps (algunos paquetes perdidos)
  • del coordinador ZNET 2.5 AT al enrutador/dispositivo final ZNET 2.5 AT: 0356 bps (muchos paquetes perdidos)
  • desde el enrutador Zigbee/dispositivo final AT al coordinador Zigbee AT: 0000 bps (no funciona)
  • desde el Coordinador Zigbee AT al Enrutador Zigbee/Dispositivo final AT: 0328 bps (muchos paquetes perdidos)

¿Porqué es eso? ¿Hay algo que pueda hacer para mejorar estas tarifas?

Editar Para tasas de baudios más altas (115200) obtengo tasas de caída de paquetes aún peores:

  • Conexión por cable (sin XBee): 94200 bps
  • usando XBee XB24-B ZNet 2.5: 27900 bps

Editar Si hago que el Coordinador se dirija al dispositivo final, entonces la tasa de caída de paquetes cae a los niveles normales (6800 bps), lo cual no es ideal pero es mejor que el escenario anterior

hay alguien con un problema similar en Digi Forum
pero crucé allí de todos modos

Respuestas (3)

Puede [reducir a cero los paquetes caídos][1] asignando la dirección de destino correcta antes de iniciar la transmisión.

Se informó que la página vinculada era un sitio de ataque de malware.
Sí, lamentablemente el sitio original ya no existe.

¿Cuál es la intensidad de la señal y la velocidad del enlace inalámbrico? Consulte los documentos de la API de XBee, debería poder acceder a esta información. Que antenas estas usando?

La velocidad de datos sin procesar de Zigbee es de solo 250 kbit/seg en la banda de 2,4 Ghz y es un protocolo de sobrecarga muy alto. Con una intensidad de señal casi perfecta y el cifrado habilitado, solo debe esperar un rendimiento máximo de datos de ~ 20-25 kbit / seg sin personalizar la pila, un poco más sin el cifrado. El protocolo de Zigbee realmente solo admite el envío de datos que caben en un solo paquete, que en mi cabeza es algo así como 100 bytes. Si está enviando un flujo de datos, la capa de aplicación tiene que dividir esos datos en paquetes e incluir información adicional en el espacio de datos del paquete para que pueda volver a ensamblarse. Este proceso puede ser bastante lento y reducir aún más el rendimiento de datos.

La pila digimesh de Digi es un poco más rápida, ya que reduce la sobrecarga y permite paquetes más grandes.

No estoy seguro de cuál es su aplicación final prevista aquí, pero Zigbee no está diseñado para la transmisión de datos. Sirve para enviar pequeños bits de información, lecturas de sensores, instrucciones, etc. que caben en un solo paquete. Es muy posible que haya elegido el protocolo incorrecto para su aplicación.

Estoy transmitiendo audio. ¿Hay algún protocolo más adecuado que utilice el mismo hardware? ¿Qué protocolo recomiendas? ¿Bluetooth?
Si aún no es audio digital, use FM. Si puede encontrar un transceptor prefabricado con el ancho de banda correcto, entonces es fácil.
@Jader: ¿Cómo ibas a transmitir audio a 9600 bps? 1.2Kbps es demasiado lento. Si desea permanecer en el ámbito digital por alguna razón, Bluetooth tiene interfaces PCM diseñadas para la transmisión de audio.
@Nick No transmitiré audio a esas velocidades, solo estaba tratando de resolver un problema a la vez. Mi preocupación ahora es optimizar el XBee. Voy a buscar en Bluetooth, gracias!
absolutamente nunca, nunca, nunca, nunca use zigbee para transmitir audio o cualquier cosa que sea crítica en tiempo o rendimiento.

ACTUALIZACIÓN: Con la reciente confirmación de que el Zigbee no está hecho para la transmisión de datos, sugeriría tirarlo a la basura y comprar un mejor transceptor con más funcionalidad, más rendimiento y alrededor de 1/4 del precio .

Recomiendo encarecidamente utilizar el control de flujo si es posible para abordar los paquetes perdidos. Lo más probable es que, en períodos de tiempo pequeños pero significativos, cuando un dispositivo está procesando, no está mirando sus pines UART y, por lo tanto, pierde bits/bytes y puede colgar las cosas. Al implementar el control de flujo de hardware (pines RTS y CTS), cada dispositivo puede decirle al otro cuándo está listo o no para recibir más datos.

Una vez que conecte el control de flujo, creo que logrará el mayor rendimiento que está buscando =)

Trabajo con dispositivos Bluetooth OBD que vinculan mi aplicación de Android a las redes del vehículo, por lo que trabajo bastante con conexión inalámbrica/Bluetooth.

Mi MCU no tiene control de flujo incorporado, así que tendré que implementarlo.
el control de flujo no resolverá los problemas con el rendimiento en zigbee, nunca fue diseñado para transmitir datos.
Actualicé mi respuesta. Uso el dispositivo al que me vinculé y es muy fácil trabajar con él.
¿Te das cuenta de que bluetooth y zigbee son protocolos muy diferentes? Si necesita zigbee bluetooth no hace el trabajo. De un dispositivo a otro por bluetooth, perfecto. Para un conjunto de esclavos y un amo, sí. Para una red de malla con muchos nodos, bluetoth no funcionará.
XBee deja caer paquetes y la tasa de datos real es más baja de lo esperado
RespuestasAquíPolítica de privacidad1y, 0v