My project uses the RP2040 Connect to read 3 mcp9600 thermocouples every 3 s via I2c and control pool valve actuators to heat a spa and pool using solar water heater panels when the sun is out. The efficacy of the panels in heating the water is amazing and I can heat the spa to way too hot in a few hours and need to switch over to heat the pool instead. The RP2040 Connect provides me with status when requested through an IFTTT webhook notification. The RP2040 Connect hangs up frequently as in 1 to many times daily (7 times today) and is restarted using the watchdog timer. The restarts are a problem because the system doesn't know where it was when it hung up and starting over creates many hassles with the overall control that I won't bore you with. Hang up events seem to occur at random and are seemingly not correlated to events like valve maneuvers.
The power input is a 19 v computer power supply that is then stepped down to 5 v with a DC-DC converter. I have a 100uf capacitor across the +/- DC supply on the 5v rails. Looks clean on the scope with a few hundred mV spike from the DC-DC stepdown circuit. Vin is used to power the nano. The valve relays are operated via a module board which isolates the digital inputs but the coil back emf is seen at the 5v rail. I have capacitors on the digital outputs to the relay module but feel thats overkill. A LCD is operated also via I2c through a level converter as it is a 5v device. I have tried pull up resistors on the I2c inputs with seemly little effect. A analogue input reads the voltage on a small solar panel via a voltage divider to decide when its sunny. The whole thing sits next to several 120v wires and a 24V ac transformer that powers the valves and I think about that noise as a factor as well as the fact that its all on a breadboard maybe acting like a big antenna. I have stopped updates to LCD when no one is looking. Thinking about doing the same with the thermocouples reads when not needed.
Is this noise? Do I need to get it off the breadboard? I know it could be software/memory things like that. The frequency is highly variable (sometimes it goes all day without a restart) which makes SW seem less likely to me. Looking for direction before I randomly start trying things.
I am surprised it works at all, given that it is on a breadboard and in an outside environment. I2C is designed for communications over some centimeters on a PCB. I see long wires going to your LCD display.
If I were you I would solder everything up on a protoboard and even then place the components in such a position that the connecting wires of the I2C line were as short as possible.
Breadboards make bad contacts. They are for testing only and only indoors, and even then they give enough trouble.
This is the official I2C standard: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Please read page 54, paragraph 7.5
The I2C bus is not the bus that you think it is.
I see wires with SDA and SCL going into the blue cable. That is not what the I2C bus is for.
Did you know that the I2C bus has three wires ? SDA, SCL and GND. The GND is the most important.
You don't seem to have a good ground plan. Grounding is a craftsmanship on it own.
Perhaps you need a metal box for the RP2040 Connect and all the modules (and the I2C bus not leaving that metal box).
There are also beehive projects. In the end it is sometimes easier to put an Arduino near each beehive and use the good old RS-485 communication over twisted pair cable.
Or if you can use analog temperature sensors and bring those wires with the analog signals all the way to control box, that might be a good option as well.
Thank you all comments and for the reference. Cavalier i2c use might explain a few other things around here. The 3-9600 thermocouples are read over 7 feet of cat 5 cable! I will modify SDA/SCL to twist with a ground wire as a trial. I do take 3.3v and ground out to the thermocouple boards on that cat 5 without attention to the twisted pairs. I could abandon i2c for spi as the adafruit breakout boards allow for either. Would SPI be a more robust comm protocol in this situation? A second arduino at the thermocouple junction is certainly an option. Based on these comments I think I'll turn off all i2c comm and see if the system stabilizes. I have a nano female socket with screw connectors to replace the breadboard. Knew the breadboard is likely trouble but certainly convenient for the shakedown period. As soon as a solder something up I always seem to have a better idea. As far as shielding in a metal box - I am counting on that ublox wifi. Sounds like the consensus is hardware. I believe I already inspected my headers under the magnifier but will double check. I will report back.
Update:
Breadboard replaced with soldered circuit board and arduino placed on an expansion board. The i2c SDA and SCL leads are all wound pairs with ground lines. I added a second ground bus given that the breadboard rails are history. Hang ups have become rare as in one every few days down from several per day. My thermocouples remain about 7 feet away with i2 comm over cat 5 cable with the wound pairs. The mcp9600 breakout boards are still on a breadboard as of now but I plan to replace that as well ASAP.
I think you guys nailed it and its appreciated. As stated above, cavalier i2c use likely explains some other issues I have with other projects as well.
