Product: 2x SparkFun GNSS Flex pHAT - DAN-F10N (SKU GPS-29491)
Summary: The module powers on (PWR LED lit) but produces zero UART output and zero PPS pulses under any configuration. We’ve isolated the fault to a hard electrical short/stuck-low condition on the RX line as seen from the host, reproduced identically across two separate Raspberry Pi 5 boards and two separate DAN-F10N modules on the same carrier pHAT, and ruled out every software/configuration explanation we could find, including checking the official u-blox integration manual and both the module’s and carrier’s own schematics. Requesting your team’s read on this and how you’d like to proceed (RMA, replacement, or a diagnostic step we haven’t thought of).
Setup: Raspberry Pi 5, Raspberry Pi OS (Debian trixie-based), module on the 40-pin GPIO header per your hookup guide, UART on GPIO14/15 at 38400 baud (your documented default). dtoverlay=disable-bt + enable_uart=1 applied (also tried the Pi 5-specific dtoverlay=uart0-pi5, and separately dtparam=uart0=on+dtoverlay=uart0 per your own software setup guide — identical result under both). Serial console removed from the kernel command line so it doesn’t contend for the UART.
What we observed:
- PWR LED: on (steady).
- PPS LED: no activity.
- Zero bytes received on
/dev/ttyAMA0at 38400 baud (confirmed via rawcat/stty,minicom,pyubx2/pygnssutils’sgnssstreamer, andgpsd— four independent tools, same null result every time). ppstestagainst/dev/pps0times out waiting for a pulse — no PPS activity detected at the OS level either, not just “no fix yet.”- Decisive test: with the UART peripheral/driver bypassed entirely, GPIO15 (RX, physically wired to the module’s TXD per the schematic) reconfigured as a plain GPIO input with the Pi’s internal pull-up enabled still reads a hard LOW — while GPIO14 under identical treatment correctly reads HIGH. A pull-up-overriding LOW like this isn’t consistent with any documented DAN-F10N TXD state we could find (checked the Integration Manual’s own pin-state table: TXD is either actively driving in Continuous/Safeboot mode, or tri-stated with an internal pull-up to VCC in Software Standby — never documented to idle or drive low).
What we ruled out before concluding this is hardware (details available on request):
- Wrong baud rate — swept all 8 standard rates (4800 through 460800), none produced output.
- Wrong device path — confirmed
/dev/ttyAMA0is correct (matches GPIO14/15 perpinctrl’sTXD0/RXD0alt-function labels and the carrier pHAT’s own schematic);/dev/serial0resolves to a different, physically unconnected UART on our Pi 5 overlay configuration. - UART/I2C interface mismatch — confirmed from your own hardware_overview docs and the DAN-F10N data sheet that this module is UART-only, no I2C exists on it; also confirmed empirically with an I2C bus scan (
i2cdetect) showing no device at any address. - Missing enable/wake sequencing — confirmed from the Integration Manual that no active enable pin exists and the module should self-start on power;
RESET_Nfloating is the documented normal condition, and we confirmed via both schematics that RESET is correctly left unconnected on the carrier board (not accidentally tied to anything that could hold it low). - NMEA disabled by default — confirmed from the data sheet’s default interface settings that GGA/GLL/GSA/GSV/RMC/VTG output is enabled out of the box.
- Console/OS contention for the UART — removed
console=serial0from the kernel command line, confirmed noserial-gettyservice bound to the relevantttyAMAdevice. - Connector seating — fully detached and reseated the DAN-F10N module from the carrier pHAT, checked the triangle/pin-1 alignment and full engagement of the 2x10 stacking header (specifically for a one-row offset) — no change.
- USB-C — no
/dev/ttyACM*/ttyUSB*device enumerates when connected via USB-C; consistent with this being a power-only path on this variant, as your own docs describe. - Two independent DAN-F10N modules tested on the same carrier pHAT — identical symptom on both, ruling out a single bad GNSS module.
- Two independent Raspberry Pi 5 boards tested — identical symptom on both (including the plain-GPIO stuck-low result), ruling out a fault specific to one Pi.
What we’re asking: given the above, is this consistent with a known failure mode on your end (e.g., a specific batch issue, a common solder defect location on the carrier board’s TX net)? Is there a further diagnostic step you’d want us to try before an RMA (we don’t have an oscilloscope, but do have a multimeter if there’s a specific continuity/voltage check that would help you narrow it down)? Otherwise, please advise on RMA/replacement process for this SKU.
Happy to provide full command-by-command logs, pinctrl output, or photos of the physical assembly if useful.
Thanks for your time.
