Hopefully the connectors will be interchangeable like the VT/CT front ends, I really dislike the rj45 connections, on my own hardware I tend to use tool-less terminal blocks (I say tool-less but I use a screwdriver to push the levers, perhaps screwless is a better term) they are easy to use, they apply a constant sprung pressure on the bare wires rather than over or under tightening a screw, plus the lever can be on the same face as the entry which makes them ideal for applications like the emonTx.
But I know the demands and desires of everyone cannot be accommodated in one design so as much as I would ideally like to avoid multiple connections along one track, I think interchangeable front (and rear?) ends is the way to go if we can find a suitable board to board connector. It would make the main board more desirable if there are multiple front ends for it and more flexible and cost effective for (commercial) users to be able to manufacture their own bespoke front ends rather than build a complete monitor or suffer the comprimises of a product made for the masses. It’s a model that has worked for Arduino shields and Raspberry Pi hats, should work for us too. So the number and type of one wire buses/connections could be left open.
I agree regardless of how many buses/conns there are we should opt for the most efficient lib so your info is of great value, I cannot comment on the tech aspects of what you found as I do not know the libs or the code well enough to recognize the benefits, but I like what you’re saying
@TrystanLea I realize that you’ve had your hands full recently managing the progression to emoncms.org billing & exporting of cloud data tools, but wondered where STM32 development fits into your future plans.
I’m conscious that STM32 development has slowed somewhat, and with no clear pathway or direction, there’s a fear that contributors may jump ship, and put their time into something else where there is some momentum.
I realize that it would be difficult, but are you able to lay down a development schedule, or even let us know when this work will have your full attention.
Hello @Paul, I’m keen to get back to it once I have the sync tools complete and we’ve setup the ability to access OEM shop emoncms credit in emoncms.org.
I have been following this thread closely. I understand most of it in principle but not the programming in detail.
I Have an F303 and an EmonTxShield with 4 ct’s and a shop 9V AC Voltage source.
I have the latest version software from @dBC via the updates in the repo provided by @pb66.
Every thing is working and after a setting up voltage calibration I am getting sensible results.
How easy would it be to add an ESP serial connection to the F303 so that the results could be sent to a local emoncms using an ESP8266 WiFi Adapter for EmonTx to test real world monitoring?
Looking at the EmonTx code it does not look as if it would be a major job to match the formatting needed by the ESP.
I have switched 3 of my EmonTx over to using the ESP. I am getting much more reliable results than I was with RFM.
Version 13 enables an opamp and includes its output in the ADC scan, so you can read its value. I also finally updated my STM32CubeMX and HAL which caused a few additional diffs.
Hello @Bramco yes, I have finally had some time to spend on this again and have made good progress over the last couple of weeks. I have been writing up a mixture of a guide on getting started with the STM32 and development notes up here as I learn:
I’ve had some help from @dBC and @Robert.Wall on PM understanding the ADC’s and a better method for DC offset removal, which is much appreciated! I got caught out for a bit using the digital high pass filter that we use in EmonLib but at the higher STM32 frequency resulting in lower than expected Vrms readings, @Robert.Wall’s DC offset removal approach sorted that nicely in a way that is independent of sampling frequency.
This approach is included in firmware examples Emon1CT & Emon3CT.
I would like to go through each of the hardware features that we would like to add to the main design to make sure I understand what can or cannot all run at the same time - preserving a core goal of full continuous sampling across a large number of CT channels, thanks @dBC for your DS18B20 example above. Plus there are plenty of basics like serial comms on the ST-link, and USB DFU that I need to understand and test.
I’ve also sketched together a basic eagle design combining a number of features I would like to see, more so that I can see how things might fit together and potential board layouts, routing requirements rather than setting the design in stone at this stage: https://github.com/openenergymonitor/STM32/tree/master/Hardware/3
Hello @ian, I have corrected the platform.ini files to include the c99 flag, thanks for spotting! I was using the Makefile.
I am however having trouble getting the examples to print numbers using platformio, works fine using make… I note you reported the same error here but cant see the solution!?
I have switched to make for further testing and that does work in so far as I can compile and upload but at the moment I cannot get the terminal to open.
Edit
All working fine. Upload and Terminal issue was USB plug displaced!
For those interested here is a rough outline of my STM32 development plan
STM32
Goals of the project:
Higher resolution 12 bit ADCs
Higher sampling rate
Continuous sampling on all Voltage and Current channels
Shield/extension design
RaspberryPi core, local datastorage, visualisation
Learning resources on the STM32 platform to enable modification & customisation.
Steps:
Work through STM32 power supply, clock, programming sub circuits, check understanding, component sourcing. Put together base board design (equivalent of a STM blue pill, or Ken’s ARMIGO) potentially with a couple of CT and ACAC sensor inputs for initial testing.
Filter design for CT and ACAC voltage input circuits.
Construct 3D model of enclosure options, visualise different stacking design options, connectors, raspberrypi location. Ease of manufacture & assembly.
Verify MBUS reader running on STM32 alongside energy monitoring code.
Understand @dBC one wire code and timing implications.
Review base-board feature requirements:
STM32 core and pin count
Number of CT sensor inputs
CT sensor mapping to ADC channels
sequential vs parallel sampling capabilities.
Number of ACAC Voltage inputs
DS18B20, pulse counting connector types and numbers.
MBUS
RaspberryPi connector and mounting
ESP8266 on board
RFM69 support
RTC
Display & push button
Evaluate cost implications of including on board vs requiring shield additions for items such as MBUS, RFM69 & ESP8266.
Create PCB layout for first hardware design. Get prototypes, testing, fix issues, EMC prelim, design iteration and revaluation of next steps from this point.
I will keep updating as this progresses. This is work I’m doing alongside emoncms and emoncms.org development and so development will be a little discontinuous at times.
So far we have used the HSI (high speed internal clock) as the clock source. I’ve been reading up on the LSE clock (32.768kHz) for accurate RTC timing and note the presence of this clock on the Nucleo development board. I also note that there is an option to have an external high speed clock (8Mhz) which could be used for both the RTC and the system clock. Do you have a view @dBC as to the best way to go?
Another small step, I’ve tested and written up an example of how to upload firmware to the STM32 from a raspberrypi including automatic setting of BOOT0 and automatic reset so that the upload could be called as part of an OTA update process. Two GPIO outputs are required rather than the one used for autoreset with the AVR but its relatively straightforward.
Not really. The clocking is very flexible so go for whatever fits in best with the rest of the design. For me that’s usually been a HSE crystal because they’re readily available. Do you plan using the RTC for anything? I almost used it once on a battery operated project that needed to wake up to count/time pulses but otherwise, if the stm32 is never going to sleep then I’ve found systick to be sufficient for maintaining msecs-since-booted time and never needed actual date and time. If yours will be always-running and closely coupled to an RPi, it might be easier to let the RPi worry about date and time.
Thanks @dBC, is there a reason that you went for a HSE crystal 8Mhz? vs the internal HSI? I imagine the timing is better, but is it significant? For energy monitoring we need to accurately calculate increments in watt hours and so the accuracy of timing is a factor of course.
Not sure about using the RTC, Ideally access to the RTC would be useful for an attached raspberrypi, especially if logging offline without access to internet time-servers… Perhaps its worth catering for both options on any board design, footprint for both a HSE and a LSE crystal…