GPS data not acquiring data

[Falcon-118]

Hi Kreeblah, Is there something missing in your build doc? Although I am not well versed in GPS, I can navigate linux well enough to follow your (well written) build doc. I have followed each and every step several times now and never get to past "#? PPS". I originally started this on a RPi 3b+ but acquired a new RPi 4b 2gb just for this build. Still no data. I had an Adafruit external Active GPS antenna, but at your document's recommendation picked up a u-Blox ANN-MB-00 SMA atenna. Still no data. My original Uputronics hat was a ver. 6.1 but to be sure your build wasn't version specific I ordered a new ver. 6.3 hat. When I run "chronyc sources"

`root@RPi4-NTP-GPS:~# chronyc sources MS Name/IP address Stratum Poll Reach LastRx Last sample

? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns

? NMEA 0 4 0 - +0ns[ +0ns] +/- 0ns

^? time-d-wwv.nist.gov 1 6 3 47 +96ms[ +96ms] +/- 39ms`

I installed the gpsd-clients and cgps shows no satellites locked. The right side of the screen is locked.

` ┌───────────────────────────────────────────┐┌──────────────────Seen 0/Used 0┐ │ Time: n/a (0) ││GNSS PRN Elev Azim SNR Use│ │ Latitude: n/a ││ │ │ Longitude: n/a ││ │ │ Alt (HAE, MSL): n/a, n/a ││ │ │ Speed: n/a ││ │ │ Track (true, var): n/a deg ││ │ │ Climb: n/a ││ │ │ Status: NO FIX (0 secs) ││ │ │ Long Err (XDOP, EPX): n/a , n/a ││ │ │ Lat Err (YDOP, EPY): n/a , n/a ││ │ │ Alt Err (VDOP, EPV): n/a , n/a ││ │ │ 2D Err (HDOP, CEP): n/a , n/a ││ │ │ 3D Err (PDOP, SEP): n/a , n/a ││ │ │ Time Err (TDOP): n/a ││ │ │ Geo Err (GDOP): n/a ││ │ │ ECEF X, VX: n/a n/a ││ │ │ ECEF Y, VY: n/a n/a ││ │ │ ECEF Z, VZ: n/a n/a ││ │ │ Speed Err (EPS): n/a ││ │ │ Track Err (EPD): n/a ││ │ │ Time offset: n/a ││ │ │ Grid Square: n/a ││ │ └───────────────────────────────────────────┘└─────────────────────────────────┘

{"class":"VERSION","release":"3.22","rev":"3.22","proto_major":3,"proto_minor":14} {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyAMA0","activated":"2023-09-05T23:02:14.992Z","native":0,"bps":115200,"parity":"N","stopbits":1,"cycle":1.00}]} {"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}`

I do wonder about the "nmea"; false in the above output, which is text below the table from the "cgps" command.

Of your troubleshooting steps, the only response I get is to 'ppstest"

root@RPi4-NTP-GPS:~# ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1693955964.995519098, sequence: 1042 - clear 0.000000000, sequence: 0 source 0 - assert 1693955965.995516956, sequence: 1043 - clear 0.000000000, sequence: 0 source 0 - assert 1693955966.995516222, sequence: 1044 - clear 0.000000000, sequence: 0 source 0 - assert 1693955967.995515746, sequence: 1045 - clear 0.000000000, sequence: 0 source 0 - assert 1693955968.995516684, sequence: 1046 - clear 0.000000000, sequence: 0 source 0 - assert 1693955969.995515683, sequence: 1047 - clear 0.000000000, sequence: 0 source 0 - assert 1693955970.995515367, sequence: 1048 - clear 0.000000000, sequence: 0 source 0 - assert 1693955971.995515328, sequence: 1049 - clear 0.000000000, sequence: 0 source 0 - assert 1693955972.995515660, sequence: 1050 - clear 0.000000000, sequence: 0

On running i2cdetect -y 1 I do see that the 52 in 2x50 gets replaced with the "UU" indicatig the kernal driver is loaded.

So It seems the antenna is just not communicating. I'm not sure if I'm looking at the wrong device but if I try to "cat /dev/ttyAMA0" I just get garbage output... indicative of a speed mismatch. If I run "sudo stty -F /dev/ttyAMA0 115200" I see what looks like GPS reads mixed with 100 or so of NEMA error 46. This repeats .

$GNRMC,010449.00,A,3859.62819,N,12102.39973,W,0.128,,270823,,,D72 $GNVTG,,T,,M,0.128,N,0.238,K,D3A $GNGGA,010449.00,3859.62819,N,12102.39973,W,2,12,0.75,600.3,M,-26.2,M,,000070 $GNGSA,A,3,03,04,26,31,46,09,48,16,06,,,,1.34,0.75,1.111E $GNGSA,A,3,73,80,71,72,88,70,74,87,,,,,1.34,0.75,1.111D $GPGSV,3,1,12,02,01,193,,03,77,187,46,04,60,318,47,06,17,310,3673 $GPGSV,3,2,12,07,11,232,,09,33,294,41,16,38,124,39,26,41,080,3275 $GPGSV,3,3,12,28,09,050,45,31,36,048,46,46,44,193,32,48,45,186,3578 $GLGSV,3,1,10,65,00,307,23,70,18,110,17,71,60,067,49,72,47,332,3665 $GLGSV,3,2,10,73,58,054,47,74,61,167,35,75,11,196,24,80,08,027,4463 $GLGSV,3,3,10,87,13,271,27,88,10,320,416D $GNGLL,3859.62819,N,12102.39973,W,010449.00,A,D6C $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg46 $GNTXT,01,01,01,NMEA unknown msg*46

I can suppress the errors by adding "-echo" to the end of the stty -F command, to see normalized output but it still has no impact on getting the desired output from "chronyc sources" of "#* PPS"

I'd appreciate any direction. I'm sorta thinking it may be a dietpi config issue as much of the setup is GB based and I'm in the California Sierras.

Thanks, Rick

[Kreeblah]

I'll take another look at what I have written, but I think I followed it step-by-step to validate it originally.

This might sound silly, but . . . is there any chance you could try moving the GPS antenna a little bit? Or, more drastically, even taking it outside (just to validate that it works)? I've had it fail to get a lock when the antenna has been sitting on a wire rack, and had to elevate it some before it would lock onto anything.

If you have a cable, you could try disconnecting the hat from the Pi and hooking it up to a computer to use it with the u-blox software, too, which might be a bit easier to get diagnostic data out of. That way you could see whether you could get a lock that way.

[Falcon-118]

Thanks! I built a custom (aluminum) mount for the Antenna. It holds it out away from my deck about 3 feet. The mount does allow the head to rotate so I'll try that. I used all 5m of the cable to run the antenna out from the equipment room where the pi lives. But, I'm 2000ft up the side of a mountain with no one within a half mile away so it gets a really clear shot of the sky. I'll try the u-blox software. There is also a new python coded app for looking at these hats, I may try to dig into that. There just seems to be a missing connectivity some how???

[Kreeblah]

Yeah, it really sounds like something's up either with the antenna's physical reception, or its ability to get data to the hat. At least you don't have to worry about a bunch of buildings obstructing your view of the sky, but if rotating the antenna doesn't help, would it be possible to unmount it and just set it on your deck to test? I wonder whether the aluminum in the mount might be interfering.

By the way, I forgot to mention this before, but the bit you mentioned earlier about the "nmea": false bit in the cgps output is normal, but if you want more info about it, you can find it at https://gpsd.gitlab.io/gpsd/gpsd_json.html. It's on table 12, where it talks about the watch object. All the data that cgps is consuming should be documented there, since it's just rendering what comes out of GPSD's JSON marshalling system.

[Falcon-118]

I've been working with Anthony Stirk, director at Uputronics. The hat(s) are both talking the the Antenna(s) with no issue. For now, I'm staying with the u-Blox ANN-MB-00 antenna and have made an adapter to fit it to the mount I had for the Haswell. In this configuration when running u-Center, I get the flashing green PPS LED and a response from <ppstest /dev/pps0>. But I get no life from on the PPS or NMEA values... it always falls to a tertiary.

I'm trusting you had this working so there must either be an update in DietPi or Chrony that has grunged the config. I've now walked through your build 4 times and it just never will show a PPS connection response from "chronyc sources"

[Kreeblah]

That's really odd. Mine's up to date with all the DietPi updates and still running fine, and I'm not seeing anything that looks to be wrong/missing in what I wrote, so I guess what I can do here is reinstall following the steps I have outlined here and see whether I run into any issues. I'll start with downloading a fresh DietPi image and go from there.

I'll let you know how it turns out. It might be a day or two.

[Falcon-118]

Cool, Thanks! Just so we are on the same or similar build path, I'm using a Raspberry Pi 4, model B with 2GB of memory. Uputronics GPS hat, u-Blox ANN-MG-00 antenna and the latest version of DietPi. Good luck, I really hope you find something, because I think of the 3 builds I've looked at, yours is the cleanest and uses the most up to date hardware/software. I really want this to work.

Again, Thanks!

[Kreeblah]

This ended up being quicker to do than I thought.

Could you try with this image (should be dated July 31 and the .img file should have a SHA256 sum of 434ec7ba4f1533fe981664be930b4dbded0545ce6979d8a1ff6350379d02b3af)? Something in the DietPi images does, indeed, seem to have changed. I can get this working with an older image (even after updating it), but not their current one. The current one they have linked from the home page is based on Debian Bookworm (version 12). They have one not linked but also built this month based on Bullseye (version 11), which also exhibits the same issues. But, they have an "old" directory with the last image for each device, and the Bullseye (and only the Bullseye) image seems to work for me there. That's the one I've linked.

As for what's going on with these other images, gpsd isn't able to get data from the serial interface. I'm not sure why, and I'll need to figure that out. I'll probably need to file an issue with the DietPi project to get some help with that, since I'm not really sure what's preventing the communication with the serial interface.

[Kreeblah]

Also, except for the memory configuration, we're running the same hardware, so we should end up with pretty much the same results here with the same software.

[Falcon-118]

Nice find! I've got it downloaded and will attack it in the morning.   If you do find the fix, let me know if you need someone to test whatever changes you find.  Be glad to help. Rick

On Friday, September 8, 2023 at 08:30:14 PM PDT, Kreeblah ***@***.***> wrote:  

This ended up being quicker to do than I thought.

Could you try with this image (should be dated July 31 and the .img file should have a SHA256 sum of 434ec7ba4f1533fe981664be930b4dbded0545ce6979d8a1ff6350379d02b3af)? Something in the DietPi images does, indeed, seem to have changed. I can get this working with an older image (even after updating it), but not their current one. The current one they have linked from the home page is based on Debian Bookworm (version 12). They have one not linked but also built this month based on Bullseye (version 11), which also exhibits the same issues. But, they have an "old" directory with the last image for each device, and the Bullseye (and only the Bullseye) image seems to work for me there. That's the one I've linked.

As for what's going on with these other images, gpsd isn't able to get data from the serial interface. I'm not sure why, and I'll need to figure that out. I'll probably need to file an issue with the DietPi project to get some help with that, since I'm not really sure what's preventing the communication with the serial interface.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[Falcon-118]

Just curious, what mem size is your Rpi?

On Friday, September 8, 2023 at 08:50:11 PM PDT, Kreeblah ***@***.***> wrote:  

Also, except for the memory configuration, we're running the same hardware, so we should end up with pretty much the same results here with the same software.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[Kreeblah]

Sure, if I find something, I'll let you know.

By the way, the reason Chrony wasn't picking up on things but ppstest works is because in order to actually use PPS data (it's just a pulse on each second, but it doesn't have any other data, so it doesn't indicate which second it currently is when a pulse happens), it needs to reference against something. So, the config has it reference against the GPS data from gpsd because that's known to be reliable (unlike, say, another NTP server). With gpsd not being able to get data from the serial port, it has nothing to reference against, so it doesn't have any time data on the PPS clock either.

Regarding my RPi memory size, mine has 4 gigs of RAM, but I've never even come close to using it all. It's one I had lying around from another project that I didn't need for that any more.

[Falcon-118]

Success! First run with the older OS build got the "#* PPS" in less than a minute. pfSense is now seeing the Pi as:

Sync Source | 192.168.1.40 (stratum 1, .PPS.)

"cgps" populates the entire screen.

Nice find! Let me know if I can help with testing any fix you come up with.

[Kreeblah]

I was just able to get this working with the latest Bookworm off of the DietPi site. I just updated my instructions on the readme.

Basically, I had something in there that shouldn't have worked, but apparently did. I had dtparam=disable-bt instad of dtoverlay=disable-bt (which is what it really should be). Not explicitly disabling Bluetooth prevents the Pi from sending serial data from the hat, which is why that step is in there, and apparently dtparam worked at one time. It really should be dtoverlay, though.

If you want to give it a go, the instructions should be correct for the image linked from the DietPi homepage now.

[Falcon-118]

Looking back, I should have looked at that more closely myself. The other build I was toying with (Jacob Deane) used dtoverlay=pi3-dt-disable. I sent him a correction for the change to disable-bt in the newer versions of Raspian/Debian. I was thinking dtparam was something different in DietPi and/or Bookworm... neither of which I had used before.

The build I have working is still working fine, even after updates. I've even moved back to my more weatherproof antenna that I built an outdoor mount for. Thank you!!

[Kreeblah]

I'm glad you got it working, and thank you for filing the issue. I'm not sure when I would have discovered it otherwise.

The other good news is that the install you have should keep working now that it's up and running in the first place. My experience with DietPi has been that it's really stable between updates. They really do seem to do a lot to make updates and upgrades as seamless as possible, so with any luck, it should be pretty easy to keep up to date.

Anyway, I'm going to close this since things are working again with the image linked off of dietpi.com, but let me know if you have any other questions.