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
