getPacketLength() on the sx1262 (FSK mode)

[moshe-braner]

I am trying to port my version of SoftRF to using the RadioLib. On the sx1262 module, I have found that the RadioLib function getPacketLength() returns 255 (the maximum possible for this module) rather than the length of the actually received packet. It does seem to return 0 if called when reception was started but no packet was received. This is in fixed-packet-length FSK mode. Does this mean the sx1262 actually keeps on filling its rx buffer instead of stopping at the requested length? It does pull the IRQ, but maybe not until the buffer is full?

Of course the fixed packet length is known, and passed to fixedPacketLengthMode() to set things up (and communication is working). But I was trying to write my receive() code (similar to the RadioLib receive(), calls startReceive() and then waits for a packet) to be agnostic about the packet size, since my software works with several protocols with different packet sizes, switching between them often. It tried to use getPacketLength() to get the length to pass to readData(). I solved it by passing the known correct packet size (for the current protocol) to my receive() function instead. But still am curious about the getPacketLength(). Perhaps I missed some config detail? Although what I didn't explicitly set up should be using a reasonable default?

[jgromes]

I'm not really sure what you're trying to do. You stated you're using fixed length FSK, but trying to implement reception "to be agnostic about the packet size", which is mututally exclusive. Either you can use fixed length FSK if you know in advance the size of the packet you expect to receive (and hence getPacketLength is useless to you), or you use variable length FSK where the packet itself has to contain the length byte. Which one you select depends on the protocol you are receiving.

I don't know what is getPacketLength going to return in fixed length FSK mode, since it just calls the RADIOLIB_SX126X_CMD_GET_RX_BUFFER_STATUS command - so it's up to the radio how it handles that. I would expect it to return the fixed length size, provided a packet was actually received prior to calling it. Of course, that length is the same as the one that was set by fixedPacketLengthMode, since the radio will just record this number of bytes once it detects the sync word.

[StevenCellist]

Actually @moshe-braner explained their usecase: use a fixed packet length with a varying fixed length based on what they expect to receive. Then having a single receive-function that doesn't also have to keep track of the varying fixed length has some usefulness.

[moshe-braner]

StevenCellist is correct. I need a single receive-function for several protocols with different lengths (although each one is fixed-length). Thus the receive function needs to know the packet length. I thought I can get it from the getPacketLength() function. Now that (after much debugging...) I know that does not work, I can pass the needed info to the receive function in some other way. So it works now.

But what I can report is that, in fixed-length FSK, the getPacketLength() function always returned 255 (the full size of the sx1262's buffer) rather than the actual received packet length. (But it returned 0 if no packet as received.) Which makes me wonder if it is all operating as it should. For example, maybe the sx1262 keeps on receiving (collecting garbage data from the noise after the real packet has ended) before pulling the "reception is complete" IRQ? What I see in the buffer (if I give the length of 255 to the readData() function) is the intended packet (Manchester encoded), followed by a short sequence of hex 55555555, followed by what looks like garbage, or at least something not Manchester encoded, thus not part of any other actual packet sent by the transmitting device in the test.

[jgromes]

a single receive-function for several protocols with different lengths

I understood that, I just don't understand how is getPacketLength fitting into the picture. The way fixed length mode works is that the radio waits for the packet preamble, followed by a sync word and then saves the pre-configured amount of bytes to the the buffer - that's it. As I wrote before, I actually don't know how is getPacketLength going to behave in this case. If it's always returning 255 then that looks like the radio is rejecting the command.

For example, maybe the sx1262 keeps on receiving (collecting garbage data from the noise after the real packet has ended)

The length byte is what tells the SX1262 the packet has ended. So yes, if the transmitter sent more bytes than what is actually being set by fixedPacketLengthMode, there will be some garbage at the end. In your use case, I think you will have to set the maximum expected packet length, and then decode the packet based on somehow figuring out the protocol it is using.

[jgromes]

@moshe-braner I was able to reproduce the issue, indeed the radio always returns 0xFF in this case. So we will handle it in the library to simplify packet handling, and I also added more explanation to the method itself.

[moshe-braner]

OK, thanks. Just so others won't be making the assumptions I was making... :-)