As we announced in the emonTx4 thread we have been working on a new energy monitoring platform to address the constraints imposed by the existing emonPi and emonTx hardware. This is a clean sheet design but is hardware and (importantly) software compatible with the current generation of platforms. The target general availability date is mid to late 2025.
This thread is to keep people updated with progress - I can’t guarantee at what frequency, but when something notable happens. I’m also very happy to answer questions and (attempt) to include or change functionality that might be generally useful.
To kick things off, we’re at a point where I’m looking to do a limited “production candidate” of the board. Here is a 3D render of the v0.2 candidate (note that the screw terminals will actually be the same push fit connectors as the emonPi2 and emonTx4/5, I just didn’t have a good model of them):
The most notable change is switching the 8bit AVR microcontroller used in the emonPi2/emonTx with a modern 32bit microcontroller with a much richer set of peripherals. All the design files and firmware are fully open source and you can find them here:
Future plans include a small WiFi adapter, but I’m looking to get the core hardware and software functionality working before starting on that (I do have a board made up already, but it’s lower priority).
I’m looking to get the v0.2 production candidate out for assembly on Monday 10th June so if you have any feedback, questions, or suggestions before then I can try to get them in.
I’ve been having a look at the pi3-0.2 branch on KiCad 8.02. Please note that I am a complete beginner on KiCad, so I apologise in advance for any mistakes!
The schematic section Rasperry Pi Header (sic) has a note mentioning RPI_PRESENT but I can’t find that net - if it is a net?
In the schematic section Temperature, Pulse, and Analog Inputs I see that the DS1820/PULSE solder links on CN1 and CN2 have disappeared. I guess that the configuration is now done in the firmware - by the serial configuration?
Hopefully the choice for 2 pulse inputs and 1 DS1820 input is still available?
I think the idea was to use the ANALOG_INPUT as a second pulse input. Would this mean that CT12 (on the expansion board) is no longer available?
I don’t know if any other EmonPi applications make use of the ANALOG_INPUT.
In the schematic section Zero Crossing Detector, the trigger thresholds on the comparator are asymmetrical about Vref/2 (512mV). This will result (I think, assuming I’ve got it the right way round!) in a delay of about 3.6 degrees from the sine wave zero crossing in the H>L comparator output transition. The L>H output transition will have minimal delay. This means the mark/space ratio of the comparator output will not be exactly 50%. I don’t know what VSENSEpol is used for in the firmware so all this might be completely irrelevant!
With the ATMega 328 and the Atmel-DB processors, the zero crossing is detected when the first positive-going sample is itself positive. So the cycle will never start at the zero crossing, but up to one sample set later. This is how Robin did it in his Mk2 PV Router, from which Trystan derived emonLibCM, and it seems to have been OK for a few years. The start of the positive-going cycle is only used to ensure that the rms average is taken over a whole number of cycles (or as close as possible) and no particular use has ever been made of the start of the negative-going cycle, so the M/S ratio and whether it is the true zero crossing is irrelevant. Only consistency is important. And the second and third phases’ averaging periods start at the same point, a long way from their zero crossings.
Hi @rupert - no need to apologise at all! So, in order:
Missed updating the text field, I’ve got some local changes here not on the branch yet. That should say DISABLE_EXT_INTF (with a bar over the top as it’s active low). The Pi can drive that signal low to set the shared interfaces (SPI and the I2C for the display) as inputs on the microcontroller - this prevents two master interfaces attempting to drive the same signal simultaneously.
Correct - rather than solder pads, one of the two “pulse” inputs can be set to a OneWire interface through R32. This is configured in software (not yet in the firmware). And yes, the obvious choice would be to use the ANALOG_INPUT as a second pulse channel; it would not be able to be used as a CT input simultaneously. That input has been used in heat pump systems, there’s a flow meter which has an analog output I believe (@TrystanLea or @glyn.hudson might be able to confirm).
Correct - there is some hysteresis applied by R68 so the switching point isn’t symmetrical. This prevents spurious interrupts triggered at the microcontroller due to the slow (relative to the comparator) transition through the set point (there’s some additional “digital” hysteresis in the microcontroller, see Figure 21-2 in the datasheet). As @Robert.Wall has mentioned, the zero crossing detection is used to get a consistent a reference point to start/end a cycle and only the rising edge is used (in the firmware, see driver_EIC.c:21).
@awjlogan , @Robert.Wall Thanks very much for the information to clear up my questions.
Re: 2. Would it be possible in the future to move the USERbutton from U3 CPU pin 20 to a digital pin (pin 2 isn’t connected on the pi3-0.2 branch schematic at the moment). This would allow pin 20 to be used as an extra ADC input ( AIN(19)) so there would be a separate input for CT12?
Or pin20 ( AIN(19)) could be used for ANALOG_INPUT while pin pin 17 ( AIN(16)) could be dedicated to CT12.
Seems a shame to loose CT12 when ANALOG_INPUT is being used, when it could be avoided!
I knew there would be little point in worrying about the “end effect” as long as it was controlled, so I hadn’t bothered. I’ve just done the sums:
Sample rate: 26 sample sets per cycle (-DB, the ARM processor should be better)
Cycles per second: 50
Averaging period: 10 s
rms voltage: 240.
Number of sample sets per averaging period: 26×50×10 = 13000
mean squared voltage: 240²
sum squared voltage per sampling period: 748800000
Now assume the worst case: add one extra sample² of 340 V
sum squared voltage per sampling period becomes 748915600
the mean square becomes 748915600÷13001 = 57604.46
and the rms: 240.0093 V
I don’t think I’m worried about that. At 1 s averaging period, it’s ~ 0.1 V so where the sampling period runs from 120° away from the zero crossing, then it might start to become significant, but still less than 0.2% of the reading.
Hi @rupert - yes, that’s a good idea. The USER LEDs and button are very unlikely to be exposed in any OEM product, and they are now DNP anyway. I’ll move the calibration inputs up a pin (just for reference, the ADC inputs for monitoring need to be contiguous as it automatically scans through channels) and remove one of the LEDs.
Are you using c.t.12 input for analogue, or the next input in the scan sequence? Because of the bias chain (part of the expansion card), using c.t. 12 effectively precludes fitting the 6-channel expansion card so limits it to c.t’s 1-6. I know this makes the main board not directly equivalent to the -DB version, but on the face of it, not a major problem.
Not sure I follow this? Is it about compatibility between the emonPi2 6CT expansion board and the emonPi3?
The emonPi2 6CT expansion board has individual bias chains for the inputs, so the CT12 output from the board is biased at 512mV. I can see that plugging an emonPi2 6CT expansion board into an emonPi2 will bias up the ANALOG_INPUT, as the ANALOG_INPUT and CT12 are connected to the same CPU ADC pin (37, PF3). So if you want to use the ANALOG_INPUT on terminal block CN3 with a 6CT expansion board plugged in, you will find that the ANALOG_INPUT is biased up at 512mV. I don’t think this information is in the emonPi2 Docs.
On the emonPi3 we are proposing separate ADC inputs for CT 12 and ANALOG_INPUT, so the CT12 input would be biased at 512mV, while the ANALOG_INPUT would have no bias.
Also the emonPi3 has anti-alias filters on CT1-6 and so I would assume the emonPi3 6CT expansion board would have anti-alias filters on CT7-12. These are not present on the emonPi2 6CT expansion board, so the expansion design would need to be different for the emonPi3.
EDIT
The reference voltage supplied to the emonPi2 6CT expansion board is 3.3V, while the reference supplied to the emonPi3 6CT expansion board is 1.024V. So the two boards will also require different reference dividers to give 512mV bias.
If that’s the case and it’s no longer a direct replacement for the -DB processor version, then everything seems to be OK and this is a definite improvement.
[Edit] I thought I was right: I’ve just checked on the only KiCad drawing I have and the place for CT12 on the main pcb header is indeed labelled ‘analogue input’.
Hi @Robert.Wall - yes, on the version referenced (39887e) the ANALOG_INPUT and CT12 are on the same pin (this is the same as the Tx4). @rupert’s suggestion is to split the inputs so there’s dedicated CT12 and ANALOG_INPUT channels. To do this, I’ve removed USER LED0 and reassigned some pins.
You can pick up the changes now, commit is ff2f8b4 - thanks for the feedback, this is a nice addition.
@Robert.Wall - interesting, thanks for the numbers. Do you think, then, that the extra comparator is superfluous and we should just do the detection in software? If so, we can remove it from the BoM - single channel comparators are surprisingly expensive (relatively) and it’s two additional single line items (the comparator and the 1 M resistor). I’ll leave the pads in place for the time being.
As always, it’s a matter of balancing the hardware cost against complexity and execution time in the software. The -DB processor had a comparator, which could be attached to a pin, but the pin was allocated to a current input - where of course it was useless. Had it been usable, it would have shaved a welcome bit of time off the first voltage processing. I haven’t yet got a feel for the difference it would make with your Arm, so I really can’t make the call. Clearly an error of that magnitude with a 10 s averaging period is not measurable under normal conditions, if you go down to 1 s averaging, then this statement is on the point of no longer holding true because it is significant as a proportion of the total error, and to remove it below 1 s you’re into the realms of tracking the line frequency with a PLL in order to guarantee averaging between the same points on the wave a whole number of cycles apart. It’s do-able, MartinR on the old forum did it with his PV Diverter and the emonTx2, but the general view is it’s not worth the trouble with a ‘long’ averaging period.
The thing to remember is it’s generally insignificant for the first or only phase, because the errant sample is always small. For the second and third phases, it’s guaranteed to happen around the ±120° point where the amplitude is peak×sin(120°), so the error sample amplitude is 0.866 times the value I assumed - better but not a lot.
void EmonLibDB_setAnalogueEnable(bool _enable)
Enables the (d.c.) analogue input. The analogue input uses the same multiplexer channel
as CT12, therefore it must not be enabled when the Expansion Board for CTs 7 – 12 is
fitted. The analogue input may only be used when when the Expansion Board is not fitted.
The voltage applied to the input connector should be within the range 0 – 1.024 V.
Damage is likely if it is allowed to go outside the range -0.3 – +3.6 V. Default: false.
(Documentation V1.0.0 for EmonLibDB V1.0.0 - 6/5/2023)
Unfortunately, I can only control the documentation that I publish on this forum. I have no control over anything that’s published elsewhere, and this includes documents which I’ve originally published here, when they appear somewhere else in maybe a different format.
I’m sometimes invited to comment before a document appears, but often I’m unaware that something has appeared as there is no mechanism in place to advise or to request advice about new items or updates.
I was just looking at the latest schematic (with the separate ANALOG_INPUT and CT12 ) when I noticed something I thought I would raise - about the input ESD protection diodes on the CT and VSx inputs.
I couldn’t see a manufacturer’s part number when I right-clicked on one of these diodes and looked at Properties, so I am assuming that they behave as a generic TVS (Transient Voltage Protection) diode would - which may not be correct! Also I do not know the clamping voltage, so I will assume ~ 5v to allow for no clamping at 3.3V The symbol used for them indicates a unidirectional TVS.
The voltage in the positive direction will be clamped by the TVS at 5V (Usually a specified parameter). The voltage in the negative direction will be clamped by the TVS at ~ -600mV (sometimes an unspecified parameter). This approximately 600mV is the forward voltage of a normal diode at 25 degrees Centigrade, and decreases by ~2mV per degree Centigrade. I.e. at 75 degrees Centigrade it will be 600-(50x2) = 500mV.
The CT and VSx inputs are 333mV rms sine waves, and so will have peak voltages of +/- 470mV. The ESD diodes are placed right across the inputs, so under normal circumstances, the voltage across the diode will be +470mV max positive and -470mV max negative. Now -470mV seems a bit close to the -600mV TVS clamp voltage.
Is this what is intended?
Or should the TVS diodes be in a different place - e.g. for VS1, should D7 be placed in parallel with C22 (i.e. right at the ADC input, where they directly limit the voltage to the CPU)?
It also has the advantage that any current caused by input over-voltage would be limited by R39 in this example.
I think this is how it was done on the emonTx3, emonTx4, emonTx5, emonPi, and emonPi2.
And should there be TVS diodes on the CN1-3 inputs?
It is mentioned in the section’s on the analog input, e.g: emonPi2, emonTx4. I can certainly make it clearer though. The analog input also requires firmware modification, compile and upload and careful consideration of the input voltage range 0-1.024V which is also covered in the documentation sections there.
