gps data on blackbox not working with 'blackbox_mode = always', before arming. (home position not set)

[atlaware]

Describe the bug

Hi, I think there is a "logical problem" with blackbox_mode = always: the blakbox record correctly gyro and other data, but no GPS data result available on blackbox log viewer. With the new blackbox log viewer (use nigtly), you can see gps data, coord, alt and other, and also save .gpx, but this work only if you ARM the quad. If I use continuous recording with blackbox_mode = always, I see only unavaible data in gps field, for coordinates lat/long, and only some occasional data for sat number, altitude.

I think, maybe, that is because gps data on blackbox are saved with reference to the home point, and for blackbox_mode = always, home point may not exist, if you never arm. Maybe a solution can be to save an initial home point when gps aquire a 3D fix?

To Reproduce

set blackbox_mode = always, not fly but let's the quad 5/10 minutes on "open air", so the gps can get 3dfix and star working. Open blackbox log with blackbox viewer nightlies that handles correctly gps data fields (https://github.com/betaflight/blackbox-log-viewer-nightlies/releases) wrong/error on gps coordinates.

Expected behavior

After 3dfix, set home position and logging gps data on blackbox, and reset home when eventualy arming.

Support ID

(not needed...)

Flight controller

OMNIBUSF4SD

Other components

Betaflight / STM32F405 (S405) 4.4.0

How are the different components wired up (including port information)

No response

Add any other context about the problem that you think might be relevant here

The use is for gps/gyro logging for this kind of result: https://youtu.be/WaIJ0YPZKak

[atlaware]

Hi, I have temporaly resolved (and tested) with this "bad" workarround: added a GPS_reset_home_position(); at line 1791 of https://github.com/betaflight/betaflight/blob/master/src/main/blackbox/blackbox.c#L1791C4-L1791C4

this call GPS_reset_home_position() every blackbox loop (very bad) on https://github.com/betaflight/betaflight/blob/master/src/main/io/gps.c#L1926C6-L1926C30 The GPS_reset_home_position() function reset home only if there is a 3dfix and only if !STATE(GPS_FIX_HOME), so I hope only "once".

I don't know how to do better. The result: https://youtu.be/WaIJ0YPZKak

[ZzyzxTek]

Yeah, we really don't want blackbox.c needing to know details about the GPS, like whether home position is set or not, and especially not triggering it. Complicates blackbox.c and creates a backwards dependency with the risk someone would work on gps.c without realizing blackbox.c also now has GPS logic.

I understand what you're wanting, to get GPS data logged as soon as the GPS module is connected and configured when blackbox mode is always.

We have two probably better options:

First is to perhaps change the GPS logging so before home point is established, it will log positional data that is not based on home position. I honestly haven't tracked that down so I don't know how feasible this is.

The second is to properly add this new home position "state." In other words, modify the GPS code so it establishes a preliminary home position once 3D fix comes from the module, and then establishes the actual home position as it does now with the min sat criteria and all. We would still not get any positional logging before the module has a fix. I've been in gps.c a lot recently for the M10 and baud rate changes, I know this is feasible but a bit more of a modification and testing effort. We still might need to modify the logging code in gps.c as well.

There's a lot going on with GPS changes right now (as of 23 June 2023), I'll make a note of this in my big list of GPS improvements & changes.

[haslinghuis]

Should we have presets for our favorite flying spot with home locations. Not sure if this defeats the necessity of the gps fix lock and create some serious issues when choosing the wrong offset.

[ZzyzxTek]

I suppose if the GPS is not working at the start of the flight and become available mid-flight, the preset might be a fallback location to try to return to. But yeah, seems risky to have that fallback available if it's not set correctly, although there are other GPS & rescue settings that can cause grief if not set properly. I think the best case is to use the reported position, since that means the GPS is functioning properly at the start of the flight.

What I was suggesting above is possibly a progression that looks like 1) no position reported --> 2) 3D fix only home position --> 3) min sats home position. And to enable logging of any available GPS blackbox data as soon as the module is communicating, adding other data like position when it becomes available.

[schachfeld]

Is there a workaround to this? I would really love to have usable gps data without arming :)