Agreed. We've struggled with this Endianness issue since the early days
of Ethernet and IEEE 802. Blame it on HDLC.
To eliminate the ambiguities, always list the bytes in transmission
order, together with a prominent note that
a) the bytes are listed in transmission order, and
b) each bytes is transmitted lsb first.
-Tom
====
On Wed, Jun 24, 2015 at 9:54 PM, Simon Duquennoy wrote:
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
