CT inaccuracies - nasty spikes making kWh readings 14 - 21% over

Hardware
1

Hi all,

I’ve been here before but manged to fix the issue myself.

Here is my set up:

8kw solar inverter with panel connected

5kw solar inverter with no panels connected but this has a15.5kwh battery

Emonpi v1

Model: Raspberry Pi 3 Model B Rev 1.2 - 1GB (Sony UK) - AC to AC adapter for voltage calibration

Emontx3

(these are both quite old now)

Underload is pretty accurate, and I can use the calibration tools in the input sections to really dial it in.
Since fitting the new battery that was a replacement for a powervault 3 (4kWh) I’ve noticed the import from grid reading are not very accurate when compared with the reading from octopus energy, I think there are two reasons for this:

  1. My use from the grid is much lower and any use from the grid is in large lumps (charge from grid)
  2. The input seems to have loads of little spike In the data these seems to happen in two occasions
    • when the battery is providing power to the house and the sun is down
    • When the sun has come up and the solar is charging the battery

The below shows the grid import Realtime trace for one hour – the battery is being charged during this snapshot my real use from the grid was 17Wh where as the emon pi reported 220wh

image
image940×529 68.1 KB

Here is what I’ve tried:

As I don’t really care about the live data accuracy only kWh, I thought I could use to use the pulse sensor sadly not as as my meter flashes on both import and export!

Tried to filter the input using

if>=, skip next value 375

Then multiply this by 0.025

This kind of worked but did not remove all the spikes as quite a few are above 375w and is quite a crude method

Before I started to try and correct this:

image
image940×367 25.1 KB

After – manged to fix overnight but the spikes during the day mean once the sun comes up the goes wonky

image
image940×334 22.3 KB

Any tips on making this work, Is there a way to average the reading for say 30 seconds this would make the spikes easier to filter out

Would it be better to fit another electricity meter that only pulses on import and then read the pulse

Would buying the newer emon pi make it better?

2

It may do, because the new emonPi2 uses a different input circuit configuration to the older emonTx’s and the original emonPi, but from what you’ve written the source of the problem is the new battery and its charger/inverter, and it really should be a case of tracking down the source of the interference and curing it at source. This will be a lot better than trying to filter it out once it’s go into the measurements. First thoughts are, is all the earthing correct (no paint under the case earth bonding leads, etc)?

3

Hi Robert,

Quick reply! I checked the earth bonding and all seems fine, I think it’s the new battery inverter (sunsynk) It’s remarkable at keeping net import or export at 0 but how it does it seems to disagree with the emonPi, oddly this only uses a CT sensor albeit a SDM120CTM Din Rail Modbus one, It could be too many CT too close together as in total I have 4 CT inside the consumer unit

image
image1012×431 17 KB

4

How do you justify this? The c.t’s are inputs to their relative devices and I can’t see how energy from the inverter could be fed ‘backwards’ into its c.t. to affect an adjacent one. The only way I can see is via capacitive coupling between adjacent c.t’s or their cables. Because of the rather unusual input configuration of the original emonPi (the plug sleeve is actually the input signal and it’s directly coupled to the ADC input, while the plug tip is the “earthy” side but it’s grounded via the relatively high impedance of a 10 µF electrolytic capacitor), this makes it a lot easier for interference from external sources to get in, as well as providing a mechanism for noise from the SMPS to affect the readings, especially with extended cables. The ‘traditional’ input arrangement of the emonPi2 is much improved in this respect, so it might show an improvement provided that this is the mechanism in play.

5

I can’t and I should have written this. I fear the way in which the CT’s are fitted means they are very close to other live wires that could lead to interference.

I think I will try the fit a new meter that pulses on import only, years ago there was a guide to what models worked and google seems to contradicts itself on what models only pulse on import only

6

I read it as you meant in close proximity to the other c.t’s, not being aware of which services adjacent cables would be supplying.

7

Just thinking out loud here but would I be better to use a input on the emontx3cm15, currently using an input on the EMONPI?
Also would a firmware update on the tx help?

image
image1190×227 27.7 KB

8

It shouldn’t make a difference - but don’t quote me if it does :smiley: Both are very similar in both hardware and software, hence ‘shouldn’t’. But when you’re chasing interference spikes like you’re seeing, weird things happen and experience has taught me that nothing is totally predictable. So if it’s easy, it’s probably worth a try.

Generally, unless your hardware is no longer supported or you’ve customised it, it’s best to stay up-to-date.

Are you using the CM software already? I can’t tell from the image, if you’re not and the battery system is throwing out spikes that just happen to be picked up by the early discrete sample software, then moving to Continuous Monitoring will definitely help.
Do you have a 3-phase supply? You haven’t mentioned it and you’re in the UK, so I was assuming not. If you don’t, then you’ll gain nothing. But if you get an emonTx4 or emonPi2, then you can have true three-phase monitoring, with the advantage of the better input circuit configuration.

And what’s the black image in post no.3 trying to tell me? I don’t recognise it.

9

Hi Robert,

Some progress, I was using very old firmware, so I took the plunge, made a new SD, updated the firmware to the CM version, set up some inputs, just the one monitoring the grid for now and the averaging over 10 seconds has made a massive difference,

I’ve ordered a USB to UART cable so I can update the firmware to the tx3 to CM as I need 3 inputs (grid, solar PV & battery)

I’m in the UK single phase house.

The image you did not recognise was an image for octopus energy, was just to illustrate how good the inverter conected to the battery is at keeping the flow of energy to nothing

10

Good news, the CM firmware is much more accurate, looking like 1.8% out with no tweaking, firmware has been updated on the tx3 to CM

Bad news, difficult to explain but in the input view I set it up like this under emonpiCM_1

image
image2286×810 31.7 KB

then randomly these feeds stop working as a new set under emonpiCM_5 have appeared?

image
image2292×759 12.9 KB

Any idea?

11

It’s possibly due to Trystan’s “autoconfig” getting itself in a mess. I suggest find the line in your emonhub.conf and if it’s on, turn it off. Defining the Node exactly in emonhub.conf gives valuable protection against malformed data coming in. From what I can see, “autoconfig” throws away that protection.

If you look at the sketch you loaded into your emonTx, there should be a Node Definition in the source file, which (assuming you’re using the inbuilt radio to get the data to your emonPi) you copy into your emonhub.conf