Two shakes, a RSD3 running .20, and a RS4D running .21, randomly stop reporting data on StationView. They do, however, continue to produce data locally, and both show active server connections. The co-located Boom running .21 does not exhibit this behavior.
All three machines have active NTP sync, albeit to differing pools of servers.
I note the machines are uploading via a Starlink connection that is subject to random interruptions, but I’d expect that the links would recover, particularly since the internet and connection statuses are showing as good.
Any hints on where to start attacking this problem would be appreciated. Nothing glaringly obvious jumps out of the logs.
Could you post the logs from all three instruments when you can? Having one that doesn’t show these transmission issues could give us a clue for the other two.
Sure thing! Should be attached, upload gods willing.
A few things:
The 3D that fell off StationView magically showed up again. This is the same 3D that’s steadfastly refusing to update to .21 that’s reported in another ticket, so I won’t upload the same logs over on that ticket.
The 4D .21 splash page indicated that services were down. I’ve attached logs taken at that time, and then again after reboot.
The Boom log is for the instrument that is always happy with life
Thank you for all the logs wiley42, they were very informative!
Indeed, the RBOOM is just coasting through its great life; the others should take an example!
Going into what I’ve found:
all Shakes display (every now and then) a disconnection from the NTP time synchronization server. This doesn’t usually last long, and the units always reconnect to the server, so it could be related to the Starlink connection (with all three Shakes together)
other than this, the RBOOM is fine
however, both the RS3D and the RS4D show some file corruption from the logs. And for the 3D, this is likely the reason why the Shake doesn’t manage to update on its own
Thus, for both the 3D and the 4D, I recommend re-burning the microSD card. You can find instructions on how to do so here.
If the microSD cards continue to show inconsistent behavior, then it may be worth using different ones.
Once the reburning is done, simply reinsert the cards into the Shakes, turn them on, and then everything should be fine now.
I have local stratum-one NTP servers, so I’ll just whack all three of them to point to one of those rather than whatever pool they’re pointing to by default. I’ll need to pull the 3D and 4D out of their vault and I’m traveling most of next week, so I’l update my observations sometime the week of the 8th. Hopefully a couple of new mlc cards and refreshed images will make them as happy as the RBOOM
