Tried cgps, also no go. xgps, nothing. I wonder what could have gone wrong.tcp://localhost:2947 JSON slave driver>
(84) {"class":"VERSION","release":"3.16","rev":"3.16-4","proto_major":3,"proto_minor":11}
(111) {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyAMA0","activated":"2018-09-21T04:
36:29.566Z"}]}
(122) {"class":"WATCH","enable":true,"json":false,"nmea":false,"raw":2,"scaled":false,"timing":false,"s
plit24":false,"pps":true}
GPS HAT not able to run gpsmon or cgps
Moderators: adafruit_support_bill, adafruit
Forum rules
Talk about Adafruit Raspberry Pi® accessories! Please do not ask for Linux support, this is for Adafruit products only! For Raspberry Pi help please visit: http://www.raspberrypi.org/phpBB3/
Talk about Adafruit Raspberry Pi® accessories! Please do not ask for Linux support, this is for Adafruit products only! For Raspberry Pi help please visit: http://www.raspberrypi.org/phpBB3/
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
GPS HAT not able to run gpsmon or cgps
I followed the tutorial on adafruit's website. I first tested the NMEA stream and it worked. With external antenna I can get quick fix. Then I disabled gpsd.socket as instructed and then attached the daemon to serial port as instructed. Then I tried gpsmon, no go:
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
I removed gpsd and gpsd-clients, reinstalled. Tried the NMEA stream, working. Did the service disable, then gpsd command, and no go with gpsmon, same errors.
- adafruit_support_mike
- Posts: 67446
- Joined: Thu Feb 11, 2010 2:51 pm
Re: GPS HAT not able to run gpsmon or cgps
What kind of RasPi are you using?
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
3b+ with raspbian from April. I could do apt upgrade but your tutorial is from 2013.
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
I haven't tried but I hope even with the busted gpsd I can still use python to get the coordinates. Is the python library relying on the gpsd? I do have a fallback plan but this seems to be wasting money and time if it doesn't work with the most recent raspberry pi so my hope is that I'm mistaken and solutions are not too hard.
- adafruit_support_mike
- Posts: 67446
- Joined: Thu Feb 11, 2010 2:51 pm
Re: GPS HAT not able to run gpsmon or cgps
Have you reconfigured the Pi3B+ so its GPIO Serial interface will work?
The RasPi only has one real UART, and versions with a built-in Wifi/BLE module default to connecting the UART to that. There's another software-based UART that gets connected to the GPIO Serial pins, but its baudrate is derived from the CPU clock. That would be fine, but Raspbian also defaults to changing the cpu clock speed depending on the processing load.. slowing it down when the system is idle to save power, and speeding it up when the load is high to keep the system responsive. Every time that happens, the software UART's baudrate changes.
By default, the GPIO Serial port on RasPis with built-in Wifi is useless.
This page from the RasPi Foundation describes the situation in more detail, and has options you can use to make the GPIO Serial port work again;
https://www.raspberrypi.org/documentati ... on/uart.md
The RasPi only has one real UART, and versions with a built-in Wifi/BLE module default to connecting the UART to that. There's another software-based UART that gets connected to the GPIO Serial pins, but its baudrate is derived from the CPU clock. That would be fine, but Raspbian also defaults to changing the cpu clock speed depending on the processing load.. slowing it down when the system is idle to save power, and speeding it up when the load is high to keep the system responsive. Every time that happens, the software UART's baudrate changes.
By default, the GPIO Serial port on RasPis with built-in Wifi is useless.
This page from the RasPi Foundation describes the situation in more detail, and has options you can use to make the GPIO Serial port work again;
https://www.raspberrypi.org/documentati ... on/uart.md
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
Thanks. I disabled BT and gpsmon works now. In your tutorial, which seems outdated, it didn't mention disabling BT.
Anyway, what do these commands do?
They are on "use 'gpsd'" page towards the end. I don't know why they have to be issued. Do I need to include the second command in rc.local? I'll test python with gpsd too.
Anyway, what do these commands do?
Code: Select all
sudo killall gpsd
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
- adafruit_support_mike
- Posts: 67446
- Joined: Thu Feb 11, 2010 2:51 pm
Re: GPS HAT not able to run gpsmon or cgps
We have to get into the details of how operating systems handle programs for a useful answer.
A chunk of potentially executable instructions stored on a RasPi's SD card is known as a 'program', or more formally as 'the text'. The text doesn't do anything until the OS loads it into RAM, allocates memory for its data structures, and creates some other data structures that let the OS control execution of the text. That whole collection of allocated memory and OS data structures is called a 'process'.
In 'nix-based operating systems, there are two ways to turn text into a process. The first is for some process that's already running to call the function exec(), which loads the text into memory and lets that take over execution in that process. The second is for a process that's already running to call the function fork(), which creates an identical copy of the original process called a 'subprocess'. The only difference between the original process and the subprocess is some data pasted into the copy's memory space as the OS makes the copy.
The traditional way to run programs involves some neutral process like a shell calling fork() to create a new subprocess, then having the subprocess call exec() to run the specified code.
The OS keeps track of the relationship between processes that call fork() and the copies that are created. Every process whose creation traces back to a series of fork()s from some original process is called a 'process group'. The first program that runs on any 'nix-based system is called `init`, and every process running on the machine is in that process group.
Programs like `gpsd` fork subprocesses to handle communication with the hardware.
The command `kill` tells the OS to do something to a specific process. If you use `kill -9` or `kill -TERM` it tells the OS to stop running the selected process, release all the allocated memory, and tear down any data structures the OS uses to handle communication with the process.
Calling `kill -9` on a process like `gpsd` will shut down that specific process, but it won't do anything about all the subprocesses it created to handle side jobs. Those subprocesses will sit around in memory, waiting to talk to a parent process that no longer exists.
The command `killall` tells the OS to shut down a whole process group, which will get `gpsd` and all its subprocesses. That's the correct way to shut down that kind of process.
The command:
tells the OS to create a process for `gpsd`. The first option, '/dev/ttyAMA0' tells `gpsd` where to find a serial connection that will feed it NMEA sentences. The second option '-F /var/run/gpsd.sock' tells `gpsd` to create an object known as a 'unix socket' named 'gpsd.sock' in the directory '/var/run'.
Unix sockets allow different programs to communicate with each other.
One of the core design principles of unix and all its 'nix-based descendants is "everything is a file." The early designers realized that the code necessary to read data from some kind of permanent storage (at the time, probably a tape) could be generalized to handle all kinds of other communication. A keyboard is an external hardware device just like a tape reader, so why not bring information from the keyboard into the system the same way we bring data in from a tape?
At an even more basic level, reading information from a file is really a way to make one process (the one that wants to read or write the file) communicate with a different process (the one that reads and writes data to/from the tape). You can use exactly the same mechanism to make any two processes communicate with each other, and you can use a named object in the filesystem as the interface to one of the processes.
When you run a program like `cgps`, that process tells the OS to create data structures that handle communication between `cgps` and whatever process controls the filesystem object 'var/run/gpsd.sock'.
A chunk of potentially executable instructions stored on a RasPi's SD card is known as a 'program', or more formally as 'the text'. The text doesn't do anything until the OS loads it into RAM, allocates memory for its data structures, and creates some other data structures that let the OS control execution of the text. That whole collection of allocated memory and OS data structures is called a 'process'.
In 'nix-based operating systems, there are two ways to turn text into a process. The first is for some process that's already running to call the function exec(), which loads the text into memory and lets that take over execution in that process. The second is for a process that's already running to call the function fork(), which creates an identical copy of the original process called a 'subprocess'. The only difference between the original process and the subprocess is some data pasted into the copy's memory space as the OS makes the copy.
The traditional way to run programs involves some neutral process like a shell calling fork() to create a new subprocess, then having the subprocess call exec() to run the specified code.
The OS keeps track of the relationship between processes that call fork() and the copies that are created. Every process whose creation traces back to a series of fork()s from some original process is called a 'process group'. The first program that runs on any 'nix-based system is called `init`, and every process running on the machine is in that process group.
Programs like `gpsd` fork subprocesses to handle communication with the hardware.
The command `kill` tells the OS to do something to a specific process. If you use `kill -9` or `kill -TERM` it tells the OS to stop running the selected process, release all the allocated memory, and tear down any data structures the OS uses to handle communication with the process.
Calling `kill -9` on a process like `gpsd` will shut down that specific process, but it won't do anything about all the subprocesses it created to handle side jobs. Those subprocesses will sit around in memory, waiting to talk to a parent process that no longer exists.
The command `killall` tells the OS to shut down a whole process group, which will get `gpsd` and all its subprocesses. That's the correct way to shut down that kind of process.
The command:
Code: Select all
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
Unix sockets allow different programs to communicate with each other.
One of the core design principles of unix and all its 'nix-based descendants is "everything is a file." The early designers realized that the code necessary to read data from some kind of permanent storage (at the time, probably a tape) could be generalized to handle all kinds of other communication. A keyboard is an external hardware device just like a tape reader, so why not bring information from the keyboard into the system the same way we bring data in from a tape?
At an even more basic level, reading information from a file is really a way to make one process (the one that wants to read or write the file) communicate with a different process (the one that reads and writes data to/from the tape). You can use exactly the same mechanism to make any two processes communicate with each other, and you can use a named object in the filesystem as the interface to one of the processes.
When you run a program like `cgps`, that process tells the OS to create data structures that handle communication between `cgps` and whatever process controls the filesystem object 'var/run/gpsd.sock'.
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
OK, that was pretty details. Thanks. So command one kills all gpsd-related processes for command two to have a clean start that takes serial port NMEA sentences to function. So my second question is: do I need to do these commands in rc.local or will command two cause gpsd to save this configuration for subsequent reboot?
- adafruit_support_mike
- Posts: 67446
- Joined: Thu Feb 11, 2010 2:51 pm
Re: GPS HAT not able to run gpsmon or cgps
You'll need to execute those every time you restart the RasPi.
To disable the default `gpsd` across power cycles, use this command:
To disable the default `gpsd` across power cycles, use this command:
Code: Select all
sudo service gpsd stop
- liudr
- Posts: 121
- Joined: Sat Jan 15, 2011 11:08 pm
Re: GPS HAT not able to run gpsmon or cgps
Mike,
Thank you so much! it works. I can run gpsmon right after booting now, just what I was trying to do. With an active antenna, I can get 10 satellites.
By the way, anyway you can stock up some active antennas with much shorter cable? Routing the cable inside my tight enclosure is pretty difficult and it takes away a lot of space. In another project I drilled a hole to bring the SMA connector out but I don't think it's waterproof.
Thank you so much! it works. I can run gpsmon right after booting now, just what I was trying to do. With an active antenna, I can get 10 satellites.
By the way, anyway you can stock up some active antennas with much shorter cable? Routing the cable inside my tight enclosure is pretty difficult and it takes away a lot of space. In another project I drilled a hole to bring the SMA connector out but I don't think it's waterproof.
- adafruit_support_mike
- Posts: 67446
- Joined: Thu Feb 11, 2010 2:51 pm
Re: GPS HAT not able to run gpsmon or cgps
Glad to hear things are working for you.
I'll mention powered antennas with shorter cables to the products team.
I'll mention powered antennas with shorter cables to the products team.
Forum rules
Talk about Adafruit Raspberry Pi® accessories! Please do not ask for Linux support, this is for Adafruit products only! For Raspberry Pi help please visit: http://www.raspberrypi.org/phpBB3/
Talk about Adafruit Raspberry Pi® accessories! Please do not ask for Linux support, this is for Adafruit products only! For Raspberry Pi help please visit: http://www.raspberrypi.org/phpBB3/