I have a Pico W set up in a boiler room in a tenanted building, where my objective is to exploit the pulse outputs from two electricity meters and two gas meters. This is also the room containing all the mains distribution for the bulding. My DevEnv was Arduino for this project, with Earl Philhower's suite of support libraries
I quickly discovered that what worked on my bench at home was NOT working in the target environment - the Pico W was resetting many times per day, so keeping running counts of meter pulses was not really possible.
There are several posts around the topic of unwanted resets, but those I found failed to provide any methodical means of troubleshooting. As an experienced Electronic Engineer, I find recommendations of 'change this, change that' until the problem goes away somewhat unsatisfactory - especially as I have the 'tools of the trade' - most importantly an oscilloscope
So here we go:
I had two problems:
1) The pulse counts were rising faster than they should be (i.e. my 'shadow' of the meter reading was creeping ahead of what the physical meters said)
2) After a short period of running (sometimes a day or two, sometimes just half an hour) the system was resetting
Armed with my trusty 'scope, I monitored one of the gas meter inputs. The gas meter contains a reed switch which closes and opens once each time the least significant digit rolls - there's a magnet embedded in the loop of the '6' on that reel! The Pico inputs are wired so that the reed switch on the gas meter pulls the GPIO low against its pull-up resistor.
The first thing I noticed was that - even with no gas flow, when the boiler switched on, there was a big spike on that GPIO input visible on the 'scope and BOTH the gas meter readings clocked up one pulse. My code uses interrupts, so even if the spike is of very short duration it is going to register.
Now the wire to the reed switch is unscreened, about 1m long, and when the switch is open, that means we have effectively put an antenna on the GPIO input. The pull-up resistance inside the RP2040 chip is between 50k and 80k according to the data sheet. That's quite a high impedance, so it won't take all that much to flip the input from high to low.
So the first thing I did was add a stronger external pull-up resistor (1k) and provide a filtering capacitor on each input (100nF).
I could have changed the connection to the reed switch to use a screened cable (I may still do that as a 'belt and braces' approach), but having these suppression components right next to the Pico W is good practice regardless
After half an hour or so of operating, the pulse counts recorded by the PicoW matched the increase in the physical meter readings.
So problem 1) has been solved.
The next thing that happened was that the Pico reset - again, luckily, as I was in the room, I heard the clicks from the relays inside the boiler and was able to correlate the resetting with the boiler changing state.
There are several possible reasons for a Pico W to reset, such as: Power problem, Watchdog timer, Software reset, RUN pin reset
Just on the off chance I did try a different power supply - the system was being powered from a USB power supply built in to a UK twin 13A outlet, and I wondered whether the quality was poor. To my not-very-great surprise, the problems were exactly the same with a 'known good' wall wart
Now there is a way to read the 'reset reason' in the library:Adding code to print this as my application started up quickly showed that the ResetReason was 'RUN Pin'.
Now I have nothing connected to the RUN pin - or do I?
In practice the PicoW has 0.1" header stakes soldered to it, and is plugged into IC socket strips on Veroboard.
So actually, the RUN pin has about 10mm of stake, and then about 15mm of PCB strip. So we have a 25mm long antenna soldered to the RUN pin.
I added a 100nF capacitor to ground and a 1k to the 3v3 line, so as to ensure this pin (like the GPIOs above) can't flap about in the breeze.
Since doing that, the board has not reset. and I can see that there have been several periods when one of the boilers has been running (the other only runs very seldom as the tenants in that unit tend not to use the heating much). So I'm cautiously optimistic that problem 2) is solved - fingers crossed.
Does that mean I can now relax?
Not quite.
The root cause of the problem is that the boilers are emitting RFI spikes. I don't think they should be doing that, so I'm going to ask a suitably qualified Gas Engineer to verify (and if necessary replace) the various suppression components.
I will re-visit this post in a few days with an update as to whether there have been any unwanted resets, and add a few photos and diagrams.
I quickly discovered that what worked on my bench at home was NOT working in the target environment - the Pico W was resetting many times per day, so keeping running counts of meter pulses was not really possible.
There are several posts around the topic of unwanted resets, but those I found failed to provide any methodical means of troubleshooting. As an experienced Electronic Engineer, I find recommendations of 'change this, change that' until the problem goes away somewhat unsatisfactory - especially as I have the 'tools of the trade' - most importantly an oscilloscope
So here we go:
I had two problems:
1) The pulse counts were rising faster than they should be (i.e. my 'shadow' of the meter reading was creeping ahead of what the physical meters said)
2) After a short period of running (sometimes a day or two, sometimes just half an hour) the system was resetting
Armed with my trusty 'scope, I monitored one of the gas meter inputs. The gas meter contains a reed switch which closes and opens once each time the least significant digit rolls - there's a magnet embedded in the loop of the '6' on that reel! The Pico inputs are wired so that the reed switch on the gas meter pulls the GPIO low against its pull-up resistor.
The first thing I noticed was that - even with no gas flow, when the boiler switched on, there was a big spike on that GPIO input visible on the 'scope and BOTH the gas meter readings clocked up one pulse. My code uses interrupts, so even if the spike is of very short duration it is going to register.
Now the wire to the reed switch is unscreened, about 1m long, and when the switch is open, that means we have effectively put an antenna on the GPIO input. The pull-up resistance inside the RP2040 chip is between 50k and 80k according to the data sheet. That's quite a high impedance, so it won't take all that much to flip the input from high to low.
So the first thing I did was add a stronger external pull-up resistor (1k) and provide a filtering capacitor on each input (100nF).
I could have changed the connection to the reed switch to use a screened cable (I may still do that as a 'belt and braces' approach), but having these suppression components right next to the Pico W is good practice regardless
After half an hour or so of operating, the pulse counts recorded by the PicoW matched the increase in the physical meter readings.
So problem 1) has been solved.
The next thing that happened was that the Pico reset - again, luckily, as I was in the room, I heard the clicks from the relays inside the boiler and was able to correlate the resetting with the boiler changing state.
There are several possible reasons for a Pico W to reset, such as: Power problem, Watchdog timer, Software reset, RUN pin reset
Just on the off chance I did try a different power supply - the system was being powered from a USB power supply built in to a UK twin 13A outlet, and I wondered whether the quality was poor. To my not-very-great surprise, the problems were exactly the same with a 'known good' wall wart
Now there is a way to read the 'reset reason' in the library:
Code:
RP2040::resetReason_t rr = rp2040.getResetReason(); restartPage += resetReasonText[rr];Now I have nothing connected to the RUN pin - or do I?
In practice the PicoW has 0.1" header stakes soldered to it, and is plugged into IC socket strips on Veroboard.
So actually, the RUN pin has about 10mm of stake, and then about 15mm of PCB strip. So we have a 25mm long antenna soldered to the RUN pin.
I added a 100nF capacitor to ground and a 1k to the 3v3 line, so as to ensure this pin (like the GPIOs above) can't flap about in the breeze.
Since doing that, the board has not reset. and I can see that there have been several periods when one of the boilers has been running (the other only runs very seldom as the tenants in that unit tend not to use the heating much). So I'm cautiously optimistic that problem 2) is solved - fingers crossed.
Does that mean I can now relax?
Not quite.
The root cause of the problem is that the boilers are emitting RFI spikes. I don't think they should be doing that, so I'm going to ask a suitably qualified Gas Engineer to verify (and if necessary replace) the various suppression components.
I will re-visit this post in a few days with an update as to whether there have been any unwanted resets, and add a few photos and diagrams.
Statistics: Posted by Chris_G_Miller — Thu Apr 10, 2025 12:34 pm