RShake heli with gaps

Detailed description of the issue:
I’m seeing many data gaps in the helicorder for quite some time now (around 3 weeks). I’ve tried restarting the RShake but it has not helped so far.

My RS is connected to a home network. Some of the gaps I know are related to my internet connection (I think the network cable is not working correctly).

I’ve attached the Log Files from my Raspberry Shake.

RSH.RADA1.2021-10-11T23_39_20.logs.tar (6.9 MB)

Hi Azamora3,

I am experiencing similar issue to what described - i.e. data gaps and my ethernet doesn’t seem to connect. Interesting that my RShake also started showing this problem in the last 3 weeks I haven’t found resolution yet. I am very keen to know how the issue is resolved.

Hello both azamora3 (welcome to our community!), James,

From what I can see from azamora’s logs, there are issues with the connection between the Shake sensor and the board, causing the gaps in the helicorder that you are seeing. Here’s an example from the logs:

2021 284 23:39:19>>	y???E?J]?ÅL]?
2021 284 23:39:19>>	AA?EBa?aàDS?AcT?E1æDIÐIS??Q

2021 284 23:39:19>>	W?T?U?Ac*?E1E
2021 284 23:39:19>>	!HªQ?
2021 284 23:39:19>>		16256	266
2021 284 23:39:20>>	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!
2021 284 23:39:20>>	Data has been successfully received, fatal condition resolved.

As you can see, after a while these issues are resolved automatically, but then they seem to appear again. Could you please check that:

  • all the connections between the sensors and the blue Shake board, and between the Shake board and the Pi board underneath are solid. If your Shake is outside in an enclosure, please verify that the enclosure is still keeping the moisture outside, and that the connectors are still in nominal shape (without visible deposits).

  • since there are also a few time synchro errors, that the internet connection of your Shake is stable without drops in signal quality (since I see that your Shake is connected also via WiFi). You already mentioned this, so I am sure you are aware of the issue.

  • if you can, your power supply is still in good conditions and can still provide between 5.0V and 5.2V and at least 2.5A. If you have another available, you can try to switch this hardware with another one to see if the gaps disappear. Similar issues have been solved with a new power supply unit.

You can also try to change the Raspberry Pi board with a new one that you may have around, to check if that was causing the recording gaps via some form of missed data packets transmission.

Thank you for your response @Stormchaser. I changed the Uninterruptible power supply (UPS) I had the RS connected to and it seems like that has solved the issue. The Shake is actually connected with a wire to WiFi, I may have to change the hardware if problems persist.

FYI, when checking the settings for the Shake it shows as “Server Connection: Not Connected” though. Is this due to the synchro errors you mentioned?

Best,

Azucena

2 Likes

Hello azamora3,

Thank you for your feedback, I am sure that it will be useful for other users in similar situations!

Yes, the “Not Connected” status can be related to synchro errors. If it persists after a while, where everything else stays green, then you can trythe following and see if it solves the connection problem?

Please access your rs.local/ page, go to Settings (the gear icon high on the left), and then the Data tab. Try unchecking the Forward Data box and, after ~30 seconds, recheck it. Then,click save and restart.

The station should now be able to connect again.

If it doesn’t, then please reboot it again, wait for around half an hour, download the new logs and then send them to me. Thank you!

1 Like

Hello @Stormchaser,

I tried unchecking/checking the Forward Data box, but it did not change the connection status.

I’m attaching the new logs.

Thanks!

RSH.RADA1.2021-10-15T19_04_40.logs.tar (4.1 MB)

Thank you for the new logs.

I can see that the new software has added the additional servers to your Shake, but for some reason, it still is not able to connect. The fact that you can see the data via the local helicorder display of the Shake tells me that the local connections are working fine and that there is something preventing the Shake’s communications with our servers.

Is the Shake directly connected to your modem, or is it connected to an additional router? If this is true, could you try to shut the Shake down, connect it directly to the modem, and then turn it on again? Does it now connect to our servers?

To cross-check if the Shake can see our server, could you please log in (instructions here: How to access your Raspberry Shake’s computer via ssh — Instructions on Setting Up Your Raspberry Shake ) into the Shake via command prompt with

ssh [email protected] or ssh myshake@shake_local_IP_address

and execute the following command from the command line?

nc -zv [raspberryshakedata.com](http://raspberryshakedata.com/) 55555; nc -zv [raspberryshakedata.com](http://raspberryshakedata.com/) 55556

This will return ‘success’ or ‘connection refused’, which will at least be a direct indication if the unit can see the server and ports it needs to or not.

If the return is a connection refused, please check that if the following ports

port 55555 [TCP]
port 55556 [TCP]

are open, and if not, please open them on your modem/router/network.

In any case, also check that

port 123 for [TCP] and [UDP] traffic in both directions

is also open. This last one is the port needed for the NTP time service, and it is required to keep the data synchronized with our network.

Thank you for your collaboration in this!

1 Like

Hi @Stormchaser,

My shake is connected to a router; I tried connecting it to the modem but it doesn’t connect (I can’t access rs.local unless it is through the router). I still shut the shake down and connected to the shake using:

ssh [email protected] or ssh myshake@shake_local_IP_address

and executed the command lines you listed. This is the message I got for each port

myshake@raspberryshake:/opt $ nc -zv raspberryshakedata.com 55555
nc: connect to raspberryshakedata.com port 55555 (tcp) failed: No route to host

My shake is, of course, still not connected to your servers.

Any suggestions?

Azucena

Hello Azucena,

Yes, this is what I suspected was happening. I don’t know why rs.local is not available when the Shake is connected through the modem, and it becomes instead available when connected through the router, but this seems a local network issue.

The only thing that I can suggest is to check the manuals of both modem and router and see how to open ports and/or check if they are open from their administration panels (which I assume are reachable via local network IP addresses). Also, it could be good to verify if any internal firewall/security measure of both modem and router could be interfering with the Shake data transmission.

The list of all the necessary ports for the Shake to transmit to our servers are here: Firewall issues? — Instructions on Setting Up Your Raspberry Shake

Once the ports are open on both devices, then the Shake should be able to connect. Unfortunately, I cannot be more precise since there are thousands of different modem/routers models on the market, so consulting their manuals is the only viable advice I can give.

Thank you @Stormchaser. The weird thing about this is that the shake was connecting to the network before without a problem until the gaps started appearing in the helicorder. I will work on getting the ports open and will let you know when I resolve the problem.

Regards,

Azucena

2 Likes


My problem with R2737 is the same - big datagaps at two different locations. I thought it was a poor internet service at the first location but this latest site has very fast internet connection. There is something wrong with the shake and I need to have it fixed.

hi there,

since the source of the problem could be any number of issues, in order to be able to assess what the problem might be, we need your log files.

see How to Download Log Files for details on how to do this.

cheers,
richard