Archived Forum

Rubbish

or a bit of mains being picked up somewhere, either on the c.t. cable or via the power supply is the most likely cause, but as you are synchronised to the mains, I would not discount digital interference from the processor itself getting back into the analogue input. I think your plugboard assembly might be at least partly to blame.

Take a look at the numbers: 30 W on a 240 V supply is how many mA / mV across the burden?  In the simplest case you're adding this to or subtracting it from a 5 W signal - the spurious one that's being picked up from somewhere - and how many mV is that? I can't work through the numbers because I don't know your circuit values, but I think 300-400 µV is in the right order.

I think you need to be looking at ripple on power supplies and things like that for the source.

Stuart, what reading do you get when your lamp is off, and is this affected by which way around the CT is connected? 

I've never seen more than a Watt of leakage when there is no current is flowing. 

Probably just the plugboard then and my spaghetti wiring !

I'll take a look later at the leakage when no current is flowing, think its around <1W as well.

I'm using a 22ohm burden resistor (5% tollerance), followed by an opamp gain of about 19 (from memory might be lower!).  Running from a 5v split (again via Opamp) to 2.5v dc offset.

Think it might be time to get the soldering iron and stripboard out.

Just remembered that I also need to invert the current samples as I'm using the OpAmp and this is inverting the signal!

I've just tried this test in the garage where my rig is as basic as they come: sensors on breadboard; the voltage sensor is a 'telecom' adapter which gives awful distortion, much worse than a Mascot; blue CT clamp with 150R burden hence high phase-shift; cut-down 'mini' sketch with PHASECAL = 1 hence no correction of phase-shift.  System not calibrated.   But, hey, it all works and provides hot water.  The Mk2a will happen in due course ...

Anyway, by uncommenting the two lines containing energyInBucket_4led (just after the "WARNING" about Serial statements), the energy change per second can be easily displayed.  Moving the CT to a test lead where no current was flowing, negligable leakage was detected either way round.  With a 40W bulb, my readings were 27.5W in one direction and 29W in the other.  For some reason, the value was always slightly greater in one direction.  At this level of power, the current sensor is really struggling, so the coarseness of the ADC's resolution may well be coming into play here, as Robert has often pointed out.

Thankfully, when measuring higher loads - from 750W to 2kW - I saw very little difference when the CT was reversed.  All of my readings look to be around 2/3 of their correct value so I have taken the opportunity to recalibrate my rig by changing the value of POWERCAL from 0.042 to 0.6.  This change makes not the slightest difference once the system gets going, but it should now reach the 1800J point just that little bit quicker than it did before.

Both types of current clamp that I've bought indicate the direction that current should be flowing in.  For the PV Diversion application, the net flow of current at the CT is zero, so there would seem to be no right or wrong way round.  But when measuring a simple flow of current in a test circuit, the construction of the CT may favour detection better in one way than the other.  Sorry, I can't recall which direction of flow gave the higher reading.

Because of screen-width limitations, the rawSampleTool that I posted a while back compresses data that's been measured on a scale of 0-1023 at the ADC to just 80 characters.  Here is a version which displays the raw data for current just as it has been sampled by the Arduino with no compression (the voltage waveform is still compressed as before).  Ideal for investigating the behaviour at small currents ...

Along with the sketch itself, two files of results are attached.  One was taken in debug mode, the power flowing being nominally 25W.  Having subtracted the nominal DC offset of 500 that is used in this mode, the output waveform is neat and symmetrical as expected, but see how few (simulated) ADC steps are involved.  In the real world, it seems likely that the sequence of output samples could be significantly affected by the precise centre point of the waveform - i.e. how close it lies to the nearest decision level.

The second file shows a real 40W filament bulb being tested (in normal mode) using this sketch on my rig in the garage.  There are three runs: first with the bulb off; then with it on, and with the CT in either direction.  The resulting waveforms are rather grainy, and I wouldn't like to have to compare their power content in any detail.  But that's what the Arduino does for us 24/7 - something to ponder about in my next free solar bath :)

Think it might be time to get the soldering iron and stripboard out.

And as you do so, pay attention to keeping the analogue and digital sides separate, keep both the analogue supply and its ground clean and free of digital signals and 50 Hz ripple.

Let's say you're looking for a 5 W equivalent ripple voltage that's being impressed on the c.t. input:
5 W @ 240 V = 21 mA.
Out of a 100 A : 50 mA c.t, that's 10.4 µA.
and across a 22 R burden, it's 230 µV.

So that's what you're looking for, and I was 50% out in my guess! To put it into context, you get more than that with 1 mA flowing across a joint with ¼ Ohm resistance.