Spikes and data drop outs from Vault

I’ve had my RS3D (station R4FA0) in a remote vault for a while and have been troubleshooting some issues.

One of the issues is spikes in the data. I think it is from RFI due to micro-arcing in some of the connections in the power supply circuit from solar to charger to battery to buck convertor to shake.

The other issue is the breaks in data which I think is due to slow comms, due to poor wifi signal. The comms has been so slow I was unable to download the log files from the shake.

Since we are going away on holidays soon, I decided to move the shake back to the shed while we are away, and this has allowed me to download the log files as well.

Are you able to read the log files to help confirm my diagnosis or point me in a new direction if required?
RSH.R4FA0.2025-05-15T06_35_47.logs.tar (2.5 MB)

I have been wrestling with keeping the wifi dongle protected from the weather and maximising the wifi signal. I can get good signal with it in the open, but the signal strength drops to about -85 to -90dBm with it under the weather cover or inside the plastic power box.

I have been avoiding drilling a hole in the box and sticking the antenna through it and sealing with silastic, but that may become necessary to improve signal strength.

The spikes I think might be helped by applying contact grease to all the connections in the power supply circuit, but any other suggestions are also appreciated.

Thanks,

Al.

1 Like

Hello Al,

Yes, with the logs that you posted (thanks for that!) I can support the conclusions you’ve written down.

Going step by step:

  • No issue at all with the booting process, the Shake does all it needs to do without issues.
  • May 15 06:00:06 raspberryshake ntpd[550]: ntpd: time set +1117.506556 s → this shows that, in some occasions, the difference between the local Shake clock and the actual time are quite large.
  • And this is also supported by many HARD RESET events that appear in your logs. These indicate that the Shake has lost connection to its time provider and you’ll get a resulting data drop.
2025 088 19:27:50>>	5.0: NTP Time (Init): NTP:	1743276466.015015602
2025 088 19:27:50>>	5.2: NTP Sync (HARD): VEL Before: 1743276476.848000050	After: 1743276465.755000114	Diff: -11.092999935
2025 088 19:29:37>>	Time adjustment M0: HARD RESET.  This will result in a one-time time-tear.
  • You also have these errors that show some connection issues.
|2025 132 08:42:20>>|DDSsend(): Send error: 0|
|2025 132 08:42:20>>|sendDClientDP(): Error sending data ... |
|2025 132 08:42:22>>|DDSsendDP(): send error EPIPE (Broken pipe), closing socket|

All in all, yes, I would recommend what you already have in mind, particularly for the WiFi.

Let us know how the experiment go!

1 Like

Thanks Stormchaser. Its good to confirm what’s going on.

It gives me some confidence about what I need to do when I get back from holidays.

Al.

2 Likes