Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPS to readsb #40

Open
marcoculver opened this issue Jun 5, 2023 · 27 comments
Open

GPS to readsb #40

marcoculver opened this issue Jun 5, 2023 · 27 comments

Comments

@marcoculver
Copy link

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"
  1. Tested gps with xgps and it works.
  2. 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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

It doesn't close the connection.

@marcoculver
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

sudo journalctl --no-pager -u readsb

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

@marcoculver
Copy link
Author

Thanks here is the log
Image

@wiedehopf
Copy link
Owner

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
Copy link
Author

Here is my tshark output
Image-2

@wiedehopf
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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

@wiedehopf
Copy link
Owner

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
Copy link
Author

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

@wiedehopf
Copy link
Owner

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

@wiedehopf
Copy link
Owner

Hey how did this go, is it working now?

@marcoculver
Copy link
Author

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
Copy link
Owner

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

@wiedehopf
Copy link
Owner

Maybe just change your GPS device ....

@wiedehopf
Copy link
Owner

Other people got it running just fine pretty easily.

@marcoculver
Copy link
Author

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

@wiedehopf
Copy link
Owner

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

@kiwibenis
Copy link

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants