Is anyone else seeing odd gaps in traces like below?
This does not seem to be related to local network or RFI issues
.
Thanks.
.
1 Like
Hello K2PI,
Thanks for the notification. I have asked our server team to check, and everything appears to be all right.
Could I ask you to download and post the logs from your Shake&Boom? So that we can have our eyes on both sides.
Thank you!
Here you go. I think whatever it is, It may require me to rebuild the card, although I did nothing to cause a card problem (I did power cycle the device after this started, which you will see on the logs.
Thanks
1 Like
I rebuilt my card, and it seems to be without gaps so far, but I’ll keep watching. I do not think it is the PS causing gaps like others have experienced. I have a commercial Acopian B5G210 5V power supply, that is very stable and is not undercurrent for the Shake. Will be interested in your analysis of what was causing this issue.
Thanks.
1 Like
Thank you for the logs, K2PI, and the further feedback.
As things stand, you’re right. The PSU does not seem to be the issue in your situation. Instead, the data gaps appeared due to this (multiple messages like the following):
2025 114 22:33:57>> Time adjustment M0: HARD RESET. This will result in a one-time time-tear.
2025 114 22:33:57>> 5.0: NTP Time (Init): NTP: 1745534037.296423674
2025 114 22:33:57>> 5.2: NTP Sync (HARD): VEL Before: 1745534031.032000065 After: 1745534037.036000013 Diff: 6.003999949
2025 114 22:33:57>> 5.2: NTP Sync (HARD): IS Before: 1745534031.032000065 After: 1745534037.036000013 Diff: 6.003999949
This continued happening due to the PPS time source listed in the same log set:
remote refid st t when poll reach delay offset jitter
==============================================================================
*pi.hole .PPS. 1 u 20 1024 377 29.897 13.119 9.961
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
+wasabi.ruselabs ipaddress 2 u 1055 1024 377 107.629 2.831 14.909
To your knowledge, is this a GPS unit of some kind? Because, before you rebuilt the card, it was not providing an accurate pulse to set the Raspberry Pi board clock as required. Thus, the resulting data gaps.
Could you download and post the logs after the microSD card rebuilding process? I’m curious to see what they display right now and compare the new set with the previous one.
Thank you!
I will send those logs after I let it run today.
The PPS is my NTP server’s GPS disciplined clock, which is my local NTP that I pointed the Shake to. It has been working just fine for a long time. As of this morning, the accuracy of my NTP server is 17ns, and it seems to be doing just fine.
Thanks for the analysis Stormbreaker!
I guess there is little sense in waiting, given the number of cycles in an hour.
Here is the latest log file after the SD card rebuild.
Thanks again!
RSH.RBE98.2025-04-25T12_56_32.logs.tar (155.5 KB)
Hello again K2PI, and thanks for the new updates.
Indeed! After the microSD card rebuilding, all data appears smooth and stable, with no gaps whatsoever.
The time offset difference is also better. From the myshake.out files, your NTP source now has an offset of -0.777, instead of 13.119, so a much better performance.
Always welcome!
I don’t know what happened, but I left this shake at it’s original config with default internet NTP servers for a day, and it’s been ok. I went back in tonight and pointed it at my local NTP server, but left several pool servers in place. I think perhaps I commented out the pool servers, and when the NTP was not being called by the Shake properly, it had no alternative NTP to look at. Just a guess, but it seems to be working with my local NTP at the moment.
Maybe it’s out there somewhere and I have missed it, but I would enjoy having even a small document that tells us what logs to look in for what issues, a simple guide that says “look here for power supply messages” or “look here for time synchronization”. I imagine that would save you a lot of support time, and be useful for those of us who would like to pay attention to what is going wrong (or right).
Thank you!
Hello K2PI,
[…] when the NTP was not being called by the Shake properly, it had no alternative NTP to look at. Just a guess, but it seems to be working with my local NTP at the moment.
Yes, this is a concrete possibility. If the primary NTP reference is unavailable, the Shake will search for alternatives. And, after not finding them… it will reach the situation we were in at the start.
Having multiple NTP sources also helps in keeping the time synchronization as precise as possible, with the OS being able to compare data from different sources and fine tune the time on the Shake.
Maybe it’s out there somewhere and I have missed it, but I would enjoy having even a small document that tells us what logs to look in for what issues, a simple guide that says “look here for power supply messages” or “look here for time synchronization”.
There is no specific document that summarizes all support instances. As a general rule of thumb, if there are gaps in the recorded data, it can be related to one (or more) of the following:
- Insufficient power supply
- NTP time servers unavailability
- General connection instability
Regarding possible undervoltage messages, this can be done from the command line (after SSHing into the Shake), using this:
sudo zgrep -a -i voltage /var/log/syslog*
Which will show all the instances, if present, of undervoltage/power supply events. It may also be possible to monitor the same with the vcgencmd python package (vcgencmd) as one user has done something similar in the last post of this thread: Using under voltage warning for pi shutdown - Raspberry Pi Forums , but you will have to experiment.
As you can see, there is much to be seen and read. Probably the most comprehensive documentation we have is the community forum itself, with years of support and issues that have been resolved along the way.
No trouble at all!
Hi Stormbreaker,
Thanks for the reply. I think you may have misunderstood my request. I wasn’t asking for a comprehensive troubleshooting guide. I know such things are difficult to write given the variables. From a 40-year career in IT and Technical writing, I also realize they are sometimes not worth writing unless you will never be able to interact with the user.
What I was asking was just a simple explanation of what each of the log files represents for the shake. This could easily be a one-page slick sheet, and I for one would find it useful. It would be useful to help us zero in before we even post a message for support. I believe it would save you time and effort.
Regards.
1 Like
Hello K2PI,
Thank you for the clarification!
I’ll bring this up with the team, as it’s something we could potentially develop and add either to our documentation or as a pinned post in the forum.
Thanks again for the great feedback - it’s exactly the kind of input that helps improve things for everyone.