No problem. I’ll be interested to hear what you find, but it seems impossible for the UART to be plumbed to two sets of pins at once so I suspect PB3/PB4 won’t work, unless there’s a typo in AN2606.
The other thing I noticed in AN2606 is that the bootloader only polls two UARTs (UART1 and UART2), so if you ever do go the three UART approach I suggested above, be sure to use UART3 for something that you don’t plan booting over (OneWire or ST-LINK debug printfs).
[EDIT] - and the bootloader is burnt in at the factory and is un-erasable. So once you get the pin issue sorted, I think you should be able to use either method (ST-LINK Vs Serial) to program your virgin chips as they arrive from Farnell etc.
I’m happy to say everything worked with the first prototype PCB!
With special thanks to @danbates designer of emonDC for helping to assemble the board with his SMT soldering skills and @dBC for finding the issues fixed above that meant all of this worked.
So far we have tested:
Power supply
ST-LINK firmware upload
Serial firmware upload
RaspberryPi automated serial upload procedure
LED indicator
8MHZ HSE oscillator
CT and ACAC power measurement
DS18B20 temperature sensing input
Pulse counting input
Datalogging to emoncms via raspberrypi serial and emonhub
All working well.
Here are a couple of pictures of the board, http://ragworm.eu/ where very kind to update the order with the fixed design and then fit it on one of their black soldermask board runs which looks particularly nice:
The next step is to test the filter design in more detail and run the unit in parallel with an EmonTx. @danbates is looking into firmware libraries for RFM69 support and we will be revisiting the requirements of a fully featured board as discussed here STM32 Hardware Development.
Overall very happy with how this first prototype turned out
This is compatible with LowPowerLab radio packets. I’ve looked at JeeLib packets and think I have a good understanding of the main differences, yet can’t quite get it working. So there’s something I’m missing there. For the ‘jeecompat’ project, I have a github branch here.
Just a heads up to anyone who might have cloned my 1-wire uart off-load example above (@TrystanLea@danbates): you get better results if you enable “Single Sample” on the uart(s) involved:
It has five times lower ppm/deg C drift (20ppm vs 100ppm), with 0.1% accuracy, so should improve accuracy, at least related to the reference error. I guess if calibration is performed the 3% inherent accuracy of the STM32 internal reference will be overcome, but not everyone has access to an accurate multi-meter. Having an accurate external reference on the VDDA means the internal reference would not be needed to be used in any calculation of the supply voltage, and hence full scale value.
I’ve bought an STM32F303 Nucleo board and intend to get an energy monitor working using it. My background is RF engineering, I am not a programmer, although I do dabble, so I wont be able to help much with the software. I’d be happy to help with the hardware design if I can be of help with the project.
I’ve been sifting through the stm32 manuals and followed most of the design recommendations. This has ended up with my choosing a voltage reference, it’s 0.1% and 50ppm.
On the case. Our large board has the footprint for an ESP12. When we go farther with the smaller basic board, we can look at getting a footprint or module header there also.
I think, overall, the rational for using rPi is clear, but we don’t want to ‘wed’, as you put it, the design to it either.
Contemplating the recurring question of NULL values in the emonCMS graphs, many of which appear to come down to an absence of synchronism between the data source (the emonTx usually) and emonCMS, I wondered how practical/desirable it would be to include a radio code clock in the STM32 sensor node - not necessarily for the purpose of providing an absolute time, but to provide a timebase for reporting that would be locked to World time - hence Internet time - that would not suffer from the drift that causes the database to have either null values or to receive values that get overwritten by the next one to arrive.
Or could it be an issue with the emonhub - MQTT - emoncms interface? Even on the EmonPi there are 2 additional steps between the Serial output from an EmonTX and the Input of EmonCMS.
You could eliminate that with a direct link, via WiFi from the EmonTX to Emoncms via an API call and possibly timestamp that data at source. I’m still not clear why the default from emonhub was changed from the API to MQTT.
@Robert.Wall thanks for reminding of this. A related topic came up while discussing the new stm32config module. Whether to poll the stm32 for the data from a directly connected rPi or wait for the interval data (which could drift in time). Same issue could crop up with the Nulls in emonCMS. Apart from hacking emonCMS there are better solutions…
My feeling is firstly, to specify an accurate 32kHz crystal for stm32’s rtc.
And then to have a method which involves correction of the node/stm32. The hub/rPi would have to detect a delay or advance of the interval, then send a command. The node/stm32 would have to interpret this command and correct it’s time.
Cheaper than building an atomic clock ourselves.
I guess time-correction is how everything along-the-chain works, going as far back into the internet as I can imagine, there’s prpbably a computer somewhere reading an atomic clock, and ‘internet-time’ is periodically being adjusted to it… I’m guessing.
Does that speed assume the MQTT broker is on the same machine? If so that is an assumption (I run a separate broker).
The other issue is that MQTT does not buffer like the API call does. If for some reason emonhub does not make the connection, with MQTT the data is lost, with the API interfacer it buffers until the data can be sent.
Comes back to tying this to an RPi and emonhub I feel.
Have you any references for that? For our implementation, does it make any material difference? Sending a high volume I imaging it would but for this?
It’s not an issue, it is a fact of implementation - that is what the MQTT protocol does. I suppose we could send the data as a JSON with a datestamp and buffer that way but that is a new implementation at both ends. Currently each data value is sent to MQTT as a separate topic/payload pair (without a datestamp).
If emonhub doesn’t (cannot) load up the broker at the instant it attempts the publish, the data is lost. Equally, if for some reason emoncms cannot pick up the data via the subscription on that cycle, the data is lost.
As the API does an ack ‘ok’, emonhub knows it has been received so discards the frame, if emonhub does not get that, it buffers and tries again but with the next frame as well.
I’d use a free one - Internet, GPS or radio code. Internet implies WiFi implies a fair bit of power, GPS implies a view of a satellite once in a while and a fair bit of power, a radio code clock is likely to use the least power and being low frequency, penetrates buildings quite well. In any case, it only needs to be used infrequently to ‘nudge’ the internal time keeping and maintain it.
