EmonPi AC-AC input

John_Fitton · 2017-06-06T08:32:12.433Z

Hi all,
I am talking to a company about supplying a DIN rail for the AC-AC power supply so I can increase the WAF rating, the one in use now (brought from the OE shop) has an output of 670ma 10w, is this the minimum that is required or can it be something different so long as the output is 9v AC?

Any insight most helpful.
Thanks
John

Robert.Wall · 2017-06-06T09:27:05.726Z

It isn’t a power supply for the emonPi, all it does is provide an isolated voltage reference for the calculation of real power. The load on the a.c. adapter is something like 100 kΩ so the power is essentially zero. What is more important is the accuracy of the wave shape and the phase error, which should be as small as reasonably possible but more importantly perhaps, constant over the range of mains voltages.
The open-circuit voltage of the Ideal a.c. adapter is 11.6 V ± 3%.

Power for the emonPi comes exclusively from the 5 V d.c (USB) supply.

John_Fitton · 2017-06-06T11:37:00.997Z

Hi Robert,
Excellent information, I didnt know what to call it other than a power supply. I will pass the information on to the company I am talking to, they were struggling to source a 9v but said 12v is really easy, now I know it can be 11.6v that should make it easier for them.

Thanks
John

charlesjudd · 2017-06-06T13:24:26.774Z

So I put a meter on my 240volt AC to 9volt AC power supply and get 10.42 VAC ( no load / open circuit). Country is Australia.

Power pack here:
https://www.jaycar.com.au/9v-ac-1-amp-plugpack/p/MP3027

It’s not the OEM AC pack. What’s the implication of the lower open circuit voltage please?

Is there a callibration process I can follow to “train” my emonpi and Tx to use my AC power pack optimally?

Robert.Wall · 2017-06-06T14:59:46.229Z

John_Fitton:

I didnt know what to call it other than a power supply.

Fair comment. It is intended and sold as a power supply, and we use it as such for the emonTx, but not for the emonPi. (I only put it that way because you mentioned and were worried about the VA rating.)

It can be any sensible low voltage, but you must be prepared to change a rather small SMT resistor on the Atmel 328P circuit board in your emonPi if its vastly different from 11.6 V on no load. Make that point very firmly, because these things are normally specified at full load.

And you’ll need to correct the voltage calibration, maybe the power calibration too, if the o/c voltage is not 11.6 V at 240 V in.

Robert.Wall · 2017-06-06T15:18:36.699Z

charlesjudd:

What’s the implication of the lower open circuit voltage please?

Assuming that is when the mains is 240 V, you’ll read the voltage and power a bit over 10% low.
You can (the hard way) do the calibration procedure described in the “Learn” section, reloading the sketch in the Atmel 328P processor each time you need to tweak a number, or (the easy way) you can change the “scales =” factors in emonhub.conf.
You should be looking under the nodeID for your emonPi, which should be NodeID=5. The scale factors relate 1:1 to the values in ‘names’, so 1 becomes 1.1 (or so) and 0.01 becomes 0.011

    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

You should change only one: either the calibration factors in the sketch or the scales in emonhub.conf, not both. The more “natural” place is in the sketch. Unfortunately, many people don’t want to load the Arduino IDE so they cannot change the calibration there.

charlesjudd · 2017-06-06T23:24:52.002Z

Thanks Robert
I’m comfortable using arduino IDE. Does the emonTX support programming via direct USB or do i need to buy an FTDI adapter?

Robert.Wall · 2017-06-06T23:42:57.578Z

Are you talking emonPi, emonTx or both? This thread is specifically about the emonPi. If it’s emonTx, I’ll split the thread.
The emon part of emonPi can be programmed using the internal serial connection and running the Arduino IDE on the Pi. However, I’d prefer to compile the Arduino sketch on a PC, then transfer the .hex to the emonPi and upload directly from the RaspberryPi using avrdude. Emonhub will need to be stopped to free up the serial port. See example script to upload .hex emonpi/update at master · openenergymonitor/emonpi · GitHub
substituting the path to the hex file you uploaded.

charlesjudd · 2017-06-07T04:14:41.092Z

Robert, I’m installing both EmonPi and EmonTX v3.
Both EmonPi and EmonTX will each have a 10.4 volt AC reference wave form attached.

option A) Should the calibration procedure be applied on the EmonPi (emonhub.conf) and EmonTX V3(updated sketch)? This would mean only callibrated data is ever received by the emonPi and logged to EmonCMS running on EmonPi.

Option B) apply the calibration to EmonPi atmel daughter board (update sketch via FTDI + IDE) and update EmonTX V3(updated sketch using FTDI process) Does this mean all data received from all nodes will calibrated when it is receved/processed by the EmonPi?

Option C) is there an option to callibrate the data using EmonCMS input feeds? This means all data is received as-is, and is calibrated by EmonCMS as it is ingetsed into the database?

I’ve added a diagram of my proposed setup.

thanks for the well received and informative discussion.

Proposed Emon Setup.jpg1152×800 77.1 KB

charlesjudd · 2017-06-07T04:23:57.416Z

Robert.Wall:

Learn

I found one of your posts here that explains much of what i need (i think)
https://openenergymonitor.org/forum-archive/node/12368.html
Re: Calibration procedure

Submitted by Robert Wall on Sat, 19/03/2016 - 21:13.
The real problem is that there is no mechanism for the processor in the emon part to read coefficients out of a file in the Pi part. What you have to do is install the Arduino IDE (on the Pi or on another machine), open the .ino sketch file, edit the coefficient(s) in the sketch, compile it (turn on 'verbose' during compilation and it'll tell you where it put the compiled .hex file) and then load that compiled file via the Pi's serial interface into the ATMega 328. The details of the procedure are in the Wiki.

If it's only the values reported in emoncms that bother you, as an alternative you could tweak the multipliers (for node 5: "scales = ...") in the emonhub configuration file, and that's accessible via the browser. You'll need to do voltage and all the powers, because at that point the multiplication has been done and voltage and power are quite independent. If you need to correct the power factor compensation, I'm afraid there's no alternative but to recompile and reload.

The next issue to test for is if software update proceedure of the EmonPi will overwrite the change made to the .hex file. I’ll wait until my order arrives and test it out.

charlesjudd · 2017-06-07T06:42:09.867Z

Incase anyone else needs to know the callibration process, there is an excellent OEM article here
https://learn.openenergymonitor.org/electricity-monitoring/ctac/calibration

Robert.Wall · 2017-06-07T10:11:05.280Z

The quick answer to all those questions is yes.
Yes, if you calibrate at source, emonCMS receives the true values - voltage and power (and current, apparent power and power factor if you decided to send those too).
If you calibrate inside emonHub, then you apply the calibration to voltage and each power separately.

If you do the full update on the emonPi, I believe it will overwrite your sketch. There’s a way to cause that to abort, and I’ve not remembered the details (but it’s been mentioned several times).

There is a lot of what we hope is useful background information in the “Learn” section. That should be the first place you look for the basic theory and techniques. Adding the calibration procedures for the emonPi to that is on my ‘to do’ list. The hardware of the emon part of the Pi is identical to an emonTx, and the code is pretty much the same too, although it’s split into several files.

pb66 · 2017-06-07T10:29:06.552Z

Robert.Wall:

If you do the full update on the emonPi, I believe it will overwrite your sketch. There’s a way to cause that to abort, and I’ve not remembered the details (but it’s been mentioned several times).

If you use the “update RFM69Pi” button rather than the “update emonPi” button it will update in exactly the same way but when it tries to upload the firmware at the wrong upload baud it will fail and the existing firmware will remain intact. This works as the 16MHz emonPi has a different bootloader to all the 8MHz RFM2Pi type devices.

Morten_Mortensen · 2017-10-23T10:18:56.630Z

Just thinking out loud here, would it not be possible to have a calibration process that you can run manually to find the right calibration values for all of your sensors / feeds, and then store that somewhere in the PI? Then take those values, insert them into the arduino sketches and compile them on the PI and upload / store them as a single process?

This way if the user choses to calibrate his sensors / inputs then the local calibration data is always stores on the PI and then that data is used to re-compile the arduino sketches for the emonPI board if they have changed from defaults?

The emonTX / emonTH sketches / compiled images could be put somewhere on the web UI where the user can then download them from and upload to his emonTX / emonTH boards manually.

It should be relatively easy to do this but it would require the installer / upgrade process to have an additional check for local calibration data and if present then it should recompile the sketches for the arduino boards and install then ones it can.

Maybe even extend the dataset sent from the arduino boards to include the calibration values so a user can keep track of those?

Robert.Wall · 2017-10-23T10:34:36.312Z

Basically, yes - once you’ve established those calibration values and you have some means of identifying an individual node.

The first is easy. It just means moving all the calibration into emonHub. Removing all calibration from the sketch means that some of your suggestions become redundant, even, because the emonTx/emonTH/emonPi sketch never needs recompiling because it never changes. I’ve done it as a derivative version of emonLib and submitted it with a demonstration/test sketch as a suggestion, but it’s been ignored.

The second has a small problem. If your emonTx (say) dies and you replace it with another, or your a.c. adapter goes up in smoke and you replace that, then even though the replacement is running the same sketch with the same nodeID, the calibration will be wrong, because it’s wholly dependent on the hardware. None of the OEM parts have unique serial numbers, so that is not available as a way to identify an individual part. Therefore, when replacing a component, the user will still have to recalibrate. Maybe this shouldn’t be a problem, but I can see some users being confused or misled here.

Morten_Mortensen · 2017-10-23T11:17:12.453Z

That’s a good point on the second option, you would need to keep track of which sensor went to which port on which node and that could prove a problem indeed.

I guess if you keep all of the calibration values in the emonhub.conf file then it makes it a lot easier to manage the calibrations centrally. A user would still have to know where he plugged in the sensors obviously.

Does the arduinos not have a serial number you can query from a sketch that could be used to track which node is which over time?

Robert.Wall · 2017-10-23T12:25:30.854Z

Morten_Mortensen:

Does the arduinos not have a serial number

An Arduino might have, but no OEM/Megni products have an unique serial number. You’d need to add your own labels - not too hard, if you’re aware of the potential problem that’ll bite you if you’re not.

Morten_Mortensen:

you would need to keep track of which sensor went to which port on which node

You have to do that anyway, whether the calibration is inside the node or elsewhere. Calibration is a property of both the components inside the node and the sensors connected to it.

Morten_Mortensen:

if you keep all of the calibration values in the emonhub.conf file then it makes it a lot easier to manage the calibrations centrally

Not only that, it can be done with a web browser and removes the need for a programmer (and platformio / Arduino IDE).