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
