Si sus datos pasan por XBees, debe poner los módulos en modo API con caracteres de escape, dividir sus datos en paquetes lógicos y aprovechar el hecho de que en el modo API un paquete que se entrega a un XBee Llegar intacto o no llegar en absoluto. Diseñe su protocolo alrededor de la transmisión de fragmentos de 1-255 bytes, y deje que los módulos XBee se preocupen sobre cómo entregar los datos dentro de cada fragmento. No se preocupe por mantener la integridad de los paquetes individuales o las subdivisiones entre ellos. Los módulos de Digi harán un buen trabajo cuidando eso. Lo más importante de lo que debe preocuparse es el hecho de que incluso si el nodo que transmite un paquete cree que no se entregó y envía un reemplazo, el destinatario puede obtenerlo de todos modos, posiblemente incluso después de recibir el reemplazo. Las cosas pueden ser más fáciles si diseñas tu protocolo de modo que un lado sea el "maestro"; Si el maestro solicita un dato, el esclavo debe enviarlo una vez y no preocuparse por si el maestro lo recibe. Si el maestro no obtiene los datos que desea, puede solicitarlos nuevamente.
El esclavo debe asignar algún tipo de números de secuencia a los datos, y el maestro debe asignar números de secuencia a las solicitudes para que el esclavo cambie de estado. Si la solicitud del maestro es de la forma "enviar el primer elemento cuyo número de secuencia es mayor que XXX", y cada parte del elemento de datos del esclavo incluye su propio número de secuencia y el del elemento anterior (si no están numerados consecutivamente ), los paquetes que llegan tarde pueden hacer que el esclavo envíe datos de manera redundante al maestro, pero el maestro no tendrá dificultad en ignorar las consiguientes respuestas que llegan tarde. Si el esclavo recibe una solicitud de cambio de estado cuyo número de secuencia es inferior al de una solicitud anterior, debe ignorar esa solicitud, ya que fue reemplazada incluso antes de que se recibiera.