GPS cutoff values

[Antonin]

I'm reworking the gps sensors (ot much knowledgeable in it, would have quite some questions):
I don't really get this part (and there's a bug)

        lat = (
            lon
        ) = alt = spd = heading = hdop = mode = timestamp = self.config.G_GPS_NULLVALUE
        .....
        if "hdop" in message:
            hdop = float(message["hdop"])
            if hdop < 10:
                mode = 3
            elif hdop < 20:
                mode = 2
            else:
                mode = 1
        if hdop >= 20.0:
            return

1. It works because hdop is always in message, else you'd have something lile None > 20.0 in that last test, so it should be moved or removed (cf 2.)
2. I don't even get why there would be an early return here, the position should still be sent to the update ? And it should just be marked as invalid in get_GPS_basic_values... But why do we have there different cutoff values:?

valid_cutoff_dof = [99.0, 99.0, 99.0] 

[hishizuka]

Hi @Ptosiek ,
Oh, thanks for reading my experimental and dirty code.

update_GB is a function that retrieves the GPS position from Android's Gadgetbridge app. It does not provide the statistical metrics that a normal GPS module provides, only the value of getAccuracy() in the Android SDK. The program uses it as hdop without any conversion. (Some mathematical conversion is required). So, I have not implemented it properly because mode is not available.

1. Yes, this is certainly unnecessary.
2. Yes, values should be sent to get_GPS_basic_values.

valid_cutoff_dof is an attempt to get a more accurate GPS position than mode=3 using pdof, hdof, and vdof, which can be obtained when using GPSd. We know that if there are multiple tunnels, even mode=3 will be inaccurate, and I would like to eventually use deep learning to control the parameters or conditions for this.

[Antonin]

Thanks for the explanation. I am still unclear about the different conversions made in the code but I'm reading on the topic :)
Closing for now!