Hello James, welcome to the community!
Thank you for posting the logs from your Shake. From them, a couple of things that are connected to the gaps in your data appear. The first one is the following:
Oct 26 23:27:02 raspberryshake kernel: [446898.167351] ttyS ttyS0: 1 input overrun(s)
|2020 301 03:42:38>>|No Data has been received from the MCU in 12 read attempts.It appears the MCU is not transmitting data. This is a fatal condition and should be investigated if this condition persists!|
|2020 301 03:42:38>>|Data has been successfully received, fatal condition resolved.|
You already had noticed the input overrun
errors, and those, connected to the MCU errors (even if they appear to solve themselves) can mean that some of the connections of the Shake are not solid.
Did you assemble the Shake yourself? Even if you received a pre-assembled unit, can you please check that every cable is properly in its socket, and that the Shake blue board is solidly inserted in the Raspberry Pi computer pins?
The second issue is this:
2020 301 03:37:06>> Time adjustment M0: HARD RESET. This will result in a one-time time-tear.
2020 301 03:37:06>> 5.0: NTP Time (Init): NTP: 1603769825.760442495
2020 301 03:37:06>> 5.2: NTP Sync (HARD): VEL Before: 1603769694.499000072 After: 1603769825.500000000 Diff: 131.000999928
2020 301 03:38:16>> Connection succeeded to DDS server.
Again, the problem seems to auto-correct, but these mean that the Shake is having a problem with the communication to the NTP server (the one which takes care of the time synchronization).
Could you please check if in your modem/router the
port 123
that is used by the NTP process is open for TCP and UDP traffic in both directions?
These ‘time tears’ also cause the issue with the broken upload to our servers, which receive data correctly (as shown here https://raspberryshake.net/stationview/#?net=AM&sta=R7314) but only between a ‘tear’ and another.
We will see what we have to do after these initial checks.