Homebrew breadboard V Arduino Shield V emonTx

Hardware
, ,
1

We received the Arduino shield and emonTX today and they look to be very well designed.

I’m dreadful with an iron and normally an associate of mine does all our soldering but I’m pleased to say my novice skills were enough and it’s happily kicking out data.

We are currently reviewing various energy monitoring systems, not just the one’s supplied by Open Energy Monitor. The basic criteria is value for money, ease of assembly, accuracy and safety considerations.

Yesterday before the additional OEM parts arrived I completed your breadboard circuit with a Leonardo.

Observations with the 100A CT and 9V AC - AC adaptor.

Voltage accurate until we power up the load (1200W hairdryer). We noticed a 2V drop from 238 to 236. This results in real power being greater than apparent power. 2V is less than 1% and we could probably factor this into our system.

Also about 130mA of noise to accommodate.

With the Arduino shield, hooked up to the same Leonardo the noise seems to have all but disappeared. However we are still seeing the 2V drop and PF > 1.

Once we have the results from the emonTx we will post them here.

2

Have you done the full calibration?

3

@Robert.Wall I think we did all the right calibration for the breadboard. For the shield we have dropped the 300.6 voltage calibration to 265.4 to tie up with DMM.

I was assuming the 60.606 calibration for current was fine as it stabilises to zero with no load.

4

The one that will affect power factor is of course PHASECAL. The default is slightly off for the latest batch of c.t’s, so when that has been set, you should see the correct power factor.

The 2 V drop is of course a measure of the fault level of your supply at the point where you measure the voltage. Real power being greater than apparent power is nothing to do with that at all, it’s because emonLib actually uses two different voltages to calculate the two quantities.

And the calibration coefficient shouldn’t affect the zero reading. In the absence of a means of measuring a substantial current (I’d suggest around 30% of full load, i.e. 30 A as the ideal value at which to calibrate), you need to adjust current calibration over time to get agreement with your supplier’s meter.

The comparison between the breadboard and emonTx Shield ties in with anecdotal evidence that’s been reported for pretty much as long as I’ve been around here.

1 Like
5

How do we establish PHASECAL?

6

Follow the calibration procedure in Learn. I don’t intend to copy and paste it here.

7

Adding the link to the calibration section of Learn Learn | OpenEnergyMonitor

@Robert.Wall what does the 3.3V battery pad references refer to as they don’t appear on the Leonardo or shield?

Running the calibration sketch with DMM reading of 3.3V for the 3.3V pin gives 735899L but it states the normal range would be 1024000L - 1228800L. I will change the library entry to 735899L but why is it so far adrift from the normal range when it reads exactly 3.3V?

8

I suspect I’m supposed to be reading the 5V not the 3.3V and that gives 1115000L.

9

Yes, that was written for the emonTx.
The internal reference has a wide tolerance on the initial value of around ±10% (1.0 V min, 1.1 V nominal, 1.2 V max) although the stability of a bandgap device. The calibration factor is a measure of the 3.3 V or 5 V supply in relation to that. Look at the maths in emonLib.cpp for the details. (Clue: the volts per ADC step, changes.)

10

On to the PHASE calibration now.

11

@Robert.Wall I had worked out 268.8 for voltage calibration which is almost spot on to the 268.97 supplied by the manufacturer.

At low end current I need a phase of 1.25 compared with default of 1.7. Would you say this is reasonable?

12

Without working it out, I don’t know. The c.t. phase error at low currents does rise rapidly, so it might well be correct. But it’s probably best to calibrate at near to the maximum normal current that you want to measure. If you look at the test report for the c.t., you’ll see how the phase error changes with current. (And likewise, the v.t’s phase error with voltage.)

1 Like
13

It’s cost me about 70 pence of 'leccy for this well earned cuppa.

14

You must have a mighty big cup. That 70 pence represents about 4 kWh of energy. Neglecting losses, I calculate that your teapot must hold about 40 litres.

1 Like
15

0.7 pence, great I can have 99 more cups today :slight_smile:

Shield is spiting out the data via TTL now so it’s probably time to move on to the emonTx.

16

I required a bit of divine intervention to get going with the emonTx (thanks G) but still quite some way off anything usable.

The docs are confusing with the different versions and references to dip switches etc.

It turns out I already have the Serial only sketch and initially it was telling me that my mains supply was down at 5V. Now at 243.8V and DMM is at 241V so probably needs calibrating.

The bigger issues are:

  1. No response from the CT. It stucks at 20kW with or without a load.

  2. Unable to flash a sketch. In the Arduino IDE is the board selection an “Uno” or is there a procedure to actually add an emonTx board. Tried Uno and just get the “not in sync” error. I don’t really want to mess around with Platformio. Tried pressing the reset button just before the upload starts, no joy.

Any ideas where I am going wrong on 1 and 2?

17

The default sketch in an emonTx isn’t the Serial only, it is emontx3/firmware/src at master · openenergymonitor/emontx3 · GitHub

2.  The board selection should be “Uno”. “not in sync” usually means a connection error. Is the programmer the right way up? GND is at the RJ45 end. You shouldn’t need the reset button when uploading. Have you got the right port? (In Ubuntu Linux, it swaps if you unplug and reconnect.)

1.  What does that channel read when you unplug the c.t. after it has started up? What do the other 3 c.t’s read? My first reaction is it’s a faulty main board, but let’s see when you get to talk to it.

18

That’s right but it was flashed with Serial before it left Wales as that is what we told them we needed it for.

Yes I have noticed that.

Looks to be wired correctly as confirmed by the TTL data I am seeing. But I’m thinking maybe it’s the reset pin on the TTL that’s the problem. I have around 20 identical USB 2 TTL, they are 5 pin with one being 3.3V (and a 5V) but no reset. Do I need this? Maybe I will have to use an Arduino to flash it. I have a 10 pin USBasp if that’s any good.

This is what I have at the moment.
ct1:19858,ct2:0,ct3:0,ct4:0,vrms:24348,pulse:0
ct1:19865,ct2:0,ct3:0,ct4:0,vrms:24354,pulse:0
ct1:19862,ct2:0,ct3:0,ct4:0,vrms:24350,pulse:0
ct1:19873,ct2:0,ct3:0,ct4:0,vrms:24356,pulse:0
ct1:19885,ct2:0,ct3:0,ct4:0,vrms:24363,pulse:0
ct1:19846,ct2:0,ct3:0,ct4:0,vrms:24340,pulse:0
ct1:19841,ct2:0,ct3:0,ct4:0,vrms:24338,pulse:0

When I unplug the CT I have:
ct1:19864,ct2:0,ct3:0,ct4:0,vrms:24351,pulse:0
ct1:19870,ct2:0,ct3:0,ct4:0,vrms:24355,pulse:0
ct1:19864,ct2:0,ct3:0,ct4:0,vrms:24352,pulse:0
ct1:19890,ct2:0,ct3:0,ct4:0,vrms:24367,pulse:0
ct1:19889,ct2:0,ct3:0,ct4:0,vrms:24368,pulse:0
ct1:19876,ct2:0,ct3:0,ct4:0,vrms:24359,pulse:0
ct1:19875,ct2:0,ct3:0,ct4:0,vrms:24358,pulse:0
ct1:19847,ct2:0,ct3:0,ct4:0,vrms:24344,pulse:0

I saw reference to ensuring CT’s are plugged in before powering up the emonTx. Could I have blown the CT? Will fire up the shield to check.

19

CT working fine in the shield.

20

No chance of that. That “power” represents a massive input, it’s equivalent to 83 A, or around 0.9 V rms. My first guess (probably only guess) is there’s a track break between the burden and the input pin of the processor, and the input is floating. If you have a low voltage ohmmeter, you could check, with reference to the pcb layout. (See the Wiki for a download link.)
The c.t’s plugged in or not is so that the sketch can detect the channels in use. An unused channel is grounded at the socket, not sitting at close to 512 counts, and is excluded from the processing.

1 Like