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
