Jonathan, Simon, After the discussion on the format order of ieee802.15.4, I believe now the format that proposed by Simon is right.
The text I copied from IEEE802.15.4 didn't cover the case of 2.4GHz O-QPSK radio chip, which will transmit the data by bits group, not bit by bit. Thanks Thomas for clarifying this! Sorry if I made some trouble on this issue! Tengfei On Thu, Jun 25, 2015 at 6:41 AM, Thomas Watteyne <[email protected] > wrote: > +1 > Thanks > > On Thu, Jun 25, 2015 at 12:40 AM, Jonathan Hui <[email protected]> > wrote: > >> There are a number of examples in Annex C in IEEE 802.15.4-2011 that >> express IEEE 802.15.4 frames as a a sequence of hex bytes. For example, >> Section C.2.1.1 has the following text: >> >> Secured beacon frame: >> 08 D0 84 21 43 01 00 00 00 00 48 DE AC || 02 05 00 00 00 || 55 CF 00 >> 00 51 52 53 54 22 3B C1 EC 84 1A B5 53. >> >> It doesn't take much to figure out that: >> 1) The bytes are listed in little-endian order from left to right >> 2) Within each byte, the bits are such that 0x01 represents bit 0 being >> set to 1 and 0x80 represents bit 7 being set to 1. >> >> We should follow the convention already used in IEEE 802.15.4 specs. >> >> -- >> Jonathan Hui >> >> >> On Wed, Jun 24, 2015 at 3:28 PM, Thomas Watteyne < >> [email protected]> wrote: >> >>> To make sure we're on the same page, below are two examples of the >>> bit-and-byte ordering in the IEEE802.15.4e-2011 and IEEE802.15.4e-2012 >>> standard, as I read them. >>> Please indicate whether this is what you understood. >>> @JonathanHui, I have IEEE802.15.4-2011 and IEEE802,15,4e-2012 in front >>> of me. Which Annexes are your referring to that contain such examples? >>> Thomas >>> >>> ---- >>> >>> *Example 1*. Frame Control Field >>> >>> Fig 36 "Format of the Frame Control field" of IEEE802.15.4e-2012 (p 59) >>> indicates it is composed of the following field. In *blue* example >>> values for an unencrypted ACK frame. >>> >>> - [bit 0-2] Frame Type *(value for unencrypted ACK: 0b010==2==ACK)* >>> - [bit 3] Security Enabled *(value for unencrypted ACK: 0b0)* >>> - [bit 4] Frame Pending *(value for unencrypted ACK: 0b0)* >>> - [bit 5] ACK request *(value for unencrypted ACK: 0b0)* >>> - [bit 6] PAN ID compression *(value for unencrypted ACK: 0b1)* >>> - [bit 7] reserved *(value for unencrypted ACK: 0b0)* >>> - [bit 8] Sequence Number Suppression *(value for unencrypted >>> ACK: 0b0)* >>> - [bit 9] IE list present *(value for unencrypted ACK: 0b1)* >>> - [bits 10-11] Dest. Address Mode *(value for unencrypted >>> ACK: 0b11==3==64-bit)* >>> - [bits 12-13] Frame Version *(value for unencrypted ACK: 0b10==2)* >>> - [bits 14-15] Source Address Mode *(value for unencrypted >>> ACK: 0b11==3==64-bit)* >>> >>> These fields are organized in the following 2-byte "structure": >>> >>> xxxx xxxx xxxx xxxx >>> 010 = Frame Type (3 bits, value 0b010) >>> 0 = Security Enabled (1 bit, value 0b0) >>> 0 = Frame Pending (1 bit, value 0b0) >>> 0 = ACK request (1 bit, value 0b0) >>> 1 = PAN ID compression (1 bit, value 0b1) >>> 0 = reserved (1 bit, value 0b0) >>> 0 = Sequence Number Suppression (1 bit, value 0b0) >>> 1 = IE list present (1 bit, value 0b1) >>> 11 = Dest. Address Mode` (2 bits, value 0b11) >>> 10 = Frame Version (2 bits, value 0b10) >>> 11 = Source Address Mode (2 bits, value 0b11) >>> ------------------- >>> 1110 1110 0100 0010 = 0xee42 >>> >>> Because this 2-byte field is sent "little endian", what you will see in >>> the air is 0x42ee. >>> >>> >>> >>> *Example 2*. header of a "ACK/NACK Time-Correction" IE >>> >>> Format of a header IE (IEEE802.15.4-2012, p.57) is below. In *blue* example >>> values for a "ACK/NACK Time-Correction" IE. >>> >>> >>> - [bits 0-6] Length *(value for "ACK/NACK Time-Correction" IE: 2)* >>> - [bits 7-14] Element ID *(value for "ACK/NACK Time-Correction" IE: >>> 0x1e, see IEEE802.15.4-2012, Table 4b, p.81)* >>> - [bit 15] type *(value for "ACK/NACK Time-Correction" IE: 0, as >>> it's a header IE)* >>> >>> These fields are organized in the following 2-byte "structure": >>> >>> xxxx xxxx xxxx xxxx >>> 000 0010 = Length (7 bits, value 2) >>> 000 1111 0 = Element ID (8 bits, value 0x1e) >>> 0 = Type (1 bit, value 0) >>> ------------------- >>> 0000 1111 0000 0010 = 0x0f02 >>> >>> Because this 2-byte field is sent "little endian", what you will see in >>> the air is 0x020f. >>> >>> >>> On Wed, Jun 24, 2015 at 11:12 PM, Tom Phinney <[email protected]> >>> wrote: >>> >>>> Agreed. We've struggled with this Endianness issue since the early days >>>> of Ethernet and IEEE 802. Blame it on HDLC. >>>> >>>> To eliminate the ambiguities, always list the bytes in transmission >>>> order, together with a prominent note that >>>> a) the bytes are listed in transmission order, and >>>> b) each bytes is transmitted lsb first. >>>> >>>> -Tom >>>> ==== >>>> >>>> On Wed, Jun 24, 2015 at 9:54 PM, Simon Duquennoy wrote: >>>> >>>> Hello, >>>>> >>>>> I believe what we want is the frame content as a series of bytes (not >>>>> bits, >>>>> symbols or 16-bit words) in the order in which they are sent and >>>>> received. >>>>> Here the second byte, in binary form starting with least significant >>>>> bit, >>>>> is: 11111100 (as mentioned in your mail). That's unambiguously 0x3f (== >>>>> 0b00111111, == 63). >>>>> >>>>> Best regards, >>>>> Simon >>>>> >>>>> >>>>> On Wed, Jun 24, 2015 at 5:55 PM, Xavier Vilajosana < >>>>> [email protected]> wrote: >>>>> >>>>> Sorry option 2 was incorrect.. too fast copy&paste >>>>>> >>>>>> 2) Another option is to convert to hex by considering the MSb first >>>>>> within >>>>>> the octet >>>>>> MSb LSb >>>>>> 0000 0000 1111 1100 >>>>>> 0x0 0x0 0xF 0xC >>>>>> >>>>>> 0x00 0xFC >>>>>> >>>>>> regards, >>>>>> X >>>>>> >>>>>> 2015-06-24 17:53 GMT+02:00 Xavier Vilajosana < >>>>>> [email protected]>: >>>>>> >>>>>> Hi Tengfei, >>>>>>> this is confusing. Lets make sure this is the right way. >>>>>>> >>>>>>> For me the problem is how do we transform an HEX WORD to 16bits >>>>>>> >>>>>>> for example can be interpreted from left to right as LSB and from MSB >>>>>>> being right to left when transforming the binary representation to >>>>>>> the Hex >>>>>>> representation >>>>>>> >>>>>>> Taking this IE as example >>>>>>> >>>>>>> 1) Header IE: list termination: >>>>>>> len = 0 as bits 0-6 >>>>>>> id = 0x7e as bits 7-14 >>>>>>> type = 0 as bit 15 >>>>>>> header = len + id << 7 which gives 0x3f00 >>>>>>> >>>>>>> if we consider that E in 0x7E is the least significative 4bits and >>>>>>> least >>>>>>> significative bits are placed first (most left) we have: >>>>>>> >>>>>>> 7 zeros 0x7e type 0 >>>>>>> 0000000011111100 >>>>>>> >>>>>>> 1) When transforming this to HEX we consider the least significative >>>>>>> bits to >>>>>>> go first from left to right. So >>>>>>> LSb MSb >>>>>>> 0000 0000 1111 1100 >>>>>>> 0x0 0x0 0xF 0x3 >>>>>>> >>>>>>> 0x00 0x3F >>>>>>> >>>>>>> 2) Another option is to convert to hex by considering the MSb first >>>>>>> within the octet >>>>>>> MSb LSb >>>>>>> 0000 0000 1111 1100 >>>>>>> 0x0 0x0 0xF 0x3 >>>>>>> >>>>>>> 0x00 0xFC >>>>>>> >>>>>>> >>>>>>> What is the right option? I am not sure but seems more reasonable to >>>>>>> be 1) >>>>>>> >>>>>>> Maybe those annexes in 15.4 can help to find the right answer. >>>>>>> >>>>>>> regards, >>>>>>> Xavi >>>>>>> >>>>>>> >>>>>>> 2015-06-23 17:33 GMT+02:00 Tengfei Chang <[email protected]>: >>>>>>> >>>>>>> Jonathan , >>>>>>>> >>>>>>>> Could you pointed which annexes or a page I can refer to? Did it say >>>>>>>> that is an example that transmitted by PHY? >>>>>>>> >>>>>>>> Tengfei >>>>>>>> >>>>>>>> On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui <[email protected] >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> As mentioned in my previous mail, the annexes in the IEEE 802.15.4 >>>>>>>>> specification use the convention I outlined. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang < >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>> The hex value is correct. But I don't think this is the way to we >>>>>>>>>> should follow to order the data. IEEE802.15.4 said we should >>>>>>>>>> transmit the >>>>>>>>>> first bit, so we should follow this order. >>>>>>>>>> >>>>>>>>>> Tengfei >>>>>>>>>> >>>>>>>>>> On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui < >>>>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Tengfei, >>>>>>>>>>> >>>>>>>>>>> Hex values are typically written in MSB order - this is different >>>>>>>>>>> from IEEE 802.15.4 which writes bit strings out in LSB order. >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> IEEE 802.15.4: 10000000 >>>>>>>>>>> is equivalent to >>>>>>>>>>> Hex: 0x01 >>>>>>>>>>> >>>>>>>>>>> So, w.r.t. the bytes being discussed: >>>>>>>>>>> IEEE 802.15.4: 00000000 11111100 >>>>>>>>>>> is equivalent to >>>>>>>>>>> Hex: 0x00 0x3f >>>>>>>>>>> >>>>>>>>>>> See the Annexes in IEEE 802.15.4 to see many more examples of hex >>>>>>>>>>> representations of MAC frames. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jonathan Hui >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> I don't think 0x00 0x3F is right. >>>>>>>>>>>> >>>>>>>>>>>> In section 5.2 of IEEE802.15.4 standard, the second paragraph >>>>>>>>>>>> said : >>>>>>>>>>>> >>>>>>>>>>>> The frames in the MAC sublayer are described as a sequence of >>>>>>>>>>>> fields >>>>>>>>>>>> in a specific order. All frame formats >>>>>>>>>>>> in this subclause are depicted in the order in which they are >>>>>>>>>>>> transmitted by the PHY, from left to right, where >>>>>>>>>>>> the leftmost bit is transmitted first in time. Bits within each >>>>>>>>>>>> field are numbered from 0 (leftmost and least >>>>>>>>>>>> significant) to k – 1 (rightmost and most significant), where >>>>>>>>>>>> the >>>>>>>>>>>> length of the field is k bits. Fields that are >>>>>>>>>>>> longer than a single octet are sent to the PHY in the order >>>>>>>>>>>> from the >>>>>>>>>>>> octet containing the lowest numbered bits >>>>>>>>>>>> to the octet containing the highest numbered bits. >>>>>>>>>>>> >>>>>>>>>>>> When transmitting the data, we should make sure b0 goest first. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *For termination header IE * >>>>>>>>>>>> *1) Header IE: list termination:* >>>>>>>>>>>> *len = 0 as bits 0-6* >>>>>>>>>>>> *id = 0x7e as bits 7-14* >>>>>>>>>>>> *type = 0 as bit 15* >>>>>>>>>>>> *header = len + id << 7 which gives 0x3f00* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When transmitting the 00 3F, the bit transmitted by PHT is bit >>>>>>>>>>>> 7, >>>>>>>>>>>> not b0. >>>>>>>>>>>> >>>>>>>>>>>> => in the document, it is currently 00 FC: 0000000 01111110 0, >>>>>>>>>>>> >>>>>>>>>>>> The first 7 bits goes is len field bit0-bit6: 0000000, then >>>>>>>>>>>> goes >>>>>>>>>>>> ID: b7-b14 7E 01111110, then type bit 15 0. >>>>>>>>>>>> >>>>>>>>>>>> Which is Correct. >>>>>>>>>>>> >>>>>>>>>>>> Tengfei >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 23, 2015 at 12:14 AM, Xavier Vilajosana < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for your comments. I might have messed bits up with >>>>>>>>>>>>> endianness. I will recheck again. Note that we read them from >>>>>>>>>>>>> left to right >>>>>>>>>>>>> being the leftmost the least significative bit and the right >>>>>>>>>>>>> most the most >>>>>>>>>>>>> significative bit. >>>>>>>>>>>>> >>>>>>>>>>>>> in this case and taking the first element you mention >>>>>>>>>>>>> >>>>>>>>>>>>> 7 zeros 0x7e type 0 >>>>>>>>>>>>> 0000000011111100 >>>>>>>>>>>>> >>>>>>>>>>>>> if I convert this to hex where the least significant bit is the >>>>>>>>>>>>> leftmost it leads to >>>>>>>>>>>>> 0x00 0x3F >>>>>>>>>>>>> >>>>>>>>>>>>> as you indicate. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks so much for your comment! >>>>>>>>>>>>> X >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-06-22 17:48 GMT+02:00 Jonathan Hui <[email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>> As someone who has implemented and deployed product that use >>>>>>>>>>>>>> IEEE >>>>>>>>>>>>>> 802.15.4e-2012 Information Elements, I agree with Simon's >>>>>>>>>>>>>> encodings. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Jonathan Hui >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy < >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe the example IE headers (for header/payload/MLME >>>>>>>>>>>>>>> IEs) >>>>>>>>>>>>>>> are wrong in section 10.1 of the minimal draft. Some >>>>>>>>>>>>>>> endianness confusion I >>>>>>>>>>>>>>> guess: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) Header IE: list termination: >>>>>>>>>>>>>>> len = 0 as bits 0-6 >>>>>>>>>>>>>>> id = 0x7e as bits 7-14 >>>>>>>>>>>>>>> type = 0 as bit 15 >>>>>>>>>>>>>>> header = len + id << 7 which gives 0x3f00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> => with little endian encoding we get: 00 3F >>>>>>>>>>>>>>> => in the document, it is currently 00 FC >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) Payload IE Header (MLME): 1A 88 seems correct >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) MLME-SubIE TSCH Synchronization: >>>>>>>>>>>>>>> len = 6 as bits 0-7 >>>>>>>>>>>>>>> id = 0x1a as bits 8-14 >>>>>>>>>>>>>>> type = 0 as bit 15 >>>>>>>>>>>>>>> header = len + id << 8 which gives 0x1a06 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> => with little endian encoding we get: 06 1A >>>>>>>>>>>>>>> => in the document, it is currently 06 34 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) MLME-SubIE TSCH Timeslot: >>>>>>>>>>>>>>> len = 1 as bits 0-7 >>>>>>>>>>>>>>> id = 0x1c as bits 8-14 >>>>>>>>>>>>>>> type = 0 as bit 15 >>>>>>>>>>>>>>> header = len + id << 8 which gives 0x1c01 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> => with little endian encoding we get: 01 1C >>>>>>>>>>>>>>> => in the document, it is currently 01 38 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and so on.. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My apologies if it is me misreading something. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One other minor remark: in section 10, when describing byte >>>>>>>>>>>>>>> order, I would suggest referring to "little-endian ordering" >>>>>>>>>>>>>>> rather than >>>>>>>>>>>>>>> "LSB format". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 6tisch mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 6tisch mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 6tisch mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
