Using SparkFun GNSS Flex pHAT - DAN-F10N on Raspberry Pi 5 (with two cameras)

GPS/GNSS
1

i’m interested in the "SparkFun GNSS Flex pHAT - DAN-F10N”, SKU: GPS-29491, with a Raspberry Pi 5 (that will probably also be running two raspberry pi camera modules), and would like to find out some details. most importantly, i’d like to know if there is any sample gps position data retrieval code available for this exact model that is proven to work.

(a while ago i purchased another sparkfun gps unit for the qwiic system to use on a raspberry pi, but have yet to get gps coordinates or date/time using the online sample code i tried, and this time want to make sure i can see known working code before purchasing.)

if anyone has python (or other) code that has been tested using the DAN-F10N on the GNSS Flex pHAT with a Raspberry Pi 5 running headless (with Raspberry Pi OS “Lite”, without any graphical desktop installed), please let me know. all i’m looking for is a simple script that retrieves the current latitude and longitude and timestamp (from the gps / gnss satellites) into variables repeatedly every 5 seconds (and i will integrate this into my own code for data logging, live position reporting, etc).

regarding the GPS / GNSS module data output:

how does the DAN-F10N firmware handle timestamps when the gps week number rolls over every 1024 weeks? at the end of 2038, if the module were only connected to older satellites since powered up, will the reported timestamp indicate the correct year (or one in the past, or no year)?

i’m also looking for more details about the GNSS Flex pHAT:

are any of the LED indicators on the pHAT controllable by user?

will the physical slot in the pHAT board allow for two raspberry pi camera cables to fit through simultaneously when using two cameras on a raspberry pi 5, or does only one cable easily fit through without risking damage to the cables?

regarding the microSD card slot on the pHAT, does the inserted card automatically show up as a mounted / mountable filesystem in raspberry pi os (when properly formatted)? or is it only accessible via special commands on the pHAT, or when using the pHAT for data logging without plugging into the raspberry pi?

can someone please clarify details about the usb-c port on the pHAT? the product page specs mention backup power but also say not a power source next to usb bus detect. can the usb-c port on the pHAT be used to power the pHAT and carrier board, as well as provide backup power to the raspberry pi if its power source is lost? (or is it best to only plug usb-c power into the raspberry pi 5 itself?)

on a related note:

i’m also considering plugging a “SparkFun Qwiic button” with LED into the pHAT. i may place the cameras away from the raspberry pi 5 and extend the camera cables via a couple “Arducam CSI to HDMI Cable Extension Module” units. these arducam extension units feature headphone jacks for gpio extension (via the same hdmi cable that is extending the camera cable).

does SparkFun happen to have any adapter(s) to convert the Qwiic plugs into male headphone plugs? if i can extend the button without soldering something that’d be great. (the remote ends of both arducam extension units will be near each other, so i can use two sets of headphone plugs to extend the four qwiic pins via both arducam adapters) would there be any possibility of hardware damage if any (or half) the qwiic pins were accidentially disconnected while the other pins were still connected to a powered raspberry pi or pHAT?

2

The GPS rollover date basis for SPG 6.00 is Week 2280, so arguably 19.1 Years from that, but as I recollect GALILEO/BEIDOU have additional bits to help resolve if you leave the device off for 20 years. Otherwise expect it to be marked / advanced in BBR or FLASH

3

thank you for the details and attachment.

my curiosity is what happens if there is a case where it knows the year is in the 2030’s (if it saved this to nonvolatile flash memory), but then is powered off for a while, before the 1024 week rollover in november 2038 that is an issue with older satellites, and then is booted in december 2038 and happens to only see older satellites for a while.. until it connects to a modern satellite that reports a number with higher bit depth, will it be reporting the incorrect date?

4

The CNAV data carries 13-bits, so L2C and L5

But the 20-NOV-2038 wrap isn’t directly impacting the uBlox firmware as it knows it’s already well beyond the 2048th week in 2019, it’s not going to be confused within the 2280-3303 week realm (ie into 2042). See CFG-NAVSPG-WKNROLLOVER range (1-4096)

It only has to archive the last known good fix to insure time doesn’t jump backward.

You can also move the goal post forward using an internet connection, a firmware build date, your own or a subsequent SPG update.

Going as far back as the Series 5 receivers these would clock across the roll-over, as it does for each week of Z-count, with no interruption. A calendar date in the RTC carries forward.

5

No idea if this works, but if it’s a multi constellation GPS receiver wouldn’t the other constellations have correct time?

I would imagine the firmware would be aware of the rollover and when seeing GPS time not in agreement with the others, it would know a rollover occurred and fix itself?

Also:
No, there isn’t a qwiic to headphone adapter, plugging or unplugging with power on would cause trouble. That and qwiic won’t work over a distance greater than a few feet.

SD:
No, that’s not visible to the Pi, only select GPS receivers that support SD cards and even then it won’t show up on a pi.

6

Per the Googlez:

The u-blox DAN-F10N GNSS module handles the GPS week number rollover using a hard-coded reference rollover week number compiled into its firmware, which delays rollover impacts for roughly 20 years.

How GPS Rollover Works on u-blox F10

• The 10-bit limitation: The legacy GPS L1 navigation message uses a 10-bit counter for the week number, which rolls over from 1,023 back to 0 every 1,024 weeks (roughly 19.6 years).
• Firmware reference windows: u-blox resolves week-number ambiguity by comparing incoming week numbers against a reference rollover week compiled into the firmware.
• Impact scope: If a rollover date is reached without an updated reference value, the receiver only misreports the calendar date (shifting it by ~20 years). It does not disrupt core navigation, position accuracy, or time-of-day/time-pulse outputs.
• Override option: The default rollover compensation can be manually overridden or extended via UBX configuration messages if required for long-deployment life cycles.
*

Looks like you’re good for the next 32ish years. The machines will probably rise up and kill us all before then.