The official PYBD running MicroPython, and its accessories.
Target audience: Users with a PYBD
I see mention of an ntptime module in the ESP8266 MicroPython docs, but it doesn't appear to be included with MicroPython on the PyBoard D firmware. Importing it fails. How are other people synchronizing the RTCs of their PyBoard Ds (which have built-in wifi) or PyBoard 1.1s (perhaps with a wifi shield or ethernet module or something to that effect)?
MicroPython v1.12 on 2019-12-20; PYBD-SF2W with STM32F722IEK
Type "help()" for more information.
>>> import ntptime
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'ntptime'
Thanks.
Why do I need an external RTC to set the time on the PyBoard? Why not use NTP the way it was always intended to be used? I was just curious why it isn't built into the PyBoard's MicroPython. I've already copied over the version from the ESP8266 subdirectory and it mostly works -- with the exception that the utime.gmtime() it relies on doesn't seem to exist in the PyD's firmware, so now I have to figure out how to to timezone offsets, which is always super tricky.
but it's always going to be a bit of a hack, since full Unix tz support requires more memory than we'll ever have available.
Non-wifi MicroPython boards can get their RTC set from rshell and the host computer's time. The RTC might drift a bit, but it's usually good enough for data logging work. NTP needs a whole network stack. You might be able to do something creative with GPS, WWV or R(B)DS radio clocks that's a lot lighter than networking
Topics are getting crossed here. My fault since I brought up multiple issues. I'm less concerned with the timezone correction, which I realize is a pretty complex issue, and more concerned with proper NTP synchronization. The basic NTP method offered in the ESP8266 subproject seems to work pretty well on the PyBoardD. I'm curious why it hasn't been folded into the main branch, or at least the PyBoardD branch so that it would be natively available on PyD without copying the file over, as I did (also, see my other post about a serious error I'm experiencing. It still isn't working properly:
viewtopic.php?f=20&t=10221
).
Once I get basic NTP working without crashing, as per that other thread, I am still curious about subsecond synchronization. I am going to start experimenting with a GPS approach later this week in fact, just as you mentioned in the previous comment.
Cheers!
That's cool! I wasn't aware of that device. You still have to set the external device though. I'm going to try with a GPS later this week when the module arrives.
BTW, the timezone correction is a piece of cake. It doesn't require all the memory in the world, thereby overloading the little PyBoard's capacity, as was implied in some other responses. All you do is convert the GMT time to an epoch time (bearing in mind that PyBoard epochs start at the millennium), roll the epoch by your timezone offset in seconds (timezone offset in hours * 3600), then convert that epoch time back to a datetime tuple and feed the result to the RTC initialization routine (you have to be careful here, since for perplexing and confusing reasons, the datetime tuple isn't in the same order now! and incurs an off-by-one discrepancy in the weekday value! -- WHY?!).
Anyway, that sets your RTC to a local timezone for practically no effort. It's so straightforward that I suspect I missed something in the earlier discussion about how hard this ought to be. What's the problem? Here's how it works:
