Hashed signals with RS3D


I have a problem with an RS3D. When installed in August, it worked perfectly well. But for the past month, the signals have been cut more and more throughout the day. I send you the log files, if you can diagnose the problem. This is a very remote station, I can only access the system remotely. The RS3D was buried 50 cm deep. It is powered by photovoltaic panels. A second RSBOOM is installed right next to it, and works perfectly well.

Thanks in advance for your help.

RSH.RBC20.2023-11-14T19 45 04.logs.tar (6.3 MB)

1 Like

Hello Olivier, and welcome back to the community!

Thank you for the logs and your Shake location details. From the files you’ve sent, the booting process is fine, and the Shake bot starts and enables the OFF-LINE mode without problems. However, these lines tell us that there is something going on between the boards and the sensors:

2023 318 19:45:02>>	internal error: buffer overflow!  cannot process read data...
2023 318 19:45:02>>	buf: `ÿE
2023 318 19:45:02>>	Yˆœ–S ÁËQ’TYI0ÉË•ªe”I§U
2023 318 19:45:02>>	Yˆ„‰e ÑÊQ‚HI ÉÊe«´ÉËQDBe”Y¢eE”ÉË…HÉÑÊA†HY ÙÊ`‚Be”Y¢±E
2023 318 19:45:02>>	Yˆœ…e ÁËQ]FI ÉË„E
2023 318 19:45:02>>	YˆœEW ÁËQ‚UHI ÉË0
2023 318 19:45:02>>		16383	285
2023 318 19:45:02>>	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!
2023 318 19:45:02>>	Data has been successfully received, fatal condition resolved.

As you can see, there are errors mixed with some ‘gibberish’ that cannot be successfully interpreted. My first thought would be (when you have the chance to go visit this off-grid installation) to check and see if the current solar panels power supply you are using is continuing to deliver a stable voltage between 5.0 and 5.2V and a current of at least 2.5A at all times, as a decrease in power could lead to data services interruption. As the data interruptions have continued to happen during the past month or so, I can assume that there are instances in which these tresholds are not met, and the Shake behaves in the way you are seeing.

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. As usual, if you decide to disassemble the Shake when doing this, please make sure you are using proper ESD (ElectroStatic Discharge) protection (such as gloves, etc.), as electronics do not like static electricity too much.

As a last resort, and if all these checks come out as positive, then I would recommend bringing with you a newly re-burned microSD card, and see how the Shake behaves with a freshly-installed system, removing potential issues derived from corrupted files. I will leave the burning instructions link here for your convenience: microSD card topics

As a final note, if a GPS was installed with this Shake, it is also not acquiring good time data, as these other lines suggest:

2023 318 19:35:20>>	Time adjustment M0: HARD RESET.  This will result in a one-time time-tear.
2023 318 19:35:20>>	5.0: NTP Time (Init): NTP:	1699990520.111477613
2023 318 19:35:20>>	5.2: NTP Sync (HARD): VEL Before: 1699990278.601999998	After: 1699990519.851000071	Diff: 241.249000072

This, too, can be related to insufficient power supply, so I would say that, as soon as it’s possible, you (or someone else) should go there and check the installation to see if everything is OK with the power supply of this Shake.

:+1:Thank you for these wise tips. We will prepare accordingly for a next mission on site.


You’re very welcome Olivier. I hope they will help in solving the issues this Shake is experiencing.