2

Context: I am reading an application note for a UWB transceiver. In it they are describing the typical message frame format, in accordance with IEEE rules. There is some wording that is confusing me and I am unsure whether I need to implement anything on the host controller, in accordance with this information.

In this application note (pg. 6 of 15)

It says

The sequence number octet is incremented modulo-256 for every frame sent, as per IEEE rules. The source and destination addresses are either 64-bit numbers programmed uniquely into each unit (during manufacture) or 16-bit addresses temporarily assigned. The 2-octet FCS is a CRC frame check sequence following the IEEE standard, (this can be generated automatically by the DW1000 IC and appended to the transmitted message)

In the IEEE standard (802.15.4-2011) (pg. 59)

It states:

5.2.1.2 Sequence Number field

The Sequence Number field specifies the sequence identifier for the frame. For a beacon frame, the Sequence Number field shall specify a BSN. For a data, acknowledgment, or MAC command frame, the Sequence Number field shall specify a DSN that is used to match an acknowledgment frame to the data or MAC command frame.

I understand the principles of modulo arithmetic and I understand (and please correct me if this is wrong) that the sequence number refers to a frame and its order within a greater sequence of frames. However, the wording "increments by modulo-256" has thrown me a little.

Does it mean that it will bit shift a single bit, within an octet, once every time a frame is sent until a pre-defined number of frames have been sent? Do I need to process this to piece the greater sequence together?

Any help is appreciated.

SamGibson
  • 17,231
  • 5
  • 37
  • 58
BitShift
  • 153
  • 8

2 Answers2

7

It just means that the number is incremented. But when it reaches the value 255 the next value will be 0.

Thus the sequence will be:
0, 1, 2, 3, .... 250, 251, 252, 253, 254, 255, 0, 1, 2, ...

You will get this behavior if you use an uint8_t ( #include <stdint.h>) and increment it:

#include <stdint.h>

uint8_t sequence_number=0;
...
   sequence_number++;
Oldfart
  • 14,212
  • 2
  • 15
  • 41
  • I see, thank you very much for this answer. Is this something that I need to then process in order, or is this something that would be handled by the radio itself for radio purposes only? – BitShift Jul 30 '18 at 09:45
  • The number is used to see if there where missing packets/frames. (I don't know what UWB uses) You expect to see the next number. If you see an increase of 2 or 3 you know some packets/frames have been lost. I have no idea what level of processing your radio does. – Oldfart Jul 30 '18 at 09:47
  • Definitely, I'll look through the rm and ds to learn more. Thanks again! – BitShift Jul 30 '18 at 09:51
  • `s/stdin\./stdint\./` – Ruslan Jul 30 '18 at 15:30
5

In addition to what Oldfart said, it means this number is maintained in a 8 bit counter. If you interpret the value of a 8 bit counter as normal unsigned binary, then you get modulo 256 automatically. 8 bits can be 0000 0000 to 1111 1111 (= 255 decimal). Incrementing 1111 1111 yields 1 0000 0000. However, the counter can't store the resulting 1 bit since it's off the end. Only the low 8 bits of the binary value are maintained, which roll over to 0000 0000.

So while modulo-256 might seem like a strange thing, it's actually fairly common as it's the result of representing a unsigned value in a 8-bit byte.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • Of course, thank you. Yes after spending a short time digesting this information, it makes quite a lot of sense to calculate a value of this nature from modulo-256. – BitShift Jul 30 '18 at 10:48
  • Whoever downvoted this, what exactly do you think is wrong? – Olin Lathrop Jul 31 '18 at 10:34