Recently I came across the RFM70 2.4Ghz RF transceiver module and decided to buy 4 of them [at 3 EUR a pop, why not?]. The module talks SPI, has an IRQ pin too to indicate it has received data, so that's pretty useful for that low price!
I found some bits of code to interface with it: the producer of the chip published some example code and some people wrote libraries around that, which in turn I did myself too, using what was available on the web...
Two modules to talk to eachother was actually pretty simply (I struggled with the RFM12B before, this one was much easier). The transmitter was sending, and the receiver was happily accepting the packets sent.
Having that in place, my next step was making the Receiver to be "interrupt-driven".
The RFM70 can be a receiver, or a transmitter, but the receiver /can/ send ACK payloads. That's what I (ab-) used to send back status reports to the Controller application, which is running on my Arduino Uno with a PlayStation2 controller attached to steer my robot. :)
In the interrupt handler for the RFM70, I write the "ack payload buffer" with the message that should be sent back.
Everything works like a charm: I hit buttons on the controller, my robot receives them, and then the controller receives an ACK with a payload and knows the "local time" of the robot and other status bytes.....
This works perfectly... no matter the order of power -up (robot first, or controller first), an RF connection is succesfully established and soon they send packets back and forth, confirmed by the Serial Monitor.
UNTIL I decide not to use a Serial Monitor. I disconnect the USB cable, and insert it again, and don't have Arduino software running or a minicom (a terminal program on UNIX) connection: a difference in behaviour: the ACK packets are never sent.
If I start minicom after that, as usual it resets the board, opens serial monitor connection et voila, the ACK packets /do/ get sent.
(Note that these 2 situations use the same code; the only technical difference is that Serial actually is open vs. not open.)
So, I am tempted to think it's a timing issue -- if I disable Serial, it seems to be missing a beat.Or going to fast for something.
Howver, I see absolutely /nothing/ in the HardwareSerial.h/.cpp shipped with Arduino software that implies a change.in timing.
The weird conclusion I got is: As long as there is a Serial monitor, my sketch behaves as I would expect it to. I can't figure out where this is coming from....
What I have tried so far:
- I have tried all different SPI speeds, all to no avail: the same "bug" occurs.
- I have disabled Serial altogether, no luck.
The reason that I write this is that I really really hope someone once ran into this and recognises it.... Or any suggestion could shed some light on this... Thanks in advance for any pointers!
