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
