In the interest of a public discussion for those interested, we’ve been discussing STM32 hardware configurations in a PM.
Early on in the thread Robert Wall posted
[quote=“Robert.Wall, post:2, topic:6846, full:false”"]
On the general subject, I’ve been having thoughts about implementation. I realise any connector represents a potential source of problems, however I was wondering about a modular approach, so (thinking on my feet here) single and triple voltage input modules, 4-input (like emonTx), 12-input (like 3 x emonTx) current modules, a temperature & humidity module, a pulses input (at least 5 - 3 elec, water, gas), EV, and a “general purpose” that looks more like a breadboard than anything else - something that could facilitate an energy diverter or d.c. battery monitor by providing an access port to analogue and digital I/O
[/quote]
Paul Burnell then replied (excerpt from the post):
[quote=“pb66, post:3, topic:6846, full:false”"]
I’ve been thinking about the modular approach and my thoughts on the separate comms board hasn’t changed, I think it would be good the be able to swap out different wifi/ethernet/serial/rs485/LoRaWAN/GSM boards. Although I have also been thinking about the front end and my original idea was to have a master board that had the stm32 and 6 adc channels broken out to ac and ct inputs and have an additional slave input board, this I thought could have the same single layout to suit either the 2nd or 3rd bank of ADC’s and just have a 3x6 pin header and a 2x6way shorting block that can sit in one of 2 positions to be the “2nd” or “3rd” board,
I then started thinking about whether there should be other types of board for example 17 CT’s and one AC (single phase) might want different slave boards to a 3ph monitor, but the 1st six adc’s are effectively fixed so options are reduced, unless we just have the stm32 on a board with no front end and a range of front end boards, this would also cater for the emonPi and emonTx differences as the “MCU board” would be the same, the emonPi amd emonTx “front end boards” would differ to suit the cases and the necessary IO connections (eg the Pi gpio).
[/quote]
I mentioned my wish to have a MBUS reader module to integrate heatpump monitor development efforts and the option to directly mount a RaspberryPi3.
Later on Paul asked the question in relation to discussion regarding 64 vs 144 pin stm32f303 package:
[quote=“pb66, post:191, topic:6846, full:false”"]
How many CT channels are too many?
[/quote]
I made a list of the main options I could think about:
- Single phase, whole house: 1V + 1CT
- Single phase, solar: 1V + 2CT
- Single phase, solar, EV, heat pump, import/export: 1V + 4CT
- Single phase, total number of used circuits in my distribution board: 1V + 7CT’s
- Three phase, whole house: 3V + 3CT
- Three phase, solar: 3 + 6CT
- Three phase, solar, EV, heat pump, import/export: 3V + 12CT
Paul then replied with an extended discussion, targeting 15-18CT’s:
[quote=“pb66, post:211, topic:6846, full:false”"]
I think “diverter” should be added to all the options that have PV as most PV users want to use their own PV rather than export it and will probably use a form of PVdiverter, especially if we build the logic into this device. It is essential to monitor “diverted” energy to retain a way of managing the normal household use which can get lost if the “use” reported includes a lot of “free energy” to heat water etc. This is in addition to any switched loads like EV.
so
| Phase | Grid | Solar | Divert | HP | EV | CT’s | |
|---|---|---|---|---|---|---|---|
| Just whole house | Single | 1 | 1 | ||||
| " | Split | 2 | 2 | ||||
| " | Three | 3 | 3 | ||||
| Basic solar (inc diverter) | Single | 1 | 1 | 1 | 3 | ||
| " | Split | 2 | 2 | 2 | 6 | ||
| " | Three | 3 | 3 | 3 | 9 | ||
| Solar and Heatpump | Single | 1 | 1 | 1 | 1 | 4 | |
| " | Split | 2 | 2 | 2 | 2 | 8 | |
| " | Three | 3 | 3 | 3 | 3 | 12 | |
| Solar, Heatpump & EV | Single | 1 | 1 | 1 | 1 | 1 | 5 |
| " | Split | 2 | 2 | 2 | 2 | 2 | 10 |
| " | Three | 3 | 3 | 3 | 3 | 3 | 15 |
I also think that powerwall and other (diy?) battery solutions will become more common as batt tech get cheaper, some of these will be mains connected rather than DC. So we could add another 1,2 or 3 CT’s to all the above… I think I am basically reinforcing my thinking that 15 CT’s is the absolute min top spec, 18 would be much better
[/quote]
Paul and Robert reinforced the point that the solution needs to be modular.
We discussed a little on enclosures, the need to find an enclosure approach that could accommodate a potentially modular + stackable approach.
Then in trying to get a better picture in my head of how this could work, I sketched up the following ideas. From left to right you have a baseboard with the STM32 core (likely 144pin STM32F303ZE), the baseboard has a good number of CT’s (perhaps 6), ACAC input, temperature and pulsecounting. The baseboard could then be extended with shield-like boards that access further IO on the baseboards STM32 core. The second board from the left shows a shield with 12 CT’s and 2ACAC inputs. The same result could perhaps be achieved with two smaller 6 channel CT boards and two connector rows (right top & bottom):
More to follow…
