Hello,
I’m coming to you because since April 1st our raspberry RA97C has stopped recording data. It is also no longer visible on https://stationview.raspberryshake.org/.
Having retrieved the logs locally from the router, I noticed the following problem in odf_SL_plugin.err:
2024 122 04:09:57>> odf_SL_plugin: Program Starting…
2024 122 04:09:57>> Unable to process configuration file ‘/opt/settings/user/UDP-data-streams.conf’, format is invalid, cannot register UDP destinations.
2024 122 04:10:38>> create_socket(): Error in getaddrinfo: Name or service not known
2024 122 04:10:38>> Likely cause is no DNS server found.
It seems that the problem is with the DNS server, or that the network connection is failing???
However, looking also at the rsh-data-consumer.log file, I notice this line: 2024-05-01 04:05:31 S.T. [ERROR] libmseedmm:
2024-05-01 04:06:34 S.T. [ERROR] libmseedmm: mst_addmsr(): Cannot allocate memory
From what I understand of these logs, they would indicate potential network communication problems, as well as memory management problems on the Raspberry.
Hello,
I wasn’t able to get out into the field before and take your advice. I am only now sending you the start-up logs for our RS3D RA97C. I find the files very surprising, with incomprehensible characters, as if the SD card had been corrupted. However, it was changed this very morning. The shake was switched off, the router was switched off, the SD card was changed and then reconnected and reconfigured. The RS3D is connected to the server.
hello,
I also have another question:
looking at my logs from a seismometer (R343A), I noticed that at certain times the UDP configuration was NONE.
I deduced from this that the ‘Error Sending Data’ problem visible in the odf_SL_plugin.err file would come from this.
I think that our power supply is insufficient (50Ah battery) to supply the router + RS3D and that consequently the router shuts down and no longer provides the local IP to the seismometer.
What’s more, stationview only displays data where the local IP has been given to the RS3D by the router.
However, data directly retrieved locally on the raspberry record other data (despite UDP config: NONE) with this message:
NTP timing is not available, so an accurate data timestamp is also not possible.
2024 171 14:21:56>> Data will be streamed locally only using HOST Computer’s clock time!
2024 171 14:21:56>> If Data-Sharing is desired, NTP must be available before this can happen!
2024 171 14:21:56>> 5.0: NTP Time (Init): NTP: 1718806916.685046434
2024 171 14:21:56>> 5.1: NTP Time (Init): VEL: 1718806916.424999952
My questions are as follows: does the timestamp come from a good UDP configuration (good IP address given by the router to the RS3D)? As far as I understand it, this means that the Raspberry would remain switched on despite the router being switched off, but would record non-time-stamped data. Is this true? and can this data be time-stamped upstream?
Hello again Evanna, and thank you very much for all the feedback and the logs.
Yes, I also think that lack of power supply could be causing this. The Shake did not properly boot (at least from this log sample) and there were many (as you noticed) NTP-related issues.
Regarding your questions:
Correct. A good/constant internet connection (and thus, good UDP configuration) is required to maintain NTP timing. That, or having a GPS module connected to the Shake, which will provide the same NTP service.
Also correct, if the power loss doesn’t affect both, the Shake would remain operating while the router goes offline. This would explain all the NTP-unavailable error messages you can see.
Again correct, the Shake would continue to record data, but they would not be correctly timestamped. When any Shake is not receiving NTP synchronized time data, there will be a drift as shown here in our manual (NTP and GPS timing details):
We commonly are asked, how much drift can one expect when there is no external clock that can be referenced to govern the shake computer’s clock? Unknown. The Raspberry Pi clock is governed by a 20 ppm crystal, so ~2 seconds/ day.
OK, thank you very much for your precise answers!
Maybe I’ll try to find out for myself how to re-stamp the data using signal processing software like Geopsy for example. Just in case our power supply problems aren’t solved right away…
Thanks again for all the help.
Best regards,
Evanna