GPSD Variables

[MNTech68]

As part of the readme I have the GPSD functioning with ultrafeeder. I have the env variables set as shown below, but they appear to be ignored by the mlat-client config.

GPSD_MIN_DISTANCE=40 GPSD_MLAT_WAIT=120 GPSD_CHECK_INTERVAL=60

Here's the log output from client: ultrafeeder | [2024-07-18 13:06:12.109][mlat-client] Receiver moved 26 meters - Stopping all mlat-clients

As you can see even with the variable set at 40, it's still using default of 20. I have taken the docker down then restarted with docker compose up -d

I'm assuming these variables just aren't matching with whatever is in the mlat-client config that reads these?

[wiedehopf]

This still an issue or can this be closed?

[MNTech68]

It was still an issue last time I looked. Were there some updates that were marked as having resolved it?

[wiedehopf]

I don't see any issue in the code why this wouldn't work.

[MNTech68]

I couldn't figure out why either, but the logs clearly show it stopping mlat-clients with a move of 26 meters, even when the GPSD_MIN_DISTANCE=40 variable is set.

[MNTech68]

I noticed somewhere else where the env variables were being read as "feet" vs "meters" as well, so maybe that's the issue?

[wiedehopf]

i don't think the env var is set correctly to put it very simple.

 docker exec -it ultrafeeder bash
 echo $GPSD_MIN_DISTANCE

[wiedehopf]

Receiver moved less than

can you look for this line in your log?

[MNTech68]

i don't think the env var is set correctly to put it very simple.

 docker exec -it ultrafeeder bash
 echo $GPSD_MIN_DISTANCE

root@ultrafeeder:/# echo $GPSD_MIN_DISTANCE

root@ultrafeeder:/#

[MNTech68]

I can also confirm it's not reading the "GPS_MLAT_WAIT" .env setting either. I have mine set to 600 seconds, and the log output still shows:

ultrafeeder | [2024-08-28 12:08:02.358][mlat-client] Receiver moved less than 20 meters, 30 seconds remaining before starting mlat-clients

[wiedehopf]

That's not how the .env file works. Thus this is user error.

.env only applies to the yml, if the variable isn't used there it might as well not exist. Thus it needs to be in the environment for a specific service. See how FEEDER_LAT for example is used in the yml and on that way set for the service.

[MNTech68]

I'm literally following the directions from the repository that shows the documented environmental variables that are available to regulate mlat-client. So, is the documentation wrong, not clear on where these variables are supposed to be set, or just not working?

https://github.com/sdr-enthusiasts/docker-adsb-ultrafeeder?tab=readme-ov-file#optional-parameters-regulating-the-restart-of-mlat-client-when-the-location-changes

[MNTech68]

That's not how the .env file works. Thus this is user error.

.env only applies to the yml, if the variable isn't used there it might as well not exist. Thus it needs to be in the environment for a specific service. See how FEEDER_LAT for example is used in the yml and on that way set for the service.

I get what you're saying. I agree that the variable isn't being called anywhere in the yml. That's why I opened the issue though. The underlying issue here is that there's a documented parameter that isn't being applied to mlat-client. I know the variable "isn't doing anything now", but that doesn't make it a user error, it makes it a bug, given that it's a documented function that isn't working as expected.

[wiedehopf]

That's an issue with whatever explains the .env file ... not with the ultrafeeder readme. Optimally you could improve the readme via a PR.

Placing all available env vars in the yml just so you can set them in the .env file is not realistic. You'll have to modify the environment: section of the yml.

[MNTech68]

I have these parameters added directly to the yml now. Still not working though. I see where mlat-client is calling for the variable in lines 95, 101, and 107.

   - GPSD_MIN_DISTANCE=40
   - GPSD_MLAT_WAIT=600
   - GPSD_CHECK_INTERVAL=90

Once I get this working, I'm happy to pull and update the documentation.

[wiedehopf]

Possibly a note in the sample .env files might be a possible way to warn of this pitfall.

You added this to the environment section of ultrafeeder? compose up -d? Check with docker exec -it ultrafeeder bash .... echo ?

[MNTech68]

Got it all working.

One item I see is that random garbage data from the gpsd can cause the location to skew massively for a second or two. Right now it's coded to kill mlat with ANY change of xx meters, but what about a setting to limit it to 3 consecutive changes in xx meters? So that way a single bad data point doesn't kill the services. I imagine somewhere in this section:

    distance="$(distance "$old_lat" "$old_lon" "$new_lat" "$new_lon")"
    if ! [[ -f "$LOCATION_PERSIST" ]]; then
        echo "$new_lat" "$new_lon" "$new_alt" > "$LOCATION_PERSIST"
    fi
    if (( ${distance%%.*} > ${GPSD_MIN_DISTANCE:-20} )); then

        msg="Receiver moved ${distance%%.*} meters"

        # kill the mlat-client instances so they get restarted with the new GPS coords
        if pkill -f "/usr/bin/python3 /usr/bin/mlat-client" >/dev/null 2>&1; then
            msg+=" - Stopping all mlat-clients"

[wiedehopf]

I don't know, GPS position shouldn't change much after the position is acquired and stable.

The intention here is to err a bit on the side of caution to prevent bad MLAT. Really, 40m is already kinda questionable.

If you don't run a truly mobile station, gpsd should simply not be used for this.

[MNTech68]

The problem is most of the low power units that someone would use with this are of poor quality and typically struggle to maintain a solid lock. They appear to be "moving" all the time within a general area.

In my case they are going to be stationary, but moving to a new site periodically for specific flight activities. For example there may be a fly in event or tour operation out of a space that doesn't have adequate low altitude coverage.

[wiedehopf]

Well if they appear to be moving all the time and you still want MLAT, i'd say you should just set the lat lon manually.

Or just don't participate in MLAT.

If you don't have a consistent, precise receiver location, not a good idea to take part in MLAT.