Variable length send issue

[dskogman]

I have a strange issue with sending variable length data using RH_RF95.send and RH_RF95.receive. As long as I send the same length data packet it works fine but if a send a longer packet (22 bytes) after a shorter one (16 bytes) a Moteino m0 receiver hangs while an Arduino Due with Adafruit RFM95 radio returns the data but truncated to the previous length (16 bytes). The sender is an Arduino Nano with an Adafruit RFM95. It reads data from a serial input and sends it using the RH_RF95. It took a while to get this far so I can live with a fixed length if I have to but any ideas would be appreciated.

[dskogman]

Did some more testing and if I send the small data first followed by the longer one, the longer one gets truncated to the shorter length. The Moteino does not hang up in this case.

[Felix]

Truncation often means some pointer/iterator is left to iterate into no-man's-land memory (unterminated strings, arrays, memory pointers etc.). Especially sensitive when dealing with manually allocated memory. In which case anything can happen - that "anything" usually means apparently frozen unresponsive board (the board behaves like it has a mind of its own).

[dskogman]

That was my first thought, so I spent a lot of time tracing thru the code and didn't find anything. I then just took the simple RH examples and just did a send with two different size strings to a receiver that reads into a fixed buffer and get the same behavior. I'm using the patched version of RadioHead v1.116.

[dskogman]

This is what is received.....

Arduino LoRa RX Test!
LoRa radio init OK!
-----------30 byte string OK----------------------------------
Received:
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70
71 72 73 74 75 76 77 78 79 7A 2A D A 0
Got: abcdefghijklmnopqrstuvwxyz*

Length=30
-------------26 byte string OK---------------------------------
Received:
31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36
37 38 39 30 31 32 2A D A 0
Got: 1234567890123456789012*

Length=26
--------------30 byte string truncated to 26----------------------------------
Received:
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70
71 72 73 74 75 76 77 78 79 7A
Got: abcdefghijklmnopqrstuvwxyz
Length=26
--------------26 byte string OK----------------------------------
Received:
31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36
37 38 39 30 31 32 2A D A 0
Got: 1234567890123456789012*

Length=26
------------------------------------------------

[dskogman]

I bought a moteino for the transmitter end to see if there was any difference and the results were the same. It's a very simple sketch on both ends (see attached).

[Felix]

Apparently simple sketches indeed. But I suggest using proper string manipulators instead of memory manipulators. Like char arrays, strlen, sprintf, etc.
Right now it looks like you're joggling memory streams and that's a pretty good indicator some null pointer is terminating your expected string.
That the result is the same, it underlines that the problem most likely is not the hardware.
The RadioHead library has some good well written examples that I would start with which should point you in the right direction (rf95_server and client).

[dskogman]

That's where they came from with some minor mods. I used basic  'C style buffers to avoid any heap or dynamic memory allocation  issues. It's about as simple as it gets

[Felix]

I provided a patched library on the LoRa page in the Moteino guide. That will ensure examples will work on the Moteinos (in terms of proper SPI_CS pins) without having to declare anything special, perhaps other than making sure you match the frequency to your hardware module and assigning any IDs etc.

I see your code is considerably different than examples in the library.
Not exactly sure what you mean by "C style buffers", I see memory buffers in your code (byte arrays) used as strings. Then you mention that is keeping things safe from "heap or dynamic allocation issues". Not sure how that makes life easy declaring and manipulating strings in C, unless you really intend to send raw bytes that look like strings.
IMO if you want to send strings, use the string declarations and manipulator functions.

[dskogman]

I used your  patched v1.116 version of the library. I tried to download  v1.121 from https://lowpowerlab.com/guide/moteino/lora-support/ but it has a 404 error.

The test programs are modified versions of rf95_client and rf95_server in the Radiohead samples. They both use  uint8_t (byte) arrays which matches the calling arguments of the send and recv functions. The only thing I did was use two different sized arrays for the sender.

I'd like to try the patched 1.121 version of the library if it's available somewhere.

[Felix]

I fixed the link to 121.
So why is there a problem with 26, that is the question. I would look more carefully at what happens before you send and after you receive and read the content of the buffer.
Check that you actually send more than 26 chars on the sender side, and then look at how the recv() function populates the buffer and the length parameter.