Giters

PX4 / PX4-GPSDrivers

Platform independent GPS drivers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add UBX-CFG-RST to force a Cold Start

AlexKlimaj opened this issue · comments

commented

I am finding that the Ublox MAX-M8 can get in a bad state when being powered on and off indoors for short periods of time. Once taken outside, it can take 1-2 hours to acquire satellites.

When booting up a fresh MAX-M8 outside, it only takes ~45 seconds to acquire satellites.

On a unit that got into a bad state, I connected it to Ublox U-center and forced a Cold start. The unit then acquired satellites in ~45 seconds. On this design, I am averaging 18-22 satellites, so I'm certain the RF frontend is working well.

The UBX protocol on u-blox 8/M8 from protocol 15 up supports a Cold boot command using UBX-CFG-RST defined in section 31.11.26 UBX-CFG-RST (0x06 0x04) of u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)

commented

How would you see this being used? Can we detect the bad state?

commented

I see it being accessible through the nut shell gps app, mavlink, and a qgroundcontrol button.

I think a bad state could automatically be detected in PX4 if a GPS module is connected and the satellite count has been equal to 0 for X minutes.

commented

@bkueng - Relative to having to test for interference, and being able establish a baseline.
I am wondering if you know if these devices can be told to use warm or cold start?

commented

In the Ublox U-center, there are buttons to initiate a warm start, hot start, or cold start.

commented

From
https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf
on page 17:

In the
UBX-CFG-RST
message, one can force the receiver to reset and clear data, in order to see the effects of
maintaining/losing such data between restarts. For this, the CFG-RST message offers the
navBbrMask
field,
where Hot, Warm and Cold starts can be initiated, and also other combinations thereof.
The Reset Type can also be specified. This is not related to GPS, but to the way the software restarts the
system.

commented

@AlexKlimaj Thank you! have you reviewed the code to identify what PX4 is sending?

commented

Could this be used for M8P RTK bases as well? I've had situations where the survey-in accuracy actually started increasing again and it would not decrease to below the required limit for a long time or at all.

Unplugging and plugging back in the module (a Drotek TinyRTK) did not fix the problem. Only leaving it unpowered for a long time fixed it. I suspect that that was due to the battery on the board keeping the module warm and it therefore not re-initializing fully.

commented

@davids5 It does not look like UBX-CFG-RST is defined in ubx.h.

Here is what would need to be added.

image

commented

Could this be used for M8P RTK bases as well? I've had situations where the survey-in accuracy actually started increasing again and it would not decrease to below the required limit for a long time or at all.

Unplugging and plugging back in the module (a Drotek TinyRTK) did not fix the problem. Only leaving it unpowered for a long time fixed it. I suspect that that was due to the battery on the board keeping the module warm and it therefore not re-initializing fully.

This is the exact issue I experienced and opened this thread for. We originally had a coin cell on our GPS design and found that the board getting turned on and off indoors during manufacturing was putting the Ublox MaxM8 in a bad state. It would take 1-2 hours of sitting outside for it to resolve itself without sending a cold start command.

Since then, we have switched to using a supercap instead of a coin cell. Mostly because a supercap can be charged fully in a single flight and hold the constellation between users swapping batteries for a single day. Once the supercap drains overnight, the GPS is forced into a cold start next time the user goes to fly.

commented

@AlexKlimaj - I see that.

We should add a gps reset {hot|cold|warm} command and do what is appropriate for the underlying hardware. We should respond with any errors or warnings if the underlying hardware does not support the command or mode of reset.

commented

We should add a gps reset {hot|cold|warm} command and do what is appropriate for the underlying hardware. We should respond with any errors or warnings if the underlying hardware does not support the command or mode of reset.

That sounds good.

commented

@bkueng - Do you have time to do it?

commented

Probably not soon.

commented

I am currently writing GPS module for Septentrio and can implement also gps reset command. If anybody has info on how to call reset for other supported modules, please post it here!