If you could point out where that would need editing (sorry I’m being lazy) I might be able to at least get that reflashed before my next brew and give you the numbers back.
The call to start_ADCs() is in main.c just after where it prints out the banner:
snprintf(log_buffer, sizeof(log_buffer),
"\nemonTxshield Demo 1.2\n");
debug_printf(log_buffer);
snprintf(log_buffer, sizeof(log_buffer),
"Patch PA0 through to PB14 for V!!!\n");
debug_printf(log_buffer);
calibrate_ADCs();
start_ADCs(0); // start ADC with x usec lagHow easy it is to get sucked into doing multiple tests to confirm what you get first time.
starting point at 0 adjustment was
0: Vrms: 1138.36, Irms: 74.97, Papp: 85346.75, Preal: 84903.35, PF: 0.995
So I edited to 316 first and that very little change, but at 0.996 I wondered if we could do better so first I tried -316 to be sure it was the right sign/direction. Since the neg value had such a big swing I tried larger edits first and then narrowed it because they were all way out, but it didn’t get any better.
@316
0: Vrms: 1142.20, Irms: 75.28, Papp: 85984.51, Preal: 85605.85, PF: 0.996
@316 again
0: Vrms: 1145.18, Irms: 75.47, Papp: 86422.79, Preal: 86048.12, PF: 0.996
@-316
0: Vrms: 1150.39, Irms: 75.90, Papp: 87309.00, Preal: 85899.79, PF: 0.984
@200
0: Vrms: 1146.39, Irms: 75.77, Papp: 86857.98, Preal: 86314.27, PF: 0.994
@500
0: Vrms: 1141.72, Irms: 75.35, Papp: 86027.18, Preal: 85206.70, PF: 0.990
@400
0: Vrms: 1140.63, Irms: 75.40, Papp: 86000.88, Preal: 85316.49, PF: 0.992
@300
0: Vrms: 1135.41, Irms: 75.09, Papp: 85253.09, Preal: 84608.67, PF: 0.992
@250
0: Vrms: 1139.24, Irms: 75.25, Papp: 85723.21, Preal: 85247.46, PF: 0.994
@350
0: Vrms: 1139.77, Irms: 75.28, Papp: 85798.78, Preal: 85212.43, PF: 0.993
I used the one result that appeared most frequently in the run of serial output for each test, but there were only 4-6 blocks ever printed so not a big data set to draw too many conclusions from. Also as this is done at 3.6 Amps, it is well inside the erroneous first 5% of the 100A CT’s range.
when they are put in numerical order of adjustment the results make even less sense unless the “300” line is discarded.
| setting | PF |
|---|---|
| -316 | 0.984 |
| 200 | 0.995 |
| 250 | 0.994 |
| 300 | 0.992 |
| 316 | 0.996 |
| 316 | 0.996 |
| 350 | 0.993 |
| 400 | 0.992 |
| 500 | 0.990 |
I did use make clean between compiles and reset the device before each test. I have not checked voltage or frequency at any point so changes in either might have altered the phase error at the VT I guess. Having just said that, looking back at the Vrms (adc counts) recorded for that “300 setting” is 1135.41 and it’s the lowest voltage reading of the batch, but not by a lot.
Perhaps the voltage swing (and frequency?) have an even bigger impact than suspected? or more likely it’s out of the CT’s more accurate range.
Any way, back to work I go :-
2 Likes
Hi
I am following this thread with great interest and I think I understand roughly how it all works. Am I correct that if I made the correct shield with 6 CT connections and 3 AC monitor connections and suitable firmware I could monitor a UK three phase installation that also has three phase PV?
Could an EmonESP be serially connected to post the results to an emoncms Rpi ?
Regards
Ian
The example isn’t quite at that stage yet.
The values that are printed are unitless, they are currently just adc steps not volts, amps or watts etc. The output is not in esp format either. It is still very basic, but yes you could take what @dBC has started and run with it, complete it for you own use, but no it’s far from a finished sketch, it’s just early tinkering.
Hi Paul
I just wanted to confirm my understanding of the number of suitable analogue ports that are available. I am thinking of getting a prototype PCB made with as many ADC connections as possible connected to CT sockets and AC monitoring sockets grouped in the most sensible way which for 3 phase I assume to be 2 CTs to 1 AC in the case of both 3 phase grid and 3 phase PV. I am still trying to understand the tutorial posted by @dBC.
That’s something we have been debating and trying to work out ourselves.
There are 22 ADC channels on the 64pin F303 fitted to the Nucleo board, we are aiming for perhaps 15 or 18 CT’s and 3 AC (VT’s) but getting them arranged so that the sampling is done in a synchronized and simultaneous way to avoid adding any further phase error is the trickier part.
Trying to get all 18 + 3 adc channels where we want may not be possible on the 64pin F303 as it is using every adc channel (one will most likely get used for the midrail opamp), the 144 pin version has 40 adc channels, so it may get considered so that it’s easier to implement and there are spares for bespoke applications and future development, not an easy decision because we don’t want to be wasteful, it’s not much more money and the extra channels and IO might give the processor something to keep it busy since sampling 21/22 channels, much faster than we have done before, looks like it might be a breeze for it.
I too would like a PCB with plenty of CT sockets so that I could test the various potential arrangements, so if you do get some made, please keep me in mind 
I assume you mean the NUCLEO-F303ZE. Its only £14.66 from Farnell which is only about £6.60 more than I paid for the 64 pin. In the scheme of things that’s insignificant. Will the code be the same for both boards?
Any one else have any thoughts on which board to choose? I doubt it will make much difference to the prototype PCB cost which ever one is chosen. But equally I guess there is no point in creating a divided effort.
Yes the Nucleo144 board is ~£6 dearer than the Nucleo-64, but it has more physical IO pins, a bigger PCB, a micro USB port and an Ethernet port (that I know about), the actual F303 chip is a negligible difference, which if/when this goes to production is what counts. There is currently no intention of using the Nucleo boards beyond development, they are just a dev tool.
I can’t answer the question about whether the code will run on both as I’m not sure what the code will consist of yet, but if it doesn’t, I do not expect it to take too much to change it. Generally speaking, as far as I can tell the code should/could be portable and could be compiled with the different board settings from the cubeMX, but if we’re addressing adc’s that don’t exist on the smaller board, that will still need changing I guess.
Admittedly a little late to the party, but I’m using Windows 7.
My Nucleo board arrived yesterday, so now I’m waiting for the shield.
In the meantime I’ll rig up a breadboard and a CT.
Following your lead, I installed gcc-arm-none-eabi-7-2017-q4-major.
Then, to get make, I installed Msys2 (a MinG-type environment)
The BINPATH fix worked like a champ.
First compile/flash went sans warnings/errors.
1 Like
Is that Msys2 Bill?
Paul
It is… Looks like I fat fingered the kybrd… 
Tnx for catchin’ that!
(post corrected)
Just finished compiling dBC’s txshield_demo_4 w/o any problems.
Gettin’ there. A little at a time…
I didn’t actually pursue the windows path any further after finding make already wasn’t there, I now have the STM32 board plugged in to a Pi that I can access remotely, it means I can now work from the laptop in various places without dragging the stm32/shield/CT’s and AC adapter around.
That’s what I’ll do eventually. ATM, all my Pis are being used in various projects, so I need to get another.
In the meantime, I’ve set up 64-bit Debian Stretch on an Intel box.
Did you run into anything wonky when you installed CubeMX on your Pi?
Got it figured out. 64-bit Stretch needed 32-bit libraries. (sudo apt-get install ia32-libs)
Once those were installed, installation went OK.
No I didn’t install cubeMX to the Pi, it’s a utility that doesn’t actually connect to an STM32, so I still use that on my windows PC plus I don’t have a remote desktop set up on that Pi. With github you can work on the files from multiple machines.
Good to know if I do decide to go totally Pi 
Strange, I’m using Debian 64bit, and didn’t need to install 32bit libraries.
Lifted from the STM32Cube user guide
"Linux®: 32-bit (x86) and 64-bit (x64) (tested on RedHat, Ubuntu and Fedora)
Since STM32CubeMX is a 32-bit application, some versions of Linux 64-bit
distributions require to install 32-bit compliant packages such as ia32-libs."
It also says
“Recommended minimum RAM: 2 Gbytes”
My i7 PC has 16gb and cubeMX isn’t exactly the fastest SW to open on that so I might not bother trying it on a Pi.
Very ambiguous!
Sounds very much like a smartly worded “if it don’t work try this…”
…my thoughts exactly 