I’m adding a GPS module to a Tufty 2350, and I can get NMEA sentences easily through the I2C connection. However, for more precise timing, I’d like to discipline the clock with the PPS signal from the GPS module.
On a Pi or Pico I can do that via one of the GPIO pins, but on Tufty 2350, I noticed there are only two ports on the top (SWD and I2C), and I’m not sure from the docs whether I could repurpose SWD for a GPIO input…
Assuming that’s not the case, are there any pads or headers inside the case I could use for GPIO input? If not, it’s not the end of the world, I just won’t be able to chase down the last second of accuracy for my GPS-clock-badge :)
(Ironically, NTP is more accurate via WiFi in this condition, due to how slow the GPS SoC seems to be sending out data at 9600 baud… need to see if I can get it faster).
No, that is not possible. These pins are connected to an internal serial wire debug bus.
Not having access to more pins is one of the biggest griefs I have with the Tufty2350. Such a nice high-end system, but limited to I2C.
What you could try: add an I2C GPIO-expander.
Another thing to be aware of: what clock do you want to discipline? The internal RTC of the RP2350 is not the best, but the Tufty2350 also has an external RTC which has a very low drift in my experience. I expect that the offset you have by reading external time via NTP or GPS and then updating the RTC will be much larger than what you have from internal clock drift.
1 Like
A SP/CE Connector would be a nice addition. Especially if it was multi functional, pin / signal wise. Just a suggestion, if a V2 happens. ;)
The board looks pretty packed though, adding extra connectors etc may be pretty tricky.
Mine ranks up there as one of my most favorite Pimoroni devices. Mine gets used daily as a portable weather station just hanging out around my neck. =)
1 Like
Definitely; I have really enjoyed messing around with it, much more than I expected! And with the little 3D printed desk stand it’s a nice multipurpose desk display.
in my case I’m trying to turn it into a microsecond-accurate GPS clock too, and the RTC resolution that’s exposed only gets me into the sub-second range. And GPS NMEA sentences over I2C have inherent latency that I won’t be able to fix without PPS.
I don’t need long term stability; the internal RTC should be okay down to minutes.
I still don’t get it. In your first post you are talking about a clock that you want to discipline. Which clock are you talking about? And the microsecond part is also very mysterious.
Right now my stretch goal is to get the time on the display to be ticking seconds in the sub-100ms-accurate realm compared to GPS time.
I’m getting GPS time over I2C, then writing it every few minutes to the RTC using rtc.datetime(), but that’s a bit inaccurate—not only does the I2C data have a lag because it’s coming across as NMEA sentences, the datetime write is also not very deterministic (IME)… I’ve seen the given time vary by ±300ms compared to my other PPS-disciplined GPS clock (which I have compared to a good reference, and is ±100ns from that).
I’m just trying to figure out if there’s a way I can discipline the RTC, maybe by getting PPS in on a pin, then having a routine that immediately sets the next second on a PPS pulse’s rising edge. It probably won’t get down to microseconds, but I can dream. I imagine it should be in the low-ms realm, though… which would be about 10x better than the 200-300ms offset I get right now.
I was initially trying to estimate an offset and account for it when writing datetime() but the variance is too much to be predictable…
I could drop down to C and skip the Badgeware stuff, but that makes it less fun and portable (I’d like my app to be runnable by anyone just buying a Tufty and dropping a folder in /apps, degrading gracefully to the non-PPS state if you don’t have PPS connected).
It’s not a practical need, as I’m already well under 1s with this setup… but I can probably do better with NTP over WiFi, and that just feels wrong when I have a good GPS module and a 3D fix :)
(I might be able to store my own PPS offset using time.ticks_us() and tracking my own offset, but the main ask here is how easy/hard it is to find a physical GPIO pin I can use. Maybe I could sacrifice one of the LEDs or buttons, heh.)
Ok, understood. Hardware and software are your limitation:
- the RP2350 does not have a clock or RTC. It has a timer (“AON-timer” - “always on timer”) that counts milliseconds. Everything else is software. You will never have a resolution lower than 1ms.
- If you had a free GPIO, you could setup an interrupt that takes your PPS pulse and sets the AON. As you note, this interrupt has to be handled in a timely manner.
- Python is non-deterministic from the timing perspective. You have things like garbage-collection and other background tasks, like tinyusb service routines. But you already noted the variance.
- Handling interrupts from MicroPython is possible, but again, you don’t have deterministic timings.
- The Tufty screen has very fast update rates, but if you want to display a timestamp with milliseconds, you won’t see much on the fraction part (you will see that the subseconds change very fast). The hardware of our eyes is also limited ;-)
It is a pity that the CLKOUT-pin of the PCF85063A is not available on the Tufty. This pin would give you a clean configurable square-wave in the range from 32kHz to 1Hz. And it is configurable in the PPM range.
1 Like