I was thinking I could add a detail that if you remove the 6CT expander header pin for CT12 it would be possible to use 11 CT sensors and the analog input.
Hi @rupert - thanks for raising this too. Iāll update the TVS symbol, it was copied from the original and the one Iām using is bidirectional (Toshiba DF2B7AE,H3F) - Iām in the middle of updating all the manufacturers, part numbers, and distributor codes right now but wanted to push the change for the analog input quickly.
Itās placed there to protect the AC coupling cap, which is only rated to 10 V. Full disclosure, Iām not an expert in ESD protection and Iām going by rules of thumb and datasheet recommendations so please feel free to correct/suggest anything in this area.
TVS diodes on the other inputs would be a good move too but will need to be careful with the clamp voltage as they are direct inputs.
@Robert.Wall - itās a small overhead to do the zero crossing detection in software. Unfortunately the built in comparator is on the same pins as the ADC so I have to use an external one for the emonPi3 (it would be feasible with fewer CT inputs). Iāll do a comparison of the two methods - the space where the comparator is could be used for a time base better than the internal RC oscillator (0.15% as discussed) if that was a more productive use of board space and pins?
Hi @awjlogan - thanks for the reply. I will admit that Iām not an expert in ESD protection either. The use of a unidirectional TVS at the input did look a bit odd but the fact that itās bidirectional to protect the AC coupling cap explains a lot.
One point that perhaps needs to be considered is whether the OEM test house does ESD testing during certification? And if so what method is used?
Depending on the level of detail, I think ESD design can be quite complicated!
On another note, itās interesting that you mention the the CPU clock. I did notice that the emonPi3 CPU didnāt have a crystal, whereas previous models (e.g. emonTx4) used a crystal. However I donāt know the timing requirements needed for emonTx power measurements!
Thanks to all involved for the work being done on the eemonPi3.
The standard is IEC 61000-4-2, which defines a number of levels of increasing energy and power. Definitely one to get in touch with the certification house before the final production run!
timing requirements
For the basic energy monitoring system, it doesnāt have to be anything special. The assumption is that the mains frequency is consistent enough (obligated to be Ā±1% in the UK) to use - the firmware converts the report interval in seconds into a number of mains cycles and uses that to determine when to send a report. However, Rob and I have been discussing some more advanced (future) features where a more precise local time source would be useful. The ATSAMD has a better onboard oscillator than the AVR, but still no where near as good as a dedicated oscillator.
thanks to all
Youāre very welcome, and thank you your constructive feedback
I did a little internet trawl on ESD earlier, and found the following, which may be useful:
I was wondering what was the surge voltage* rating of the 6.3 WV / 10u input capacitors. The ones used in the emonTx4 are yageo CC0603KRX5R5BB106, and according to their data sheet
although they donāt have a surge voltage* spec, it seem that they are tested at 2.5 x Ur which I presume means 2.5 x 6.3 = 15.75V (bottom of page 17).
not sure if this is the correct term - it was used on big electrolytic can style capacitors!
Looking at the ATSAMD21J17A-M data sheet, Section 37.10 Injection Current gives the spec limits for the maximum current injection into / out of an I/O pin by voltages above Vdd or below GND, at both Vdd: 3V < Vdd ā¤ 3.6V and Vdd: Vddā¤3V.
Hi @rupert - Iāve added ESD protection to all the inputs and around the buttons. As the TVS diodes will breakdown at ~5V, we need to limit the current into the pins (1K1 is the calculated value, but 1K is fine and easier for BoM purposes); this is R7, R46, and R48 for the pulse and analog inputs. The buttons already have the series resistance in line. You can get the update on commit 763795a. Iāve also added you to the acknowledgements, thanks for your input on this.
@awjlogan
Thanks for the update, and thanks again for all the work everybody is putting in.
Itās all looking good! Good luck with powering it up when it arrives!
Hello all - just a very quick update, itās been a little while! Iāve made a few hopefully final tweaks to the board (not too much visually different):
The RasPi header is now on the top side, like a lot of HATS. This allows us to go single sided for assembly. The Pi mounting remains the same.
The three screw terminal headers are more generic now, and the software follows this. The āanalogā one can do pulse and analog, and the other two are now both selectable in software to be OneWire or pulse inputs. It would have been nice if all three were identical, but thereās not enough pins available on the micro to do that, unfortunately.
The indication LED is now on the front panel and is bi colour for more informative visual indication.
Marked the hardware zero crossing detection as do not populate. I think the use case is actually pretty limited, and itās quite expensive in terms of cost and single line BoM entries.
A lot more focus on software lately, particular highlights:
Software USB stack is now working, so end users no longer need a Pi attached or a USB/serial adapter with wires.
USB UF2 bootloader. The emonPi3 looks like a USB drive and users can just copy over new firmware without any specialist hardware.
Working with @Robert.Wall to port over the AVR-DB CM library to the new system.
As mentioned above, more flexibility in the I/O connections.
As ever, very happy to look at feedback and suggestions
@awjlogan Thanks very much for the update. A lot of progress - thanks to everybody .
A couple of comments;
A good idea to go single sided for assembly. As the RasPi header is now on the top side, does this mean that a 40 way stacking header will be needed? I donāt know if this has any mechanical implications.
Looking at the latest (c4595b5 I hope!) schematic - we now use separate inputs on the CPU for the analogue input and CT12, to avoid conflicts when the 12 CT expansion board is fitted.
Before this change, the analogue input had a 3.3k / 10nF anti alias filter, which has now disappeared with the change to separate inputs. Is this significant?
I would guess that the anti alias filter (time constant = 33uS) wouldnāt affect the pulse input?
Sorry that I didnāt notice this earlier!
No change to the mechanical setup - the Pi stills mounts from the underside, this just moves the mounting hardware to the top side. What would be nice would be to use the 40 pin RPi header rather than the (very) old 26 pin one. This wonāt fit with the current CT expander board as it overlaps with the header on the emonPi, but might be possible if @TrystanLea would be keen for a respin of the CT expander. The advantage here is just cost - the 40 pin header is now standard, so the mounting hardware is much cheaper than the older 26 pin header.
I removed the AA filter on that the āanalogā input, yes. I had thought about making it aconfigurable OneWire input as well, where the AA filter would interfere. Iām not convinced thereās a case for 3x individual OneWire interfaces, so could easily put it back there.
One thing I would like to do is move the reset button, and hence access to the bootloader, to one of the panels but thereās no space available there. To reflash the board currently, you either have to remove the board from the case for physical access to the switch or ādouble resetā through the attached Pi. May be possible with some shuffling, weāre going to respin the header side anyway as it brings out the indicator LEDā¦
Good to hear that there are no mechanical changes. Sorry but Iād forgotten that the emonPi3 just used a 26 pin connector, rather than a 40 pin one.
With regards to the CT expander board, wonāt the emonPi3 expander schematic be different to the emonPi2 expander? See below / per input ā¦
As OneWire devices (e.g DS18B20 temperature sensors) have their own individual addresses, you can connect several to one OneWire interface, so I think two OneWire interfaces should be fine. Perhaps a new āTerminal Block Breakout for DS18B20ā (see shop) with three pin pluggable terminal block inputs, rather than RJ45 would be useful?
With regards to the reset button, can it be accessed in a similar manner to the display button (SW1), by an extra hole in the display panel? To prevent accidental use, the button could be recessed below the surface of the panel. And should the indicator LED be on the display panel too (perhaps through a window) ? Just to avoid confusion, by ādisplay panelā I mean the blue plastic panel through which you look at the OLED display.
Yes, the inputs are slightly different but compatible. The most important thing is the bias point at 1/2 Vref. In the Pi3 this is derived directly from the reference, whereas in Pi2 it comes from the noisier/less stable 3V3 line. If we want to change this, it would have to be a full respin of the CT expander board and a small modification to the Pi3 board, which is an OEM shop decision depending on their stock levels and future plans; @TrystanLea, @glyn.hudson or @Gwil might be able to chip in. Side note, I love your schematics - I assume theyāre hand drawn? Unfortunately my hand drawn schematics are much more of the Bob Pease varietyā¦
Yes, in the current 0.1 board thereās a single OneWire input and a configurable number of maximum supported sensors (it does a search for available devices at reset). For 0.2 onwards, Iāll need to refactor a bit to handle the multiple physical lines (although each physical line can still support multiple sensors). Thereās no provision on the Pi2 or Pi3 for the RJ-style OneWire connector.
It could, but again an OEM shop question. The end panels are cheaper and easier to modify, so that would be the preferred minimum change option. The status LED would also then require a light pipe to the top. You can reset and enter the bootloader from an attached Pi, but thatās obviously a little clunky (and no good for the Tx version without the Pi). I lean toward having it on the front panel for flexibility and mechanical stability (@gwil mentioned the long stem for the display button is a pain already) but can certainly see the advantage to the top panel.
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)
I faced this problem in a project where the frequency was allowed to vary +/- 5%, and the first implementation was to compute the rms value on the number of samples per period. It was not providing stable results.
We then move to an implementation with a moving exponential average which has provided good precision perfomance as well as less compute power.
Of course at start it need some time to stabilize to the correct value
Here is the code:
#define MOVINGAVGSAMPLES 6000.0f // number of samples for 10 periods at nominal frequency
static flt32_t f32_Avgcoeff = expf((-1.0f)/MOVINGAVGSAMPLES);
flt32_t ComputeRMS(flt32_t Value)
{
static flt32_t f32_RmsValue = 0.0f;
flt32_t f32_square = Value*Value;
f32_RmsValue = sqrtf(f32_square + f32_Avgcoeff* (f32_RmsValue*f32_RmsValue - f32_square ));
return f32_RmsValue;
}
@awjlogan - thanks for the update - comments in order below ā¦
The anti-alias filters on the emonPi3 inputs have a delay of ~0.6 degrees at 50Hz, so if the emonPi2 expander is used, the phase calibration/correction constants for inputs 7-12 may need to be slightly different to those for inputs 1-6?
On the subject of my schematics - some history - They are hand drawn. Early in my career in R+D, there were no CAD tools. The design engineers drew the schematics for their projects. They were hand drawn using pencil and ruler on A0 sheets of matt transparent mylar film. These sheets were copied onto treated paper using a flatbed whiteprint diazo (āammoniaā) machine. The copies were used by other departments during the project development, until they were redrawn and published in the manuals. So I had a fair bit of practice hand drawing schematics!
The first CAD tool that I used to draw schematics was Orcad SDT for DOS on a 286 PC with a pen plotter.
In emonLibDB, I made the phase correction for the voltage and current inputs separate. The āUSAā pre-set calibration in the sketch should use the phase error because itās different for the emonVs when running on 120 V vs 240 V, but nobody seems to bother. Most users appear to be ignorant or unconcerned, probably because loads with a power factor approaching zero (where the error matters) donāt make a significant contribution to overall energy consumption.
Been there, done that, but using a draughting pen and Indian ink.
I usually used a hard green ink eraser, but the chief draughtsman could āshaveā the ink off with a hand-held razor blade, without marking the surface of the film!