Archived Forum

It might not even be your Arduino! What are the units of the 'y' axis, Watts? The maximum you can measure, given 230 V and the input scaled for a 100 A CT, is 23 kW. OK, there's some 'headroom' above that but you won't get anywhere near 800 kW from the maths. I think you can rule out the ADC and the input side.
So if you are reading 800 kW it's either the Arduino inventing big numbers - meaning it is picking up interference that is coming in via your electricity supply, or your base is picking up something that's being interpreted as a transmission from your Shield. Does your electricity company put HF signals on the network for control purposes? If so, you could be picking that up.

You could add a software limit inside your Arduino sketch - that would indicate whether it is the Arduino (the peaks get clipped at the limit you set) or not.

Thanks for the quick reply!

The y axis is indeed watts. The 3 phase MCB is only rated to 80A, and there aren't any loads which would come close to that on that phase. 

There are no HF signals where I live. Off peak power is controlled by a timer supplied by the distribution provider and is located in the meter box. Not sure if this timer may be emitting some interference, but the timer sits on the red phase, whereas the 'noise' is on the blue phase. 

Can't be the base picking up random signals, as the arduino is connected directly to an OpenWRT router via USB running emonhub to submit the values to emoncms. 

Wonder if I can put in the sketch something like this:

if value > 10000, then use the last value measured for that phase. 

although it would be preferred to get to the root of the issue. I have ordered a (knockoff) Arduino Leonardo to rule out the ADC on that channel.

"although it would be preferred to get to the root of the issue. I have ordered a (knockoff) Arduino Leonardo to rule out the ADC on that channel."

Yes, finding the cause is best, but wrong about the ADC. In the 328P at least, there is only one ADC, it is switched between inputs (see the Atmel data sheet).

And that is indeed the sort of limit I was thinking about (but I would force it to zero so that you at least know about it). Looking more closely at your data, the rogue numbers all appear to be single values, but there also appear to be some single zero values. This might be telling us something.

What values is emonHub getting, can you monitor and check? If you can see exactly what is coming in, that might indicate the area to look at. IS the data sent as ASCII characters or bytes? Is the USB link dropping characters and it's concatenating consecutive numbers? We need to ask Paul (pb66) about that.

Looking at the logs, it appears there is some weird rounding going on. Here's an example of a line with the blown out value for CT3

2014-12-27 09:49:34,350 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1419635974.2000002,5,672.63,227.98,194.85,-24.48,242.08,20.1,38.9,19.5,23.5]]&sentat=1419635974

The headers for the arduino values are: [[Node ID, CT1 power, CT2 power, CT3 power, CT4 power, Voltage, temp, humidity,  temp, temp]]

here is the full log (~4mb) (you'll see what I mean by weird rounding with excessive decimal points): http://www.users.on.net/~teepingkoh/emonlog.txt

Weird indeed. (Sorry, but I'm not going to wade through 4 MB of data!) You need to discover where that corruption is happening, have you put a limit on the Arduino output?

Have you got anything that could be causing conducted or radiated interference? I think it is an appliance. Looking at the emoncms output, there appears to be a fairly regular pattern. There is a bunch of spikes about 4 mins apart (sometimes it misses one or two, so 8 mins, and sometimes there's one in between, then there is a gap of about 40 mins. You are looking for something that is cycling, running for about 15 mins every hour (give or take 10 mins), a boiler or aircon, or a fridge or freezer? If you can't tie it down to something of yours, is it a neighbour's?

Which phase is your Arduino powered off?

The only thing that has changed is that now I am using a router with emonhub on it which is connected back to the internet via Wifi which sits in the meter box with the arduino, so within 10cm of each other. Previously I was using a laptop which sat a meter or so away. The router + arduino is inside an oldish metal meter box outdoors.

The only cyclic appliances would be fridges. Hot water is solar, so we have the booster off for the summer to conserve power. 

Arduino is powered off the router via USB, which is powered off phase 1. Maybe it would help powering the arduino directly. 

Are you sure that the rounding issues would be caused by inteference? Would wifi be able to cause this kind of inteference? 

Hmm interesting. I have wrapped the arduino in aluminium foil and grounded it to make a faraday cage of sorts. seems that the spikes have stopped for now. 

http://emoncms.org/vis/auto?feedid=63828

check the last few hours

edit: looks like i spoke too soon. I will edit the code tomorrow and see how it goes. Weird that it's only on a single phase though.

Hi Guys, interesting stuff!

I'm inclined to agree with Robert about the stray values being interference and suspect they are more likely to be conducted rather than radiated (therefore unfoiled by the foil), It would be good to see the input as well as the output values from emonHub's logs to confirm the issue is not related to the rounding issue we see.

The rounding is odd and I believe peculiar to your set-up (as far as I'm aware) which makes me wonder if openWRT does something different with floats. None of the values with additional decimal places are significantly changed. This is illustrated with the unix time stamps, derived from time.time() and although the precision isn't enforced in emonHub the "natural" level of precision I have experienced in windows and linux has always been 3 decimal places, but in your log we can clearly see 7 places, frequently.

I took a small sample from your data and stuck it in excel (sidenote - excel wouldn't even display the extra decimal places as the significance was so minor). In the sample I took there were 4 obviously abnormal occurrences, in the attached excerpt, you can see by the preceding and following datapoints there was nothing abnormal outside the fact that the ct3 value is momentarily out of range. ie no effect to other phases, no missing packets, no concatenating of values etc.

Could you run emonHub with loglevel set to DEBUG? and then from emonCMS identify a "spike" and find that packets full journey through emonhub in the log by the timestamp to confirm the value is passed faithfully by emonHub.

If you are confident this was previously working ok you could try switching back to the previous set-up to confirm that is still the case and then either switch to using the laptop with the CT's where they are now or move the router so that you can put the ct's back where they were previously to try and narrow the search.

Paul

Thanks for the insight Paul! I have change the log level to debug, so I will let that run overnight and post the relevant bits of the log in the morning.

 for now, here's a single entry with the extra precision being added:

2014-12-29 01:50:41,623 DEBUG 338 NEW FRAME : 1419780041.62 5 947.24 132.67 388.81 -24.25 243.72 19.40 58.40 17.75 24.37
2014-12-29 01:50:41,628 DEBUG 338 Timestamp : 1419780041.62
2014-12-29 01:50:41,632 DEBUG 338      Node : 5
2014-12-29 01:50:41,636 DEBUG 338    Values : [947.24, 132.66999999999997, 388.81, -24.25, 243.72, 19.4, 58.4, 17.75, 24.37]

So it would appear to be something in the script processing which is doing that. WIll need to see in the morning with an abnormal reading to confirm.

With the previous setup, I was using the older oemgateway script running on os x. I can try running the oemgateway script on openwrt, or emonhub on my laptop to try and pinpoint if openwrt is doing something odd.

Will report back with logs in the morning!

I think the data above confirms that the python float behaves differently on openWRT the value "132.67" is fine as a string but when converted to a float it becomes "132.66999999999997" which is incorrect, some would say "near enough" but none the less it's not "132.67". This is not seen on windows or raspbian. I do not know enough about openWRT or the "floats" minefield to offer an explanation or a solution I'm afraid. I don't think forcing emonhub to round at a preselected level is the answer as this would then produce unfaithful results for higher precision floats.

Although you may get a very very small level of inaccuracy introduced by the precision I think this will be lost in the overall results and only poses an increase in the number of characters posted to emoncms from emonHub and is most probably unconnected to the issue in hand.

I'll have to look into that further. My eventual plan is to get an Arduino Yun and put the shield on that to have a fully contained unit. Such a small inaccuracy is not much of a concern though. 

The results of the debug log are in. I have taken out a few samples of the abnormal results and pasted them below.

Here's the full log: http://www.users.on.net/~teepingkoh/emonlog-debug.txt

Abnormal values are on (approx) lines: 254, 1535, 2088, 2942, 3547, 4359, 4709, 5367, 7696, 8844, 10144, 11150 ,11297, 11318, 11381, 11402, 11871, 12410, 13040, 14448, 17398, 18154, 19260, 19601, 26425, 30953, 31023, 32639, 33825

2014-12-29 11:16:25,618 DEBUG 13177 NEW FRAME : 1419813985.62 5 915.81 230.67 155684.90
 -24.23 244.51 20.80 50.00 20.44 24.62
2014-12-29 11:16:25,623 DEBUG 13177 Timestamp : 1419813985.62
2014-12-29 11:16:25,627 DEBUG 13177      Node : 5
2014-12-29 11:16:25,631 DEBUG 13177    Values :
 [915.81, 230.67, 155684.9, -24.23, 244.51, 20.8, 50, 20.44, 24.62]
2014-12-29 11:16:25,671 DEBUG 13177 Append to 'emonCMS' buffer => time: 1419813985.62,
 data: [5, 915.81, 230.67, 155684.9, -24.23, 244.51, 20.8, 50, 20.44, 24.62],
 ref: 13177

2014-12-29 11:24:29,378 DEBUG 13360 NEW FRAME : 1419814469.38 5 930.55 229.98 2797536.25
 -24.03 244.14 21.10 50.20 20.81 24.81
2014-12-29 11:24:29,383 DEBUG 13360 Timestamp : 1419814469.38
2014-12-29 11:24:29,387 DEBUG 13360      Node : 5
2014-12-29 11:24:29,391 DEBUG 13360    Values :
[930.55, 229.98, 2797536.25, -24.03, 244.14, 21.1, 50.2, 20.81, 24.81]
2014-12-29 11:24:29,407 DEBUG 13360 Append to 'emonCMS' buffer => time: 1419814469.38,
 data: [5, 930.55, 229.98, 2797536.25, -24.03, 244.14, 21.1, 50.2, 20.81, 24.81],
 ref: 13360

2014-12-29 11:27:58,167 DEBUG 13439 NEW FRAME : 1419814678.17 5 927.28 231.82 16579931.00
 -24.12 245.15 21.30 48.50 21.00 24.87
2014-12-29 11:27:58,173 DEBUG 13439 Timestamp : 1419814678.17
2014-12-29 11:27:58,177 DEBUG 13439      Node : 5
2014-12-29 11:27:58,181 DEBUG 13439    Values :
[927.28, 231.82, 16579931, -24.12, 245.15, 21.3, 48.5, 21, 24.87]
2014-12-29 11:27:58,276 DEBUG 13439 Append to 'emonCMS' buffer => time: 1419814678.17,
 data: [5, 927.28, 231.82, 16579931, -24.12, 245.15, 21.3, 48.5, 21, 24.87],
 ref: 13439

Cheers

Edit - wrapped long lines  - BT

The examples you've picked out all show the "spike" is present before the packet is processed by by emonHub, so the issue isn't related to the float precision or being introduced by emonHub.

Another test that may help you narrow the search could be to swap 2 ct leads over at the emontx and swap the input numbers in emoncms (while emonhub is stopped), so you have same phase, same ct, different channel via emontx/sketch/emonhub etc and still logging to the same feeds so your data isn't effected. If the "spikes" remain on the same phase the source is definitely external to both the software and the hardware as you have already ruled out the ct's themselves.

Beyond tips on narrowing the search or eliminating parts I'm not sure I can help you much if it is interference as we suspect, Maybe Robert can assist you further with some prevention or filter tips but it's probably just going to be a process of elimination unless you add some sanity checks to the sketch.

I  think swapping the CTs over to different channels isn't as easy as it seems due to me using direct voltage sampling and 3 phase, meaning i need to probably change some parameters in the sketch to account for this. I might give it a shot and see tomorrow. 

If that leads to the same issue, I will just add some error checking into the sketch.

Would it do any good to add some ferrite chokes to the CT leads to possibly stop interference there?

That might help. If you're pretty sure the source is not under your control, then ferrite chokes on the mains input would be a better (but more expensive) solution. There are commercial mains filters available.

First, try taking the CTs off their cables and moving them as far away as possible. If the problem is still there the same, I'd bet it's not getting in via the CTs, and you need to look at the power supply.

If it is coming via the CTs, then it's probably capacitive coupling onto the secondary winding.
You could try to fashion an earthed foil screen around the CT secondary winding, but make absolutely sure you don't form a single shorted turn anywhere.

The real problem with the CT leads (all the YHDC ones that I've looked at) is that they are twin twisted screened cable, the screen has no connection at the CT end (correct) but it might or might not have a connection at the plug end - I've seen all 3 variants: a deliberate connection, no connection and an 'iffy' connection. If you have an 'iffy' or no connection, a deliberate connection to the plug sleeve might help. Better, probably, would be if you stripped the screen back a little, brought it out and connected it to GND (directly, not via the plug sleeve and the capacitor). A ferrite bead then on the inner cores might help.

(If you do swap the phases around, you need to swap in "G" section in "sumP1 += phaseShiftedV1 * filteredI1;" ) If you don't swap, the powers and power factors will be wildly wrong (because there's now ±120° of artificial phase shift in there), but the spikes will surely still be huge in relation to the wanted input.

So today I switched around CTs 3 and 4, and just changed the pin assignment in the sketch (seemed like the easiest way to swap it around).

No spikes in the data recorded since! CT4 has currently no power draw on it but it's not seeing any spikes at all. seems odd?

Will monitor how it goes over the next day or so to confirm that the issue is gone. Is it possible that there is something wrong with that input on the Arduino?

http://emoncms.org/vis/auto?feedid=63828

Maybe a CT cable plug not pushed all the way home in its jack?

Maybe a CT cable plug not pushed all the way home in its jack?

Definitely not the issue. Could be a cold solder join, but it all looks fine. 

"Is it possible that there is something wrong with that input on the Arduino?"
I can't see how that on its own could account for the values you saw. The sampled value, which just has to be within the range 0 - 1023 as that's all you can get out of the ADC, must go through the library power or rms algorithm and come out as several hundred kW? Even if it was a square wave, it couldn't be that big - only about 34 kW maximum (given a 100 A input), unless of course you are getting values bigger than 10 bits out of the ADC, then there's the effect that would have on the software HP filter to consider.

Let's just assume the software filter sits at 512 and stays there, and you get out of the ADC a square wave with 25 samples of 0 followed by 25 samples of 65535. And assume (to make the answer worse and the maths easier!) the voltage wave is similar but values of 0 and 1023. V x I is then -512 x -512 for the first half, and 512 x 65023 for the second. Averaging and taking the root gives 4096 (and a bit - ignore it). Now the 'standard' input is a sine wave that swings 512 maximum, usually about 470 allowing some for tolerances, so the average of two of those multiplied together is about 330, which scales to 24 kW, so the maximum I can envisage given those quite extreme conditions is about 300 kW. That's still not enough - only a third of what you recorded.

Well I'm completely lost as to why switching pins in the code seems to have fixed the issue. I have a spare arduino coming so will swap that out and see if that is any different.