Approximately 8:20minutes after system power-up, the Here4 loses about half of its satellites for a second or less. As a result, the position becomes too inaccurate, and depending on the configuration, the system switches to failsafe land mode or drops out of position modes like Position (Px4) and back to, for example, Althold. After this single dropout occurs, it does not happen again. I was able to continue a test flight for about 30 minutes after this dropout without further problems.
This dropout can also be observed while on the ground. In fact, any flight controller with a connected Here4 module is sufficient to reproduce this error. It happens consistently, regardless of the flight controller hardware (in our tests, CubeOrange and Holybro 6x) or the time of day (satellite position).
this is Jannis. I spoke to you at the Xponential. Michael is one of my colleagues and it seems that he was faster posting this then me Thanks for your help thought!
Here is the FW-Version of the Here4. It should be the newest:
Here is a ublox log I recorded three days ago. But i noticed, since i enabled all debug msgs, there are some glitches in the communication, where no data is displayed (?).
Here are two logs, with and without debug-msgs enabled.
I set the baudrate to 460800 on the SL can port on the top right in mission planner and also on the popup that appears when setting the Here4 in passtrought mode.
I am chiming in to confirm that we are experiencing the exact same critical failures with our HERE4 GPS units.
We operate a drone light show fleet, and this specific glitch has already cost us 5 drones. Like you, we see a sudden drop to 0 satellites, a massive HDOP spike, and altitude instability. The most frustrating part is that there is no pattern—it happens randomly mid-flight or even while the drones are stationary on the ground.
In our case, this glitch is catastrophic because it triggers a safety feature where the drone enters Land Mode (believing it’s in the final 5 meters of the mission). Since we fly mostly over the sea, the drones simply land in the water and are lost.
A few points to add to the discussion:
We have tested all v1.15 firmware iterations, and the issue persists on every single one.
We’ve been forced to ground our entire fleet because the GPS is the core of our business and we can no longer trust the hardware.
I’ve attached a preview of our logs showing the instantaneous satellite drop and EKF variance.
This is a professional-grade module, but right now it’s performing like a liability. We need an official word from the developers—is this a known batch issue or a fundamental flaw in the current firmware’s GNSS processing?
Over 50% of our fleet is experiencing the glitch some after 9 min, the example below is at 51 as you can see so we cant predict it
1. Today I conducted a few more tests. Specifically, I equipped a Holybro 6X FC with a Here4 CANbus GNSS module, and set up a second system with a Holybro 6X and a Holybro DroneCan F9P. First off, with the Holybro DroneCan F9P, I didn’t experience any dropouts—as described in this thread—during any of my test runs today. The longest log file with the Holybro DroneCan F9P is about 33 minutes long and has no dropouts.
In the comparison test, both systems were started simultaneously. The Here4 dropped out after ~8 minutes, while the DroneCan F9P continued running at the same time. ( In Image Orange, the System with Here4, Gren the system with Holybro Droncan F9P)
2. Regarding PX4 1.15 vs. 1.13, it seems something has changed here. There is also a thread on the PX4 forum: Failsafe Triggered: "Invalid Setpoints" and Blind Land with Here4 GPS - PX4 Autopilot - Dronecode Forum | Open Source Drone Development . However, it confuses more than it clarifies. The commit on GitHub, linked below, doesn’t provide much insight either. What is certain is that in PX4 1.15, EKF2_NOAID_TOUT set to 5 seconds by default does not work the way a human would expect based on the description. Instead, the 5 seconds are used to wait after the EKF position error occurs until the failsafe is triggered. However, the parameter suggests that the position does not have to be incorrect over a period of XX. I have included an image showing when the dropout generates a horizontal error. Incidentally, this is well below the threshold value of COM_POS_FS_EPH, which defaults to 5 meters. See the image for what Px4 1.15.4 does instead.
It has a minor positional error due to the brief satellite drop and triggers failsafe AltHold 5 seconds later. In my opinion, that’s completely wrong! (failsafe to AltHold in Yellow)
I have no idea if it’s possible to configure PX4 1.15 to have a slightly softer EKF positional error decision without jeopardizing the entire EKF system or making it too insensitive.
Thanks for your help thought!
