[Feature Request] Implement GPS-Module support

[MiBatu]

Hi Ketil,

Based on my experience with Stratux receiver, I thought it might be useful to add GPS module support to your project.
For example VK172 USB or similar module for GPS/GLONASS. It cost ±5$ and gives mobile users, who use run receiver from a car or vessel, flexibility with GEO Variables. No need to set LAT and LON if GPS module detected on the device.

B.R.
Michael

[ketilmo]

Thanks for your input, @MiBatu!

[DanBuBerlin]

Hi,

heres a good work around

https://gist.github.com/hsiboy/a24933ec63c004d10e2377d93aae80f6

Daniel

[janipewter]

Is there any update on this?

[ketilmo]

Thanks for reaching out, @janipewter.

Not at this stage, as I still need to get a suitable GPS device to implement this functionality.

[shawaj]

I have been looking into this a little bit as I have one of the cheap GPS receivers in question.

The issue I think is going to be that dump1090-fa does not support a GPS input net connector. Whereas readsb does support --net-connector localhost,2947,gpsd_in - ref

So whilst it is possible to get GPS location to work with some services (the ones that are using readsb here and a couple custom ones), there are some things to consider before adding this:

• we have to expose /dev/ttyACM0 to each service container. As not all people will be using GPS, this means that any containers we want to sort GPS for will need to use privileged: true unless there is a balena workaround for this that I'm not aware of
• i think piaware, rbfeeder can use the GPS
• services using readsb (adsbexchange, wingbits) can use the GPS
• I don't believe fr24feed, planefinder or opensky can use the gps

So adding gpsd support is fairly simple, it's just a case of whether to do so, it is ok to make piaware, rbfeeder, adsbexchange and wingbits containers privileged?

[ketilmo]

Thanks for the writeup, @shawaj! This is very interesting and something we should consider if it gives enough value/solves a given use case. The announced changes at Wingbits might make something like this (or similar) highly relevant. Another question that arises: Should we consider a move to readsb? It seems alive as a project, with a steadily increasing feature set. Again, thanks for all your efforts on this.

[shawaj]

Just had an idea here... One other useful feature could be that if you have the USB it updates the LAT/LON/ALT environment variables for you as well

[kanokc]

I shared my ADSB data with FlightAware, FightRader24 and ADSB Exchanged from a P3+ with GPS Hat for over 2 years. The GPS hat also provides time source and PPS for this RPi as a NTP sources on my house.

Moving to Balena-ads-b to be able to share to Wingbits. And found that the GPS no longer works.

I'm not good at Docker and Balena is very new to me but willing to help troubleshooting the implementation.

Thanks.

[shawaj]

Thanks @kanokc

I've got a few ideas on how this can work I just need to find some time to implement it

Your help with testing would be appreciated though

[kanokc]

@shawaj This Balena project might be a good start for getting GPS data off the receiver and use gpsd to translate into useful information eg. time inc PPS, LAT, LONG, ALT
https://github.com/nmaas87/gpsTime

Update:
I have had more success implementing this project than the above. Now the GPS hat is running and I can see the gpsd providing the coordinates and time. ntp also acts as timesource and allows other ntp clients to sync to. I believe what we need now is to provide the GPS data to service needed.
https://github.com/misterpeee/balena-gps-ntpsecd

[Nekstad]

Upvoting this initiative! 💯

GPS support would be essential for positioning antennas close to major events (search and rescue operations, forest fires, etc.) without requiring technically skilled individuals to modify configurations.

One use case could be journalists in the field, who often have vehicles equipped with mobile internet, antennas, extra batteries, etc., and who could contribute to improved coverage of relevant news events with an antenna.