I tried connecting the Here4 (firmware 1.15.309D03B7) to two Cube Orange boards running Ardupilot 4.7.0 and 4.7.1, and I constantly get this output: GPS_RAW_INT:
fix_type = 1
satellites_visible = 0
lat = 0
lon = 0
h_acc = 0
v_acc = 0
Although in u-center I see the satellites and geographical coordinates correctly:
By comparison, through mavlink I only rarely receive any non-zero outputs, and for very short times:
gnss_debugging_logs copy.zip (88.9 KB)
I attached several logs and scripts that I used for debugging, and the params from Mission Planner, hopefully someone can help us find the issue. Thanks a lot! 
Summary of what we tried so far: Here4 (node 125, GNSSPeriph 1.15.309D03B7, HW 4.19) on a Cube Orange+ running ArduPilot 4.7.0 never delivers a fix to the autopilot — GPS1 reports fix_type=1, sats=0, hdop=655.5 indefinitely — because the module’s own AP_Periph GPS driver is stuck in a loop: it probes the internal u-blox at 230400 baud, receives the version reply (EXT CORE 1.00 (2caf6e)) 0.6 s later, then gets no navigation output and no acknowledgement of any configuration command, times out after 4 s with gnss.Status healthy=false and error_codes=24575 (14 config items unacknowledged), and restarts exactly 13.6 s later. The receiver itself is fine: through the CAN passthrough, u-center gets a clean 3D fix from it with 7 satellites used of 26 tracked, HDOP 1.91 and C/N0 of 41–42 dBHz on both L1 and L5. We have ruled out the autopilot (three Cube Orange+ boards, GPS and CAN parameters verified identical), the CAN bus (zero rx errors and zero bus-off across 85 000+ frames, terminator enabled, static node ID 125), the DroneCAN node itself (OPERATIONAL, health OK, uptime monotonic with no reboots, and its RM3100 compass streaming flawlessly throughout), the GNSSPeriph firmware (reflashed to 1.15) and sky view (tested outdoors with no change). So this is not a hardware or bus fault but a failure of the configuration handshake between AP_Periph and the F9P — the receiver answers MON-VER but ignores every CFG message — which we suspect may relate to the u-blox firmware build, since ours reads 2caf6e where CubePilot’s documentation references 49f616.
