gpsd has a goal of finding the GPS receiver when it is attached to your system invisibly and providing data via a network port so an application doesn’t have to worry about what kind of receiver, its particular protocol, or how it’s connected. Doing that is a can of worms.
The current most common method for connecting a GPS receiver to a computer is via a serial port that runs through a serial to USB converter. That converter is usually a single chip and it shows up as a USB TTY device. When UDEV sees such a device, it looks in /lib/udev/rules/60-gpsd.rules to see if gpsd should be launched to check it out. That rules file is installed with gpsd. What is interesting is that both the Prolific Technology, Inc. PL2303 and the FTDI 8U232AM / FT232 are “disabled in Debian as it matches too many other devices”
That’s why that cable didn’t work to get the serial output from the GPS module. It would work if I was using the USB port on the module itself as that’s U-Blox but doing the serial to USB off the module pins with a Prolific based patch cable didn’t. So I removed the comment indicator at the beginning of the rule and, whatdoyouknow?, it works. On ttyUSB1 no less.
The lesson out of this is that gpsd is most likely to find a GPS receiver on a USB port if you use the converter chip that comes with the receiver. Using a couple of the most common serial to USB converter chips is going to need some rules adjusting.
I bought a couple of simple converters that are intended for microcontroller access. While the ESP8266 boards I have, a NodeMCU and a Wemos D1, both have onboard USB and the handshake lines that can be used to put the ESP8266 into firmware download mode, I still needed the simple converts to examine the debug output from the second, output only, ESP8266 UART. I am also using one of them so I can monitor the GPS receiver output via the RY835AI pins to see what I2C configuration from the ESP8266 is doing. I don’t want to use the USB port on the RY835AI because it would supply power to the module and I want the module to get its power from the microcontroller board.
The next question is why all the fuss about gpsd? The NTP stratum 1 server will be able to do a lot more than just dish out time based on GPS clocks. One option is to serve up the data on a web page. Another option is to stream it out a network port compatible with the gpsd schema. So I need to understand gpsd. Next on that process is going to be some Python gpsd client code experiments.