A post was split to a new topic: DS18B20 reliability considerations
I’ve been helping @TrystanLea with the RFM69 side of things. I’ve made some good progress, with special thanks to @dBC for help over pm.
I’ve written a guide to the implementation which can be found here:
. STM32/RFM69.md at master · openenergymonitor/STM32 · GitHub
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.
1 Like
I’ve brought together the emon3CT and RFM69 code here:
. https://github.com/openenergymonitor/STM32/tree/master/Emon3CT_RFM69
For the TxShield, it might be worthwhile developing a bit-banging SPI approach to accessing the RFM69 module.
If testing the emon3CT sketch on a TxShield, only CT2 and CT4 are available.
1 Like
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:
When I get a chance I’ll write up a spiel on why - complete with scope traces, and I’ll freshen the tar file with that and a few other features.
I was reminded of this project by @Robert.Wall WiFi only EmonTX - #5 by Robert.Wall.
It seems this design is wedded to an RPi setup? What is the rationale for that design decision?
I’d like to see the option for a WiFi setup. Maybe a daughter board that could plug into the RPi header for a Wemos D1?
Hello all,
First post here.
Has an external voltage reference been considered for the VDDA supply on the STM32, e.g. LT6656?
https://www.analog.com/media/en/technical-documentation/data-sheets/6656fc.pdf
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.
It looks like great progress has been made!
Best regards,
Paul
1 Like
Welcome Paul,
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.
MCP1501T-33E.pdf (1.1 MB)
The decision for this one is made mostly on cost… I’ll check the one you posted now…
Seems no longer supplied by farnell! Seems the price is a fair bit higher too.
I’ve put a solder junction on the prototype to bring either 3.3V source into VDDA, so we can keep exploring the options.
2 Likes
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.
1 Like
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.
MQTT is very fast by comparison.
@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.
Good to think of this now.
1 Like
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.
I don’t know. All I know is that it’s around 60 times more efficient than a http request for small data packets.
Not sure about buffering either as I don’t know the innards of emonhub. Sounds like it’s worth raising a github issue over.
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.
1 Like
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.
I wouldn’t guess. There are good web pages (e.g. NPL: Time and frequency products and services - NPL).
Fantastic, the NPL’s Internet Time Service (ITS) User Guide seems to have the details on what’s needed for use with the NTP libraries used.
I appreciate what you’re saying about power consumption.
Their 60kHz radio clock, I hadn’t twigged you’d meant this radio-controlled clock, we’d need some extra hardware to pick that up. Could be a ‘module’ add-on feature.
Another low-power option would be to use the rfm69 module to receive a packet of time information from the ‘hub’.
edit: the NTP libraries seem to use server default pool.ntp.org.
Looking up
pool.ntp.org(or0.pool.ntp.org,1.pool.ntp.org, etc) will usually return IP addresses for servers in or close to your country. For most users this will give the best results.
. pool.ntp.org: How do I setup NTP to use the pool?
@Robert.Wall are you contented with the use of internet time from the ‘hub’ and a radio packet sent to the node, with some kind of correction algorithm implementation outlined above?
Seperate subject. I did some testing yesterday on the stm32 proto board we received earlier this year. Specifically, testing the accuracy of VT and CT inputs, and checking the channels for noise. A problem was apparent straight away, with unusually high CT channel readings, and high VT channel readings while the VT was disconnected.
Using the scope I found the problem at the stm32 analog reference input (VREF+), upstream the MCP1501 0.1% reference voltage had too much capacitance on it’s output, causing an oscillation at 16kHz 400mV peak to peak.
I removed the capacitance and everything became stable. Looking at the MCP1501 datasheet the reasons are clear.
Next, I spit out the ADC readings of the BIAS and it was doing something interesting. It was bang on set on a single ADC value of 1984 (a bit low for some reason), EXCEPT, for occasional dips for a single value at a time (every few milliseconds) down to about 1970. The next ADC sample it’d be back up to 1984. This is something to revisit and check in a different context, and with a different voltage reference IC.
AN2834 for the stm32 shows capacitors connected to VREF+, but in the context of the MCP1501 that amount of capacitance wasn’t appropriate. Looking again at AN2834 I noticed the suggestion of using a diode as a reference voltage, something like a LM236.
Any other recommendations welcome. I’ve ordered a LM236 to test. I’m interested in finding a fairly bomb proof 0.1% reference. Just to make clear the reasons why, we need to know the volts per adc division.
. https://github.com/openenergymonitor/STM32/blob/master/Emon3CT_CB/Src/main.c#L177
Noticing another interesting one here: https://uk.rs-online.com/web/p/voltage-references/1000664/
It’ll come down to cost too. How much are we willing to spend on eliminating about 0.9% error? Users here have posted a few times about accuracy, so it’d be nice to nail something good out-of-the-box.
1 Like
I was only throwing the suggestion into the ring. As lead designer, any decision is yours - presumably in consultation with Glyn & Trystan.
Yes, each step of the way.
Speaking as a pesky foreigner… one issue with the radio clock is that it would appear to be a bit UK-centric.
2 Likes
With a receiver operating at 60 kHz, it’d be able to hear WWVB in the US.
(for users in the North American “market”)
Decoding the signal could be another story.