I’m receiving data via seedlink. But my latencies are very high (+100s). I check that with the command slinktool. How can changed this and improve the connection?
Hello abbyrz12, and welcome to the community!
Yes, that’s a very high value indeed! Could you describe in detail how the Shake is connected to the seedlink destination?
That is: Shake — network ? — destination
It is possible that one of the components along the network is causing this visible delay.
Yes, I connected the RS via WiFi to a modem with cellular data. On the modem, I configured port forwarding for the SeedLink port (18000) so that I can access the RS remotely using OVPN. First, I thought the high latency was due to NTP synchronization issues, so I updated the NTP settings. But, the latency didn’t improve.
Thank you for the further details abbyrz.
As you already checked the NTP (good catch on that) the issue could be located between the WiFi, VPN, and cellular connections.
WiFi can add jitter, and cellular connections/VPns can introduce long and variable latency, especially if:
- Signal strength is low.
- The modem uses NAT or CG-NAT aggressively.
- There is upstream bandwidth throttling or high packet loss.
Could you try to SSH to your Shake and then execute:
ping -c 10 8.8.8.8to see what time values come up, andtraceroutebetween the Shake and the destination machine?
Would it be possible for your installation type to connect the cellular data modem directly to the Shake? For example, via USB? That could, in part, reduce some of the lag you’re experiencing.
If you performed tests before deployment, did you observe similar lags (probably not, otherwise you wouldn’t have deployed in the first place, I imagine), or was the SeedLink connection noticeably smoother?
Lastly, could I ask you to access the shake rs.local/ page and download the logs via the orange button at its bottom? Or, if the page is not accessible, could you zip all files contained in /opt/log and send them to me?
They could offer more insight into what is possibly causing the data transmission delay.
Thank you for your collaboration!
I try with ping and the connection is okay.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=109 time=111 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=109 time=116 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=109 time=93.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=109 time=112 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=109 time=111 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=109 time=110 ms
This is .zip with logs from yesterday
RSH.R10FC.2025-07-22T16_22_48.logs.tar (4.1 MB)
Before, I didn’t have this issue but I changed the SD card because it was corrupted. And from there, I have this problem.
Thank you
I see, thank you for the logs and the ping results!
While most of the Shake functionalities are working well, there are issues that require attention.
Starting with the timing services, there are still many hard resets that signify loss of contact with NTP servers (and thus, possible time inconsistencies and data interruptions):
2025 203 16:22:17>> Time adjustment M0: HARD RESET. This will result in a one-time time-tear.
2025 203 16:22:17>> 5.0: NTP Time (Init): NTP: 1753201337.553261042
2025 203 16:22:17>> 5.2: NTP Sync (HARD): VEL Before: 1753201217.042000055 After: 1753201337.292999983 Diff: 120.250999928
2025 203 16:22:17>> 5.2: NTP Sync (HARD): IS Before: 1753201217.042000055 After: 1753201337.292999983 Diff: 120.250999928
I would recommend looking for additional NTP sources closer to the Shake location, and then adding them as indicated here. This should help stabilize the data output.
Then, you have much “gibberish” followed by MCU errors:
2025 203 16:22:47>> TQ‚ŽÿOkˆM¸²…Q:•E”AAÐE
2025 203 16:22:47>> 'QA
2025 203 16:22:47>> 16316 394
2025 203 16:22:47>> 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!
2025 203 16:22:47>> Data has been successfully received, fatal condition resolved.
These are usually associated with a lack of power supply and/or possible microSD card corruption (which, in turn, can be caused by the same insufficient power arriving at the Shake).
I would recommend checking if the current power supply continues to deliver a stable voltage between 5.0 and 5.2V and a current of at least 2.5A at all times (3.0A if the Raspberry Pi board that is being used is a RPi4), as a decrease in power could lead to data services interruption. If you have another Pi power supply that you know is in working condition, please try exchanging the current one with that and see if the Shake now appears more stable.
A second check that you can do is to see if all the connections between the sensor, the blue Shake board, and the Pi board are still solid and free from dirt or any other element that could compromise transmission. If you decide to disassemble the Shake during this process, please refer to our recommended ESD (ElectroStatic Discharge) guidelines and assembly/disassembly video guides here.
Lastly, as you stated that these issues popped out when you changed the microSD card, I would then recommend re-burning a completely new microSD, after formatting and erasing all its data/partitions first (you can use DISKPART for this as it is very efficient), and see how the Shake behaves with the newly installed system, possibly removing the issues we are seeing. I will leave the burning instructions link here for your convenience: microSD card topics.
Let me know how these checks go!