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
