-
-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple diagnostic tool #386
Comments
Which operating system do you use? It looks like this problem is gone on debian bookworm. (Please fill the form when you create an issue) |
Raspberry PI OS, Debian 11
I filled the form that was available when I created the issue. |
Could you test with Debian 12? You could check the status page. If there is a problem with the F9P link, you should see no sat levels. |
Sorry, I thought you've created the ticket with the "bug" template. |
Any update about this? Do we close this issue? |
The station has been relatively stable over the last few months I've been using it. Close if you'd like, but this is primarily a feature request ticket. |
The status page isn't a good solution? |
Not for diagnosing background issues. The status page gives you hints that something's wrong, but isn't a diagnostic tool for what is wrong. |
Is your feature request related to a problem? Please describe.
I run a portable field base station, which I use on established position stakes. Being portable, this means I move it, take it home with me when I'm not on a site, that kind of thing. The problem I've run into a few times now is that when booting up the base station, it refuses to connect properly to my GPS unit (ZED-F9P), and I lose up to an hour rebooting and tinkering until it eventually connects properly. This despite seeing a solid PPS lock on the GPS unit.
Describe the solution you'd like
A simple diagnostic page or tool that shows the current state of the GPS signal, the NMEA string being received from it, if the str2str_tcp service is properly up and able to connect, and whatever other basic diagnostic data would be useful to know that the chain from antenna to service is working correctly or something needs to be fixed.
Describe alternatives you've considered
Fix the str2str_tcp service per issue #333 to be more resilient. This still wouldn't help diagnose connectivity or signal issues imho.
The text was updated successfully, but these errors were encountered: