Some time ago Glyn posted a note on High Accuracy Current Measurement Over a Wide Range using adjustable gain to improve measurement resolution at low currents. I can't find any further references to this.
My free running EmonTx based monitor is getting better than 0.5% accuracy relative to the utility meter. I'm fairly pleased with this, but would like to improve the accuracy when current measured drops to a low value.
I've been considering adding variable gain to my monitor, but I'm not clear about how well it would work in practice, particularly as I'll be using a burst fire PV controller.
The adjustable gain design in the above note is based on an ATmel Application Note. The Atmel firmware appears to wait about 100 samples before switching the gain. In my case this would be after about 2 cycles. If a burst fire controller is switching current on and off every few cycles this would not appear to work. But maybe I've misunderstood how the adjustable gain modification would operate.
Has any anyone done anything further on adjustable gain in EmonTx?
Re: Adjustable gain monitoring
You could try looking through the blog posts, but I think I read that the project has been dropped. I can see what you mean about a measurement delay. I haven't studied the software in that much detail so I can't confirm that. But it sounds reasonable for normal purposes, if not for you. You cannot know what gain you will need until the cycle has hit a peak one way or the other, but maybe you could risk switching after only 13 samples if you know where the zero crossings are, and start counting then (just a thought).
Re: Adjustable gain monitoring
Good to know I'm thinking along the right lines. I couldn't find any blog posts, but I might have missed one.
The kind of problem I envisage is this. It's summer and there's little power being used, apart from what's being diverted from the solar PV to the immerser. The burst fire controller has switched off the heater and the monitor is sampling current using the highest gain. The controller switches on and the ADC goes off scale. By the time a lower gain has been selected and things have settled there have been a lot of far too low current readings. Then the controller switches the current off.....
My suspicion is that I'd get worse accuracy with variable gain than without.
What puzzles me is that the Atmel Application Note is dated August 2013 and there's no mention of problems with burst fire controllers. This is why I thought I must be misunderstanding how the variable gain mode operates.
I could try using zero crossing points to be a bit smarter, but I'm not currently using these. As the sampling is free running, I decided it was better not to make assumptions about the shape of the waveform.
Actually it's maybe not as bad as I've made out. If there's very little current being used in the house apart from the immerser, the burst fire controller would not need be active, and the immersion thermostat would be controlling the heater.
All the same, I think I will give variable gain a miss. But if anyone has used it successfully with a PV controller, I'd be interested to know.
Re: Adjustable gain monitoring
Hmm. The only difference between the thermostat and the triac is one switches more frequently, and the other switches at a random point!
The other thing you need to consider is how big are the gain steps? You're assuming that the dump load will always take the input off-scale. That might be right but I think it doesn't need to be. If the gain is set so that adequate resolution is obtained, rather than maximum resolution, then if the steps are the right size you might have enough range left to still be inside full-scale when the dump load comes on. I suggest you look carefully at their control algorithm and the gain steps, because in the back of my mind I've got the feeling that I looked at this and it had been thought about.
Re: Adjustable gain monitoring
You're correct about the gain steps. I found the Atmel sources and the firmware does limit the gain thresholds. The algorithm does not take the all or nothing approach I was implying. I confess I hadn't found the code before. I'd just used the documentation.
Isn't the difference between using the thermostat and the triac that the switching period of the thermostat is of the order of minutes or tens of seconds, but for the triac it's of the order of cycles?
Re: Adjustable gain monitoring
The triac switching frequency depends on your algorithm of course, and that in turn depends on your meter and the way you are charged for energy. Here in the UK, meters tend to have an energy packet size of 3600 J - meaning that when the energy taken crosses that threshold, a unit of charge is applied. Inside that packet, energy can shuttle back and forth without charge (see the meters page in BB). So if you allow the dump load to be on until a nett 3599 J has been consumed, and then you export energy until the same 3599 J has been returned, there is no charge. Of course, in practice you allow a guard band at each end; but even so, in the case of Robin's anti-flicker sketches, the switching frequency is seconds, not cycles. It is still mush faster than the thermostat though, which will be minutes or possibly tens of minutes.
What you're getting at is the error (given that the monitor saturates) is proportional to the time it spends saturated out of the total.
Re: Adjustable gain monitoring
arnnoldh re "But if anyone has used it successfully with a PV controller, I'd be interested to know." .... yes, I have successfully used variable gain in my PV controller!
For the variable gain I used the same hardware design as given in the Atmel app-note the only difference is that my op-amp feedback resistance (R2) is 500 kohm (2 x 1Mohm in parallel).
The gain is determined for each mains cycle based on the average current measured in the previous mains cycle, so reacts quickly.
The diverter has been running now for well over a year. The design was based heavily on Robin's Mk2 and Stuart's interrupt driven modifications. It uses burst mode firing driving two external solid state relays. Never had any flicker problems, but then we only have one neighbour on the same phase and next nearest neighbours are some way away. Some features of the diverter:
I have attached the sketch for anyone with an interest - it is pretty well commented throughout. I have used floats extensively for readability, rather than converting all code to run using integer arithmetic.Compiled code takes up almost 23kb of the 30kb of available program memory. Only just runs within the 2kb of SRAM - learned the hard way that things go real strange when you run out! (addressed through use of F('string') to put constant strings into program memory).