STM32 Development

dBC · 26 March 2018 07:26

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:

start_ADCs(10);

start_ADCs(-10);

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)

Bramco · 26 March 2018 08:51

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?

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.

Bill.Thomson · 26 March 2018 11:29

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

TrystanLea · 27 March 2018 07:48

4 posts were split to a new topic: STM32 PlatformIO

Paul · 27 March 2018 08:36

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

dBC · 27 March 2018 08:49

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?

Paul · 27 March 2018 09:36

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

dBC · 27 March 2018 09:44

hmmm… I hope that’s not a bug

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

pb66 · 27 March 2018 09:57

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

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

Paul · 27 March 2018 10:09

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

Paul

dBC · 27 March 2018 10:12

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?

pb66 · 27 March 2018 10:28

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

dBC · 27 March 2018 10:30

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

pb66 · 27 March 2018 10:40

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.

Robert.Wall · 27 March 2018 10:45

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

dBC · 27 March 2018 11:16

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

dBC · 27 March 2018 11:36

OK, I’ll release a new v6 tarfile later tonight, but in the meantime, the fix to power.c is pretty simple so @pb66 you might just want to patch it into your github, or wait for the v6, whichever is easiest. I also bumped the Version number to 1.2 in the startup banner (not shown here).

*** power.c.v5	2018-03-27 21:04:45.632134108 +1000
--- power.c	2018-03-27 21:25:38.706592139 +1000
***************
*** 118,131 ****
        //
        // And remove its RMS from the accumulated RMS
        //
        local_stats.sigma_v_sq -= (float)(Vmean * Vmean);
        local_stats.sigma_i_sq -= (float)(Imean * Imean);
  
        //
        // Calculate the RMS values and apparent power.
        //
!       Vrms = sqrt(local_stats.sigma_v_sq/(float)count);
!       Irms = sqrt(local_stats.sigma_i_sq/(float)count);
        Papp = Vrms * Irms;
  
        //
--- 118,133 ----
        //
        // And remove its RMS from the accumulated RMS
        //
+       local_stats.sigma_v_sq /= count;
+       local_stats.sigma_i_sq /= count;
        local_stats.sigma_v_sq -= (float)(Vmean * Vmean);
        local_stats.sigma_i_sq -= (float)(Imean * Imean);
  
        //
        // Calculate the RMS values and apparent power.
        //
!       Vrms = sqrt(local_stats.sigma_v_sq);
!       Irms = sqrt(local_stats.sigma_i_sq);
        Papp = Vrms * Irms;
  
        //

It’s improved my PF with the signal generator too. It was just slightly off 1 (at about the 3rd decimal place) and I put that down to some uncorrelated noise that was showing up in the RMS number, but not in the dot product. But with that fix in place, Real and Apparent are insanely close…

emonTxshield Demo 1.2                                                                                        
Patch PA0 through to PB14 for V!!!                                                                           
CPU temp: 38C, Vdda: 3304mV                                                                                  
CPU temp: 38C, Vdda: 3302mV                                                                                  
0: Vrms: 1199.63, Irms: 1199.38, Papp: 1438808.88, Preal: 1438810.75, PF: 1.000                              
1: Vrms: 1199.63, Irms: 1199.06, Papp: 1438419.75, Preal: 1438394.62, PF: 1.000                              
2: Vrms: 1199.63, Irms: 1199.05, Papp: 1438417.88, Preal: 1438419.25, PF: 1.000                              
3: Vrms: 1199.59, Irms: 1199.05, Papp: 1438368.00, Preal: 1438352.62, PF: 1.000                              
CPU temp: 38C, Vdda: 3302mV

pb66 · 27 March 2018 12:41

so I have put the corrections into another (fix_maths) branch pending review. ~~(see fix_maths · stm32oem/stm32tests@66a87d9 · GitHub)~~ [branch now deleted as the changes are in the master branch]

This is my output after flashing

emonTxshield Demo 1.1
Patch PA0 through to PB14 for V!!!
CPU temp: 30C, Vdda: 3306mV
CPU temp: 30C, Vdda: 3302mV
0: Vrms: 0.03, Irms: 0.02, Papp: 0.00, PrCPU temp: 30C, Vdda: 3302mV
0: Vrms: 0.03, Irms: 0.02, Papp: 0.00, Preal: 93.21, PF: 145989.391
1: Vrms: 0.03, Irms: 0.23, Papp: 0.01, Preal: 2643.36, PF: 355324.750
2: Vrms: 0.03, Irms: 0.23, Papp: 0.01, Preal: 2643.36, PF: 355313.250
3: Vrms: 0.03, Irms: 0.23, Papp: 0.01, Preal: 2795.30, PF: 365186.438
CPU temp: 30C, Vdda: 3302mV
0: Vrms: 0.47, Irms: 0.02, Papp: 0.01, Preal: 63.16, PF: 7055.821
1: Vrms: 0.47, Irms: 0.23, Papp: 0.11, Preal: 1175.71, PF: 10830.193
2: Vrms: 0.47, Irms: 0.23, Papp: 0.11, Preal: 1175.71, PF: 10830.193
3: Vrms: 0.47, Irms: 0.23, Papp: 0.11, Preal: 1266.90, PF: 11672.945
CPU temp: 30C, Vdda: 3304mV
0: Vrms: 2.98, Irms: 0.02, Papp: 0.06, Preal: 227.31, PF: 3590.232
1: Vrms: 2.98, Irms: 0.23, Papp: 0.68, Preal: 1222.68, PF: 1791.838
2: Vrms: 2.98, Irms: 0.23, Papp: 0.68, Preal: 1222.77, PF: 1792.022
3: Vrms: 2.98, Irms: 0.23, Papp: 0.68, Preal: 1378.88, PF: 2020.809
CPU temp: 30C, Vdda: 3304mV
3: Vrms: 2.97, Irms: 0.23, Papp: 0.68, Preal: 2416.33, PF: 3542.793
0: Vrms: 2.97, Irms: 0.02, Papp: 0.06, Preal: 248.25, PF: 4068.411
1: Vrms: 2.97, Irms: 0.23, Papp: 0.68, Preal: 2259.68, PF: 3313.200
2: Vrms: 2.97, Irms: 0.23, Papp: 0.68, Preal: 2259.62, PF: 3313.120

Empty CT plugged into ct1, first 2 blocks with no AC, second 2 blocks with AC connected.

Irms looks much better, presumably the connected empty CT is closer to zero than the absent CT’s because the unused inputs are only grounded via the 33R burdens.

What is the 2.97 Vrms value though?

Robert.Wall · 27 March 2018 12:51

I’d almost expect it to be the other way round, due to pick-up by the c.t itself and on the input cables. The c.t. at around 100 Ω plus some inductance will only pull the parallel impedance down to about 25 Ω, so it should improve the low frequency noise a little. But the series inductance of the secondary will reduce the effect at higher frequencies.

dBC · 27 March 2018 12:53

I think you might have missed some of the patch? If you scroll down in the patch window you’ll see a change down below as well. If I’m reading your diffs correctly, I think you’re now dividing by count twice?