Raspi, Icom 7200 and GPS, cannot make this combination work

John Schultz

Hello all,

Hoping to get some ideas from the group on an issue I've intermittently attempted to fix and subsequently give up on for the past several months.  I recently reached out to Jason, KM4ACK for assistance and he recommended that I post here for some help.

I am running a Raspi with JS8call on my home station 24x7 (N0JDS and N0JDS/P).  This system has been fully functional and stable using FLRig and JS8call for weeks / months.  The Pi is set up with a real time clock and I would also like to add a GPS dongle to sync time to the RTC.  Pretty straightforward, I have this exact config running on two other systems here at home but, both of those rigs are Yaesu radios.

With this Icom, as SOON as I install the all of the gps utilities attempting to use ttyUSB0 for rig control, I get failure from FLrig or Hamlib to connect to the radio.  To be perfectly clear the dongle for GPS does not need to be plugged in for this failure to occur.  I thought it was a cat port resource conflict however I have attached the results of verifying com port assignment as a photo on this post.  I've also attached the error message I receive.  The radio is assigned ttyUSB0 and the GPS is assigned ttyACM0 so there should not be a conflict.  The only way to restore connectivity to the rig is to completely remove the installed packages for GPS support.

When I sent Jason the results of dmesg he noticed that it appeared that perhaps the radio was being interpreted as an additional time source due to the "pps" information.  That's the first real breakthrough I've had in this situation however, I'm clueless how to proceed with fixing it.

Again, this system was working perfectly for several months with zero issues.  As soon as I attempt to configure GPS the issues begin so it's not a port speed issue, port selection issue, etc... It's something else and I am completely stumped where to begin.

Thanks in advance for any information.


John Schultz

Well as it turns out, that tip from Jason about PPS was the key to the solution. 

I ran CGPS and paid attention closely to what was being displayed at the bottom.  CGPS was not working in spite of the presence of a GPS dongle.  As it turns out, CGPS was attempting to use ttyUSB0 (the radio) as it's source of GPS info. 

So I looked at /etc/default/gpsd and saw that ttyACM0 was correctly identified in that file however USBAUTO was set to "True".  This meant that USB plug in devices other than ttyACM0 were allowed to be added to the GPS daemon.  I flipped that flag to "false" rebooted and everything worked!  So while I do not know why the radio was being detected as a GPS source, constraining the GPS daemon to only allow ttyACM0 is the solution in this case.

In the photos:
CGPS is functioning
NMEA is recognized as a system time source
FLRig is connected to the rig and happy



Had the same issue with IC-7300, the issue is with the configuration of the gpsd.

sudo nano /etc/default/gpsd

verify/edit following entries:


Hit ctl-x y enter

John Schultz

Thanks Kevin,

Yes the key piece of that info is to set USBAUTO to "false".  All of the tutorials set this to "true" and that's where our problems begin.

In fact, I cannot think of a reason why I would want this set to "true" on any of my systems so, I'm resetting that flag to false even on the currently working systems, that way there are no surprises in the future.


John Schultz

The more I contemplate this issue, the more I feel like setting USBAUTO="false" is just a workaround for a different problem.  This does not happen for Yaesu radios, even those that use the same cp210x converter (my FT891 for example).  For some reason our Icom radios are being detected as a source of PPS for GPSD.  Running dmesg|grep -i tty immediately after connecting the rig will reveal that it is showing up as a GPS source.  Immediately after the cp201x converter is attached to USB0 the next line is pps pps1: source .....  This is USB0 (The Radio) being added to the GPSD daemon.  The real fix is figuring out why this happens and how to stop it.

It is possible to remove a specific device from the GPSD device pool from what I can tell.  Scripting this removal may be a better workaround than simply setting USBAUTO to false.  This seems like it would be a better solution since setting USBAUTO to false seems to indicate that if we boot up our system and then plug in the USB GPS device we would have to reboot for detection.  I need to verify this behavior this weekend.

Any thoughts on this issue?