# STM32 Development **URL:** \ **Category:** Hardware\ **Tags:** stm32, development\ **Created:** [12 March 2018 17:30 UTC](https://community.openenergymonitor.org/t/stm32-development/6815 "2018-03-12T17:30:28Z")\ **Posts on this page:** 20\ **Page:** 18
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [18 January 2020 10:06 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/344 "2020-01-18T10:06:14Z")
Actually Robert, Bill had provided exactly the information on Cable I was interested in. I’ve had a look at those manufacturers also, interesting stuff. I’ll pick up other points later. Many thanks. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [18 January 2020 11:43 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/345 "2020-01-18T11:43:12Z")
It’s good to have the wire AWG information regardless 🙂 [These plug breakouts](https://thepihut.com/products/adafruit-3-5mm-1-8-stereo-audio-plug-terminal-block) accept 26-16AWG. ![image](https://community.openenergymonitor.org/uploads/default/original/2X/b/b26e6cd1b65874afc5ec9644b8c0d4b055508223.jpeg) ![image](https://community.openenergymonitor.org/uploads/default/original/2X/9/9b3ef4bc7ed65351690a0c43481c0a827b521f63.jpeg) Who has an opinion on these? @Bill.Thomson Edit: I’ve ordered one to get a feel of the quality. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [18 January 2020 11:47 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/346 "2020-01-18T11:47:31Z")
@pb66 Can you use eagleCAD? The files are available if you’d actually like to have a look and comment on specific elements. Pretty much all of what you’ve mentioned has already been thought about or discussed in the lab. I don’t have a table of pinouts, connections or capabilities I can post here now because we’re developing, testing… however this will be a natural part of the documentation. . [GitHub - danbates2/STM32: STM32 Energy Monitoring](https://github.com/danbates2/STM32/) ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [18 January 2020 13:36 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/347 "2020-01-18T13:36:53Z")
Elsewhere… > [@Need Gerber files for RFM69PI (v3)](https://community.openenergymonitor.org/t/need-gerber-files-for-rfm69pi-v3/13039/4): > > I could do it for you, but I’d have to charge thousand and thousands of pounds 😁 You’ve already had “thousand and thousands of pounds” worth of help from @dBC on this project, so how about putting some of it back into the system? Isn’t that what Open Source is all about? 🤭 ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [18 January 2020 13:49 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/348 "2020-01-18T13:49:02Z")
Turn it up everyone. [![]( " - YouTube") ](https://www.youtube.com/watch?v=9wt4ElSEaNw) ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [18 January 2020 15:00 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/349 "2020-01-18T15:00:17Z")
> [@pb66](#): > > Is there any issue with the Silicon Labs Si7021 It seems they do not really come in a robust form (which I was looking for), just bare board. ---
**Author:** ![dBC](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/5f9b8f/32.png) [@dBC](https://community.openenergymonitor.org/u/dBC)\ **Post date:** [18 January 2020 22:55 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/350 "2020-01-18T22:55:31Z")
Nah, I’m way cheaper than that ;-). ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [18 January 2020 23:07 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/351 "2020-01-18T23:07:22Z")
🤫 Don’t tell everybody that. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [16 July 2020 22:42 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/352 "2020-07-16T22:42:28Z")
Hello everyone. Here’s the latest iteration of the stm32 board. Discussion welcome. ![stm32 v0.9 top](https://community.openenergymonitor.org/uploads/default/original/2X/7/748a841077f2b1ae8ae1a93e3b585cfd5f9989f4.png) ![stm32 v0.9 bottom](https://community.openenergymonitor.org/uploads/default/original/2X/7/750c0e2bbed6d3d0a3e9cd1abae74fe10d54238a.png) Noticing not all the plated through-hole have come out in the image exports there. ![stm32 v0.9a schema](https://community.openenergymonitor.org/uploads/default/original/2X/c/cc949fd2574228d232a72fa301eb035da32e2850.jpeg) Full Gerbers and eagleCAD - [stm32 v0.9a.zip](https://community.openenergymonitor.org/uploads/short-url/lzvVhlkPsgxQIAP1KoD7qWA5Wov.zip) (1.6 MB) Changelog for this version below. * * * v0.9 main changes - ferrites and caps on USB input to suppress noise from the power supply. - added extra 3.3V regulator for analog supplies and revised the capacitor selection of the other. - ferrites on each regulator supply input - inner-layer 3V3 copper has separated pours for DIGITAL and ANALOG supplies - ground inner pours separated into ANALOG ground, DIGITAL ground, and RADIO ground. - ferrites for separating each GND’s to final GND (for testing). - reset line has a blocking capacitor (I think) of the correct value now, calculated from datasheet information. - The MCU’s integrated op-amp use for the BIAS now has it’s inverting input broken out for filter testing - UART at south-west of board added accessible from outside the enclosure, connected to the shared STM32 and rPi UART… (UART1) I might revise this to UART 2 if there’s a clash trying to upload firmware while rPi connected. - CT burdens changed to 2x parallel 0805 0.1% resistors for cost reasons, through-hole resistor option remains. - VT inputs for SINGLE phase and THREE phase now have separated input chains all the way to the ADC channel inputs, previous versions tried to combine the AC-AC adaptor and L1 of the 3-phase input – Single phase retains the conventional barrel-jack and voltage divider for the 9V AC-AC adaptor, while the Terminal Block for three phase has a dedicated path to the STM32 ADC channels. Three-phase inputs at this terminal block would be 3.3V peak-to-peak max, sans DC offset. - A lot more protection diodes, everywhere - Expansion port is perhaps under-utilised - worth discussing. - RFM69CW tuning capacitor? - microSD card footprint included for use with standalone stm32 or esp32 - SPI1 and SPI4 selected for marginal power saving. SPI4 for the rfm69, SPI1 for SD card and comms between stm32, rPi, or ESP32. design to do: - breadboard a couple of ways to keep the backup coin-cell charged (with short protection). - change SMA antennae mount to a through-hole or SMT type, instead of edge type. cubeMX(v4.2.7) file also: [Sombrero\_VE\_Working5.ioc.zip](https://community.openenergymonitor.org/uploads/short-url/ujRlYq0lpyBHzb16wDYiPB7dwpX.zip) (5.8 KB) ![Screen Shot 2020-07-16 at 23.51.52](https://community.openenergymonitor.org/uploads/default/original/2X/1/161795215b6e04f5418b6f96c8badf6ecb0a426c.png) ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [17 July 2020 14:28 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/353 "2020-07-17T14:28:09Z")
Looking at the voltage and current inputs, would I be right to think that you are keeping the rather non-standard - as far as measuring instruments are concerned - 50 mA input for the current side and 12 V rms (from a nominal 9 V source) for single phase or 1.1 V rms for 3-phase for the voltage side? If so, you are preventing the use of the standard and very widely available (and accurate) 0.333 V rms output c.t’s and rather less widely available but accurate v.t’s. For a justification of “very widely available”, especially for c.t’s, a Google search for the two types will suffice. You might like to read this from a US c.t. manufacturer: [Current to Voltage vs Current to Current Transformers Magnelab](https://www.magnelab.com/current-to-voltage-vs-current-to-current-transformers/) This is not to say that the existing OEM practice should be abandoned, but that I think consideration should be given to make it easy for the user to use either, by a method that doesn’t require an excessive level of knowledge either in electrical engineering or in the product. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [17 July 2020 16:35 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/354 "2020-07-17T16:35:48Z")
We’ve come away from a discussion on this subject just now, so it’s confirming to read your comments, the article too. I’ll take this point about the voltage output CTs seriously and read further. We should get some for testing… The other point raised in discussion easier is that many voltage output CTs are 1V output, thus, we could change the range of the Analog Reference at the stm to suit, for better accuracy. I can’t find reference to a 333mV device for the 3phase voltage inputs… The inputs should be okay in theory… The BIAS, GND, and 3V3 are available along side the voltage inputs. Whether the physical form of their availability suits practical use or not I can’t say for sure… ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [17 July 2020 16:41 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/355 "2020-07-17T16:41:35Z")
> [@danbates](#): > > many voltage output CTs are 1V From what I’ve seen, the 0.333 Volt type are _much_ more common than the 1 Volt type. Magnelab, Byram Labs and the others that offer the 1 Volt units, offer them as an option that typically costs more, and incurs additional lead time to manufacture them. The 0.333 Volt devices are a standard stock item that Magnelab et al have available for immediate shipment. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [17 July 2020 16:48 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/356 "2020-07-17T16:48:35Z")
In terms of our design here, the difference I can see this making is in the chosen ADC range, i.e. the chosen reference voltage level. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [17 July 2020 16:55 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/357 "2020-07-17T16:55:37Z")
And don’t forget, Magnelab’s precision v.t. is also 0.333 V output. > **[SPT-0375 Potential Transformer Output Proportional Input Magnelab](https://www.magnelab.com/products/potential-transformer-output-proportional-input-spt-0375/)** > > The potential voltage current transformer provides a linear output voltage proportional to the input voltage. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [17 July 2020 17:07 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/358 "2020-07-17T17:07:54Z")
It seems as if one of the output leads of that transformer can be connected to the BIAS line ~~as a virtual earth~~ the other lead of course connected to one of the three voltage inputs. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [17 July 2020 18:30 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/359 "2020-07-17T18:30:36Z")
> [@danbates](#): > > the BIAS line as a virtual earth It’s not a _virtual_ earth, it is an earth to alternating currents – an a.c. earth is how it’s usually described. A virtual earth is one that is maintained by the feedback action of an amplifier. If you fail to reduce the ADC reference and the bias point appropriately, then you are using just one third of the available input range of the ADC. That won’t be significant with a voltage input that can be expected to remain within 10% of the nominal value, but using only a third of the range of a current input effectively means that the current below which the measurement accuracy becomes unacceptable is three times higher. ---
**Author:** ![dBC](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/5f9b8f/32.png) [@dBC](https://community.openenergymonitor.org/u/dBC)\ **Post date:** [17 July 2020 19:47 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/360 "2020-07-17T19:47:50Z")
I think the minimum allowable Vref on that processor is 2V so you’ll be stuck with half the available range. ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [17 July 2020 23:51 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/361 "2020-07-17T23:51:24Z")
> [@Robert.Wall](#): > > Magnelab’s precision v.t. is also 0.333 V output. Ya caught me nappin’ _That_ one I shouldn’t have forgotten. 😉 ![DSC03504](https://community.openenergymonitor.org/uploads/default/original/2X/c/c0375547d5ecb0a6adb3c02d54d0e4ced8a449e6.jpeg) ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [18 July 2020 00:41 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/362 "2020-07-18T00:41:55Z")
If you were thinking of VREF+, that is indeed 2 V – VDDA. Even then, that at (say) 2.048 V is better than a 3.3 V reference, given 1 V p-p outputs. ---
**Author:** ![danbates](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/ecc23a/32.png) [@danbates](https://community.openenergymonitor.org/u/danbates)\ **Post date:** [18 July 2020 00:51 UTC](https://community.openenergymonitor.org/t/stm32-development/6815/363 "2020-07-18T00:51:02Z")
> [@Robert.Wall](#): > > It’s not a _virtual_ earth, it is an earth to alternating currents – an a.c. earth is how it’s usually described. A virtual earth is one that is maintained by the feedback action of an amplifier. Understood. This is an earth to the AC. I can see where the virtual earth at an op-amp is a clear and useful definition, however I was using the term more loosely as a rail-splitter (I’ve just read the wikipedia). ~~Developing on this understanding, with respect to virtual earth purely at the non-inverting op-amp input, it would be correct to describe this application more fully as a ‘virtual earth to the AC transformer’, as it is maintained by bias which is sourced from an amplifier, thus it’s sourced from a split rail.~~ As a side note, I have set the op-amp in this latest version as, not a follower only, but as a standard op-amp, I have footprints enabling myself in the next round of testing to explore using feedback to reduce noise and oscillation noise if necessary. I can of course use the voltage divider input to the non-inverting input to scale down the bias to a level compatible with any CT/VT system chosen. It’ll be a matter of testing… @dBC I was going to mention this next, the datasheet recommends a minimum vref of 2V for this stm. I believe, for no particular reason, that it can go lower than this, but that is the recommendation. So happens the ref19x reference I’ve chosen has it’s lowest variant at 2.048V. The footprint is compatible with the LT1461 the lowest option of this is 2.5V. @Robert.Wall Seen your latest above just now. [Previous page](https://community.openenergymonitor.org/t/stm32-development/6815.md?page=17) [Next page](https://community.openenergymonitor.org/t/stm32-development/6815.md?page=19)