telecommand_primaryheader_adder frame_sequence_number overflow error

[kurtulmehtap]

Code execution stops when frame_sequence_number is larger than FF hex.
Here is the message:
thread_body_wrapper :error: ERROR thread[thread-per-block[11]: <block telecommand_primaryheader_adder(1)>]: IntegerError: Error in path (building) -> frame_sequence_number
number 256 is out of range (min=0, max=255)

At:
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(1384): _build
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(2774): _build
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(2263): _build
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(5258): _build
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(464): build_stream
/home/rftest/.local/lib/python3.10/site-packages/construct/core.py(452): build
/usr/local/lib/python3.10/dist-packages/satellites/ccsds/telecommand_primaryheader_adder.py(61): handle_msg

[daniestevez]

Looking at https://github.com/daniestevez/gr-satellites/blob/main/python/ccsds/telecommand_primaryheader_adder.py#L58, the problem is that the frame sequence number is incremented without taking modulo 256. At the moment the CCSDS web server is down, so I can't get the TC Space Data Link Blue Book to confirm, but I would imagine that the frame sequence number field is 8-bits. Therefore, the code should do self.frame_sequence_number = (self.frame_sequence_number + 1). Also, it would be more reasonable to increment the frame_sequence_number after it is used for this frame rather than before. Can you test these changes and submit a pull request?

[daniestevez]

I could now access the Blue Book and indeed the Frame Sequence Number is 8 bits.