I have had my energy monitor panel installed for about three months now and everything seemed to be working properly. Using an ESP32 microcontroller and the Emon library software found on the Arduino IDE 2. platform.
I have started to see intermittent voltage drift on the main service panel’s two line voltage inputs that feed the modified ZMPT101B voltage transformers (per the astute Mr. Hall’s recommendation) and their associated circuitry.
The voltages are climbing quite high to well over 200 volts per line input. My Fluke meter readings diagree with these values. The thing is it is doing this on BOTH inputs (Line 1 & Line 2) and the erroneous values being reported are not identical or close to being the same. So I feel like it is not necessarily the hardware at fault.
Are there any parameters inside the EMON software that could be adjusted to try and counter this drifting? And the inputs never drift downward, it is always elevated.
Currently I am trying to use software to eliminate these elevated values by monitoring them over ‘X’ EMon cycles to see if they have returned to normal levels. The high values can remain for 3 to 5 minutes from I can tell so far.
So I am interested in my options in dealing with this as these erroneous inputs obviously destroy any validity to the data EMon generates.
thanks…
edit - I forgot to mention that whenever the ESP32 is restarted it takes several cycles for the EMon software to stabilize. Typically there will be very high voltage input readings (800+) but then they will always immediately fall to the actual values on the lines.
This is for a 120 V nominal line voltage? So nearly a factor of 2 times?
There will be numerous sources where that might originate, quite possible several are combining to produce a “worst case” condition. I know very little about the ESP32, so please bear this in mind.
You say you’re using the ZMPT101B isolating current transformer to measure the voltage. This works by converting the voltage to a current using one or several high value resistors in series, around 60 kΩ in total. Are these resistors stable in value, have one or more become contaminated and there’s a parallel current path that’s effectively lowering the resistance? Is one short-circuited?
The output from the ZMPT101B is also a current. This is converted to a voltage by its burden resistor across the output. This would need to increase in value to make the line voltage appear to rise. Is this still reading the correct value - is there a dry joint that’s increased the resistance seen by the c.t’s secondary winding, which will increase the voltage sent to the ADC?
The voltage is biased to raise the quiescent voltage to the mid-point of the ADC’s input range. This per se won’t affect the calibration, but if it was badly wrong, it would clip the input on one half-cycle and reduce the voltage reported.
The next thing to check is the voltage reference the ESP32 uses. Is this stable and correct? It might be from an internal band-gap reference, or it might use the power supply voltage as the reference. If the latter, is this stable and the correct value. A lower reference voltage will also have the effect of making the line voltage appear to increase.
Finally, is there a fault on your software that’s altering the calibration?
Well yes, but they were highly modified per your instructions to remove the circuitry that would adversely affect the readings.
By ‘dry’ are you maybe implying a ‘cold’ solder joint?
I am going to assume (dangerous, I know…lol) you are referring to the ESP32 power supply. The microcontroller is being powered by one of those universal “wall warts” that accepts anything from, say, 32vAC to 240VAC. It is tied to the service panel feeds, L1 & L2. If you are suggesting an unstable 5vDC to the microcontroller could create an issue I would have to agree. But this ESP32 will still operate with as little as 3.2 vDC feeding it; 5vDC being the upper value limit.
That is a huge question!!! I honestly cannot respond with an informed comment. That is why I was asking if perhaps some of the EMon parameters might need tweaking. I am more than willing to provide a copy of the code being used.
The fact that these erroneous values are happening simultaneously on BOTH line inputs makes me think it is more likely something in the software.
Right now all the data coming in is rock solid and right where you would expect it to be. But that is subject to change. Maybe it s the weather and doesn;t like increased humidity…lol. I could stuff the enclosure full of dessicant packs I suppose…haha. Trying to keep a good attitude about this as the project took alot more time than I ever anticipated and it has been performing very well until recently.
If your ESP32 does indeed use the power supply voltage as a reference, and your wall wart supply is drifting below 5 VDC, you’ll see the behavior you mentioned, despite the fact the ESP32 works with an input as low as 3.2 VDC.
I did miss that…thanks. Ok, if I understand this correctly IF IN FACT the EMon software is looking at the microcontroller supply voltage as a reference to what it is sensing at the line voltage inputs then any fluctuations would introduce an error, relative to the amount of fluctation.
There is no reason I should not change the supply volt source at this juncture. Priority 1.
edit -update: new power supply has been installed and instead of powering it from both L1 & L2
(240VAC) it is working from a 120 volt potential.
Probably - “dry” joint is the term I’ve always heard and used. One where the solder has not flowed and wetted both surfaces - or one that’s not even been soldered at all!
Bill’s confirmed that suggested that if it does use the 5 V d.c. as its reference against which it compares the line voltage. If that falls from 5 V to 3.2 V, your 120 V will measure 120 × 5 / 3.2 = 187.5 V
The data sheets and all the references I’ve ever found are remarkably silent about the ADC - so I’m really suspicious in this area.
Whether you’re using this in emonLib depends on if and how you’ve changed it. For the emonTx V2 and the emonTH, emonLib does use the Vcc supply as its reference but it compares that against its internal band-gap reference (which whilst its initial value is subject to quite a wide tolerance, the stability is good) to correct for variations - expected when supplied by batteries. You can set a directive to tell it not to do this if the supply voltage is stable and known and 3.3 V.
If this is the case, it points to hardware and maybe a failed or failing soldered joint or corrosion on a socket. How long has it been in service - since July I think, and what is the environment?
D’oh, I misread that, sorry Bill. And I should also have written “emonLib on the Atmel '328P uses the supply as the reference…”. But it might still be the case. The data sheets and tech ref. for the ESP32 make no mention of the reference voltage source, but the ADC appears to be able to measure a 3.3 V rail, which implies an internal reference to be able to do this. And if you can measure a 3.3 V, why do they make measuring it available? It’s not at all clear.
If the problem is not one of the things I’ve mentioned, then I’m struggling. If it restores itself without intervention, my money is on a dry joint and vibration ‘curing’ it temporarily. And we’ve all chased a few of those in our time - and they can be very hard to find; one I remember took me about a year to find, because as soon as anyone so much as touched the case, it went away for a month or more. It gradually got worse to the point where I could open the case and it didn’t go away - then I found it. 5 seconds with a hot iron and it was cured forever.
I admit a deficient solder joint could be the root of the problem but the odds seem slim that a solder joint is the culprit on each of the separate circuits since the failures occur simultaneously. And it took its time to emerge as the system has been operational for a couple months.
After replacing the 5v power supply the spurious readings are continuing. I have a counter that records how many times the EMon cycle input voltages are being “software clamped” (above 130) and it currently sits at 19 over the past 4 hours. Each count represents 10 cycles of the two Emon instances or about a minute total.
I am going to recheck my input calibration but I know they can’t be far off from when I tested them about two weeks ago.
No, but I find it odd that this anomaly is occurring at the same instant on both legs. Both input values are together skyrocketing before falling back to normal levels. Software clamping is my only option currently and since voltage typically varies little on residential feeds I would rather have to deal with voltage concerns over amperage. I am glad my energy provider’s meter is not suffering from this issue or I would need a bank loan most probably.
There’s surely one very obvious direction in which your thinking ought to be heading: you have one problem affecting both channels equally. And that comes down to power supply (both the 3.3 V or 5 V side AND the ground / 0V side) and the ADC reference. Then there’s the software - how have you customised emonLib for your purpose? Look at how it checks the supply voltage to measure it against the internal band-gap reference to adjust the calibration, and check how the ESP works and how the two work together. A problem there would affect both channels equally. I suggest you investigate and test on this basis until you can prove all the common things are correct and stable. And don’t forget the link that @dBC provided. If you do come to the conclusion that the ADC in your ESP32 is not up to the job, quite frankly I won’t be surprised. You only have to search this forum to find instances of people who’ve tried and failed with the ESP32, and people who gave up before they started and used an external ADC with the ESP32 providing the processing and WiFi comms etc.
I agree with that summation. I may decide to go with a non-wall wart more legitimate power supply unit that provides a clean stable reliable output voltage.
The ADC reference is something I have been reading about. Over on the Arduino forum I have read some discussion on the voltage reference.
[quote="jim-p, post:4, topic:1234184"]
The ESP32 uses an internal voltage refrence of 1.1V. So if you stay within the recommended operating voltage range, the ADC measurments will be within specs.
[/quote]
According to “Jim P.” if you stay within the analog input limits the ADC can be reliable. The voltage reference is completely stable and independent of VCC level according to those at the Arduino forum. That is not gospel but what was said. But even they admit that, as you have alluded to already, the ADC section of the ESP32 can perform questionably. The later version ESP32s, like the S3 supposedly have a superior ADC section.
And adding an external ADC interface may be a wise idea as you have suggested.
The ONLY parameter I have adjusted is:
```cpp
emon1.voltage(V1, CV1, 0.75); // Voltage: input pin, calibration, phase_shift; Mr. Hall recomends between 0 and 1
emon1.current(I1, CI1); // initial value: 1.732 -but that was when using an unmodified ZMPT101B
Is there a good place to learn how to make an intelligent customization of the stock EMon calibration values?
“Look at how it checks the supply voltage to measure it against the internal band-gap reference to adjust the calibration, and check how the ESP works and how the two work together.”
I asume that type of information would be at the Espressif site? We are quickly getting out of my wheelhouse. …lol…
edit update- after reading that link from @dBC I am of the mind to get th latest version ESP32 and seriously consider a seperate ADC module. They also mentioned that the WiFi componentry could create issues with signal processing stability. A lot to consider…
There must be something in the ‘Docs’ section under “Electricity Monitoring”, otherwise, if you need the exact detail, you’ll need to work your way through the maths of the library.
For the amplitude calibration, the easy bit to remember is the number you put in as the calibration constant is the physical value (be it voltage or current) which would (if it were possible) give 1 V at the ADC input pin. You can of course express that as an rms, a peak or a peak-to-peak value as long as both the quantity you’re measuring and the input pin’s voltage are measured by the same method.
For phasecal, you’ll need to set up a purely resistive load (say an electric heater of some sort with no fan motor or suchlike), and adjust on test to show power factor closest to 1.0, and bear in mind the phase error of your c.t. will vary according to the current passing, so it’s not an exact science.
If you use calcIrms( ) you need to set the number of samples according to the sample rate of your ADC to give as close as possible an exact number of mains cycles, and long enough so that the ‘end effect’ of not having an exact number of whole cycles is lessened.
I’ve already mentioned (without naming it) readVcc( ), which attempts to adjust the calibration to reflect the changing supply voltage. You need to ensure this is working properly with your ESP32, or if as you think the ESP32 is using its internal 1.1 V reference, disable it by putting #define emonTxV3 somewhere near the top of your sketch.
You gave me plenty of additional information to digest regarding optimizing the software. I appreciate that greatly.
Interestingly enough I have discovered after downloading the microcontroller yesterday with
additional code to monitor and restrict spurious increases in the voltage levels sensed that after
24 hours there has been no jumps in the sensed line voltages. Each line went up to just over 125 vAC for a brief period and then returned back to the 120-123 volt levels. And from what I have read residential line transformers here in the U.S. can be expected to vary by about 6% up and down from the 120 volt baseline. So those upper values I have seen the past 24 hours are realistic.
Why this microcontroller is behaving itself right now remains a mystery. But I do hope it continues.
My guess - and that’s all it is, is you’ve disturbed something and that’s resulted in the fault going away. I don’t like that sort of fault - they have a habit of coming back.
D’oh, I misread that, sorry Bill. And I should also have written “emonLib on the Atmel '328P uses the supply as the reference…”. But it might still be the case. The data sheets and tech ref. for the ESP32 make no mention of the reference voltage source, but the ADC appears to be able to measure a 3.3 V rail, which implies an internal reference to be able to do this. And if you can measure a 3.3 V, why do they make measuring it available? It’s not at all clear.