Archived Forum

Unless they've lifted their game lately, CurrentCosts just measure apparent power while I assume your EmonPi is measuring real power?  Depending on your load, that might go some way to explaining the difference but probably not all of it.  Your load would need to have a PF of close to 0.5 to explain all of it, which seems unlikely.  Did you calibrate your EmonPi?

Hi and thanks for the reply, yes the EmonPi is measuring real power as i have AC input also, is there a calibration process i should go through ?

JD

Yep.  There's a section or two about that under Building Blocks above.

Yep i read through some of that yesterday, it all seems to refer to the EmonTX range and not the EmonPi, or where to find the values to change in the EmonPi unless I am missing something here ?

JD

hmm... good question.  I thought an EmonPi was basically an EmonTX stuck to a RaspberryPi in which case the calibration principles should about be the same.  As for the exact mechanics, hopefully someone more familiar than I am will chime in.

If I'd got an emonPi and knew my way around it, I'd amend the calibration instructions...

As dBC says, the principles will be very similar, i.e. you adjust some calibration coefficients to make it report the actual values that you measure accurately by some other means. But what I don't know is where the calibration coefficients are in the 4 GB of software that the Pi runs on.

If anyone has a doc on where to amend these figures on the EmonPi that would be good?

Many Thanks

JD

After a quick look through GitHub, I'd try to find where this file is on your Pi, and change the coefficients in there and see what happens. It looks sufficiently close to the instructions to be able to find your way round inside it: https://github.com/openenergymonitor/emonpi/blob/master/Atmega328/emonPi...

The main sketch should be located within the "emonpi" directory in the users "homedir" eg ~/emonpi/Atmega328/emonPi_RFM69CW_RF12Demo_DiscreteSampling/emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino, but that is not uploaded to the emonpi board there is a hex file there too. 

I would recommend keeping a copy of any adjustments you make as using the "update emonpi" feature from within emoncms will try to overwrite them (but the local edits will probably prevent github updating). Currently it looks like it may be easier to compile on another machine and then upload from the emonpi using avrdude. 

The alternative is to either have your own emonpi repo and edit the github url so you auto update from your own repo or to install the arduino IDE etc (you will need a remote graphical desktop via rdp, vnc or x11 etc) this shouldn't be too difficult but you will need to negotiate the read-only status to (install &) use the graphical IDE.

For these smaller edits you may be able to use just a text editor over ssh and then something like inotool to compile on the emonpi.

Paul

That all sounds like it could end in tears.  It seems the old "edit these lines in your source code and re-flash the AVR" model of calibration really doesn't mesh well with the new-beaut auto-updating EmonPi.

The good news is, for the most part, the calibration can be done anywhere in the chain.  A multiply is a multiply whether it happens down on the AVR or all the way back in the emoncms input chain.  Does the emonTx in an EmonPi only talk to the Pi, or does it still do RF broadcasts as well?  If it only talks to the Pi, then you could save the AVR some cycles by not having it attempt to translate any values into real-world values.  You could remove all the scaling multiplies, and just leave the multiplies that matter for calculating power, RMS etc.  It would then report all its reading to the Pi in raw A/D units, and the Pi could own the entire calibration process.  

I'm guessing the further away from the AVR those custom multipliers are, the easier it is to preserve them across system updates.  Presumably the user doesn't have to re-enter their emoncms input chain rules after a software update, so putting them in there might be a good choice.

The one notable exception to all this is phase calibration.  That really does need to happen down at the pointy end. Once that V*I integral has been calculated, it's impossible to sort that out later.

The voltage and current calibrations really do need to be close if you have any 'constant power' loads, such as switched-mode power supplies.

If you have purely linear resistive loads, such as water heating, then clearly because current is a linear function of voltage, calibrating power is exactly equivalent to calibrating voltage and current separately.

If however you have a significant load that is constant power, the relationship between voltage and current is inversely proportional, so both current and voltage must be calibrated independently if calibration is to be valid over a range of voltages.

Why does the phase adjustment have to be done right at the front end? If the processing power is available, the AVR could simply transfer the I/O values and the entire processing (voltage interpolation, rms and average power calcs, kWh totaliser, etc) could be done in the Pi, which would open the way to a config file containing the calibration constants, which is loaded at start-up.

I'm pretty sure this is only a temporary glitch, I think G&T will have something in the pipeline to accommodate custom sketches. Primarily the concept of having the hardware and firmware defined the nodes section in emonhub.conf was to allow a generic sketch to be customised at compile time with calibration data, settings and struct forrmat etc 

As a temporary work around for multipliers you are right that can be done at any point and the emonpi board only passes it's data to emonhub for processing before passing to emoncms(s) and there is already scaling taking place, so the 2 multipliers could be combined eg if AC voltage is 2% high it is currently "scaled" x0.01, this could be x0.098 to "calibrate" (0.01/1.02 = 0.098039) as you point out this won't work for phase calibrations though.

In my own opinion we should strive to have real values asap rather than passing uncalibrated and unscaled values around, the fact that the data can end up in many places could lead to the same values being different at different locations and and any calibration would need repeating at every end point.

Paul

I go along with the concept that calibration should be done as early as possible in the chain - what I was suggesting was move the entire calculation into one process in the Pi. It would receive raw data (integers 0-1023), and would be responsible for all calculations including the calibration. It would be trivial to move the multipliers in there as well, then there would indeed be consistent values available for whatever purpose.

Hi Robert, my reply above was to dBC's comment as I had started writing before you posted, I couldn't comment on the actual advantages/disadvantages of moving the calculating away from the AVR but transporting 1 integer per AIO sounds easier if that was the case, but I have read comments that the Pi's aren't too good with in-depth floating point math (may of changed with the quad core?) plus we all tend to meddle with the Pi's and restarting etc so it maybe wiser to leave the calcs ticking over where we can't get to them too easily perhaps :-)

Paul

I assumed you'd be bandwidth limited if you just shuffled AVR raw A/D values across to the Pi.  What does that use, a serial link?

By having the AVR continue to calculate Vrms, Irms and Power like it does now, you greatly reduced the bottleneck.   It would only have to send them to the Pi at the same rate it currently sends them out over an RF link. The only thing I'm suggesting removing from the AVR is any attempt to turn them into real-world values.

Why does the phase adjustment have to be done right at the front end? 

It has to be done before you calculate power, and I'm proposing that the AVR continue to calculate power (just not in real-world units) to reduce link bandwidth.

read comments that the Pi's aren't too good with in-depth floating point math

True, but they're several orders of magnitude better at it than a 16MHz 8-bit AVR. 

the fact that the data can end up in many places could lead to the same values being different at different locations and and any calibration would need repeating at every end point.

Yes, I agree you definitely want to scale it before the data forks off to multiple data sinks.

Hmmm it seems its not very 'easy' to calibrate the EmonPi then from all the above reading, has anyone had to calibrate the EmonPi yet ? where do we think it sits with regards to accuracy ? like I say my currentcost shows about 800W usage, but the Pi is around 480W so a significant difference, I realise one is an average reading and the other is true power, but its a significant difference, most of that load is a UPS powering PC's etc, I don't know if that has a power factor baring?

JD

most of that load is a UPS powering PC's etc

They can be pretty ugly.   Here's what my energy monitor sees on my GPOs 1 breaker.  At the time I snapshotted that, my UPS+computer+comms-gear was about the only thing on that circuit.  My energy monitor reckons it has a power-factor of about 0.8.    I bet the CurrentCost makes a real mess of measuring that.  I doubt it's enough to explain all the discrepancy you're seeing, but if you do want to calibrate against another meter, I think you'll need something far better than a CurrentCost.  Some "plug-through" meters are quite accurate, and others are really bad  (see photo below... the rear one reading 2.5W and a PF of 0.1 is correct, the front one reading 98W and a PF of 1 has lost its mind).

P.S.  What happens if you load them up with a nice beefy resistive heating element, like an oven, kettle or toaster. Do they get closer then?

[EDIT] A bug in my gnuplot script mean the scale on the Amps y-axis was wrong.  The correct plot shows the current peaking at about 3A not 9A.  And the timebase was a bit screwed up too.

the front one reading 98W and a PF of 1 has lost its mind

Got a good laugh out of that!

Cheers!