Packet structure??

[Rusty105]

Hey everyone, I am trying to understand how the openlRSng packs the packets for transmission. Is the packet structure documented anywhere? Or can someone point me to the code where it happens?

Thanks

[mikeller]

@Rusty105: https://github.com/openLRSng/openLRSng/blob/2c5d3fc7970fe91caef852a409be46666c58beb8/openLRSng/TX.h#L1055

[Rusty105]

Ah, thank you.

[gibbi]

are u maybe wondering about the phylayer? .. i once disected the actual phy for university

[Rusty105]

I was probably going to dissect it as you did, but I'll use your chart as a starting point,

Thanks

[jelle737]

are u maybe wondering about the phylayer? .. i once disected the actual phy for university

Maybe a bit out of way on the topic but still fairly related:

How easy is it to have a package become valid if only half op a package is received? I guess there are 3 things that have to be valid for a package to be used by the RX, the FRM has to detect a preamble, a correct CRC and the atmel decrypts the right bindcode/header. I don'r really know how void data looks like, would it be something like turning off the TX mid-package, and would that be read by the RFM/RX as '0'?

Is what I write above actually possible?

[gibbi]

the checksum is 16 bit so after syncword and preamle are detected but something else is messed up the chance of the CRC beeing valid by accident is 1 in 65536 ..

[jelle737]

the checksum is 16 bit so after syncword and preamle are detected but something else is messed up the chance of the CRC beeing valid by accident is 1 in 65536 ..

You make a valid point. And it seems like that CCITT CRC should be foolproof. However this page shows it's solvable in blocks using just a table and '0' remains '0', although there is more going on (like the inverting and XOR'ing.

From the RFM22 datasheet it seems like the FIFO write pointer for receiving packets is returned to the beginning of an invalid package when it's detected, so the next received packet can be written there. However I could not pinpoint from the datasheet if reading the FIFO receive memory would work. I did find that the register 03h D0 (icrcerror) and D1 (ipkvalid) should mention if a packet gave a crc error (and be discarded?) or if a packet is valid (and should be read). In the existing code of openLRSng that memory is periodically read but the content is discarded/not checked.

[gibbi]

packages are written to the fifo as soon as a valid syncword has been detected. It has to be like that because the 64 byte is all the memory the tranceiver has, and it can receive much more. Since the crc is in the end the data has to be in the fifo before the valid package is beeing read.

openlrs packages are small so we could get away with only ever read the buffer when a complete valid package is in the fifo. this limits us to 64byte packages but makes handeling much easier. (we only check one interrupt). Periodically reading enables higher packetsizes as the tranceiver has long forgotten the beginning of a 128byte package when it realizes it is valid.

[jelle737]

So openLRSng waits until a complete valid package is in fifo memory? (you say could, so it might be that we don't do that and do read it periodically). Could you also point me to that one interrupt in the code? Is it a physical line being triggered or is it a register value being read? Edit: I think I found it here https://github.com/openLRSng/openLRSng/blob/master/openLRSng/hardware.h#L918 Thx for helping me out here, it's interesting to dig through the code/FRM part for me.

[gibbi]

rfm.h:210 sets up the receiver to interupt should a package be valid.. only when that happens the fifo get read (rfm.h:199). This is the <64byte mode that i described above.

[jelle737]

rfm.h:216 sets up the receiver to interupt should a package be valid.. only when that happens the fifo get read (rfm.h:199). This is the <64byte mode that i described above.

Just also found how the nIRQ line interrupts are enabled to trigger the output. Could it be an idea to instead of read out the fifo directy, doing everything else with that package, and clearing the interrupt by reading (and discarding) the 03h to clear the interrupt status. To instead actually do read the 03h status, verify it's content having all correct values (no crc error for ex) and then reading the fifo memory?

Actually on a crc error the write pointer to the fifo memory is moved to it's original location, it's a little unclear how that actually works, as in the datasheet it's shown that multiple messages can be in the memory. Is there also a read pointer and is the memory like a ring? Or is the content shifted out of the memory when being read? Is there a way to verify it's empty? Since we expect to read a certain length message, can this ever become wrong aligned? TL;DR: From going through some relevant code only one message can be received at once as "the rxon bit will be cleared if ipkvalid occurs and the rxmpk bit is not set." (datasheet quote). So that's what the resetting and setting is for after receiving each package.