GPS to readsb

[marcoculver]

I followed the following steps.

GPS: u blox vtk172 USB GPS.

1. Installed gpsd & gpsd-clients
2. /etc/default/gpsd:

 # Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES=""

# Other options you want to pass to gpsd
GPSD_OPTIONS="/dev/ttyACM0"
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="true"

`START_DAEMON="true"

4. Tested gps with xgps and it works.
5. After adding the --net-connector localhost,2947,gpsd_in to the readsb config, I get lats and long reading 0 when running cgps -s. Only after I stop the readsb.service, do I immediately regain lats and longs on the cgps -s page whcih seems like it then frees up ttyACM0 and the I can regain my coordinates, instead of it reading just 0
   How can I fix this?

Thanks!

[wiedehopf]

No clue.
I got it running and it uses gpsd data via that TCP connection.
Now if gpsd behaves weird when you have that connection that's not really my issue on the readsb side.

It seems like some exclusive mode where the first connection gets use of the GPS device?
I mean google for it / fix the readsb source.

What happens if you have cgps -s running and workign and you start readsb?

[marcoculver]

I will have a look and try that. I'm going to try move my set coordinates to somewhere else and see if tar1090 updates my location. Could you maybe try and see if you are able to get data on cgps -s if you are already running readsb from boot? This will help. I t seems it could be whichever grabs the ttyACM0 first wins scenario? Thanks for the help!

[wiedehopf]

I have tested this previously with inputting fake data into gpsd.
Zero desire to replicate that setup, thus you are pretty much on your own.
gpsd is poorly documented, it has worked for several people so my inclination to touch it is low.

How this gets fixed is: You find the exact issue and tell me what my program needs to do different.
I'd suggest monitoring the TCP connection using for example tshark.

tshark -f "tcp port 2947" -i any

Might need root.

That should allow you to check how readsb behaves.
Now as soon as you know what you want readsb to do differently, that's when i'm open for input.

[marcoculver]

Thanks very much. Do you get constant position updating or should readsb be getting constant position updates? I can get a position on the map but I find I have to restart gpsd to get a new position update on the map.

[marcoculver]

Hello, It looks like readsb it programmed to get the gps coordinates from startup and then close the connection. Is there a way to keep the connection to gpsd open? I struggle to keep my aircrafts adsb signal hence why I want to keep getting GPS coordinates from the gpsd.. Thanks!

[wiedehopf]

It doesn't close the connection.

[marcoculver]

Ok.. Just seems like that because it doesn't update the GPS coordinates unless i restart the readsb.service. Do you get constant position updating? Trying my best to make this work

[wiedehopf]

What GPSD does, and what it cannot do
GPSD solves some of the problems with GPS/AIS sensors. First: multiplexing; it allows multiple applications to get sensor data without having to contend for a single serial device. Second: coping with the hideous gallimaufry of badly-designed protocols these devices use — regardless of device type, you will get data in a single well-documented format. Third: on operating systems with a hotplug facility (like Linux udev), GPSD will handle all the device management as USB devices are plugged in and unplugged.

What GPSD can’t do is pull fix data out of thin air when your device hasn’t reported any. Nor is it a magic power supply, so its device management has to be designed around keeping the attached sensors open only when a client application actually needs a fix.

As you’ll see, these constraints explain most of the design of the GPSD wire protocol, and of the library APIs your client application will be using.

https://gpsd.gitlab.io/gpsd/client-howto.html

Your gpsd is doing weird things.
It's working for other ppl and you haven't provided tshark outputs or anything really.
Not even the log from readsb.

[wiedehopf]

sudo journalctl --no-pager -u readsb

Let's check the log first, if readsb disconnects it's gonna be in the log.

[marcoculver]

Thanks here is the log

[wiedehopf]

I've updated readsb to accept TPV messages, not sure why i was ignoring those.

Regardless if the above fixes the issue, you can now use --devel=debugGPS to get verbos log of all the comms with GPSD.

[marcoculver]

Here is my tshark output

[wiedehopf]

Have you updated readsb?
And added --devel=debugGPS to the readsb command line options?

After that i'll need just the readsb log from the journal due to the new debug functionality.
Forgot how to tell tshark to show the actual contents of the TCP as well but all that shouldn't be necessary now with debug fucntionality.

[marcoculver]

Thanks I've run the update script. Sorry I'm a noob, how do I add --devel=debugGPS to the readsb command line options?

[wiedehopf]

https://github.com/wiedehopf/adsb-scripts/wiki/Automatic-installation-for-readsb#change-the-configuration

The syntax of the config is clear, make sense of it and add the parameter to any of the existing strings in ""

[marcoculver]

Ah thanks. I'll give it a go 🙏🏼

[wiedehopf]

You could for example modify this line

DECODER_OPTIONS="--max-range 450 --write-json-every 1"

To this line:

DECODER_OPTIONS="--max-range 450 --write-json-every 1 --devel=debugGPS"

[marcoculver]

Thanks very much! I'm going flying just now and I'll give it a go

[wiedehopf]

I'd recommend testing in a car, much easier! ;)

[wiedehopf]

Hey how did this go, is it working now?

[marcoculver]

I never really got it working 100%. Seems I always had to restart the gpsd service for it to update my position. I tried out Stratux and this is the GPS functionality that I need, but their ADSB data lacks a lot of info I want displayed. I'm stuck between the 2

[wiedehopf]

You ran with the debug?
Seeinng a log would help.

[wiedehopf]

Maybe just change your GPS device ....

[wiedehopf]

Other people got it running just fine pretty easily.

[marcoculver]

I'll do a fresh install and try again.. I really want it to work! Thanks for the help so far

[wiedehopf]

Well put the debug option and show the log as instructed.

[kiwibenis]

this is a bug in gpsd < 3.25. if gpsd has a locked position, it is not updating lon/lat/speed ... and maybe more values anymore.
look also here: https://raspberrypi.stackexchange.com/questions/136196/why-does-gpsd-not-update-a-location-past-its-first-fix

you can check your installed gpsd-version with gpsd -V, I suggest it is 3.22

3 possible solutions:

1. wait for debian Trixie with gpsd 3.25 OR
2. use nightly builds of trixie now OR
3. build it from source: https://gpsd.io/building.html#_quick_start

Using backports will not work because Trixie-builds for gpsd are not backported to bullseye/bookworm (by now?)