"Interesting part. Why did you pick it?"
I chose this dev board that uses the UM220-III NL chip because it speaks the mostly universal NMEA-0183 protocol (I've provided examples of it's output in previous messages), feeds that over RS232 (and I later found +3.3VDC TTL/CMOS or whatever) and provides 1PPS (500ms wide) timed on the GPS radio signal. It was also a good price online and came with a GPS antenna for about USD$20. I bought two module/antenna pairs, and with shipping it came to about $60 with a two week wait from China.
The single module is connected to two devices at the same time.
One device (CentOS workstation) uses RS232 w/ 1PPS on DCD.
The other device is the RPi 3 B+ which uses the hardware UART on the GPIO pins and 1PPS on GPIO_04 (at the moment, I've been trying different pins.)
I see nothing wrong from an electrical standpoint with this configuration.
"What are those asterisks doing there? That looks very wrong."
As far as the mystery " * " in my commands, not sure where those came from. They are not the original commands I ran and were not part of the output I provided in my e-mails.
Regarding this...
"That is just plain wrong. Take a look at the RS-232 spec... "
My understanding of RS232 is sound enough to know that the webpage I referenced is technically correct and sufficient for describing what I am trying to discuss. I will say that perhaps I shouldn't have mentioned RS232 just yet since we are talking about an RPi 3 B+?
"console is wrong: "
Every write-up I am finding is saying that we must detach the console process from the serial port in order for this GPSD->NTPD thing to work correctly. What you are providing me appears to re-enable the console process on /dev/ttyAMA0? Additionally, I believe one needs to remove "
kgdboc=ttyAMA0,9600" from their cmdlines.txt as well.
Per ESR -
"Only two specific changes need to be made to make the HAT work. First in the file /boot/cmdline.txt, remove this part "console=ttyAMA0,115200 kgdboc=ttyAMA0,115200". That frees the serial port from console use so
the GPS can use it."
"Looks good. But still no evidence the serial is working."
I think I've provided examples of the serial data driven output of gpsd in my previous e-mails. Everything is working. I can cat the port, load up gpsmon and get 1PPS pulses in addtion to NMEA sentences, and all the other etc...
"OK, but I also have this:
dtoverlay=pi3-miniuart-bt
Are you sure your ttyAMA0 is working without it?"
dtoverlay=pi3-miniuart-bt
Are you sure your ttyAMA0 is working without it?"
Whoops, yes I have that in there too.
For notes, here's an interesting thread about that function.
"Neither have the correct time. Which points, again, to your GPS."
Gary, you're saying that my GPS device doesn't have a time fix? I find that unusual. Here's why.
I've described two ways to interface with the serial data coming out of the GPS module. I am using both, at the same time.
One way is via RS232 to a serial port. This is what I am using on my CentOS 7 box.
Hang in there with me while I explain why I'm mentioning this machine.
The other way is via the TTL out on the GPS module itself. Because of the way the pin headers are wired, I can drive the Pi 3 B+ AND a RS232 serial port at the same time from this one module using different voltages.
I use the +3.3VDC for the Pi and RS232 for my workstation. What this demonstrates is that both devices should be receiving the exact same serial data AND 1PPS signals (RS232 DCD on CentOS box and GPIO_04 on RPi 3 B+).
With me so far?
What this configuration allows me to do is compare how different versions of GPSD on different distros, kernels, and architectures work. Super useful, yes?
So going back to the GPS bad time thing, here's a copy/paste from my CentOS 7 box that is using the exact same serial and 1PPS data as the RPi 3 B+...
address@hidden ~]$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.28.1 .PPS. 0 l 5 8 377 0.000 -0.069 0.008
+129.6.15.30 .NIST. 1 u 10 16 377 46.968 0.587 2.687
+132.163.97.4 .NIST. 1 u 10 16 377 59.459 2.123 2.336
Since I've been monkeying with it during the course of this RPi testing, I've seen the offset vary more wildly, probably from rebooting and un/plugging things, but I've had this thing rocksolid to +/- 5uS when I thermally isolate it from the room it is in.
I believe this shows that ntpd is preferring my 1PPS clock to NIST's servers. Pretty cool. I don't believe this would work using this configuration if my GPS module didn't have valid, accurate, and precise time.
Futher, please see the following (sent earlier) from the RPi 3 B+:
gpsd:PROG: KPPS:/dev/pps0 assert 1532034832.977119719, sequence: 2151, clear 0.000000000, sequence: 0 - using: assert
gpsd:PROG: KPPS:/dev/pps0 Assert cycle: 1000028, duration: 0 @ 1532034832.977119719
gpsd:PROG: PPS:/dev/pps0 Assert cycle: 1000028, duration: 0 @ 1532034832.977119719
gpsd:PROG: PPS:/dev/pps0 Assert ignored missing last_fixtime <- where does this value "last_fixtime" come from?
gpsd:PROG: GNRMC sentence timestamped 211353.00.
gpsd:PROG: GNRMC starts a reporting cycle.
gpsd:PROG: GNGGA sentence timestamped 211353.00.
gpsd:PROG: GNGLL sentence timestamped 211353.00.
gpsd:PROG: GNGLL ends a reporting cycle.
gpsd:PROG: xxGSA sets mode 3 (*notice in the below example that these lines are different?)
gpsd:PROG: xxGSA sets mode 3
gpsd:PROG: Partial satellite data (1 of 3).
gpsd:PROG: Partial satellite data (2 of 3).
gpsd:INFO: PRN= 5 az=254 el=79 (-0.183417, -0.052594, 0.981627)
gpsd:INFO: PRN= 6 az= 67 el=25 (0.834261, 0.354123, 0.422618)
gpsd:INFO: PRN= 9 az= 43 el= 9 (0.673602, 0.722350, 0.156434)
gpsd:INFO: PRN= 12 az=232 el=42 (-0.585606, -0.457526, 0.669131)
gpsd:INFO: PRN= 13 az=163 el=16 (0.281046, -0.919259, 0.275637)
gpsd:INFO: PRN= 17 az=131 el= 6 (0.750575, -0.652465, 0.104528)
gpsd:INFO: PRN= 19 az=125 el=27 (0.729870, -0.511060, 0.453990)
gpsd:INFO: PRN= 25 az=287 el=31 (-0.819713, 0.250611, 0.515038)
gpsd:INFO: PRN= 29 az=318 el=15 (-0.646331, 0.717823, 0.258819)
gpsd:INFO: PRN=172 az=322 el=36 (-0.498081, 0.637514, 0.587785)
gpsd:INFO: Sats used (10):
If we convert everything, we can see that the epoch time of 1532034832.977119719 converts to Thursday, July 19, 2018 9:13:52.977 PM.
The GNRMC, GNGGA, GNGLL messages all agree that UTC local time is 21:13:53 (9:13:53 PM EST).
The GPS and PPS assert times match and are correct for my location.
Something that is really interesting in all of this is that I can "apt -y install" the "official" gpsd from the Raspbian repo and I get PPS assert accepted messages and can use that info in the "official" Raspbian NTPd, just everything isn't ticking as accurately as I'd like.
Thanks for your time, let me know if you have any questions.
Chris S