Sorry @Trytan, my profuse apologies for missing that! 
I had looked in a lot of places in the OEM site, but had missed the Docs / emonPi2 and emonTx4 / Temperature, Pulse and Analog sections! Silly me!
I would suggest:
Adding a Temperature, Pulse and Analog section to the emonTx5 Docs
Adding a note that a 6CT expansion board canāt be fitted if the analog input is being used, to:
https://docs.openenergymonitor.org/emontx4/6ct_expansion_board.html
Apologies again for the blunder!
Thanks @rupert, good suggestions!
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.
Thatās a very good idea!
It looks like this limitation will be removed in the emonPi3 and emonTx6, and the emonPi3 / emonTx6 6 CT Expansion board.
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.
Yes, nice work on all of this @awjlogan, look forward to catching up on Thursday 
ESD testing
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
https://www.mouser.co.uk/datasheet/2/447/UPY_NP0X5R_01005_4V_to_25V_V10-3003057.pdf
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).
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!
rupert
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):
A lot more focus on software lately, particular highlights:
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!
Hi @rupert - thanks for the message.
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ā¦
Hi @awjlogan - thanks for the reply
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.
Hi @rupert - thanks, replies in order below
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 ā¦
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.
A bit of a diversion but ā¦
It was easy to make corrections and modifications to pencil drawings on mylar. How was it done when using 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!