LR1110 and max packet size?

[cobraPA]

Hi all,

I'm working with LR1110 hardware/firmware and doing a lot of testing and learning about the hardware. I'm having some trouble with firmware sending and receiving using the LR1110 hardware, so started testing with the pingpong example from RadioLib and wondered what the max sizes should be for successfully transmitted and received Lora packets.

My initial testing was to run the pingpong example, setup for my hardware, and get it to work. Then I tried sending longer strings than the default 'Hello World!'. My understanding is the max packet should be in the area of 255 chars (depending on Lora settings), but I am seeing failures around 50 chars... So that is the main problem statement!

Has anyone done longer packet testing with RadioLib and LR1110 hardware? How long and with what Lora config? I have run the Meshtastic firmware with my hardware and successfully sent simple messages, so I know that firmware can send/receive (but not what packet length it uses.)

I'm working with Seeed hardware, the Wio Tracker 1110 dev board and T1000-E tracker device as my main test case so far, using Arduino for development and have RadioLib 7.0.0 installed ( I see 7.0.2 is released now, off to update!)

My background is working with the Reticulum/RNode/Sideband firmware and software, and I provide an iPhone/iOS port of that project.

Greetings!

[jgromes]

My understanding is the max packet should be in the area of 255 chars (depending on Lora settings)

The absolute maximum should be 256 bytes, independent of the LoRa configuration (there is some dependency in GFSK modem but not in LoRa).

I am seeing failures around 50 chars

What sort of failures? CRC errors? Mangled data? Missing packets completely?

From the driver point-of-view, there is no difference in handling 50 characters as opposed to 250 characters, it's just more bytes being sent in one particular SPI write. Though very large payloads are somewhat uncommon in the real world, I would expect this to work the same.

[cobraPA]

This is using the startReceive(), which I believe is non-blocking? And then looking for the interrupt flag to be set. The flag does not get set though, even after multiple transmit packets. I started dumping RSSI, and I can see it changing, so I know the LR1110 is seeing some of the packet, but RxDone does not seem to be recognized? My understanding is that a packet that fails to receive should still generate RxDone, possibly with CRC errors or other error indicated. But I am not seeing that, it seems.

Should I attempt readData anyway after some amount of time? I have not tried that, although I know the docs say that partial packet reception is possible.

[jgromes]

My understanding is that a packet that fails to receive should still generate RxDone

Where is this information coming from? Or better, what do you mean by "fails to receive"? RxDone is what tells the library a packet reception has completed, and some data is available, regardless of whether CRC check passed or not. If this flag is not set there is not much that can be done from the software, there is no way to distinguish that state from a standby state or an ongoing reception.

I know the docs say that partial packet reception is possible.

Seems unlikely - which docs?

I started dumping RSSI, and I can see it changing, so I know the LR1110 is seeing some of the packet

This doesn't tell you anything about the state of the demodulation, it merely tells you the power level at the RF input is increased.

[cobraPA]

I know the docs say that partial packet reception is possible.

Seems unlikely - which docs?

Do you have access to the LR1110 user manual? In the version I have, in section '10.3 Using the Data Buffer' there is a note:

Note: All the received data is written to the data buffer even if the CRC is invalid, permitting user-defined post processing of corrupted data. When receiving, if the packet size exceeds the buffer memory allocated for the RX, it overwrites the transmit portion of the data buffer.

I guess this does not say the packet will be marked as done or not... but makes me think you can look at as much data as was received in the buffer.

I started dumping RSSI, and I can see it changing, so I know the LR1110 is seeing some of the packet

This doesn't tell you anything about the state of the demodulation, it merely tells you the power level at the RF input is increased.

On startup, it seems to only update when modulation is seen? The behavior here when dumped on 1sec intervals is that it starts updating when the other device starts to transmit:

[LR1110] RSSI: -0.00 dBm
[LR1110] RSSI: -0.00 dBm
[LR1110] RSSI: -0.00 dBm
[LR1110] RSSI: -111.00 dBm
[LR1110] RSSI: -111.00 dBm
[LR1110] RSSI: -111.00 dBm

(And can change some if multiple packets are transmitted.)

I found an error on my part... I had stubbed out the interrupt enable, this was why I did not get the event!

  // set the function that will be called
  // when new packet is received
  // radio.setIrqAction(setFlag);

I migrated that from the multi transmit example and hadn't turned it back on.

[jgromes]

Do you have access to the LR1110 user manual?

I do. But my understanding of the same note is that it says nothing about reading only part of the packet. It says that data will be written regardless of CRC validity. How would the radio be able to tell the CRC is invalid without having first received all the data? To me this strongly implies that there is some internal buffer that keeps the data durign demodulation and decoding and only writes them into the user-accessible FIFO after it has completed decoding of the expected number of symbols (given either by the LoRa header contents, or the configured length in implicit header mode). But feel free to correct my ideas and speculations by proof.

On startup, it seems to only update when modulation is seen?

Have you read the documentation for LR11x0::getRSSI? If not, here it's here, and it says that the method returns RSSI of the last received packet, so this is the expected behavior.

[cobraPA]

Do you have access to the LR1110 user manual?

I do. But my understanding of the same note is that it says nothing about reading only part of the packet. It says that data will be written regardless of CRC validity. How would the radio be able to tell the CRC is invalid without having first received all the data? To me this strongly implies that there is some internal buffer that keeps the data durign demodulation and decoding and only writes them into the user-accessible FIFO after it has completed decoding of the expected number of symbols (given either by the LoRa header contents, or the configured length in implicit header mode). But feel free to correct my ideas and speculations by proof.

Hmm, that is possible. I've got more info out of the pingpong problem I was seeing by dumping irqStatus and it indicates a header error when reception fails. I think the RadioLib read does not enable that interrupt in the pingpong sample, so does not return a read error in this case. I don't think I can pull the receive buffer with the RadioLib interface, but maybe this case would show partial data if I could. So I will let you know if I implement code that shows it one way or the other.

On startup, it seems to only update when modulation is seen?

Have you read the documentation for LR11x0::getRSSI? If not, here it's here, and it says that the method returns RSSI of the last received packet, so this is the expected behavior.

I had not, thank you for pointing me to it.

[cobraPA]

With some further testing, I was able to make longer packet transmissions/receptions work with some of the sample code, but the delays in pingpong example and some logic may need to be modified. If the tx or rx time is too long, they overlap with the base delays in the example and will lead to rx failures.