Again only replying to questions to not be too confusing with indentation issues.
> Nothing we can do about that. A lot of these weird serial drivers are
> broken. That means gpsd init will fail. And it did. Which is why your
> device ends up in NMEA 0183 mode.
So if it ends up in NMEA 0183 mode is that a bad thing? When I run gpsd directly connecting to the ublox device, things seem good. When I run ntpshmmon I am getting samples written to the shared memory segment and the time on the box gets set correctl (running "data" is correct to the second). So even if gpsd init fails, it soldiers on. So what does "broken" mean. gpsd seems to do "enough" to get things working. Even if the serial driver is "broken", which isn't a good thing I agree, it doesn't seem to hamper the functionality of gpsd or does it? I attached a debuginfo file which pulls some of the output of the script gpsdebuginfo that I pulled down off the site when running gpsd in the direct scenario.
> We can't really support that usage. Unless you setup the receiver
> in a way that gpsd can use it, your results will be marginal. Too many
> variables out of our control.
I get that this is not a normal situation and that you can't support it. I am not asking to have it supported. I am just curious as to why it would not work.
What setup is done to the receiver by gpsd so it can use it? I see the file driver_ubx.c. Does that contain all of the setup that is done? Specifically the ubx_cfg_prt() function. If we are able to mimic what is done to configure the device and then simply forward all the messages to gpsd, why wouldn't gpsd be happy? I guess I am having a hard time understanding why. Not to be argumentative, just curious. Because things seem to work when gpsd is directly connected to the device. And once it is up and running and processing messsages, I can run gpspipe and see raw nmea messsages.
Speaking of nmea messages, when I search through the debug output (-D4 -D5 -D6) generated when running directly connected, I see GSV, GGA, GLL, GSA, RMC, VTG and GSV sentences being processed by gpsd. I don't see any other messages that are being processed. Are these the messsages that gpsd relies on?
> And what driver creates a /dev/TTPS1 ?? Clearly problems there.
Typo. Should be /dev/ttyPS1. This is the physical device (uart) on our processor that has been wired to communicate with the GPS device.
> gpsd knows nothing of pseudo-terminals.
Does gpsd assume anything about the device you send it? I didn't think it mattered. So if I create "/dev/ttyGPS0" and link it to the pseudo-terminal that gets created by calling openpty, write messages to "/de/ttyGPS0" and run gpsd using "/dev/ttyGPS0" why wouldn't gpsd be able to read the messages that are written to it. Before you indicated we should not used the "-b" option when starting gpsd. However in our indirect scenario it makes sense to use the "-b" if we have another process configuring the device. Do I misunderstand the usage of "-b"?
> Why bother with a link?
A link is created so the underlying pseudo terminal is hidden from the software. The software can refer to the same name even if openpty gives different results. Provides portability.
Also nothing I see indicates to my why the ntpshm_link_1_activate link is not getting set to "1" which you indicated is why the shared memory segment is not getting set. Maybe you can point me to a place in the code that could help me out.
I appreciate you keeping up with the questions. It is really helpful.
debuginfo.TXT