Migrate Ruby gpsd to Python3

[km4ack]

This may be worth investigating.

see this post

[km4ack]

I wish I could count the number of "small" requests from others that had me beating my head against a wall for days. I'll give it a test run in a bit and let you know what I find. Thanks for the work on this!

[starbasessd]

Helps me learn more about python, so not all bad.

[km4ack]

I hate to be the bearer of bad news :-(

GPS plugged in with fix - Script is good GPS plugged in with no fix - Script errors or hangs as before GPS not plugged in - Script hangs as before

I started with the GPS unplugged. Then I tried plugging in the GPS and running the script before it had a fix. Last thing I tried was waiting for the GPS to get a fix.

Note: I am only waiting about 15-20 seconds before killing the script. Should I wait longer?

With the GPS plugged in but no fix I received these errors: Traceback (most recent call last): File "./pygridsquare", line 41, in findgs() File "./pygridsquare", line 29, in findgs gridsquare = mh.to_maiden(lat, lon) File "/usr/local/lib/python3.7/dist-packages/maidenhead/to_maiden.py", line 23, in to_maiden a = divmod(lon + 180, 20) TypeError: can only concatenate str (not "int") to str

[starbasessd]

OK, several issues: You are not the bearer of bad news, yet, grin.

The problem with 'GPS not plugged in - Script hangs as before' may be that gpsd is installed wherever, is discovered on port 2947, but doesn't realize there isn't a GPS connected. This will entail checking the GPSd config file, and checking for the device. This won't work on a connection to a network server. This may be more effort than what it's worth. For Sanity check, IMO GPSd shouldn't make itself available if there isn't a GPS it can talk to.
This program assumes you wouldn't be using it if:

You don't have any GPS receivers (network or local) running (Should come back and say "NO GPS") Your server (network or local) you want use is isn't available for whatever reason

Will check the Plugged in but no fix errors. I wonder why it thinks you are trying to concatenate when it looks like it is trying to add 180 to the reported longitude...

I'll try a new setup here in a bit. Gotta dig out another USB GPS.

[starbasessd]

What do you have for /etc/default/gpsd ?

[km4ack]

#The -b switch was added per https://github.com/km4ack/pi-build/issues/144
#km4ack 24SEPT2020

# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time
START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="false"

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_7_-_GPS_GNSS_Receiver-if00"

# Other options you want to pass to gpsd
GPSD_OPTIONS="-n -b"

[starbasessd]

For DEVICES= I use /dev/ttyACM0 for GPSD_OPTIONS= I use "-n -G" Your GPSD_OPTIONS negates read/writeable... Hmmm...

[km4ack]

the -b switch is due to this issue https://github.com/km4ack/pi-build/issues/144

[km4ack]

I changed my GPSD_OPTIONS to match yours and get the same results. The /dev/serial/by-id is symlink to /dev/ttyACM0 so that shouldn't matter.

[starbasessd]

I'm doing an almost complete re-write (at least as far as logic is concerned) will be back in a bit...

[starbasessd]

Changing modes: Date night for son & dil, I get to watch the grandsons, so resuming tomorrow...

[starbasessd]

New Situation: Pi3B+, Bullseye, fully updated. GPSD & GPSD tools installed from repo, version 3.22 Python 3 3.9.2 Fired up after a day off. cgps reports 3D fix, & time (compared to my GPS Time server is correct). Lat & Lon report 0.00N & 0.00E, Alt shows 0.00 Reboot, same. sudo systemctl restart gpsd cgps now shows correct Lat & Lon & Alt reboot back to 0.00, 0.00, 0.00 Repeatable. Thoughts? This is playing havoc with testing the gridsquare script.

[km4ack]

Take a look at your /etc/default/gpsd file. With USBAUTO set to false, the GPS isn't hot swappable. BAP does this by design as when this is set to true, it can cause Icom rigs not to work correctly with cat control. As such, you have to restart the gpsd service each time you plug in the GPS if it isn't plugged in at boot.

[starbasessd]

That's the weird thing. I didn't unplug the GPS, just reboot. USBAUTO is set to true. Will flip it to false in a bit and test. Also my 'sanity' check is valid. You can't plug in the GPS and expect it to work without at least a sudo systemctl restart gpsd Your previous:

I hate to be the bearer of bad news :-(

GPS plugged in with fix - Script is good GPS plugged in with no fix - Script errors or hangs as before GPS not plugged in - Script hangs as before

I started with the GPS unplugged. Then I tried plugging in the GPS and running the script before it had > a fix. Last thing I tried was waiting for the GPS to get a fix.

Wouldn't be a valid usable status for options 2 & 3 without something else to update the USB connection.

Getting more caffeine and another skull session...

[starbasessd]

I have to make some sanity assumptions: You won't be running this if you don't have a USB GPS receiver. You won't be running this if you don't have it attached. You won't be running this if you haven't installed gpsd, gpsd-tools, and the python modules, gps3 gpsdclient, and maidenhead. I got knee deep in the dead (Doom game reference) with trying to figure out how to detect if the USB GPS device is even connected without much consistent luck. You might be able to write a bash wrapper, but... It's like running some of the Ham Software, expecting it to work in all conditions, it doesn't. Attached are the latest instructions: PyGetGridsquare.txt

[km4ack]

I agree with the sanity checks. However, in order to incorporate this into BAP the script can't hang when a GPS isn't attached. Suppose I install the GPS stuff with BAP and typically run a GPS. However, for a particular outing, I forget/damage the GPS. If the script hangs, then a new instance of the script will be created every time Conky or cron calls it trying to update the grid. This will result in multiple instances of the hung script running. Can the script at least exit with no results after 5-10 seconds of not being able to read the GSP data? If not, we can put the code on GitHub and link to it in the forum for users that need network GPS and understand the potential downside.

[starbasessd]

The latest script doesn't work with network GPS. (at least yet, it wasn't a priority since you were having issues with local USB GPS). This version goes through 5 times maximum and then exits. If it finds a No Fix, 2D Fix, or 3D fix, it reports that. If it goes 5 times, it reports NO DEVICE I was over-engineering it. Try it and report please. Needs a new piece of pip install, though...

[starbasessd]

If this works as expected, I'll work on modifying for Network & Local.

[starbasessd]

Nevermind. The hangup isn't in my code, it's in the module(s) I'm using. They hang due to they figure you have a GPS attached, and want to use it, and wouldn't call if you didn't.

[starbasessd]

This is why I am a Help Desk person and not a programmer...

[starbasessd]

New try: Checks for gpsd installed (via /etc/default/gpsd)     exits with message "GPSD_ERR" to conky and "GPSD Not Installed" to stdout Checks for a device set (via DEVICES="/dev/..." in /etc/default/gpsd)     exits with message "GPSD_ERR" to conky and "GPSD DEVICES= not set in /etc/default/gpsd" Goes through trying to parse gpsd data 5 times.
If it fails all 5 times, reports "NO DEVICE" to conky and exits
If it gets mode = "n/a" it reports "NO GPS" to conky and exits
If it gets mode = "1" it reports "NO FIX" to conky and exits
If it gets mode = "2" it reports "2D FIX" to conky and exits
If it gets mode = "3" it reports the GridSquare to conky and exits
PyGetGridsquare.txt

[starbasessd]

Sorry in all my cutting and pasting, I missed the first line of the PyGetGridSquare.py:

!/usr/bin/python3

Will correct when someone tests it.

[starbasessd]

Further testing, further update. I started with a clean Bullseye on Pi3B+ sudo apt update && sudo apt upgrade -y sudo raspi-config # password, hostname, locale, timezone, etc... reboot check python & pip version python3 --version # 3.9.2 pip3 --version # not installed sudo apt install python3-pip -y sudo pip3 install gpsdclient maidenhead gps3 Created script sudo nano /usr/bin/PyGetGridsquare.py copied script from attached instructions saved and make executable sudo chmod +x /usr/bin/PyGetGridsquare.py reboot First test, gpsd not installed reports GPSD_ERR to conky and GPSD Not Installed to stdout gpsd installed, DEVICES= not configured reports GPSD_CONF to conky and GPSD DEVICES= NOT CONFIGURED to stdout If all is installed and USB disconnected reports GPS_ERR to conky, and NO GPS DATA to stdout If all is connected, will report NO FIX, 2D FIX or GRIDSQUARE to conky & nothing or gridsquare to stdout. PyGetGridsquare.txt

[km4ack]

Thanks for the update. It's going to be next week at the earliest before I can play with it. I'll let you know how I make out.

73, de KM4ACK

[starbasessd]

Status?

[SpudGunMan]

Apt Package python3-gps, gpsd-tools, might be interesting? As well as gpsd-clients