Ahhh, it is clear now… Axel, Daniel, thanks for your help.
I had tried reversing the endianess but I got caught by the order of the subfields… silly mistake, thanks for the heads up!
Eduardo
From: address@hidden [mailto:address@hidden On Behalf Of Daniel Thiele
Sent: 09 March 2011 23:15
To: address@hidden
Subject: AW: [uracoli-devel] Frame Control Field
Dear Eduardo,
the order of subfields in the zooming of Frame Control Field is (left:LSB to right:MSB), but the indices are correct. Perhaps you read it from left to right and interpreted the left most bit as MSB, but this is the LSB (index 0). Transmission starts MSB first, so the first subfield is “Source addressing mode”.
0x8841 equals to “Source addressing mode=2, dest addr mode=2, Pan compr=1, Frame Type=1”
I would suggest to swap the order of bit indices.
I hope this could help.
Best regards
Daniel
Von: address@hidden [mailto:address@hidden Im Auftrag von Eduardo Aldaz Carroll
Gesendet: Mittwoch, 9. März 2011 19:19
An: address@hidden
Betreff: [uracoli-devel] Frame Control Field
Dear all
First a disclaimer, I’m a beginner with the 802.15.4 standard.
I have successfully used the example xmpl_radio_range.c, however I have a doubt concerning the forming of the Frame Control Field as defined in the datasheet (see figure below)
In the xmpl_radio_range.c file we find:
#define FRAME_CTRL (0x8841)
rt_frame_t TxFrame = {
.fctl = FRAME_CTRL,
.pan = RT_PANID,
.dst = RT_ADDR,
.src = "">
};
I assumed 0x8841 would be the intended contents of the Frame Control Field, but it seems to me that it would result in writing a 1 in one of the reserved areas, which makes me doubt I’ve understood the purpose of that define?
What does this value actually do/configure?
Thanks
Eduardo
