802.15.4 frames vs Digi API frames, Al fin lo entiendo!!!!!!

Probablemente lo que explico en este artículo será tratado por muchas personas como una obviedad, es uno de esos temas en los que estás atascado durante varios días. Al final, siempre, cuando encuentras la solución era evidente.

El caso es que como os contaba logré poner en marcha el AVR Studio con el AZ Raven de Atmel, a la primera, podía ver los paquetes de la red. El día que lo puse en marcha me contenté con ver la actividad en la red, líneas de texto de colores con direcciónes de origen, de destino y payloads.

Como ya comenté estamos intentando hacer cosas con los módulos de Digi, me he leido cientos y cientos de páginas de información técnica de sus módulos, había llegado incluso a entender su API y casi a memorizar el formato de sus frames.

En el AVR studio el formato del frame que leía de la red Zigbee seguía el siguiente esquema:

Formato de Frame IEEE 802.15.4

Basicamente leía los datos de la MAC sublayer, el frame control, el número de secuencia, la Address info (red de origen, nodo de origen, red de destino, nodo de destino) y el Payload (una colección de bytes en hexadecimal no interpretable por seres humanos). Todos los frames de MAC que no llevan payload son perfectamente interpretables, de eso se encarga el AVR Studio, agrupando los bytes en columnas, pintándolod de diferentes colores, etc.

Mi problema vino a la hora de interpretar el payload, esperaba que fuera un fragmento del XBee API frame, este fué mi gran error, suponer que el Frame del APi de Xbee tenía algo que ver con lo que viajaba por el aire, el formato es el siguiente:

Formato del XBee API frame

 Si os fijais no tiene demasiado que ver, el API frame empieza por un carácter fijo (la tilde), le sigue la longitud, El Frame data y un checksum.

La conclusión es que tu en una radio de Digi que forme parte de una red le envías el API frame por la UART, la radio de Digi lo convierte internamente en un Frame 802.15.4 y lo lanza por el aire, otra radio de Digi en la misma red lee el frame 802.15.4 y (si tiene que sacarlo por la UART), lo saca en el formato de la API de Digi.

Todo esto está muy bien para los comandos propios del fabricante, para la interoperabilidad con otros fabricantes el secreto parece estar en el Explicit Transmit API Frame (0x11), que es el tipo de frame con el que se envían los comandos ZCL, los de los perfiles públicos, etc.

Aún así me gustaría conocer la transformación que se hace el microprocesador de la radio para convertir un Explicit Transmit API Frame en el paquete 802.15.4, trabajando con dispositivos de Digi  en ambos extremos no es necesario, porque el dispositivo de destino se encarga de hacer la transpormación inversa, por lo que lo que llega es predecible, pero ¿qué pasa si el coordinador no lleva una radio de Digi?

En todo caso me siento liberado solo por haber deducido lo que pasa aunque no tenga la solución al 100%, incluso siendo consciente de que todo esto es una pura deducción, agradeceré a cualquier persona que me corrija o que me confirme.