STM32 without crystal for sensor project? - Page 1
Forum section: electronics / general

author: panoss
author_rank: Frequent Contributor
timestamp: June 06, 2019, 07:15:44 pm
content: I want to build a temperature sensor.An STM32F030F4P6 with a LoRa module.The STM32 will wake every 30 minutes, send the data with LoRa and the sleep.Would it be wise to use the internal oscillator in such an application?I ask because I read that (except that it 's not as accurate as the crystal, which I don't care because I don't mind if it wakes up every 25 or 35 minutes instead of 30) it 's not very stable.That means it crashes?What do you think?

author: ejeffrey
author_rank: Super Contributor
timestamp: June 06, 2019, 07:39:39 pm
content: By "stable" it means that the frequency changes with time, usually due to temperature or voltage drifts not that it crashes.

author: panoss
author_rank: Frequent Contributor
timestamp: June 06, 2019, 08:01:18 pm
content: So you think there 's no problem in using the internal oscillator instead of a crystal in such a project?

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: June 06, 2019, 08:05:01 pm
content: Note that precision of wake-ups is just one factor worth considering. You have to communicate somehow with the temperature sensor and with LoRa module. It is quite likely that you will use asynchronous UART to talk to the LoRa module. In UART you have to keep the baudrate precise, otherwise the other end may start receiving invalid byte once in a while (or a complete garbage when the drift is huge).

author: lucazader
author_rank: Regular Contributor
timestamp: June 06, 2019, 08:07:27 pm
content: It depends a bit on how you are using it.If you are wanting to put the micro into sleep mode and use the rtc, then the internal one is very inaccurate.The main HSI clock in most stm32's is ok, but will have more temperature variability than a crystal will.If you are making this as a 1 off for personal use, then I would lean towards using a crystal (as they dont cost much).In my experience, the internal HSI is usually good enough for uart operation up to around 512k baud.And since the data rates of lora are quite low, and hence the baud rate of the uart will be low, I would probably suspect that this would be fine.

author: devan
author_rank: Contributor
timestamp: June 07, 2019, 04:05:33 am
content: Touching on the topic of wakeup accuracy - you also need to consider timing accuracy over shorter spans. I was just playing with some LoRa code running on an ATMega328 and found that between the tasks I had it running and the clock tolerance, I had trouble receiving downlinks because it was not turning on the radio to receive at the right time and it missed the downlink messages.I had to run the code with a high clock tolerance setting, which I believe means turning on the radio for more time (to ensure reception), which in turn means higher average power consumption.

author: DBecker
author_rank: Frequent Contributor
timestamp: June 07, 2019, 11:34:36 am
content: There are several aspects of stability.Long term accuracy is the obvious one. The STM32 internal clock is factory-calibrated. It's going to be pretty accurate, with under %1 error on older parts and better with newer production.Changes with temperature is another aspect. The STM32 internal clock is temperature compensated over the normal range, but the datasheet states error increases to 3% at the extremes of rated temperature. It's probably not that bad, but they aren't going to be testing parts to make a stronger claim.Phase stability -- short-term changes in frequency -- is a third issue. A internal clock will be considerably worse than a crystal, and it's likely to be correlated with program activity. That might matter in specific applications.Several of my STM32 applications have used CAN bus. CAN requires a external crystal to meet specs, but it works without any observable degradation on the HSI clock. That suggests that the HSI clock is considerably better than datasheet-worst-case. (This was repeatedly observed when code bugs and prototype build flaws resulted in the switch-over to the external crystal not happening. The STM32 will just stay on the HSI clock if the external crystal isn't working.)For lowest power you should use the HSI clock when possible. If you need an external crystal, you can often turn it on only when required. There is a app note on calibrating the HSI clock against an external crystal. The procedure varies depending on which generation of STM32 chip you are using.

author: Rerouter
author_rank: Super Contributor
timestamp: June 07, 2019, 12:26:56 pm
content: Otherwise you can trim for the internal oscillator with each transmission, with the main communication node returning a offset in the ACK for how much it had drifted, the device then uses that to predict the next wake up and works off that, minimize the error if you cant remove it, and leave sufficient spacing in your communication blocks so that if a device drifts at its worst, it doesn't conflict with the next node,If your concerned about power on both ends of the link, then the more accurate the timing, the shorter you need things switched on, sometimes an external RTC device with a interrupt pin can be a lower power option than running the watchdog and internal RTC,

author: panoss
author_rank: Frequent Contributor
timestamp: June 07, 2019, 02:31:57 pm
content: Only the transmitter 's power consumption is a matter for me, as it will be battery operated.The receiver will be powered from the mains, so I don 't care about it's consumption.There is no need for any timing between sender & receiver.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 07, 2019, 03:11:27 pm
content: Then I wouldn't fret about it. The internal oscillator should be more than good enough for your needs, and no it won't crash the MCU. The only real concern would be any UART communication, so make sure with the datasheet that you'll be within specs in all cases. The ideal case would be to use only I2C or SPI, then there would be absolutely no concern.One possibility if you're going to use the RTC to keep time/date is to use a 32.768kHz crystal for the LSE. Not sure about the STM32F0 series (you'll have to check), but with other series such as the L4, there is a mode in which the HSI can be automatically calibrated from the LSE so you wouldn't need any other crystal (just the 32k one, activating LSE and HSI). If you're going to use the RTC, a crystal is mandatory IMO, otherwise the drift is too severe to make the date/time keeping usable.

author: panoss
author_rank: Frequent Contributor
timestamp: June 07, 2019, 03:32:17 pm
content: Because a crystal is needed, I'd rather avoid the internal RTC too.(I 'm trying to make it as minimal as possible. My logic is if it can function without a component, then why not. And save space on the pcb of course)

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 07, 2019, 03:47:13 pm
content: Minimizing part count always makes sense as long as it doesn't compromise robustness, so I'm all for that.If you're not going to use the RTC and you have no critical timing in your design (again, check for UART communication if it applies), then you shouldn't need any crystal indeed.As a side note, if it's a device supposed to run for extended periods of time, I strongly suggest activating the watchdog as well so that potential lock-ups (either due to a software bug or EMI issues) would not block the device indefinitely.

author: georges80
author_rank: Frequent Contributor
timestamp: June 08, 2019, 03:59:55 pm
content: I use a Lora module and an STM32F030. No crystal needed for the STM. Lora and the STM communicate over SPI and since the STM is master, there is no UART/Clock stability issue to worry about.The internal STM internal clock is plenty accurate for something that just needs to wake up every so often and do something.cheers,george.