Could one be added? A plastic/3D Printed case would ease that issue.
Not easily - the ESP32 module is available with a U.FL connector in place of the PCB antenna, but that makes the antenna a requirement. It would also require an additional cutout or structure in the front panel to accommodate it.
Cost is a killer when it comes to casing - itās a relatively big board, so a 3D printed one would be a long print (so not cheap) and anything custom is expensive. When designing things, it should always be case first and fit the PCB and components inside that.
However, the end plates are plastic so it would be best to check this is actually a problem before trying to fix it ![]()
What board is this? I donāt think Iāve heard of it before.
You can find variants with external antenna, at least the version where the pins are on the border.
What board is this? I donāt think Iāve heard of it before.
@Gwil I designed a small add on board which fits the Tx4, Tx5, and upcoming Tx6 - similar to the board linked in the thread below. Itās just a simple ESP32 board with headers, and Fred and Brian did a lot of work on the ESPHome software integration for HA.
Hi Fred - hereās an image of the adaptor board connected to one of the emonPi3 prototypes. [E26FE5EF-FD39-495A-9A11-B6C4DBD15FA7_1_105_c] I donāt know enough about the HA integration side to comment too much on the data thatās available and how itās parsed. For example, the emonPi3 will always output all the voltage and CT channels, even if they are inactive, as 0 is still a valid value. If the HA integration can filter out values that are known to be unused, that would be best - is that the ā¦
You can find variants with external antenna, at least the version where the pins are on the border.
@FredM67 - yes, you can. The 1U variant of the ESP32-C3-Mini Iām using has only a U.FL connector so you must either have a feed through to an external coax socket or an antenna (which doesnāt solve the original issue). Either way, itās quite a bit more cost and āeffortā to include. Anyway, it may not even be a problem so get that testing out the way first ![]()
I hope I am a contributor here, but please excuse me if Iām a detractor.
I was wondering, āWhat is the purpose of the zero-crossing detector?ā Is it just used as a trigger to start sampling? It seems to me that it doesnāt matter where in the cycle the sampling starts, just as long as there are a known integer number of samples per cycle. At what point in the cycle the sampling starts is arbitrary as long as it ends at the same point.
The frequency could be determined from the data of the previous cycle which could be used to adjust the time period in which a sample is taken so that the samples are evenly spaced. Extra samples could be taken for the sole purpose of determining frequency.
Hi @Grape - itās so thereās always a whole cycle captured. The mains frequency is not fixed so you canāt rely on the tick capturing a full cycle consistently. (Also the microcontrollerās timer is not absolutely constant). If you donāt capture a cycle, your RMS calculation is skewed.
In the Pi3, samples are taken at a constant rate derived from the internal oscillator. The phase between the voltage and current samples is calculated assuming a constant sample rate. This is used at the end of the accumulation, so you canāt change the rate on the fly.
Essentially, using the zero crossing has no down side (no need for a precision oscillator, full cycle capture) for very little software cost and avoids a lot of complexity.
I hope I am a contributor here, but please excuse me if Iām a detractor.
And no excuses needed ![]()
The mains frequency is not fixed
A note of clarification: The UK statutory limit is ±1% (49.5Hz - 50.5Hz) and National Gridās operational limits are ±0.4% (49.8Hz - 50.2Hz). There are links enabling power to be exchanged with Ireland, and mainland Europe where the frequency tolerance is much tighter, but these links are all direct current.
Itās worth noting that on solar installations, when running off grid, eg during a power cut or in an off-grid house, the frequency from the off-grid controller can rise up to 52 Hz. This is done to cause the solar inverters to reduce solar output in the event that the load (or batteries) canāt sink the solar power being produced.
If the frequency does rise above the statutory limits, then the point of the discussion hasnāt changed, the full cycle - possibly the next after the anticipated one - will be included in the rms calculation just the same. And the inverse will happen if the frequency drops.
Yes I agree - my point was more of a warning to anyone coding around assumptions that the frequency would remain in the tight limits set by the regulations for the public grid, when it could be off by 4%, especially as solar and battery are probably quite popular with the OEM community.
Weāve had that from a user in continental Europe, whoād assumed that because we exchanged power, our grid was locked to theirs. The links being D.C. mean that assumption wasnāt valid.
And if my memory serves, Robin Emley encountered the situation you describe with his Mk2 PV Router and an off-grid purchaser.
Essentially, using the zero crossing has no down side
As I rethink it, zero crossing is essential!
samples are taken at a constant rate
got me thinking and I think that this is a possible scenario:
Initialize end time and number of cycles to sample
Wait for - to + zero crossing interrupt
note start time
Interrupt to occur on + to - zero crossings. (Interrupt to: increment number of cycles sampled and, if number of cycles sampled is equal to number of cycles to sample, note end time)
- Repeat for each CT port in use: Select V1, A to D sample, store data, select CT, A to D sample, store data.
- send data to Rpi(?) (since every sample is sent to RPi(?) no count is needed, the RPi(?) will count)
- if end time not noted, go back to 1. (interrupt will count cycles).
- note end of sampling time
Send end time, start time and end of sampling time to RPi(?)
The system just samples as fast as possible until the cycles to samples is complete. In this is the scenario, sample time is not important. Nor how many CTs. Not even time in interrupt. Everything is all sorted out by the zero crossing interrupt.
The bummer is send data to Rpi(?) because if I remember the data sheet for the [chip doing all this, citation, please] correctly, it has limited data storage and must send the data to the RPi(?)
If I understand correctly, to obtain the best accuracy (not skew the RMS calculations), what is needed is an integer number of samples per [integer number of] cycle[s], which is provide in the above scenario.
In order to āsqueeze blood from a stoneā (further increase accuracy): The cycles divided by the end time minus start time is the line frequency. The sample rate is the (end of sampling time minus the start time) divided by the number of samples is the sample time. If the (end of sampling time minus end time) divided by the sample rate is more than 0.5, keep the last sample, otherwise drop the last sample.
3 phase and split phase systems would be similar.
Another thought to keep you awake at night, a waveform that is different from cycle to cycle? ![]()
Another thought to keep you awake at night, a waveform that is different from cycle to cycle?
What makes you think the waveform isnāt different from one cycle to the next? Iām thinking particularly current, as various loads - like inductive hobs - switch on and off or chop the wave up in varying proportions to regulate power, but because the supply has a non-zero source impedance, the current wave influences the voltage wave too.
The system just samples as fast as possible until the cycles to samples is complete. In this is the scenario, sample time is not important. Nor how many CTs. Not even time in interrupt. Everything is all sorted out by the zero crossing interrupt.
The bummer is send data to Rpi(?) because if I remember the data sheet for the [chip doing all this, citation, please] correctly, it has limited data storage and must send the data to the RPi(?)
No, you need to have the time between the voltage and current measurements to account for the phase difference. Hence why the constant sample rate is required (as an additional item, itās needed to for the correct AA filter frequency). Have a look in the source for whatās happening. Thereās also no point in sampling as fast as you can as the bandwidth of the sensors is only about 1 kHz. For the Pi3, it samples at 4.8 kHz and is then downsampled to 2.4 kHz which more than covers anything you can capture using these components.
Time wise, thatās essentially what is being done - the report time is converted to the nominal number of cycles and when that number of cycles has been detected by zero-crossing, then a report is triggered. The actual number of samples taken gives you the exact time rather than coarse time.
Another thought to keep you awake at night, a waveform that is different from cycle to cycle?
If that were not the case, we could get rid of all this nonsense and just plug some numbers into the calculator ![]()
Apologies for this mundane comment on this post, but is there an update on expected timelines for the new emonPi3/Tx6 availability in the shop? I see we were looking at end of 2025, so just wondering if that is still the case. Thanks!
Hi @TurnipTales - welcome, and no worries at all! At a stretch, we might manage 2025 by the letter, if not spirit, of the law! Thereās some supply issues for the accompanying emonVs and a bit more testing of the whole package. Sorry not to have a better answer, but donāt want to rush out something not fully validated.