STM32 Development

Hardware
,
93

yes a single ac:ac adapter 3ph solution

indeed, and you will find no one keener than I to use 3 ref voltages, but as you know many users do not go that route, I will never use a single ac:ac adapter 3ph monitor if I can avoid it, and I always do. My interest here is purely to contain the number of FW’s in circulation, I do not recommend using a single ac::ac 3ph solution and I’m well aware of the reasons for that, But still users will want it. To think it is not going to be required would be foolish.

I’ve used “derived-3ph” as a term to replace “single ac:ac adapter 3phase” as it’s a lot of typing, do you have a preferred term? There has to be a simple way of distinguising between “3 ac:ac adapter 3phase” and “single ac:ac adapter 3phase”. “3phase FW” is too vague and will cause confusion

94

Actually, if you are going the s/w phase correction route, and you don’t mind also correcting for the slight offset introduced by the ADC cycling around from channel to channel, @TrystanLea’s project above might be a better starting place. It has the advantage that it works with a stock shield (no jumper required). You could potentially even productise that and sell more shields. It was only the delayed ADC-trigger stuff that forced me to move the V signal.

95

Adding the jumper and using a shield are just means to basic tests on it, we would want more than 4 cts and 1ac.

I personally need 3ac’s and 5ct’s per phase minimum. the intension here is hopefully not to be to constrained by anything, start with a clean sheet, decide what we want and use what we’ve learnt to achieve it rather than reuse what we’ve developed already

I actually recommended we order a short batch of a (say) 10 cheap pcb’s with footprints for 18-21 3.5mm sockets and 3 AC’s sockets that we can populate by hand and connect to the nucleo board with jumpers for initial dev testing. That way we can try all the adc routing options.

96

Yes, fair point. The 1V+4CT shield is just an interim prototype board.

97

OK, I completed the ADC trigger delay stuff, even if it ends up not being used it might be useful for playing around or calibration. It now supports:

+ve lags (Current ADCs are launched early, Voltage ADC is launched late)
-ve lags (Voltage ADC is launched early, Current ADCs are launched late)
0 lag (all four are launched at the same time).

In these traces Red is the Voltage ADC input, Blue and Yellow are two of the three Current ADC inputs. Green is the ADC trigger signal:

scope_387
scope_387800×503 20 KB

start_ADCs(10);

scope_388
scope_388800×503 20 KB

start_ADCs(-10);

scope_389
scope_389800×503 11.7 KB

start_ADCs(0);

I’ve also added access routines to the CPU temperature and the Vdda reference voltage (since we were sampling them anyway), and a dump facility in power.c in case you want to look at the signals instead of doing power maths on them.

I think that’s about it, and I’ve tar’d it all from one level higher, so hopefully no build dramas this time.
txshield_demo_5.tar.gz (883.2 KB)

98

Paul in this thread you pointed out that STMDuino now gives support for the STM32 chips in the Arduino environment → Best hardware option for multiple CTs & WiFi - #24 by fahrvergnuugen

It would be great if the code you guys are working on could be made into an Arduino library - say, CT-STM32 or STM32MainsPower or some such name which can be used like say OneWire, i.e. by creating an object with parameters that would specify the inputs etc. or at least have the most common configurations pre setup so to speak?

Also just want to say this has been one of the most interesting, informative threads for a long time. Please keep documenting things as you go along. Just wish I had more time to be able to experiment along with you guys. Can we have star ratings for threads? :slight_smile:

Simon

PS If there’s so much spare capacity in the system and if this becomes the new standard for emon processor then maybe we could get them mining bitcoins in the background to pay for our emoncms.org accounts. :smiley:

99

I’ll drink to that. It’s the first thing I read after logging on! :grin:

100

4 posts were split to a new topic: STM32 PlatformIO

101

For info, this is the latest version (v5) of dBC’s txsheild_demo_5.tar.gz, which as can be seen, now captures & prints CPU temperature and Vdda (the analogue reference voltage).
The readings are obviously wrong as I’ve just hooked it up with no CT’s or AC input into the shield at the moment, just for a quick screenshot.

Moving forward nicely!

Paul

v5

102

Those Irms values look very good… almost too good to be true. Do they ever change at all? I’m assuming that’s the mid-rail? I’m not quite sure what to make of Vrms but it looks pretty solid too.

I struggle with headphone jack schematics. Can someone advise what the expected behaviour is when nothing is plugged in please?

103

No, the Irms is always a steady 2047.88
The Vrms is very changeable - I assume just noise because it’s not connected.
I need to get another set of CT’s and an AC/AC power adapter, then hopefully I’ll get some meaningful readings.

Paul

104

hmmm… I hope that’s not a bug :frowning:

Is the shield plugged into the Nucleo, or are the Nucleo inputs totally floating?

105

That’s what I thought too. However here’s a schematic

schematic.png1787×1282 69.4 KB

thinking that was a typo, I’ve buzzed out a pcb and found it is correct.

The wrong side of the CT/burden gets grounded, so instead of the expected behavior it is grounding the mid-rail and the ADC input is then pulled to ground via the 33R burden.

There is no such mechanism on the AC input so that ADC is left floating.

So now I too question the unconnected results as I would of expected the Irms to have been much lower.

As were my remaining 3 unpopulated CT inputs, they too were a fixed 2047.88 exactly. I’ll do some connected v unconnected comparisons in a bit

106

The shield is attached (as well as the link).

Paul

107

My shield hasn’t turned up yet, but I should be able to mimic that just with a resistor bung straight into one of the current input holes on the Nucleo. It might be something to do with the offset removal maths. Does a multimeter on any of the current inputs read 0V?

108

Both ends of the burden are 0v for me, if I ref to VCC they are both at 3.3v.

109

Yeh, I’ve replicated it by just grounding all my inputs. Looks like a maths issue. Expect a patch soon.

110 
CPU temp: 29C, Vdda: 3304mV
0: Vrms: 1145.40, Irms: 41.06, Papp: 47028.46, Preal: 229.47, PF: 0.005
1: Vrms: 1145.40, Irms: 2047.88, Papp: 2345638.25, Preal: 2673.99, PF: 0.001
2: Vrms: 1145.40, Irms: 2047.88, Papp: 2345638.75, Preal: 2673.90, PF: 0.001
3: Vrms: 1145.39, Irms: 2047.88, Papp: 2345630.25, Preal: 2770.55, PF: 0.001
CPU temp: 29C, Vdda: 3304mV
0: Vrms: 1144.57, Irms: 40.84, Papp: 46745.62, Preal: 236.96, PF: 0.005
1: Vrms: 1144.57, Irms: 2047.88, Papp: 2343937.25, Preal: 1980.77, PF: 0.001
2: Vrms: 1144.57, Irms: 2047.88, Papp: 2343937.75, Preal: 1980.78, PF: 0.001
3: Vrms: 1144.54, Irms: 2047.88, Papp: 2343879.75, Preal: 2062.65, PF: 0.001
CPU temp: 29C, Vdda: 3304mV
3: Vrms: 668.60, Irms: 2047.88, Papp: 1369220.62, Preal: 2514.68, PF: 0.002
0: Vrms: 668.62, Irms: 40.71, Papp: 27217.23, Preal: 139.99, PF: 0.005
1: Vrms: 668.62, Irms: 2047.88, Papp: 1369244.50, Preal: 2432.89, PF: 0.002
2: Vrms: 668.62, Irms: 2047.88, Papp: 1369244.62, Preal: 2432.91, PF: 0.002
CPU temp: 29C, Vdda: 3302mV
2: Vrms: 62.37, Irms: 2047.88, Papp: 127720.05, Preal: 2871.00, PF: 0.022
3: Vrms: 62.40, Irms: 2047.88, Papp: 127797.09, Preal: 2951.69, PF: 0.023
0: Vrms: 62.37, Irms: 40.54, Papp: 2528.41, Preal: 87.57, PF: 0.035
1: Vrms: 62.37, Irms: 2047.88, Papp: 127720.03, Preal: 2870.98, PF: 0.022
CPU temp: 29C, Vdda: 3302mV
2: Vrms: 62.33, Irms: 2047.88, Papp: 127642.02, Preal: 2791.56, PF: 0.022
3: Vrms: 62.36, Irms: 2047.88, Papp: 127712.30, Preal: 2866.68, PF: 0.022
0: Vrms: 62.33, Irms: 40.41, Papp: 2518.43, Preal: 138.58, PF: 0.055
1: Vrms: 62.33, Irms: 2047.88, Papp: 127641.99, Preal: 2791.55, PF: 0.022

with v5 loaded I get pretty similar results to Paul. I have a CT plugged in “ct1” with no load and initially I had a 9v AC input too for the first 2 printed blocks, then I whipped it out, so the last 2 blocks are with a floating AC input.

111

I quickly scanned your maths and it didn’t look right, but it was late…
I’ll look again later today.

112

Yeh, I got the divide and the sqrt() around the wrong way in the RMS calculation!