…isn’t it anyways needed to update system time anyways via NTP (internet connection needed) first to set the RTC properly? Or else reading out the RTC could produce rubbish…
My understanding is, that the RTC’s purpose is to continue running (with properly set time) while the device is powered down or is in deep sleep mode (here usually no time updates happen)…and then, you are able to perform timed operations like wake-ups, push data to somewhere and go back to deep sleep mode to ensure long battery life…
Other than that, the RTC of course also provides time without an internet update…but this depends on the accuracy/deviation of the timing chip… usually the RTC is updated with accurate time regularly (e.g. whenever the device has internet connection) to keep the drift at a minimum…
So, before reading out the time from RTC, one need to make sure to have it set correctly…correct me if I am wrong…
Perfectly valid. But with Pimoroni’s MicroPython, there is a lot of magic sauce in the soup. So the external rtc could already be updated behind the scenes.
BTW: you have two RTCs: one built into the RP2350, one external in the Tufty (PCF85063a). I haven’t checked with the specific Pimoroni API, but what I usually do is to first do a heuristic check of the value of the internal RTC, then the same check of the external RTC and only if the latter fails, I update the time from the Internet. From a battery perspective, WLAN activity is very costly so this procedure optimizes power consumption. For a Tufty with it’s TFT screen this is not relevant, but for the Badger it is.
I went with the with filesystem V2, and ran the clock app first thing. On it’s first run It connects over WIFI and sets the RTC up based on the info in the secrets.py file. It’s all good, and as long as I leave the battery plugged in, it stays correct.
I’ll put some print statements in, my original file had them way back when I started coding it. Then as some point I did a house keeping and stripped them out. One of those, seemed like a good idea at the time.
The screen resolution on Tufty is a possible 320x240, but by default this is pixel doubled to 160x120 for the purposes of speed. It’s perfectly possible to change between the two and even switch on the fly, however, by using the above command as badge.mode(HIRES) or badge.mode(LORES).
@BillyTPilgrim Thankyou very much. I was looking in all the wrong places. =)
That I think explains what I’m seeing, mine is in the default LORES. Where is that mentioned in the documentation?
EDIT: Never mind, found it under graphics.
adding badge.mode(HIRES) fixed things up for me. Now I’m finally getting some where.
Next mission is to make my displayed text bigger. Time to play with some fonts I think.
Vector fonts aren’t documented yet, as I was just a little late pushing the file up to GitHub… however, they’re super simple. You can load a font into a variable just like you can with pixel fonts. Just my_font = font.load(path_to_font_file) and then you can use my_font wherever you’d use a pixel font, in the image and text modules.
Vector fonts are stored in the Alright Font (.af) format. This converts the complex structure of .ttf and .otf fonts into simpler glyphs that can be stored in less space. There are three .af fonts preloaded on the badge, but you can find more, and make your own, at [the Alright Fonts GitHub repository](GitHub - lowfatcode/alright-fonts: The font format designed for embedded and low resource platforms.).