…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.).
Yes, this is indeed a deep sleep mode for shipping so that units wouldn’t arrive with customers with flat batteries, but it doesn’t engage in quite the way you mentioned - the actual combination is holding UP and DOWN together while long pressing Reset.
Then you’ll be in a deep sleep that is functionally identical to the normal sleep mode, except that the front buttons and Home are disabled and the unit will only reawaken on Reset.
but for my units, a sleep-like state without reaction to buttons!=reset can be triggered with all buttons.
Skimming handle_long_press() in “github .. pimoroni .. tufty2350 .. modules .. c .. powman .. powman.c” reads exactly as you say for the official method ( :-), and sorry: discourse-restrictions bit me).
The following is true for version 4.03 on my tuftys and the badger:
Is there something with the sequence of setup_gpio and powman_setup_gpio_wakeup WHILE a (non-reset) button is still pressed, that makes normal long_sleep fail to notice interrupts of (non-RESET) buttons? (basically shipping mode currently in the source has the same code as sleep mode except the gpio setup for rtc and buttons).
Battery is still near full after 3d, thus whatever codepath I trigger when using say the ‘b’ key while long-pressing reset, my units DO enter sleep. I’m on version 4.03. Note that with ‘b’ etc I need to press the key before reset and release it after leds go off.
There’s also a third code path (or method of crashing?): press boot, and during pressing it, also short press (or long) reset: similar behaviour, but without the 4 leds. No reaction to keys other than reset and screen is off. I’ve one unit in that mode and will have a look at the battery in a few days…
There also seems to be an explicit off_state implemented in powman.c. Do I read this correct that this one is currently unused?
What he said. That puts it in Boot mode, it will show up as RP2350. You can then erase it (flash_nuke it) of flash it with a uf2 file. I’ve done that on mine to bring it up to the V2 firmware.
So I got this because I thought it would be fun to make the thermal camera mod in the email. Uhm not fun yet…….the tufty booted fine out of the box, then I downloaded the app for the thermal camera. Rebooted . Wired the camera up to the I2C port and that seemed to brick the tufty.. no screen response on the on board screen , leds onthe back do stuff ad things.
@Adamwest
What App from where? Link please. :)
Also, how did you install that new App?
If you have copied over the main.py file on the Tufty that explains why its crashed.
It sounds like something might have gone awry with where/how you’ve added that app, which is causing the unit not to boot. First of all let’s check the unit is working okay by flashing a fresh copy of the latest firmware, found here:
You’ll want the “with filesystem” version - bear in mind it’ll wipe everything currently on your badge. Just follow the instructions on the above page.
As for the thermal camera, I’m assuming you’re talking about the app found here:
For it to function properly you’ll want to connect in disk mode (double tap the reset button) so that the badge appears as a removable storage drive on your computer. Navigate into the apps folder, then make a new folder inside there called thermal_camera. That’s where the three .py files and icon.png should be copied to. Then you can just reset the badge, and your app should be accessible as an icon on the menu.
I found outish, what happened installed the app ok but, when I connected the mlx90640 with an i2c to i2c cable. It soft locks the tufty.
Full disclosure I thought I could just plug both in and it would work, but then I looked at email picture you all post from Ryan I see that he had it solder on the breakout so I will try that out. Side question does the i2c looking connection on the mlx90640 function the same as the soldering point?
Also is the i2c port hot swappable? Or do I need to make sure I sleep or rest the tufty before I attach it?
I have the Sensor Stick connected to my Tufty via the QWICC cable / connector. I put mine in sleep mode when connecting / disconnecting. I have accidentally pulled the cable out once or twice, and as far as I can tell no harm done to the Tufty. My App crashes, but all is good after a reconnect and reset etc.
As far as I know your mlx90640 should work via the QWICC connector, with no need to use the solder pads.
I think I foind the problem the upper i2c pins look like the are almost touching and when i plug anything in they short out to each other. I only found out because I plugged just the cable in without any thing on the other side
