Jee Labs Talk

This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!

1. professor-chaos
   

   I've been testing a setup where a JeeNode connected to an Ethercard not only receives data from remote radio nodes, but also sends commands to them. My sketch is based on the Ethernode server.

   It seems that immediately after serving some web page data, the JeeNode enters a state where rf12canSend will return true, but calling rf12sendStart will not actually transmit any radio data.

   Putting in more calls to rf12recvDone didn't help, but adding a short delay (100 msec) between serving the web page and invoking rf12sendStart seemed to fix the problem.

   JCW, let me know if you want me to send you the sketches to reproduce the issue; they're kind of long to post here.

   Posted 19/06/2010 20:02:45

2. jcw
   

   Please do - I realize that the tests I've done so far (for days on end) only involved reception of packets - intermixed with serving web pages. There are some interactions, since both use the SPI bus - so if you have a setup which can bring out a bug, that would be nice.

   Posted 19/06/2010 21:41:41

3. jcw
   

   Could you try something? Add "delay(5);" after the rf12sendStart() call. If the problem is with losing interrupts, then that should fix it (this idea comes from the latest weblog post).

   Posted 19/06/2010 23:09:53

4. professor-chaos
   

   That seems to fix it! Now transmissions proceed without any need for waiting after web serving

   Posted 19/06/2010 23:23:20

5. jcw
   

   Thx. I think I understand what's going on. I'll see if I can find a more automatic solution.

   Posted 19/06/2010 23:44:02

6. jcw
   

   Ok, I've tweaked both the EtherCard and the RF12 libraries (by avoiding digitalWrite() for SPI chip selection). With a bit of luck, the delay(5) should no longer be needed, because EtherCard polling will no longer claim the SPI bus as much. If that's still not good enough, I could add logic to temporarily raise the SPI bus frequency.

   Posted 20/06/2010 00:03:50

7. jcw
   

   One change leads to the next. The rf12sendStart() call now accepts an extra argument - set it to 1 to have the send wait until the packet has been sent out. This can now be used instead of the above "delay(5);" trick. It'll only wait as long as needed, i.s.o. a fixed time. The docs on this page have also been updated.

   Posted 20/06/2010 01:44:42

8. professor-chaos
   

   Excellent, JC - sending with the sync parameter works without the need for any delay after rf12sendStart().

   Posted 20/06/2010 02:32:10