I need some help with the next issue. I’m reusing working code from an Arduino Ethernet to a Mega board as of the memory limitations on the old Ethernet one, where I use an nRF24 radio and ENC28J60 Ethernet board to connect to the internet.
Both Blynk and nRF24 code works, individual, perfect but there is trouble when I use them both. The issue seems to result in losing the connection with the Blynk cloud server as soon I address the RF24 radio.
Here the output of the serial monitor:
[25] Using static IP
[1077] IP:
[1078]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ / '/
///_, /////_
/__/ v0.4.3 on Arduino Mega
I’ve narrowed down the issue to the next code which seems to be conflicting. The moment radio.available() is issued the connection is gone and fails to reconnect.
Now, again, it does work all nicely together on my other board so there is nothing wrong with “the code” but i did used an older Blynk and different Ethernet libraries. So my best guess is either there is something with the UIPEthernet that doesn’t match with the RF24 library. I’ve used older Blynk libraries resulting in the same problem.
My question is to anyone who can assist in troubleshooting this?
Or does someone has a working nRF24 setup working (with a ENC28J60 preferable) and can share some details on Libraries and code? (ps: I’m using the RF24Network to hook up with the rest of the boards)
Sorry, I do not have those particular components to test with, however I have had some experience dealing with connection issues.
Then the next thing to consider is obviously the hardware - particularly pin conflicts/differences between the board that works and the board that doesn’t. I started with an UNO but switched to a MEGA (for memory), but then started seeing issues that simply turned out to be shields sharing pins.
I suggest double/triple checking that the radio board doesn’t share any pins or i2C addresses, pullup/pulldown issues, etc.
I sometimes try isolating the hardware with simple sketches that do one, and only one, thing at a time, to confirm mutual code/library/hardware cooperation. Then slowly stack the components together until complete. Tedious at times, but it can be a solid diagnostic solution.
True, I’m doing this as well but it never crossed my mind it could be a hardware issue. They do share same pins as both of them use ISP. So I hooked up my nScope, cool osciloscope for other Kickstarter campaign, and surely I recon the clock pin flattens-out the moment the radio commands get issued.
Although, I’ve replaced both nFR24 and ENC28J60 with different board types, the problem reoccurred. This may exclude a faulty board and could point to be an architecture incompatibility… well, I’ll continue some troubleshooting today. I do have to dig into ISP to find out if I can find how these boards are addressed on their corresponding addresses. I’m still not 100% convinced the problem is pure hardware related and can be solved via software.
And its solved the problem
So, yes, I did some research and found already fairly quickly from this video https://youtu.be/Fj8IuivkQWI?t=1m17s I’m sharing pin 53 as SS for both modules. I somehow mixed up I2C with SPI (oeps!)
It was fairly simple to change the SS pin from the RF radio as this one gets declared (RF24 radio(9,10) as I couldn’t change the SS pin for the ENC28J60 board right from the sketch (I assume I’ll had to change it in the library).
Thanks to you all, gunner and vhymanskyy for the golden tip!
Ps: I was just wondering why the SS pin has been “fixed” on certain arduino board types? I assume any digital pin could do just fine?