Let's Make Robots!

The most peculair behaviour, with Serial vs. without Serial.

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!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
How did you have the receiver connected to your Arduino? Which pins did you use? I assume your grounds are all connected? What is your power source? If you have an electrical noise issue then regulated 5V from the USB cable might have masked the problem?

The receiver is connected through SPI -- pins 10, 11, 12 and 13.

It is powered by a regulated 3.3V source, which is coming from the 5V pin from the Motoruino [the 3.3V pin did not seem to give any current so I worked around it this way].

The Motoruino itself is powered by a battery pack of 6 x 1.2V AA batteries and it is "jumpered" to always use this external power source.

Thanks for you throught about electrical noise. I must see what happens if I connect the board to a steady, non-USB, 5V source and see what happens then. If it then also "just works" -- it "simply" may be a power problem somewhere...

For the moment I have given up on this. I am sure it is a timing issue but can't figure out how to fix it....

Per usual, I had put #ifdefs around various levels of verbosity of debugging. Experimenting with different ones I found the one #define DEBUG_XXXX that was responsible for "correct" and "incorrect" behaviour.

So to all the #else part of those  #ifdef-clauses, I put in calls to delayMicroseconds() -- and kept increasing the delay until it behaved normal again. Then, I removed all the references to the Serial device, skipping its initialisation, and every Serial.printXXX compiled out.

And guess what? It does not work.

Interestingly, taking into account Serial should be compiled out, (the call to Serial.begin() really is not there) the ICSP adapter does allow a Serial connection still.

That is where the plot thickens: if I now connect with Arduino IDE's Serial monitor -- same "broken" behaviour. However, connecting with minicom -- it works like a charm!

And flabbergastingly, that behaviour stays the same if I compile out all those calls to delayMicroseconds() I just implemented...

/me is confused beyond belief. :-)

I think that a workaround will be less time consuming and also interesting to implement (basically momentarily switching RX/TX modes on both receiver and controller, for the controller to receive a short burst of requested data, taking no more that a few hundreds of milliseconds)... That was my initial plan anyway but reading about that ACK_PAYLOAD in the datasheet made me focus on that feature which I, for the time being, am giving up on now...

Woops, when I posted it this morning I completely forget to even at least mention the board in question -- it's a Motoruino.

I have it connected through an USB adapter [like the one for the Lilypad -- the USB <-> ICSP headers that one can stick on compatible pins on any board].

I was thinking along the same lines as you, but I was looking in my own code and Arduino libraries. But your suggestion does contain a fresh angle that is worth looking into... Perhaps when that little device is hooked up, ICSP mode somehow does change some timings.. some place.. some where...

I had already tried adding delays here and there, but it either completely breaks or only works with Serial active... Too coincidental to be a problem with the code although I can never be 100% sure... I will still continue to keep throwing everything at it I can think of... (Well not real things, I would break those tiny transceivers!)

 I do love a puzzle every once in a while, but the "hair-pullingly depressing and demotivating" ones I like to keep to a minimum.... :)

How is the device connected to your system? Could it be that it requires some clock or handshaking that is only present when you have the serial monitor running?