Go Down

Topic: ArduinoCloud.update(); interferes w/ RFM69 operation (Read 1 time) previous topic - next topic


Using Nano 33 iot w latest IDE & boards. Collecting PIR data outside and sending to nano via RFM69 using lowpower labs library via SPI (D10-13). The goal is to send the data to the web and have Echo Dot announce guests. Sketch runs well with ArduinoCloud.update() commented out (no web interface of course). Radio stops once ArduinoCloud.update executes. Hiding the update in a if-then to run only when my Thing variable changes followed by re-initialization of the RFM69works to keep the radio on but intermittent execution of ArduinoCloud.update appears to disconnect nano from wifi. A simple sketch w/o radio code shows web interface runs as expected. I assume the libraries in use are in conflict but I don't have the depth to troubleshoot that. I know the RFM69 SPI code and ethernet shield is trouble(just gave up on that option) - is this more of the same? These radios are great otherwise.

Suggestions desired.


hi @MegaHolmes

I had bookmarked this post with the intention of getting back to you earlier once having talked to a couple of our engineers.
Which library are you using to control the RFM69?
I know that there may be some issues depending on SPI transactions and clock settings, but I'm still investigating.

Unfortunately if you don't call ArduinoCloud.update() the connection won't be kept alive, especially if the instance is relying on a ConnectionHandler object (meaning you don't manage network connections yourself).

I do have a suggestion for you, though.
Would you mind trying to use RadioHead library to control the RFM69?
It's pretty straight forward and allows you to use other pins than the predefined ones, and the SAMD21 is fast enough to work well like that.

Take a look at this page, and let me know if you can work it out.
I have a couple of RFM69 lying around but I'm traveling for the next 3 weeks so I won't be able to test.

good luck, I'll keep an eye on this space :)



I don't own a RFM69, but I was able to reproduce the same problem when using an SD card and Arduino IoT Cloud. I investigated this and discovered there is a bug that causes pin 10 to be set to INPUT mode when ArduinoCloud.update(); is called before the Nano 33 IoT has connected to Arduino IoT Cloud. Since the RFM69 library uses pin 10 for the radio's CS pin, this breaks the SPI communication with the RFM69.

I have a workaround for you. Right above where you call radio.initialize() in your setup() function, add these lines:
Code: [Select]
// Wait for connection with Arduino IoT Cloud
while (!ArduinoCloud.connected()) {

This will still set pin 10 to INPUT mode, but it does it before the call to radio.initialize(), which configures pin 10 for communication with the RFM69, so it does no harm.

I'll do some further investigation to try to discover the cause of the bug so that we can get a real fix in the library and make the workaround not necessary in the future. But the workaround isn't so bad, other than delaying the start of your program while it waits for the connection.

Go Up