Unwanted Uno Resets - How do I get rid of them? (Solved)

The Uno I built to control our solar hot water system used to work reliably (mainly through the winter months) but has recently been resetting itself over and over, mainly between 2:AM and 7:AM. I need the controller to be reliable. Please let me know if you can think of anything I can do to make it function correctly all the time.

I have attached a document (Uno Resets and what I’ve done) explaining the problem, the system that the Uno controls, major components, and things I’ve done to try to eliminate the resets, plus my observations. I’m not terribly experienced with Arduinos, but I’m doing the best I can with code and electronics. I placed this request for help in the General Electronics sub-forum because I think I’ve determined the problem is not the code (at least, not completely). But again, I’m not an expert.

I’m sorry for all the information I’m including - there is a LOT of it. But I’ve done enough reading in the forums here to know that the folks who help generally want to see everything at first, rather than having to ask for more after only an excerpt is provided.

UPDATE: I didn’t realize that PDFs and .ZIP files were not normal here on the forum. I’ve removed those files, and have replaced them with .JPG and .TXT files.

Please see attachments~~, namely~~
ATTACHMENTS:
(1) Unwanted Resets and what I’ve done (PDF)
(2) Unwanted Resets Sketch (PDF)
(3) Unwanted Resets SolarController schematic, a zipped PDF of Fritzing Breadboard
(4) Unwanted Resets Screen Shots smaller, a zipped PDF Document with screen shots from the many videos I’ve recorded, showing 4 screens of normal behavior by the system, followed by several representative failures.

ATTACHMENTS:
(1) Schematic (JPG)
(2) Full sketch (TXT)
(3) Resets and what I’ve done (TXT)

If you can see what I’m doing wrong, please share a possible solution with me.

Thank you.

ugfrog

Solar Controller - Full Sketch.txt (34.3 KB)

Unwnated Resets and what I’ve done.txt (36.8 KB)

So in essense, you code is reseting in all conditons;

The resets occur during the execution of all parts of the code - not just in one or two places. During the rest of the
day (7:AM through the next day’s 2:AM), resets VERY SELDOM happen - almost never.

Almost never is not the same as never.

Could this be a power problem? IE the utility supply is lower quality in those hours because hardly
anyone complains about it? Short of data-logging mains voltage and frequency over 24h that's going
to be a hard one to investigate.

The other obvious change is temperature which will be at its lowest during those hours. Can any part
of the system get cool enough for condensation to form?

Anyway you have seriously long cable runs, I suspect whatever the time-varying cause its getting in via long
cable runs without any protection from interference? Robustify all those cables with the usual EMI precautions and
its got a reasonable chance to make a difference.

SRNET,

srnet:
So in essense, you code is reseting in all conditons;

Almost never is not the same as never.

Yes, the code DOES reset, sometimes due to Watchdog, and sometimes due to Arduino just starting over (resets occurring far less than 8 seconds apart)... exactly like pressing the reset button. What I was trying to say there, is that MOST of the resets occur during the early morning hours. But sometimes, rarely, resets happen during the day; but not during most days.

MarkT, I almost wanted it to be a power problem, but owing to the various power sources I've tried, all of which continue to generate the resets, I'm not sure I can believe it's power source. I've tried 12v wall warts (plural), battery with voltage regulator, battery with voltage regulator and smart charger attached. I've also had both PROD and TEST set up running on the same AC outlet at the same time; PROD has resets, and TEST does not. I've powered PROD on a different AC outlet. Still getting resets.
I have thought about temperature, too, but the system was working well through the winter. The only part of the system that isn't indoors and dry (Colorado's normal relative humidity is about 20%) is the sensors. They are supposed to be weatherproof, plus I've sealed the shrink wrap on them with silicone sealant.
I'm not sure how to 'robustify' the cable that goes to the COLL sensor. It's 51 feet long, it's cat5e cable, and Data and Ground are one twisted pair. Power is half of another pair. The extra conductors are not connected at this point. I'm not experienced enough to know what all the usual EMI precautions are - sorry. Help?

ugfrog:
The Uno I built to control our solar hot water system used to work reliably (mainly through the winter months)

One important thing --- when describing something --- is to be specific. Eg....avoid something like "used to work reliably", followed by something that contradicts it.... such as 'mainly through ....'. It's either .... used to work reliably for months on end - without glitches .... or it worked with occasional hiccups. So when you mentioned ... used to work reliably, then does it mean it simply worked well (eg. for months at a time over a few seasons), with no hiccups (until recently)?

If the system (assuming it is the SAME as it is right now) once worked reliably (for long periods of time) suddenly develops issues....... then the focus will be on what might have changed with the system/or the environment.

ugfrog:
I've tried 12v wall warts (plural)...

You do realise most Arduinos run on 5volt.
7volt has to be dropped (as heat) in the regulator.
Better to use a 7-9volt REGULATED supply than a 12volt REGULATED supply.
Or, even better, a 5volt cellphone charger on the USB socket (bypasses the 5volt regulator).

What is the setup doing at night.

Most restarts are from

  1. overheating 5volt regulator (the above). FEEL if it's hot.
  2. relays switching inductive loads (use snubber circuits).
  3. code
    Maybe in that order.

Not going to read .pdf and .zip files.
Post a diagram and/or pictures HERE, and post your code INLINE HERE.
See the " how to post" sticky that's on top of every main page.
Leo..

Wawa:
Post a diagram and/or pictures HERE, and post your code INLINE HERE.

I was going to mention that it is not kosher to post .zip files.

I did look, and the code is probably too long to post inline. It is however, a proper PDF from which the code can actually be cut-and-pasted, not a "make it so it cannot be used" obfuscation PDF. :grinning:

Again it was TL;DR and I could not figure out what ugfrog had actually done, but with the further description it does sound like the common blunder of powering an Arduino in a real-world application from the "Vin" or "barrel jack". You need a proper, fully regulated switchmode power supply and feed it in to the 5 V pin.

"Vin" and the "barrel jack" are essentially for experimental or demonstration/ learning purposes - as indeed is the UNO form factor itself. For end applications, the Nano is more practical (and has two extra dedicated analog inputs).

Wawa,

  1. I have checked the onboard regulator. It's warm, but not at all hot. I've tried lower voltages from the variable output step-down regulator I'm using
    (2pcs LM2596S Adjustable DC-DC Module | Open ImpulseOpen Impulse),
    but for some reason, when doing that, the sensors don't respond to requests for temperature data. I'm running it now on 10v. I'll try it on 7v tomorrow.
  2. The resets happen at night when the pump isn't running, so inductive loads aren't the problem.
  3. Code... from the videos I've taken, I can see that the resets occur in every part of the code. I'll admit that I'm new to C++, but many of the resets occur while the code is sending data to the LCD (only part of the screen displays before the reset occurs) or during delay() while the LCD displays the data. Sometimes the resets occur immediately after another reset (within 1 or 2 seconds), over and over and over. Resets have happened in every part of the code, based on video reviews.
    Instead of providing screen shots of the LCD screens as resets occur, I'll just say that there are four "normal" screens that should repeat during normal operation, and that there are five error screens. Resets have occurred during every screen's display, and resets have occurred due to Watchdog intervention and non-Watchdog events. The Watchdog events are verified in the videos I've recorded (timestamps on the progress slider bar) showing a reset very close to, or greater than 8 seconds from the previous screen shot. The non-Watchdog events occur much closer together than 8 seconds apart, sometimes within a single second.
    I'm sorry about the .pdf and .zip files. I didn't know they were taboo. If I had a place on the web where I could post the items, I'd include a link to that; but I don't. As for my code, it's far larger than the 9,000 character limit. That's why I included the attachments.
    I've created a .TXT file of my full sketch, a .TXT file of what I've done, and a .JPG of the Uno schematic. I'll remove the original taboo files, and include the .TXT and .JPG files in my original post.
    ugfrog

Paul__B,
You say I need a proper, fully regulated power supply. Is the one I'm using:
https://www.openimpulse.com/blog/products-page/product-category/lm2596s-mini-dc-dc-buck-adjustable-power-supply-module/
not fully regulated? The website says it is regulated, and the data sheet says its output is regulated. I am not familiar with all these things, but I am trying to learn.
Also, I've read several times that it's NOT good to feed the 5v pin on an Arduino in order to power the board. I don't have the references now, but I've been doing a lot of reading, and have noticed that a few posts say not to do that. I've also read in the specs for the Uno that input voltages between 7vdc and 12vdc are acceptable. I guess I don't know whom to believe, and not being an electronics tech, well - I'm just muddling along asking those who know for help.
Please note that I have replaced the 'bad' .zip and .pdf files with generic .jpg and .txt in my original post. I hope that helps, too. I just want to get some help with this to get it to be reliable.
Thanks for your input.
ugfrog

Is the project still on a breadboard or have you used that simply to illustrate it. If you are having stability problems, maybe consider putting it all on a solder board.
What relay/relay module are you using?

ugfrog:
You say I need a proper, fully regulated power supply. Is the one I'm using not fully regulated? The website says it is regulated, and the data sheet says its output is regulated. I am not familiar with all these things, but I am trying to learn.

Yes, that one (all over eBay!) is fine, so set it carefully to 5.0 V and connect it to "5V" and ground on your Arduino. It is only missing one important feature which you do not expect to get anyway in "consumer-grade" equipment.

ugfrog:
Also, I've read several times that it's NOT good to feed the 5v pin on an Arduino in order to power the board. I don't have the references now, but I've been doing a lot of reading, and have noticed that a few posts say not to do that.

Yes, and they are nonsense, sadly including the Arduino site itself. :astonished: The microcontroller operates on 5 V and it needs 5 V. (Actually, it is not all that particular; it will work on a range of voltages but if the supply is unstable you are going to have problems.)

You use a good regulated supply such as the one you have, and use it to feed 5 V to the Arduino 5 V rail. Then you have adequate power to stably supply the Arduino and however many 5 V peripherals you have up to the rating of that regulator.

Note that you do have to be careful with relays - extra electrolytic bypasses of a few hundred µF across relay modules would be advisable - and you might be better off providing a separate regulator if you are operating motors. Mind you, it is relatively unlikely you would have a motor operating from 5 V. :roll_eyes:

ugfrog:
I've also read in the specs for the UNO that input voltages between 7vdc and 12vdc are acceptable. I guess I don't know whom to believe, and not being an electronics tech, well - I'm just muddling along asking those who know for help.

Yes, the UNO with its on-board regulator is essentially a toy. It is as I say for demonstrating microcontrollers and experimentation. But not really for "serious" work. If you have a rough source of 7 to 12 V - but it must not dip significantly below the 7 V, that is OK for playing, If you have a proper regulator, you do not waste effort using it to feed the under-rated (because of lack of heatsinking) on-board regulator.

I there a reason why you use "onewire" sensors as "threewire" sensors?

The diode across the relay transistor does nothing there, and can be removed.
Is this a mosfet?
If it's an NPN transistor, then you MUST use a base current limiting resistor.
A diode across the relay CONTACTS is also needed (a motor is an inductive load).

Best not to mix temp sensor ground with relay/transistor ground, although not a real issue with digital sensors.

Disconnect that wire to the DC socket, and try a 5volt cellphone charger on the USB socket.
Leo..

ugfrog:
I just want to get some help with this to get it to be reliable.

It's first necessary to establish whether or not you mean 'reliable again', or reliable. Your opening post mentions something about 'used to be reliable'. So you should indicate whether or not this system you're working with was once 'reliable' ---- as in working faultlessly for long periods of time ---- such as many months without glitches.

If the system did indeed work 'reliably' in the past, then the people here at least know that it 'used to work properly'. For such case, they might then ask you if you changed your system in any way, or if any changes occurred recently (hardware, power supply, wiring, software, watering system installations, etc.) --- to the environment...around the house etc.

Thanks, everyone, for your responses.

Southpark:
No, the system has never operated for many months without a glitch. Yes, I have made software modifications (enhancements) from time to time. No, the resets did not start at the same time as any of those enhancements. Yes, recently, I have made modifications to the wiring (see the "what I have done" document) and have tried several different power sources. I have also reverted to breadboard wiring in place of all soldered connections (because the TEST system works that way, but the PROD system was having resets). I know breadboards are supposed to be for prototyping, but when the soldered (and re-soldered) wiring didn't solve the reset problem, well - trying something is better than not trying.

Wawa:
In my "what I've done" document, I explained that I replaced the oneWire single bus with three separate buses because the star topography I was using was off-balance. One leg (TANK) was 6 feet, one leg (OUTS) was 15 feet, and one leg (COLL) was 51 feet. Changing the pullup resistance value on the single bus didn't seem to help, so I tried 3 separate buses. OUTS and TANK have 4.7k resistors, and COLL now has 2.2k.

The diode across the relay transistor was an idea I tried after finding it on the web. It didn't make any difference in performance. I'll remove it.
The transistor is a 2N3903 NPN. What value of current limiting resistor should I use on the base?
I'm not sure how I would apply a diode across the contacts of the relay. The motor is AC. How would I do that?

I'm working on the 5v power source suggestion.

Paul__B:
I'm glad the step-down voltage regularor I have is a decent one.

The power requirements for the Uno that I've read on the web have been confusing. Some say one thing, others say something else. You mentioned the Nano in a previous post - is it significantly better for "real-life, needs-to-work-flawlessly" applications? Can the Uno's code be ported directly to a Nano? What differences are there between the Uno and the Nano that might cause me to change wiring, code, anything else? I'm curious.

You said

extra electrolytic bypasses of a few hundred µF across relay modules would be advisable

I'm using a 12vdc coil SPDT relay with 30A contacts - no module. That relay makes a connection between the source side and the motor side of the hot (not common) wire of an AC power source. So how should I connect the electrolytic capacitor across "the module"? Does that mean across the coil? Or does that mean across the contacts (not sure how I'd do that with an AC motor)? Or was that suggestion only for a relay module?

6v6gt:
As mentioned in response to Southpark, currently the system is back on a breadboard. I did that because the soldered version wasn't the answer, and changes are easier on the breadboard. When the thing gets more stable, I'll go back to a soldered board.
See my response (just above) for relay information.

ugfrog

Thanks ugfrog for explaining the situation with the system. One possible approach to tracing the problem might be temporarily fall back to a simpler set-up --- for testing. Temporarily only.

This could involve involve making up test code (based on your existing code)..... focusing maybe on system monitoring..... and maybe not use watch-dog timer (for purposes of testing only). And see whether the system will be stable for this case. Then you can start to build up ---- or rebuilde --- step by step. It should be possible to eventually nail the issue.

An NPN transistor without base resistor is bad.
It will have stressed the transistor and the pin (>=60mA fault current).

Resistor value depends on relay current.
Use ~470 ohm if you don't know the relay specs.

Use a snubber circuit across the relay contacts for the AC motor (Google it).
Parts values depend on the motor.
Keep relay/motor wiring away from Arduino wiring.
Leo..

Southpark:
Your idea of starting with more basic functionality, then adding on until I find whatever the problem is has been on my mind for a week or so. I've forced it back, though, because it feels like losing ground. But I know it's not that way. Reverting is about the only thing I haven't tried. I do keep previous versions of all my sketches, no matter what the project, so it shouldn't be hard to go back to some more basic functionality, and add monitoring to help diagnose what goes on. I'll just have to watch the system constantly during the testing time to make sure the recirculator pump pumps when it should. No vacations this summer!

Wawa:
Thanks for the info about the transistor's base current-limiting resistor. I had no idea. I'll do that one right away. For me, even basic electronics is always surprising me with little things I needed to know, but didn't.
I'll also check out the snubber circuit for the AC motor. I don't know what that is yet, but Google is my friend!

ugfrog

ugfrog:
I'm glad the step-down voltage regulator I have is a decent one.

As far as we know.

No-one has responded to my quip about "something missing". What it lacks is a safety "crowbar" circuit to prevent it applying its full input supply voltage to the output if it should fail. Arguably, in this unlikely but definitely possible event, it is cheap enough to replace both the regulator and what it powers - the Arduino. It represents a balance of cost considerations in engineering practice.

ugfrog:
The power requirements for the Uno that I've read on the web have been confusing. Some say one thing, others say something else.

Such is life. :roll_eyes:

ugfrog:
You mentioned the Nano in a previous post - is it significantly better for "real-life, needs-to-work-flawlessly" applications?

It is cheaper, smaller and generally used with downward-facing pins so that it fits into a breadboard, socket or protoboard such as your "soldered" version - or can easily be used as a "daughterboard" on a custom PCB where it is pretty futile to try and duplicate the whole Arduino module.

The only thing a real UNO (not to be confused with the fakes so commonly sold as "UNOs" when they are actually clones or variants of the earlier Duemilanove) has that is different, is the second processor used as a USB interface, but you rarely want to use that second processor for any other purpose so a CH340 as on the "clone" Nanos will do just as well.

ugfrog:
Can the UNO's code be ported directly to a Nano? What differences are there between the UNO and the Nano that might cause me to change wiring, code, anything else? I'm curious.

Most Nanos are now sold with the same "Optiboot" bootstrap code as UNOs, or can be re-flashed as such, so you cannot tell the difference. Just different pin placement.

ugfrog:
You said I'm using a 12vdc coil SPDT relay with 30A contacts - no module. That relay makes a connection between the source side and the motor side of the hot (not common) wire of an AC power source. So how should I connect the electrolytic capacitor across "the module"? Does that mean across the coil? Or does that mean across the contacts (not sure how I'd do that with an AC motor)? Or was that suggestion only for a relay module?

Schematic.jpg
Yes, I was referring to a relay module. You clearly must have a transistor controlling the relay so it all forms a "module" anyway.

The base resistor is important. You already show a "kickback" diode across the relay coil so that is sufficient. A diode across the transistor is misguided, it needs to be across the relay coil but not actually at the relay coil.

The capacitor should be placed across where the power - 5 V or whatever - supply comes to the control transistor; you effectively have the diode and transistor in series connected across the capacitor which is fed from the power supply, the relay coil then connects across the diode by whatever length of wires is required.

It is important to keep wires paired, the two wires to the relay should travel together; the two wires from the power to the relay "module" should be together as in fact should be the power - and control - wires to each other part of the circuit. This is to prevent both radiation and pick-up of interference from impulses.

As Wawa points out, you will also want a "snubber" across the relay contacts.

ugfrog:
I do keep previous versions of all my sketches, no matter what the project, so it shouldn't be hard to go back to some more basic functionality, and add monitoring to help diagnose what goes on. I'll just have to watch the system constantly during the testing time to make sure the recirculator pump pumps when it should. No vacations this summer!

It's definitely great to hear that you're very thorough in what you do, including storing previous versions of code.

There's nothing wrong with keeping your system as-is to see if the issue can be traced with the recommendations of everybody here (and your own effort). Scaling back can always be done in the future, at anytime.

For now, it'll just be interesting to see what events or conditions are different between the 2AM to 7AM period and the rest of the day. Eg....... any operations or functions that the arduino does more of from 2AM to 7AM?

Questions like ... is there more activity during those early hours? Or less? If there is supposed to be less activity in the early hours....... less switching, less sending of data signals to the LCD etc.... things like that.

Also...... could maybe see what happens if you power the LCD with its own voltage source....just for testing purposes.

Paul__B,
Thanks for all the info. I've removed the diode that was across the transistor, and have installed a 470 Ohm resistor between the Uno pin and the base of the transistor. Thanks, too, for the Uno / Nano info. I'll have to look more closely at the Nano.

Southpark,
The times when the resets happen most often (2:AM to 7:AM) do not seem to have any obivous differences. Everything in our house has been more or less shut down after 9:PM. We arise and start doing things in the house around 4:30AM. The utility power grid has more use during the day than in the 2:AM to 7:AM timeframe, but I can't see anything special about those times. As for the code, it doesn't have a clue about what time of day it really is. There aren't any conditions when the program should behave differently with respect to timings of the screens, of data capture, or anything else. Plus, it doesn't seem to matter when I load a sketch to the Uno (early morning, evening, afternoon). It keeps failing in the early morning hours.
Separate power for the LCD might be good to try. I suppose I would have to connect the grounds of the two supplies together, right?