Problems for NanodeRF_multinode sketch to process long jeelib RF12 messages
Submitted by mountaindude on Mon, 24/09/2012 - 16:53
The RF12 lib specifies that a valid RF12 package can be up to 66 bytes, see http://jeelabs.org/2011/06/09/rf12-packet-format-and-design/.
That's plenty, but when a remote tx node gather a bunch of sensor data and sends all of it to the node running the NanodeRF_multinode sketch, you might end up with rather long packages.
Last night I ran into exactly this problem. The remote TX node sends packages with 25 bytes of payload (add a few bytes for the headers etc). That's well within protocol specs. However, the NanodeRF_multinode sketch doesn't create a valid POST URL, instead the last few characters of the URL are just garbage. Reducing the number of sensor readings sent over rf makes the problem go away. Meanwhile the rf transmissions are received just fine by a 3rd node that just collects and view the raw RF12 packages.
I am pretty sure the above is due to the fact that the NanodeRF_multinode sketch uses jeelibs Ethernet library, which in itself use 700 bytes of RAM. The sketch itself also use a bunch of RAM to build the URL etc. We're running out of RAM, in other words.
I tried moving all strings to flash memory, no luck though (which is a bit strange, I would have expected that to give SOME improvement, at least).
Bottom line: Be careful when sending lots of sensor data from the tx node - when approaching 23 or so bytes of payload you might start to get errors.
This is a bit of an issue for me, so if anyone has any ideas on how to reduce the RAM usage of the sketch (other than using flash memory for strings) I am all ears - it'd also be a nice improvement to the sketch as such.
Problems for NanodeRF_multinode sketch to process long jeelib RF12 messages
Submitted by mountaindude on Mon, 24/09/2012 - 16:53The RF12 lib specifies that a valid RF12 package can be up to 66 bytes, see http://jeelabs.org/2011/06/09/rf12-packet-format-and-design/.
That's plenty, but when a remote tx node gather a bunch of sensor data and sends all of it to the node running the NanodeRF_multinode sketch, you might end up with rather long packages.
Last night I ran into exactly this problem. The remote TX node sends packages with 25 bytes of payload (add a few bytes for the headers etc). That's well within protocol specs. However, the NanodeRF_multinode sketch doesn't create a valid POST URL, instead the last few characters of the URL are just garbage. Reducing the number of sensor readings sent over rf makes the problem go away. Meanwhile the rf transmissions are received just fine by a 3rd node that just collects and view the raw RF12 packages.
I am pretty sure the above is due to the fact that the NanodeRF_multinode sketch uses jeelibs Ethernet library, which in itself use 700 bytes of RAM. The sketch itself also use a bunch of RAM to build the URL etc. We're running out of RAM, in other words.
I tried moving all strings to flash memory, no luck though (which is a bit strange, I would have expected that to give SOME improvement, at least).
Bottom line: Be careful when sending lots of sensor data from the tx node - when approaching 23 or so bytes of payload you might start to get errors.
This is a bit of an issue for me, so if anyone has any ideas on how to reduce the RAM usage of the sketch (other than using flash memory for strings) I am all ears - it'd also be a nice improvement to the sketch as such.
/Göran