Gaps in data stream

Hi!
In recent days I have noticed that some momentary intermittencies occur in the registry, as well as high amplitude signals prior to the gaps.
I don’t know what the reason of the problem, this is the vault type installation, the connection is through Ethernet.

I hope you can guide me to solve the problem, I think that can be the high humidity inside the vault, but I want to listen to you…





1 Like

Hello elsismologo54, and welcome back to the community.

Thank you for the description of the issue and all the screenshots you have provided (great vault installation!)

Could I please ask you to download the logs from the Shake and send them to me? If needed, instructions on how to do it are here: Please read before posting! We can try to take a look and see what could be causing this issue.

Also, could you zoom in on one of the larger spikes in SWARM so that we can see how the waveform is structured?

Thank you for your collaboration.

1 Like

Hi!, sorry for the late response, I had to go to the station location to collect the data, but here it is, and the data segment with high amplitude signal:

1 Like

Hello ElSismologo,

No trouble at all, and thank you for both the screenshot and the logs!

It seems that, while the ports are open and the Shake can see our servers, every now and then it is unable to transmit data and closes the connection:

2024 219 19:18:08>>	DDSsendDP(): message send failed after 61 retries, closing connection.
2024 219 19:18:08>>	DDSsend(): Send error: 0

There are also many HARD RESET errors:

2024 151 00:00:54>>	5.2: NTP Sync (HARD): VEL Before: 1717027243.957999945	After: 1717027253.957999945	Diff: 10.000000000
2024 151 00:49:34>>	Time adjustment M0: HARD RESET.  This will result in a one-time time-tear.

That are created because the Shake is losing connection to the NTP time synchronization server.

Can I ask you to do the following?

  1. Shut down the Shake, then your router
  2. Disconnect power and LAN cables, wait for 5 minutes
  3. Turn on your router again, and wait for it to regain internet connection
  4. Reconnect LAN and power cables (in this order) and turn on the Shake again
  5. Wait for ~30 minutes (or until a new spike/data interruption appears, whichever comes first), download the logs from the Shake (if needed, instructions here: Please read before posting! ) and attach them to your next answer?

I would like to compare the new logs with the ones you’ve just sent me.

Thank you again!

Hello, I finally had time to go to the station and do the procedure that you recommended me. It worked fine for a few minutes, but then the connection was lost again, there are data gaps.

If I open Swarm from an RS.local connection I can access the data in real time and without gaps in the registry, the helicorder is complete. However, from the RS Community server there are many gaps and lack of data, it seems that the problem with the connection to the server is still wrong.

I don’t know if it is a problem with the WiFi modem that rejects the connection or there is already an internal error in the RS, or both.

I hope you can help me solve it, thank you.
I attach the .LOG files

RSH.RB581.2024-10-03T02_32_24.logs.tar (4.5 MB)

1 Like

Hello ElSismologo, and thank you for the further updates and screenshots/log.

The fact that, locally, the Shake is working and its helicorder is full is good news. Together with the logs, I can confirm that the unit is in perfect status and is operating as expected.

The issue appears during the transmission phase, where I can see the following errors:

2024 277 00:56:57>>	Connection attempt #1 (raspberryshakedata.com:55556) failed with error code: No route to host
2024 277 01:43:01>>	DDSsendDP(): send error EPIPE (Broken pipe), closing socket
2024 277 01:43:01>>	DDSsend(): Send error: 0
2024 277 01:43:01>>	sendDClientDP(): Error sending data ... 
2024 277 01:52:34>>	DDSsendDP(): message send failed after 61 retries, closing connection.

At boot, the Shake manages to get an IP address, find an internet connection and communicate with our server via the usual ports 55555 and 55556. However, after a while (in some cases), or more quickly (in others), it seems that the path breaks, and the Shake cannot transmit successfully anymore.

As you mentioned your WiFi modem, I would investigate that. You can try by resetting it to factory settings and see if, now, it keeps a more stable connection, or, if you have another available, try a different WiFi modem.

Or you can temporarily try to see if the Shake behaves the same or not using a cabled LAN connection.

EDIT: Have you recently changed any item (like the WiFi modem) in the data transmission chain, or these issues have appeared since the beginning?

1 Like

Hello, This week I was finally able to go to the station and revert my modem settings to factory settings, the Rasberry is now giving data to the server, with some data gaps, but they are minor and very sporadic than the previous data gaps.

The raspberry was working fine, until a few months ago when I moved some configurations of my internet modem to try to make a static IP, in the process surely I moved something that I shouldn’t have, causing the connection problems to the server, but all this was resolved by reverting those changes to the factory values.

Now, I seems that everything is perfect, I attach the .LOG files

RSH.RB581.2024-10-12T20_15_59.logs.tar (4.5 MB)

2 Likes

Hello ElSismologo,

I was just checking on your Shake the other day and saw that it was now transmitting data without gaps (compared to what we were seeing before). I thought you must have been working on it, and, in fact, here’s your message!

Happy to hear that now the Shake is transmitting data as intended!

1 Like