I gather there has been an autodetection of a USB serial device as a PPS source. However this is a false detection. I do have a USB device attached, but it is an Arduino board so that I can check on the temperature and humidity of my outdoor enclosure. How do I disable the PPS auto-detection?
I assumed as a general rule it was inappropriate for a PPS process to be trying to sync to a source that was definitely not an accurate timebase. If it ever does decide my Arduino Temp/RH reports (which are more-or-less at 2 second intervals, similar to some GPS stations) are “close enough” to a time signal, that is going to make my data timestamps inaccurate by a possibly large amount. It may be generating log file entries, and I want to minimize SD card wearout. The main issue though is I wanted to read my Temp/RH data by myself, and I assumed the PPS daemon sitting on the /dev/ttyUSB0 device was going to block me from doing so.
Thank you for the further details, jbeale. Indeed, it would be interesting to see what the Shake thinks about this PPS signal coming in from the Arduino board.
Could you run ntpq -p after SSHing into the Shake and copy/paste the output here? This way, we’ll have a list of all time sources the ntpd service is detecting.
Have you also checked if stopping the PPS signal from the Arduino board side is possible? Unless it is required for the temperature/humidity data…
Regarding your microSD worry, you can rest assured that additional PPS (or the main) source(s) will continue to write to the Pi shared memory. So, there will not be additional “wear and tear” of the microSD itself.
Here it is. FWIW I think gpsd will never recognize my Temp/RH data strings as a valid NMEA GPS sentence, so time offsets likely wont happen.
remote refid st t when poll reach delay offset jitter
==============================================================================
SHM(0) .GPS. 0 l - 16 0 0.000 0.000 0.000
SHM(1) .PPS. 0 l - 16 0 0.000 0.000 0.000
+lithium.constan 132.163.96.2 2 u 18 64 1 87.282 -6.805 1.998
*ntp1a.versadns. .GPS. 1 u 18 64 1 86.440 -3.728 7.279
+time3.lshiy.com 216.239.35.0 2 u 14 64 3 174.220 3.885 14.154
My problem is simply that gpsd opens the USB0 serial port, thereby occupying it, and blocks my access to my sensor data. I guess I just have to go in and manually kill the /usr/sbin/gpsd -n -G /dev/ttyUSB0 process at some point after boot. I tried preventing it from ever starting, by the hack of renaming the /usr/sbin/gpsd file, but I see making that change also prevents the data producer/consumer process from starting. Maybe you check the /etc/rc startup scripts for an error, or some other process consistency check before startup, which is reasonable.
Anyway, I guess that’s just what it is. I just have to do the manual step of killing the gpsd process after any restart, if I want to check on my enclosure sensor temp and RH conditions.
Thank you for the command output and the other details of your installations.
Our team suggested that, instead of doing it by hand every time, you could set up a systemctl service calling a file to execute the “kill” automatically after the Shake OS service has completed its task. In this way, you just need to remember to re-apply this service if you re-burn the microSD card, but other than that, it will work on its own. If you need some guidelines, you can find them here: Setting Up a systemd Service.
Could I ask you to download the logs from your Shake (with the Arduino attached to it) and send them to me? The team would like to check what’s going on with a bit more depth, and the logs could help.
Looking around on the internet, it seems that an Arduino board could produce this PPS signal (without a GPS module attached) via either their USB serial comm method, or timers to toggle GPIOs, or other sources. I think it would be worth the effort to investigate and locate the source of the signal, to see if it can be turned off at its source. This would make the systemctl service above redundant, and you should be able to receive data through the USB port as intended.
Ok, as of 2pm PST 2/15/2024 my R-Boom station RC93C-HDF is again outside, connected to the long soaker-hose input, and is back to measuring outdoor signals instead of mostly just interior HVAC cycles and various interior doors opening and closing.
Unless there is some other reason I would not waste your time looking at my logs, my Arduino monitoring temp and humidity produces a short string about every two seconds which I believe a ‘gpsd’ process would normally assume does indicate a connected GPS, but that actual data is never a valid NMEA string, so it would never actually alter the ntp timebase. It is not a big deal to manually kill the gpsd process after a reboot, I will figure out systemd eventually.