Hatched signal

Hello,

we are a seismic observatory (in Grenoble, France), we get some shake and Jam since several years (about ten units). Recently I made 5 Jam mobile “box” equipped with GPRS router and internal battery. The GPRS router have also GNSS antenna and is a NTP server, with excellent precision.

Problem is, I don’t know how to “tell” the Jam to use the local NTP server, cause in SSH when I type “ntpd -q” it seem that the Jam get synchronization from somewhere on the web.

And so, I think (but may be wrong) that’s why the data is totally hatched since I started it up on the field.
The cuts are very similar one on the other (most of the time), as you can see here.
This is a signal issue, the Jam still “on” during these cuts, I can use SSH all along.

Precision : This jam box worked perfectly during several weeks just before…

Which is the way ?

1 Like

Hello benjamin, and welcome to our community!

Thank you for explaining all the details of your JAM situation. From the attached screenshot, it definitely appears that there is some kind of NTP timing-related issue, or possibly a power supply issue. Could you please also provide the following?

  1. the contents of /etc/ntp.conf file in one of the affected JAMs
  2. the logs of one of the affected JAMs
  3. the output of ntpq -p

This additional information, which can be accessed via SSHing into the Shake (for the command outputs) and via the Shake rs.local/ (for the logs) will help us in defining your current situation better.

Also, could you check (if possible) that all power supplies of all affected JAMs are providing a constant output of at least 2.5A and between 5.0V and 5.2V? Thank you!

Hello,
thanks for your response, here are what you asking for :

1. Content of /etc/ntp.conf :

tinker panic 0
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

    # GPS Serial data reference                          
    server 127.127.28.0 minpoll 4 maxpoll 4 noselect     
    fudge 127.127.28.0 time1 0.500 refid GPS             
    #                                                    
    # GPS PPS reference                                  
    server 127.127.28.1 minpoll 4 maxpoll 4 prefer       
    fudge 127.127.28.1 refid PPS         

2. The logs ; not sure which log you want, I put result of a “cat” of these files :

  • /var/log/boot.log
  • /var/log/messages
  • /var/log/syslog

into a drive here

Actually there are a lot of message about voltage, that’s surprising indeed. I now Raspberry 3 models have issue about voltage warning (far too sensitive according to devs) but here it’s look like there is something to worrying about.

3. ntpq -p

myshake@raspberryshake:/home $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   0.000
 SHM(1)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
+time.cloudflare 10.22.8.4        3 u  419 1024  377   63.495    1.130 141.298
*saturne.obs-bes .LTFB.           1 u  609 1024  377   72.431    1.862  57.492
+mail.klausen.dk 193.79.237.14    2 u  607 1024  377   76.004    0.400   2.292

4. Power

The Raspberry & Jam are powered with a uninterruptable power supply (230Vac to 12Vdc) and a converter (12Vdc to 5Vdc).
I’m not able to check it right now (it’s on the field) but it worked a week ago. But o course, next time I pass near this one, I’ll check it, it could be damage or something.

Hello Benjamin,

That’s perfect, thank you so much for all the data you’ve gathered for me. I’m sorry about the logs, I should have pointed them out more precisely.

I would require, when you can, the ones that you download from the rs.local/ interface (instructions here: Please read before posting!) or, alternatively, the entire content of the /opt/log/ folder.

They will help in providing a more complete picture of the situation. Thank you again.

Hello,

sorry I didn’t see you said the log from the web page.
So you’ll find in the drive here :

  • R7920.zip, contain all the log files of the “/var/log/” folder, get in SSH.
  • RSH.R7920.2023-03-23T07 56 08.logs.tar : which is the file downloaded from the URL interface of the Jam.

bye

Hello Benjamin,

no problem at all, and thank you for the logs. From all the data you’ve sent me, two issues pop up:

  1. As you have said, there are many messages regarding voltage events, and in most cases, an insufficient power supply can cause the many gaps you are seeing in the data from your unit(s). When you can, please check if the UPS connected to the Shake constantly supplies at least 2.5A with a voltage between 5.0V and 5.2V.

  2. From the logs you sent in the last message, it appears that the Pi board cannot see the Shake board connected to it. These lines show the issue:

2023 082 00:06:42: Unable to read Firmware version number off of Serial Port /dev/serial0 after trying for 15 seconds, cannot continue!
2023 082 00:06:42: Is the Pi computer connected to the Raspberry Shake Board?  Please confirm and try again.

As this unit is on the field, when you are able to, please verify that 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.

Regarding the ntpq -p output, when an NTP server might be available, and/or that a GPS module is attached at the same time, the NTP is configured to retrieve data from all available sources, thus using both the internet servers and, when needed, switching to the GPS signal. In your situation, as you have correctly surmised, the GPS module is configured, but not connected, so it is not being used. If GPS were connected, the * would be next to the SHM(1) entry.

Hello,

ok, it seem that we have to check the installation, may be something gone wrong…

About GPS, that’s not a GPS antenna with USB configuration (like with the Raspberry shake package), it’s a GPRS router with a GNSS synchronization, that’s create a local NTP server.
Is the Jam can detect a local NTP server ? Without any previous configuration ?
When I’m using this configuration (NTP server through GPRS router with GNSS synch.) other digitizer (like scientific datalogger digitizer Campbell) are able to read NTP server, but need a configuration first, of course. But it’s usually works.

Thanks for your help,
bye

Hello Benjamin,

Thank you for the additional details on your local NTP server. When needed, yes, NTP servers can be manually configured by SSHing into the Shake and then editing the /etc/ntp.conf file. You will find all the details here: NTP and GPS timing details — Instructions on Setting Up Your Raspberry Shake

Also, remember that if a Shake has gone too long without NTP synchronization, it may be necessary to manually reset its internal clock before any NTP service can keep the time in sync. Instructions on how to do so, if needed, are here: Offline and stand-alone applications (like classroom demos) — Instructions on Setting Up Your Raspberry Shake

To confirm, when you write this:

Precision : This jam box worked perfectly during several weeks just before…

I assume that the JAM was not in the mobile box yet, and was acquiring NTP data from a standard internet connection? Just to fully understand the situation. Thank you.

I assume that the JAM was not in the mobile box yet, and was acquiring NTP data from a standard internet connection? Just to fully understand the situation. Thank you.

No precisely, the Jam was in exact same configuration, that is why it’s surprising me. But in the other hand, another unit of raspberry (shake this one) has exactly the same problem (data cutting), and changing power supply seem to resolve the problem. I think it could be a bad contact of a short-cut on a connector (I hope).

I’ll go on the field the next week, I’ll let you know what I have done to resolve this ; In the worst case I replace the entire unit (the entire box) then I bring back the dysfunctional unit to test it in our lab.

Thanks for your time.
bye

2 Likes

Thank you Benjamin, that was what was confusing me a bit, so your clarification was more than helpful.

Yes please, if you can, let us know what you have found out when you have time to go back to the field unit, and if I (we) can help more.

No problem at all, you’re very welcome.