Copter 4.0.0 is not the problem, batteries of my 2 Beitian BN-880 indicated 0.2V and 0.7V, I didn’t even know that last GPS position was stored on GPS and not on Ardupilot. That causes my problem, thanks. BTW, could it be a “software” way to check that GPS battery is out of order, or do we have to assume that “Bad GPS health” is the message for this? Or couldn’t the last GPS position be stored somewhere in order to avoid such problems? Nice to have. Thanks.
If you have telemtry radios of some sort then there’s a tlog with the GPS coordinates.
Also do you have your voltage and current measurements set up properly and battery failsafes?
yes, using yaapu telemetry and battery failsafe (only voltage) on my F4 omnibus AIO, if you need some of my parameters values, tell me. But the problem each time I power on my done I have No Fix, and then after maybe 10 minutes, I have position around center Africa, and if I wait more, around 20 minutes, he find my localisation in Center Europe.
@chris661, great that you figured out somehow that it was the GPS battery that was the issue. I’ve asked @WickedShell (our GPS driver maintainer among other things) if he knows if we can get the GPS battery voltage through the UBlox serial protocol.
EDIT: MichaelDB says that the protocol (as far as we know) doesn’t support checking the GPS’s battery voltage. 
Thanks for answering, and @WickedShell for investigating, but cannot Ardupilot store the last used position in order to “help” the GPS looking for a position in the right area? I’ve seen parameter SBAS in Inav UBLOX config
They write: “If you use a regional specific setting you may achieve a faster GPS lock than using AUTO” for example setting parameter to EGNOS is for Europe. Just as a suggestion.
Is there any documentation for StandBy mode? I have been waiting for this feature for a long time…
The GPS doesn’t take a position from an external source to help it. Also, the GPS has to update more than just it’s present location when the battery dies. Unfortunately it is what it is. It is also rather common among the knockoff GPS units.
thanks, but what about the SBAS parameter supported by UBLOX and exploited in Inav?
Sorry… couldn’t resist 
Not sure what you mean? SBAS is Satellite Based Augmentation System. That isn’t something that the vehicle would send or manipulate other than enable/disable if you desired. It would enabled by default on an M8N GPS anyway. And it isn’t something that helps or hurts the startup time.
Yes, I think it’s possible that we could enhance ArduPilot to download the info from the GPS and then provide it again on the next reboot. Feel free to add an enhancement request to the to-do list. I can’t make any promises when it would be implemented. Features in AP generally get done because a volunteer developer is interested in making the change or a company sponsors it. Either is possible but it just makes predicting when it will happen difficult.
2 Likes
Sorry, the link I provided was bad. More info about this parameter https://github.com/iNavFlight/inav/wiki/GPS--and-Compass-setup#sbas
A lot of fun, Monsieur Poirier !
1 Like
That’s not sending a position to the GPS to give it a head start. That’s just enabling/disabling the use of SBAS, and forcing a regional system vs automatically determining which regional system to use.
Forcing the SBAS system to a specific region is not going to make it recover from a dead battery faster. The GPS will acquire sats without any SBAS at all. SBAS doesn’t make it aquire sats faster. It enhances the position accuracy of the ones you already have.
Starting up an M8N with a dead battery is what it is. There is no way to cheat it into working faster. The solution to the long start up time is to have a battery on the GPS that isn’t dead. I hate to keep saying this, but with hacked knock-off cut rate GPS units like this one, you get what you pay for quite often.
1 Like
Doesn’t AGPS aid the startup by uploading Almanac Ephmeris (costelation position orbits) at boot time?
That would allow to push the data into the GPS instead of the GPS having to retain it in memory. Is this correct?
1 Like
Retaining almanac somewhere and uploading it to GPS at boot would definitely help some, since its validity is a couple of days, and takes longer to get it from sats. Ephemeris is less important, as it’s valid for a couple of hours only.
But all this stuff, and the work involved is beat by a $2 lithium button cell.
3 Likes
I believe the functionality of U-Blox AssistNow is being cited:
https://www.u-blox.com/en/solution/services/assistnow
AssistNow Autonomous is a best-guess approximation of the constellation modeled from the periodic nature of the satellite orbits and does help a bit with acquisition during cold boot. Does not require any external data, just a config flag on the GPS.
AssistNow Online grabs data from the U-Blox servers based upon what satellites are visible at time of request. I’ve yet to be able to use this in-field, no comment on effectiveness.
AssistNow Offline can supplement Online & Autonomous by downloading differential files that can be cached for a number of days in advance of the download request, with accuracy/effectiveness of the differential files decreasing as the date increases from the point of download. This I have used, and liked.
All of these combined should lead to super fast fixes, especially in tough conditions, and especially when the constellation has changed significantly while the GPS was offline (days between collections, survey sites in vastly different geographic locations, etc.)
All of these services are freely usable for U-Blox cusomters provided a SLA is not needed.
Hi,
Regarding the PreArm: Internal errors (0x400) - had a similar setup - 2 X UAVCAN GPS (mRo Location One).
attaching a log & a tlog - used GPS_AUTO_SWITCH = 2 (Blend)
Seems that the error comes up when the 2nd GPS gets a 3D FIX
Adding some more info:
When testing with one Here2 module and one mRo Location one the PreArm doesn’t come up.
When changing GPS_AUTO_SWITCH = 1 (UseBest) the PreArm doesn’t come up as well.
1 Like