Archived Forum

"Like all ARM based boards, they operate at 3.3V rather than 5V, so the input signal conditioning needs to be adjusted to suit the max voltage range, i.e the voltage dividers on both the current and voltage sensors need to be changed slighltly."

No they won't (nor the default calibration) if you use the emonTx values, which also uses a 3.3 V supply.

Hi Robert

Although the voltage dividers to create the mid point bias/offset voltage don't need to be changed, voltage dividers for both the voltage sense and the current sense are not likely to be the same , i.e if you already had built some external signal conditioning for an AVR baord,

i.e My understanding is that for best accurary, the AC input from the voltage sense, need to provide the AVR boards with just under 5V AC peak to peak, where as on ARM boards this needs to be just under 3.3V peak to peak.

As I'm building this from scratch, with the signal conditioning on a piece of Veroboard, I 'm using a 10k trim pot to form the voltage sense divider, and I trimmed it to produce about 3V for 250V input. and also trimmed current sense input to give around 3V P/P when there is a 4kW load

I still need to clamp the max current at 4kW, as I know the read damand could exceed 4kW but I don't have the capacity to export more than 4kW, and managing the amount of power that is exported vs used for heating etc, is my main aim.

Hence I'm aiming for best accuracy up to 4kW and anything above that, will be dealt with by the software.

You can run the AVR at 5V or 3.3V and some of the OEM designs do use 3.3V.

@dBC

Thanks. I was aware that AVR can be run at 3.3V, but at 3.3V, I think you need to lower the clock frequency to stay within the spec (thats not to say that most chips don't work fine at 16Mhz on 3.3V)

My main reason for posting, was just to let the community know that that eMonLib compiles and works fine on STM32 devices, as there are many libs that don't work on ARM boards or the STM32

... to let the community know that that eMonLib compiles and works fine on STM32 ...

I think this is very nice to hear as the Atmel 8-bitter is 'at the edge' regarding performance for a lot of the energy monitoring stuff (one of the reasons why it is overclocked  at 16MHz and 3V3!), especially in three-phase systems and when other functionality has to be added (temperature sensing, RF connection, ethernet).

The ARM controllers are a 'natural' replacement for the Atmel, the only problem is that there are so many of them around that it is hard to make a decision which one to use. But the 'Maple' like hardware with 12 bit ADC and Arduino compatibility seems to be a very good choice.

BR, Jörg.

Yes, I certainly didn't mean to discourage your ARM work, indeed I've long been suggesting it.  I was just pointing out that any resistor work you need to do for 3.3V operation is presumably already done for the 3.3V AVR OEM designs, so you could potentially copy that.

@dBC

No discouragement taken ;-)

I'll have a look for some other 3.3V implementations, but at the moment my only issues seem to be related to the current clamp scaling values, which seem to need to be quite low , possibly because the ADC is 12 bits not 10 - but I'm not sure, or possibly because I'm limiting my range to around 4kW by having approx 200 ohm burden resistor on the current clamp

One thing I've also just noticed is that if I swap the current clamp direction I'm getting quite different results i.e different power being shown. But I doubt this is a ARM issue, and I presume this is a common question, so I'll endevour to track down the answer.

 scaling values, which seem to need to be quite low , possibly because the ADC is 12 bits not 10 - but I'm not sure

That probably makes sense since all the readings will be 4x bigger.  Your raw mid-line reading will be 2048 instead of 512, and your high peak will be approaching 4095 instead of 1023.

"One thing I've also just noticed is that if I swap the current clamp direction I'm getting quite different results i.e different power being shown."

The likeliest reason for that is voltage crosstalk, i.e. there is some voltage signal adding to the current signal, so when you reverse the orientation of the CT and hence invert the current signal, the voltage now subtracts, hence the difference.

Robert,

Thanks

I'll put my scope on the two analogue inputs and see whats going on.

You probably need to take the CT off, and well away from, its cable and see what you read. If it's half the difference, there's your answer.

Robert,

Its possible my test rig is no good.  I'm using a plug / socket arrangement with separated live and neutral wires that is part of a commercial power monitor, but the L and N wires are in two quite short loops and they are not very far apart from each other, so there could be some inteference.

I'll probably need to make a better test rig cable

I did measure the influence of adjacent cables on the 'shop' 100 A CT - see the report.

Can you post a link  to that

http://openenergymonitor.org/emon/buildingblocks/report-yhdc-sct-013-000-current-transformer

@dBC

Thanks for the link.

I don't know what I was doing wrong yesterday, but the difference between the power when flowing in different directions, has now been fixed.

I think I just had wildly wrong calibration figures, as I was running on a different PC, and was using the default calibration values.

My re-calibrated values are

  emon1.voltage(PA0, 243,7.5);  // Voltage: input pin, calibration, phase_shift
  emon1.current(PA1, 8.42);       // Current: input pin, calibration.

The current calibration is low because I only want to read 2kW for max input voltage range, and also I suspect because the ADC range is 12 bits instead of 10 bits on AVR

I have noticed however an problem that I needed to fix

I checked the ADC inputs with no signal input, and the are the current input reading about 1860 when they should be reading about 2048 (half of 4095).

Checking the voltages on the pins, the voltage divider on the current input is wrong, reading around 1.45V instead of 1.6V, so it looks like one of my resistors is way out of tollerance, or the capacitor is resistive.

(The voltage input is fine)

I'll need to take the circuit apart and re-measure the resistors

This will of course be causing problems with my results, which are actually surprisingly good even though the current input voltage must be going below 0V for a small part of the waveform :-(

I'm also seeing a lot of supply noise coming in from the PC via USB, which I don't get at all when I run the board from a separate USB PSU. I don't think there is a lot I can do about this, apart from getting a powered USB hub, but I think I'll live with it for development.

Just as a matter of interest, I timed by max min test sketch, and its performing a million samples in 7 secs, i.e 7uS per analogue sample (well the rest of the code is probably taking a few uS, so the sample is probably more like 4 or 5uS)

Looking at the code in calcVI, having faster sample times, may help with calculation precision, as its going to be in the while loop for a lot more iterations.

Also, I noticed that most variables are doubles, which is great, as the STM32 being ARM has proper double unlike AVR which AFIK typedef's double to float.

Of course processing doubles is going to take more cpu cycles (on any processor) than floats, so it would be interesting to compare the number of iterations in the main while loop of calcVI on STM32 vs a Uno etc

(But I'll leave that for another day)

Anyway, thanks again for all your help

Cheers

Roger

You might want to tune PHASECAL as well as I believe its current setting assumes the 110 usecs between sampling V and I, while your V and I samples will be much much closer together.

@dDB

I did change my phaseCal to 7.5 as this seemed to give me a power factor of 100.00 when runing a 2kW oil filled electric radiator.

I have one of those inline power meters which I'm using as my calibration reference (actually I have 2 different types of these, so I should compare what they both read), and it shows 100% power factor for the radiator.

My calibration factor is about 7.5, which probably makes sense, as it would imply that the STM32 is sampling between 4 and 5 times faster than the AVR boards (if the default value for phaseCal is 1.7)

Generally the STM32's, running at 72Mhz come out at operating at around 5.5 times faster than a 16Mhz AVR, because of both the clock speed and also some instructions are more efficient on the ARM CPU.

However, the calculatuions of doubles on ARM vs I think doubles type defed to float's on AVR probably slow things a little in relative terms, so values of about 4 times larger for phaseCal on STM32 @ 72Mhz sound about right.

 I only want to read 2kW for max input voltage range

You may have considered and dealt with this already, but in case not: if there's any chance a fault on the circuit being monitored will cause much larger power flows (at least until a fuse blows) then you need to consider what voltages/currents that will expose your ADC pins to.   There's quite a bit of detail in the datasheet for your CPU about that under "I/O current injection".

Also, if you "amplified" your CT output simply by increasing the burden there is a limit to how far you can do that before the signal starts to distort, or phase errors become large, but since you have a scope that should be easy to test.

@dBC

You may have considered and dealt with this already, but in case not: if there's any chance a fault on the circuit being monitored will cause much larger power flows (at least until a fuse blows) then you need to consider what voltages/currents that will expose your ADC pins to.   There's quite a bit of detail in the datasheet for your CPU about that under "I/O current injection".

Thanks

I was going to clamp the input with zeners

 

Also, if you "amplified" your CT output simply by increasing the burden there is a limit to how far you can do that before the signal starts to distort, or phase errors become large, but since you have a scope that should be easy to test.

I will probably reduce the burden resistor a bit, (is a 200 ohm trim pot), and get a range up to 4kW.

However even at the moment I get a nice clean sine wave with about 200 Ohms as the burden.

I understand that impedance matching can cause problems if the burden resistor is wildly miss matched with the pickup coil.

My CT is a SCT-013-030 but I opened it up and removed the internal 68 ohm resistor, so that I can use an external variable resistor.

I'm not sure if the 030 has the same coil as the SCT-013-000, but I know I'm not the first person to convert a SCT-013-030

I took a look online and I noticed that one eBay vendor was selling a wide range of SCT-013 devices, some of which looked a bit more suitable for my application e.g. the SCT-013-010 claimed to give 1V per 10A, however it wasnt clear if this was 1V RMS or 1V P/P, I'm assuming RMS i.e so P/P would be 2.82V at 10A i.e at 2.4 kW  (assuming 240V supply)

But I'll carry on with testing my current config.

BTW. I am also interested in ESP8266 devices, but they only have 1 ADC. So I've just ordered some 16 Channel analog mux modules, as it it should be possible with slight modification to the code to switch the input into the ADC via the Mux, and hence still read V and I

However, I suspect a bigger issue with the ESP8266 is that putting code in a tight loop while the signals are analysed, e.g. in calcVI, would cause drop out of its wifi operations.

So... I've also ordered some EW3135 modules, which are a STM32F411CE microcontroller, paired with a wifi module (via SDIO I think)

http://www.seeedstudio.com/depot/EMW3165-CortexM4-based-WiFi-SoC-Module-...

This would offload the sensing to the STM32F411CE, which is an exceptionally fast device

Update.

I figured out my offset problem, was just the load of my scope, affecting the offset voltage divider.

Everything now seems to work really well.

This is not an entire fair comparison, but I tested an Nano using the same external circuit (but re-adjusted the trim pots for 5V P/P) and the Nano actually suffered more from supply noise, or possibly ADC noise of some other kind, than the STM32 does.

The voltage readings I see on the STM32 are far more stable.

With no load, I'm seeing data like this (sampling over 100 crossing points, i.e 1 sec)

242.30V RMS ,0.05A RMS ,-0.53W ,Powerfactor -4.28%
242.57V RMS ,0.05A RMS ,-0.72W ,Powerfactor -5.57%
243.00V RMS ,0.05A RMS ,-0.63W ,Powerfactor -5.10%
243.09V RMS ,0.05A RMS ,-0.74W ,Powerfactor -6.71%
243.12V RMS ,0.05A RMS ,-0.75W ,Powerfactor -6.15%
243.51V RMS ,0.05A RMS ,-0.45W ,Powerfactor -4.02%
243.48V RMS ,0.05A RMS ,-0.46W ,Powerfactor -3.83%
243.22V RMS ,0.04A RMS ,-0.67W ,Powerfactor -6.33%
243.76V RMS ,0.04A RMS ,-0.57W ,Powerfactor -5.24%
243.69V RMS ,0.04A RMS ,-0.64W ,Powerfactor -5.96%
243.56V RMS ,0.04A RMS ,-0.75W ,Powerfactor -7.06%
243.32V RMS ,0.04A RMS ,-0.73W ,Powerfactor -6.95%
243.14V RMS ,0.04A RMS ,-0.65W ,Powerfactor -6.14%
243.43V RMS ,0.04A RMS ,-0.70W ,Powerfactor -6.59%
243.15V RMS ,0.04A RMS ,-0.72W ,Powerfactor -6.85%
243.14V RMS ,0.04A RMS ,-0.61W ,Powerfactor -5.87%
242.77V RMS ,0.04A RMS ,-0.60W ,Powerfactor -5.72%

On load of just over 2kW, I get values like this

33.92V RMS ,8.56A RMS ,2001.17W ,Powerfactor 100.00%
233.80V RMS ,8.53A RMS ,1993.19W ,Powerfactor 100.00%
234.09V RMS ,8.52A RMS ,1993.35W ,Powerfactor 100.00%
234.15V RMS ,8.50A RMS ,1989.96W ,Powerfactor 100.00%
234.61V RMS ,8.50A RMS ,1993.47W ,Powerfactor 100.00%
234.37V RMS ,8.47A RMS ,1986.32W ,Powerfactor 100.00%
234.43V RMS ,8.46A RMS ,1983.89W ,Powerfactor 100.00%
234.40V RMS ,8.45A RMS ,1980.42W ,Powerfactor 100.00%
234.31V RMS ,8.43A RMS ,1976.01W ,Powerfactor 100.00%
234.59V RMS ,8.43A RMS ,1978.64W ,Powerfactor 100.00%
234.41V RMS ,8.42A RMS ,1972.77W ,Powerfactor 100.00%
234.80V RMS ,8.42A RMS ,1977.74W ,Powerfactor 100.00%
235.76V RMS ,8.45A RMS ,1992.04W ,Powerfactor 100.00%
235.08V RMS ,8.42A RMS ,1978.59W ,Powerfactor 100.00%
235.26V RMS ,8.42A RMS ,1980.28W ,Powerfactor 100.00%
235.67V RMS ,8.43A RMS ,1985.90W ,Powerfactor 100.00%
235.79V RMS ,8.42A RMS ,1986.25W ,Powerfactor 100.00%

The drop in load is real, i.e its also reported by my inline current meter, the resistance of the fire must go up as it starts to warm up.

I had considered whether it may still be best to use a Nano for this project for ease with interfacing to other peripherals, but as the STM32 seems to give better results, I'm almost certainly going to use it, even though I may need to put more work getting the radio libs to compile and run.

Anyway, thanks for everyone's help with this.

I figured out my offset problem, was just the load of my scope, affecting the offset voltage divider.

Hi Roger,

Was it your scope input set to 50 Ohms vice 1 MOhm?

"I understand that impedance matching can cause problems if the burden resistor is wildly miss matched with the pickup coil."

That's a red herring. The CT is a current source, and the secondary resistance is essentially irrelevant. Provided that the CT has a sufficient VA rating, the burden voltage is determined solely by the burden resistance (given a constant primary current). The CT is happiest, unloaded and at its most accurate, when working into a short circuit.

"The drop in load is real, i.e its also reported by my inline current meter, the resistance of the fire must go up as it starts to warm up."

Indeed it does, and the phenomenon is known is "inrush". For a tungsten lamp, the inrush current is around 12 × the running current. You can look up the temperature coefficient of resistance if you're really interested, it varies of course from metal to metal.

"it wasn't clear if this was 1V RMS or 1V P/P"
It is always rms unless stated otherwise. To the best of my knowledge, all SCT-013-xxx CTs are the same beast, the only difference being the value of the internal burden resistor, or the absence thereof (replaced by zeners) in the -000 version.

"Was it your scope input set to 50 Ohms vice 1 MOhm?"
Even a 1 MΩ input impedance 'scope would seriously drag down the centre point of a pair of 470 kΩ resistors, from 50% to about 40% of the supply voltage.

Indeed.  Roger, assuming you're not trying to run your front end off batteries, don't be shy about lowering those 470KRs way way down.  They are historically that high to enable long battery life, but if you're going to power it from the mains, 470K is crazy high for building a stable, low-noise rail (as you just discovered by loading it up with your scope).

Using 470K dividers instead of 20K dividers saves you about 100uA.   On AVR designs (so not relevant to this thread), disabling the digital input buffer on that ADC pin will save you about 800uA.  AFAIK the current OEM sketches don't do that.  It's a pretty big save for the cost of setting some bits in the DIDRn registers.  

@dBC

Re: Dividers

As I need to sense voltage as well as current, because I need to measure power flow. I will need to have a mains supply near the Tx for sensing, so I may as well power it from the mains.

I assumed that the 470k resistors in the dividers where that high to allow the Tx to run on batteries, but also to make the bias voltage less immune to noise.

I'd already dropped the 470k's down to 270k, after previously having tried some low values. I think I tried 1k

But using higher values does give some noise reduction on the bias rail, hence I pushed the values back up to 270k.

From memory, I think there are issues if you try to use the ADC on the STM32 to read impedances of above around 150k (I think there is an application note about this)

However, I thought that the input impedance from the CT is more a function of the CT and the 10uF capcacitor than it is of the 270k (or 470k resistors)

i.e The 10uF cap is what is really supplying the input current into the ADC and not the resistor divider network.

So I suppose a better arrangement would be to change the 10uf to a larger value e.g. 47uF and drop the resistor dividers to 47k, as that would give a similar time constant / noise immunity.

But of course electrolitics are not good at absorbing noise, so I should have some smaller e.g. 100nF or 10nF caps across the 10uF

However, if I run the whole thing of a less noisy supply, I think the issues will go away

I'm just rig up something where I can connect via USB to the board, but apply a separate supply. So I'll post again when I've done that and got some results

But using higher values does give some noise reduction on the bias rail, hence I pushed the values back up to 270k.

It'd be interesting to know more about that.  My gut feel is that the stiffer that rail is the better.  My definition of "noise" includes anything that knocks it off it's nominal voltage.  Do you have a theory as to why increasing the R reduced the noise?

I think there are issues if you try to use the ADC on the STM32 to read impedances of above around 150k 

That's pretty impressive.  The equivalent value for the AVR is anything above 10K.

i.e The 10uF cap is what is really supplying the input current into the ADC and not the resistor divider network.

Yes, that's the conclusion I came to do on my back-of-the-envelope equivalent circuit here:  http://openenergymonitor.org/emon/node/10097

I think you can do pretty much anything you want to those Rs and it won't make much difference to the source impedance.  Some have claimed the higher value helps protect the input pin from higher currents, by my analysis in that thread suggests not by much.

Given the current design seems to come in below the 10K AVR restriction, I wouldn't have thought you'd have any problems coming in below your 150K restriction.

@dBC

I'd need to model the divider in LTSpice to see if the higher resistors make any difference, but in my not too technical tests were that higher values seemed to be showing less noise on my scope.

I presumed that the divider is an RC network, so the high the R lower the  3dB point, in the frequency response would be.

Re: 150k input impedance.

The Application note is http://www.st.com/web/en/resource/technical/document/application_note/CD...

Section 3.4 on page 20 indicates quotes 150k as a high input impedance source.

Spec on the whole STM32F103C microcontroller is here

www.st.com/web/en/resource/technical/document/datasheet/CD00161566.pdf

I think most of the ADC data is on page 76

It has these statements

External input impedance  50 k ohms

Sampling switch resistance 1k

I think one problem is at those high R values, your scope is becoming part of the circuit, and probably earthing things too (unless it's isolated).    Without any test gear attached, does the ADC report less noise when you use higher R values for the divider?  If so, maybe you need to improve your Vcc.

That's a great application note, and most of that stuff applies to all AtoD applications.  As you've already discovered, and it re-enforces, a good ripple-free supply is critical.  I'd start there.  My low-divider-R theory assumes that the divider has good low impedance access to a GND and a low impedance ripple-free Vcc.

The specs on the ADC look good, and the 50K source impedance gives you quite a bit more headroom than the corresponding 10K for the AVR.  I doubt you'll have any source impedance issues there.

@dBC

Running on my bench supply is a lot better than the USB from the PC.

I do still see some small spikes on the ADC line, but I'm not sure if this is noise being generated by the board it's self on its supply lines, or some function of the ADC sampling its self.

If I let the ADC line float and look at it on the scope I see a saw tooth waveform, which I think is caused by the ADC sampling the pin.

Strangely, I think when it samples, that the ADC pin is pulled slightly high by the acquisition, (which I think accounts for the small spikes).

But I really don't think its worth worrying about too much.

I will however take another look at the mains voltage sampling, as currently because I'm using a 12V transformer, I'm using a divider of a 33k resistor in series with a 10k trim pot.

But this means that I've got about 40k input impedance on Vin. I'll probably drop this down to a 1k trim pot and a 3.3k resistor, so that there is more drive available.

I'm not sure what the normal range of variance on the voltage measurement is, but I'm seeing a maximum of +/- 0.4 V , when sampling over 100 crossings.

My incoming supply is actually not that stable, as our power is via overhead power cables (even here in the suburbs of Melbourne), and I see voltage changes of several volts over a 5 minute period on the mains supply, even when we don't have any large loads going on and off in the house (or any solar coming in)

However I think those fluctuations are very low frequency and not the "noise" i'm seeing on the mains voltage.

I suppose I could try measureing the mains with my DVM if I feel adventurous ;-)

The glitches are probably the charge-n-hold cap being charged (or discharged).  I think that got a mention in your application note, and I posted a picture of the AVR equivalent recently here:  http://openenergymonitor.org/emon/node/11011

With regards your Voltage sensing input, did you check out how the OEM designs do it?  They pretty much replicate the current input, but just replace the CT with the VT.  I think that'll solve any input impedance issues.  Those designs are fairly well proven, and there's even a 3.3V version.  In theory, you should be able to just swap out the CPU and leave everything else untouched ... perhaps tweaking R values to suit your specific needs.