Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fragmentation problem between RPi and Arduino #88

Closed
adarazs opened this issue Apr 11, 2016 · 3 comments
Closed

Fragmentation problem between RPi and Arduino #88

adarazs opened this issue Apr 11, 2016 · 3 comments
Labels

Comments

@adarazs
Copy link

adarazs commented Apr 11, 2016

Hi @TMRh20,

I'm using your libraries (RF24+RF24Network+RF24Mesh) since about 1.5 years heavily in my home automation project and it worked flawlessly. Awesome work, thank you! I used a checkout from 2015-07-01 from all libs (Development branch from RF24Network - c88ccdc) until now, but I recently pulled the new commits and my system developed a bad issue.

The problem occurs when I'm sending more than 1 package worth of data from my RPi2 to an Arduino node. When package fragmentation occurs, the client crashes/prints gibberish on the serial console, etc. Completely unpredictable behavior.

I'm quite unfamiliar still with the library to debug the problem myself, but I found a way to reproduce it by slightly modifying the examples in the repo:

diff --git a/examples_RPi/helloworld_tx.cpp b/examples_RPi/helloworld_tx.cpp
index 1b7a7a0..2100ae2 100644
--- a/examples_RPi/helloworld_tx.cpp
+++ b/examples_RPi/helloworld_tx.cpp
@@ -50,6 +50,7 @@ unsigned long packets_sent;          // How many have we sent already
 struct payload_t {                  // Structure of our payload
   unsigned long ms;
   unsigned long counter;
+  char msg[50];
 };

 int main(int argc, char** argv)
@@ -70,7 +71,7 @@ int main(int argc, char** argv)
                        last_sent = now;

                        printf("Sending ..\n");
-                       payload_t payload = { millis(), packets_sent++ };
+                       payload_t payload = { millis(), packets_sent++, "0" };
                        RF24NetworkHeader header(/*to node*/ other_node);
                        bool ok = network.write(header,&payload,sizeof(payload));
                        if (ok){

The Arduino rx side needs the same changes, adding char msg[50]; to the struct and printing it out after receiving.

struct payload_t {                 // Structure of our payload
  unsigned long ms;
  unsigned long counter;
  char msg[50];
...
    Serial.println(payload.ms);
    Serial.println(payload.msg);
};

If I change msg[50] to msg[2], everything works perfectly and I can send as much package as I want without trouble. With msg[50] (or anything above 1 package worth) results in the Arduino (receiver node) freezing/restarting.

Here's a serial output from the Arduino: https://gist.github.com/adarazs/b8dc782c9dd5e5077873518b4e3e0e06#file-gistfile1-txt-L47

You can see that it badly identifies the length, then the sketch restarts after line 48 and then it completely freeze up after the last line in the log. But the way it dies differs every time.

I tried with multiple Arduinos and multiple radios (I use the black small ones from ebay).

Please let me know how I can help to debug the issue some more.

@dano8406
Copy link

I think this may be related to the same issue that I am currently facing.

I have a raspberry pi (address 00) interfacing with an Arduino Mega 2560 (address 01). I am able to send a message from the pi to the arduino once without problems, however, subsequent transmissions result in fragments out of order.

Any messages sent from the Arduino to the Pi are sent without issue.
Once the Arduino is reset the first message can be resent without problems and all subsequent messages are dropped (ACK is OK).

See debug outputs below:

First message received without problems

14627: MAC Received on 5 id 1 from 00 to 01 type 148
 14628: NET message 0409

14630: next_frame 1121 
14635: frame_queue 1121 
14639: NET Enqueue @0 
9
4
FA
FF
67
65
74
42
61
74
74
65
72
79
56
6F
6C
74
61
67
65
0
0
0
14658: MAC Received on 5 id 1 from 00 to 01 type 150

14667: NET message 0000

14671: next_frame 1121 
14675: frame_queue 1121 
14680: NET Enqueue @0 
fq 3: 36
9
4
FA
FF 
67
65
74
42
61
74 
74
65
72
79
56
6F 
6C
74
61
67
65
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
enq size 36
14708: NET message size 36
14713: NET r message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 67 61 74 6c 6f 56 79 72 65 74 74 61 42 74 65 67 ff fa 04 09 

14736: next_frame 0 

Subsequent messages:

25751: MAC Received on 5 id 1 from 00 to 01 type 148

25751: NET message 2e54

25753: next_frame 0 
25756: frame_queue 1121 
25761: NET Enqueue @fb9f 
25765: MAC Received on 5 id 1 from 00 to 01 type 150

25775: NET message 0000

25779: next_frame 0 
25783: frame_queue 1121 
25787: NET Enqueue @fb9f 
Drop frag 0 Out of order 

TMRh20 added a commit that referenced this issue Apr 12, 2016
Per #88
When receiving fragmented payloads, padding was not being added to the
frame on non-linux devices, but subtracted during reads.

- Remove padding altogether from AVR devices (#defined ARDUINO_ARCH_AVR)
- Add padding to received, fragmented payloads on non-AVR, non-Linux
devices (for 32-bit devices like ESP8266)

May have affected nRF24/RF24Mesh#71
@TMRh20
Copy link
Member

TMRh20 commented Apr 12, 2016

@adarazs @dan8551 Thanks for the code example and info. Can you please update on Arduino and test with the latest update

Padding was being added for compatibility with 32-bit devices, but with fragmented payloads that don't work out evenly it was not padded. I removed that altogether for AVR devices, and fixed it for others.

@TMRh20 TMRh20 added the bug label Apr 12, 2016
@adarazs
Copy link
Author

adarazs commented Apr 12, 2016

@TMRh20 So far so good. It looks like everything works with fragmented payloads now.

Thank you for the quick response and fix! \o/

@adarazs adarazs closed this as completed Apr 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants