Hi, I have found a problem with emonTX when I started testing my PV diverting hardware and have written a new version that provides a solution by continuously monitoring 3 CT inputs + voltage. I have been running this for a few weeks now and thought I should post it for others to look at, comment on, suggest improvements and use if they wish to.
When I started to test my PV divert software I found the readings on my emonGLCD were very erratic with the original software.
My PV diverter is fed through the house consumer unit so it was reading house load + divert load on CT1, PV on CT2 and divert load on the third CT3. I changed the emonGLCD to deduct the CT3 from CT1. With steady loads on the divert hardware everything works fine with the original emonTX software. It was when I started to test my SSR based diverter with faster load changes that I noticed that readings from the emonTX were wrong.
The standard emonTX software is written to monitor CT1 for 20 cycles/crossings then moves onto CT2, then CT3. At the end it reports data via the wireless hardware. My test software highlighted that this method of monitoring power is not suitable where PV is being diverted and in my setup just compounded the problem as the divert value measured with CT1 is not the same as measured with CT3. I was just getting large errors in the data.
Moving my divert hardware onto a separate feed from my house would alleviate the problem (expensive) but the only true solution would be to read all 3 CTs at the same time.
The only way to do this though would be have 3 synchronized emonTX devices or to make the emonTX hardware read data faster. I think I have put together a viable solution that just runs the data capture faster by reducing the time analog reads are taken. This still gives over 50 sets of readings per cycle for each CT and tripple that for the voltage values.
The only problem encountered was what to set the voltage phase shift value to for faster read times. I used 1.28 - I don't know if this is correct but it seems to work well. In the original software I never bothered to change it and had no problems with accuracy once calibrated. Can anyone shed some light on what this should be please.
I have just done a calibration check of my PV values over 5 days. From my original calibration done two weeks ago it is within 1% of the PV meter. I measured 84.03 from daily totals PV off my emonGLCD and 83.4 from the PV export meter. Otherwise I have noticed that when less than 500 watts the value is slightly high and for very large values the reading is slightly low when compared to the reading on the export meter and inverter.
Please have a look, use and post comments
Ian
Re: New emonTX continous monitor software 3CT & Voltage
MartinR's PLL sketch does this - but genuinely continuously, meaning that all (in his case two c.t's) and the voltage are each sampled in sequence. You can find his sketch here: Solar PV power diversion with emonTx, emonGLCD and temperature measurement
And an earlier post giving a bit more details on the phase-locked loop here: Phase-locking emonTx to the 50Hz supply
It should be quite easy to extend that to 3 c.t's, Dan Woodie is doing that now http://openenergymonitor.org/emon/node/2624
Martin has also done 3 synchronised emonTx's, but for monitoring only on a 3-phase supply: Full-fat 3-phase monitor.
You can read up on the phasecal algorithm in Building Blocks.
Re: New emonTX continous monitor software 3CT & Voltage
Thanks Robert
I've had a quick look at those and they contain some low level code that I don't fully understand to control the transmission of data using RF12.
The sequence of reading data and applying voltage offsets also seems a bit confusing and follows
Wait for time interupt - voltage read initiated
ADC interrupt for voltage - start CT1 read
Process voltage reading - calcs include power calcs for the previous CT1 and CT2 readings
ADC interrupt for CT1 - start CT2 reading
Process CT1 data
ADC interrupt for CT2
Process CT2 data
Wait for next timer interrupt
This seems confusing to me or do the CT1/2 readings really lag the voltage by that much?
Ian
Re: New emonTX continous monitor software 3CT & Voltage
The ADC is semi-autonomous and it is allowed to free run. When it completes a measurement, it throws an interrupt, switches the multiplexer to the next channel and carries on with the next reading, in the meantime the main loop processes the result and then hangs about doing nothing particularly useful while it waits for the next conversion result. But you need to tell the ADC what it's going to switch the multiplexer to before it's finished the conversion it is on, hence the next instruction to the multiplexer appears to be one step ahead of processing the result.
This actually goes a lot quicker than the standard library routines because in that mode, the ADC completes its conversion, returns to the library routine called by the sketch, the answer is processed, then it send the instruction for the next conversion, the ADC goes away and does it, etc.
The low level code for the RFM12B is doing exactly what is needed and nothing more. It is simply more efficient than the library routines, which have to cater for every possible situation.
It works well. In Dan's thread, Martin reports that he tried Dan's code with 3 c.t's and at 60 Hz, and there was plenty of time to spare, but that was with 25 samples per cycle I believe. Martin's original works with 2 c.t's and 50 samples at 50 Hz,
Re: New emonTX continous monitor software 3CT & Voltage
I am currently running Martin's code in a 120 V / 60 Hz environment, but with only 2 CTs running. As I posted in my original thread asking for assistance, I could not get it running with 3 CTs, but that was probably more due to errors in my code additions than any fundamental hardware limitation that cannot be overcome. I am currently running a 3+ day benchmark on this code versus my electric utility meter and a Fluke 3 phase power analyzer. I then plan on running a similar benchmark on the standard sketch and some other variants, with intentions to share all that I learn here in the forums.
Dan
Re: New emonTX continous monitor software 3CT & Voltage
ianjm wrote: This seems confusing to me or do the CT1/2 readings really lag the voltage by that much?
The way this works is that the ADC goes through the repeated sequence Volts,CT1,CT2,Volts etc. After each voltage reading the sketch determines what the voltage would have been at the current sampling points by linear interpolation between 2 consecutive voltage samples. The interpolation fraction is made up from a fixed delay due to the ADC read sequence, plus a delay dependent on the relative phase shift of the current and voltage transformers.
mad_dad (Paul) is also looking at a 3-CT solution on the main thread so you (and Dan) might want to look at what he's done.
Oh, and thanks for all your support Robert.
Re: New emonTX continous monitor software 3CT & Voltage
Thanks everyone - theres some really good work being done that I have missed
My PV diverter using an SSR and should be on a PPL as its very sensitive to late control pulses and misses a cycle - I will convert to interrupt driven.
I have had a look at Martin's PPL code and the building blocks and still cannot see how the phase correction number is derived.
Martin In your PPL version where the phase shift is calculated behind the current voltage reading the phase shift is I1PHASESHIFT (((5+63)*256)/400) and I2PHASESHIFT (((5+127)*256)/400)
These work out as the last voltage + 0.17 & 0.33 the difference between the last and current voltage difference
why 5
if the ADC is running at around 60 micro seconds then 63 & 127 means your board at 63.5 is that correct?
In my sketch I read the voltage before the current and use 1.2 to move the voltage forward
In the Mk2i_PV_Router_rev5b sketch a value of 1 is used - no phase movement (this sketch is using standard ADC timings)
Does anyone know how I should calculate values for the standard CTs from openenergyorg shop
Thanks
Ian
Re: New emonTX continous monitor software 3CT & Voltage
There are two "phase" shifts to consider. The one is actually a time shift between readings, the other is the difference between the phase shifts of the v.t. and c.t. Those two are variable, depending on the voltage and current respectively. You can read up about those in the reports on the two sensors. So yes, if you can say at what voltage and current you want the correction to be accurate, you can see what the time difference needs to be that will give you the best correction. At any other value, it will be wrong. However, Robin has found, given that most domestic loads that draw a substantial power are very close to unity power factor anyway, that the phase correction in practice makes little difference to the operation of his diverter. If you are interested in measuring smaller loads that can have a very poor power factor, then the phase correction assumes a greater importance.
I should point out that both Martin's and Robin's designs only use the signal from one c.t. on the common grid connection to control the dump load. Martin's uses the second purely for indication.
Re: New emonTX continous monitor software 3CT & Voltage
I did determine (or best guess) that the equation you listed:
I1PHASESHIFT (((5+63)*256)/400) and I2PHASESHIFT (((5+127)*256)/400)
the 400 value represents the time in microseconds between sampling points. The 5 represents the amount of phase lag inherent between the two transformers (I would assume that is mostly hardware dependent) and the 127 is the timing difference the sampling times. Martin and others please correct me if I am wrong. So changing to the 60 Hz frequency I had to adjust the 400 in the denomenator to 333, as my samples are closer together at 60 Hz.
Dan
Re: New emonTX continous monitor software 3CT & Voltage
Ian,
The values of 5 for I1LEAD and I2LEAD are just placeholders, they should be replaced by the actual number of microseconds that current leads voltage by at the inputs to the ATmega328. The PHASECAL value of 1.7 used in the standard sketches is equivalent to an IxLEAD value of about 158, so that might be a good start. Maybe I should have used that as the default.
if the ADC is running at around 60 micro seconds then 63 & 127 means your board at 63.5 is that correct?
I'm not quite sure what you mean by that but 63.5 microseconds is the delay between consecutive ADC samples so the third CD will require a fixed delay of 190.
The sum of IxLEAD plus the fixed delay can't exceed 400 microseconds so there may be an issue with the third CT if IxLEAD exceeds 210 microseconds.
-martin
Re: New emonTX continous monitor software 3CT & Voltage
Dan,
You posted while I was typing.
I'm not sure 333 is the correct value for your sketch. You have 25 samples in 16.666r milliseconds so I make that 666 microseconds between samples?
Re: New emonTX continous monitor software 3CT & Voltage
Surely 25 samples in 16.666 milliseconds, so 666 microseconds per set of 4 samples?
Re: New emonTX continous monitor software 3CT & Voltage
Thanks for info Robert
I've now had a good read of the Yhdc SCT-013-000 Current Transformer page
Looking at the SCT-013-000 CT with a burden resister of 18 ohms it looks like a 2 degree leading shift for higher currents and up to 4 degrees at lower currents. With 1 degree arc at 50Hz being 20000/360 = 55.5 µs
2º to 4° is 111 to 222µs - on standard reads of about 113µs that's a lag of 1 or 2 sample periods.
Running the ADC faster at PS_64 gives about 60µs per reading that is nearly 2 to 4 sample periods!
Is this maths correct?
Re: New emonTX continous monitor software 3CT & Voltage
The absolute phase shift is not important Ian, what matters is the difference in phase shift between voltage and current.
Also, the sample period for a complete set of results (i.e the time between voltage samples) is around 400µs so the phase difference is usually less than that and that's what's important if you are going to interpolate between voltage samples.
Re: New emonTX continous monitor software 3CT & Voltage
Martin,
The math I used was this:
For a 50 Hz mains and 50 samples per cycle:
For a 60 Hz mains and still 50 samples per cycle:
So, higher mains frequency while holding the samples per wave to 50 leads to a shorter interval between sampling interrupts. It made sense at the time. I left the phase error of the CTs at the 5 microseconds you had in the code since I didn't believe my alternate CTs to be that different. I do not have the equipment to accurately measure that but it seemed to be OK on the standard sketch. Let me know if you think I made any errors here. Thanks.
Dan
Re: New emonTX continous monitor software 3CT & Voltage
Thanks Martin
I've now read the Mascot adaptor page and from my experience it fluctuates between low 230 to low 240 - from the graph of voltage against lead that would seem to be just above 4 to just less than 5º lead on the voltage.
Adjusting this with the CT lead of between 2 and 4 the combined spans worst case high voltage + high current (5 & 2) net 3 (voltage leading the current) and best of low voltage + low current (4 & 4) in phase.
Pitching a middle ground of 1.5 gives about 83µs of voltage leading current. Do you think this is reasonable assumption?
Ian
Re: New emonTX continous monitor software 3CT & Voltage
Dan,
Your maths is correct but in the sketch that you posted you are using 25 samples/cycle...
#define NUMSAMPLES 25 // number of times to sample each 50Hz cycle
...that's what Robert and I were responding to. If you're running with 50 samples and 3 CTs in a 16ms cycle then you are doing much more per cycle than my code so you need to make sure that you're not running out of time anywhere.
Ian,
There's nothing wrong with your reasoning and 83µs is certainly within the range I have seen. It may not be the optimum value but it's probably close enough.
-martin
Re: New emonTX continous monitor software 3CT & Voltage
Thanks Martin
You said "It may not be the optimum value but it's probably close enough"
Could you suggest a better value for general use please?
I can see now that for some CTs it will be possible to use a better value - A CT measuring my immersion circuit will always have full cycles at a fairly constant current so it should be easy to set a better phase adjustment value around the mid point of voltage fluctuations.
The house CT is difficult as its low except when a heavy usage appliance is switched on. Is it possible to cater for this?
Re: New emonTX continous monitor software 3CT & Voltage
Ian,
I think you're expecting too much from an "economy" c.t. Any split-core c.t. will struggle to maintain accuracy over a large range, you could look at the Magnelab range that Robin thinks are better constructed - especially the "revenue" grade. Alternatively, you need to look at a ring core one, which will almost certainly be better in any case, and you can get - for a price - very high precision in that format. (And for obvious reasons - there's no iffy joint in the magnetic path that can introduce a variable air gap.) You'd need a registered sparks to install it for you though, as it would mean breaking your electricity provider's seals to thread the meter tail through it.
But beware - many have a maximum 0.333 V rms output so will only use less than one third of the emonTx's input range.
Re: New emonTX continous monitor software 3CT & Voltage
Thanks Robert
I'm not expecting a budget CT to be supper accurate and my question wasn't about that.
I am more concerned at getting the correct value for phase shift or now as I have learnt more the best compromise value.
I now realise that my 3CT sketch is using the wrong phase shift value by a large measure - it is however accurate at measuring daily KWh totals for my PV due to its calibration - it however shows low at higher values and too high for low values.
Ian
Re: New emonTX continous monitor software 3CT & Voltage
my question wasn't about that. Well, I think it was, at least in part, because phase error is an integral part of the transformer accuracy specification, and a revenue grade c.t. will show a much smaller and nearly constant phase error.
Your problem now looks more like the familiar problem of noise pickup in the c.t. inputs rather than a problem with the c.t. itself. It's been known for a long time that there are two effects - mains voltage pickup that can be minimised in a single phase installation by measuring the neutral rather than the line, and digital noise from the processor itself. Unfortunately, there is little that can be done about that, though extra decoupling on the 3.3 V rail might help. Unfortunately because it is noise and uncorrelated with the input signal, it appears as a current with a random phase, usually manifesting itself as a power error of a few watts and a somewhat larger VA error.
In addition, there are systemic errors in the A-D conversion process, see:
http://openenergymonitor.org/emon/buildingblocks/measurement-implication...
http://openenergymonitor.org/emon/emontx/accuracy
http://openenergymonitor.org/emon/node/1385
http://openenergymonitor.org/emon/node/2311
Trystan did some wonderful animated pages demonstrating how the errors vary here: http://vis.openenergymonitor.org/dev/adc/noiseless, here: http://vis.openenergymonitor.org/dev/adc/noisy and here: http://vis.openenergymonitor.org/dev/adc/noise.mp4.
Re: New emonTX continous monitor software 3CT & Voltage
Thanks for the info Robert
Sorry about the delay I went live on PV diverting to my HW tank at about 5:30 pm on Friday - very pleased with how its working.
Saturday (mixed sun and cloud) I had over 9kWh diverted, I wasn't expecting that much-:)
Today is very cloudy but even so its diverting with low surplus available.. Red light seems to be solid on my meter so my divert sketch looks as though its working well.
I had read about keeping all CTs on the neutral line and all mine are. The animated pages look nice - I haven't quite worked out what they are trying to tell me.
I still cannot see how a phase shift value above 1 can be achieved when both CT and AC adaptors are giving +ve phase shifts and the voltage shift is larger. I will draw a diagram and someone can tell me if I am not thinking down the correct lines.
Ian