GPS Timing

Hi Stormchaser,

I also would like to check the GPS timing status associated to RS acquisitions as I generally use my RS units in remote field locations with USB GPS antennas.
I understand that I have to look for time-tears in the odf_SL_plugin.err file. Below I attach the whole log I downloaded from one of my units.

RSH.RC373.2021-05-18T16_21_18.logs.tar (3.3 MB)

I read into the odf_SL_plugin.err file, but I honestly do not know how strings indicating time-tears should look like. Could you give me some hints?
In addition, I checked the gpsd-mgr.log file (also attached in the downloaded log) but could not find any info about GPS timing status. However, I noticed that messages in the gpsd-mgr.log file date back to 2018 (i.e., when we originally started using the RS units with the GPS antenna), while messages in the odf_SL_plugin.err file starts in 2020. Is there any reason for this?

Thank you very much and sorry for the long post.
Diego

Hello Diego, welcome to the community!

I have moved your message to a new topic so that we can concentrate on your questions. There’s no problem at all with the post, no problem, we are here for this.

Thank you for your logs. If any kind of time unsynchronization happens, this is what would appear in the odf_SL_plugin.err file:

2021 175 00:00:37>>	Time adjustment M0: HARD RESET.  This will result in a one-time time-tear.
2021 175 00:00:37>>	5.0: NTP Time (Init): NTP:	1624492837.052569866
2021 175 00:00:37>>	5.2: NTP Sync (HARD): VEL Before: 1624492832.039000034	After: 1624492836.792000055	Diff: 4.753000021
2021 175 00:00:37>>	5.2: NTP Sync (HARD): ACC Before: 1624492832.039000034	After: 1624492836.792000055	Diff: 4.753000021

or similar variations to the one above.

In your logs, I cannot see anything like this in that file, so there haven’t been any time tears, and the GPS has kept the synchronization active and working as it should. When the ODF error file odf_SL_plugin.err does not have any time tears, the data will always be within 10 milliseconds of absolute accuracy. More info here: NTP and GPS timing details — Instructions on Setting Up Your Raspberry Shake

The reason for the file difference in years is to be found in the size of the two files themselves. We keep as much information as we can in our logs, but without generating files that would be too big and start using more resources than necessary.

If you need anything else, I remain available.

Hello again Diego, further information from our technical team.

Since you are putting the Shake in the field, without internet access, you can also check the timing status with the following procedure:

  1. put the unit in stand-alone mode.
  2. check the log file gpsd-mgr.log to confirm the system thinks the GPS module is properly connected (it isn’t).
  3. look in myshake.out file in the logs to check the status of NTP, and the output of the command:
    > ntpq -p
    to verify GPS signal is working (this last check is done by logging in into the Shake How to access your Raspberry Shake’s computer via ssh — Instructions on Setting Up Your Raspberry Shake and executing it from the command line).

Hi Stormchaser,
thanks for your kind replies.
At this point I have a further question. Since, as far as I understand, there are no time-tears in my data, how should I interpret the errors listed in the odf_SL_plugin.err file? In addition, why do I get missing data in my recordings if there are no time-tears? As an example, I attach the file of the East component collected on 06/08/2020 (219th day of that year).
AM.RC373.00.EHE.D.2020.219 (5.2 MB)
You will see that there are some gaps in the data and I wonder in which log file I should read the presence of those gaps.
Thank you
Diego

1 Like

Hello Diego,

You’re welcome, I’m here for this.

Regardinng the errors present in the odf_SL_plugin.err file, some are related to the fact that the Shake is not connected to any network (since it is out in the field) and are explained by these lines:

|2021 138 17:11:29>>|sendDClientDP(): Error sending data ... |
|2021 138 17:12:09>>|create_socket(): Error in getaddrinfo: Name or service not known|
|2021 138 17:12:09>>|Likely cause is no DNS server found.|

Thus, they are not related to anything GPS, they are simply stating that the OS is not finding any network to transmit data to. This is a consequence of setting Data-Sharing Mode : ON on rs.local/ Settings -> Data page. If you uncheck the box, these should disappear from that log file.

Regarding these other errors:

2020 219 00:41:48>>	JSON Packet error: ':' expected near 'MA'
2020 219 00:41:48>>		Cannot process record, throwing it away.
2020 219 00:41:48>>	{'MA': 'RS3D-5-4.1','DF': '1.0','CN': 'EH2','T{'MA': 'RS3D-5-4.1','DF': '1.0','CN': 'EH2','TS': 0,'TSM': 0,'TQ': 45,'SI':  5000,'DS': ['FFFFBF28','FFFFBFD5','FFFFBF01','FFFFBE43','FFFFBF1E','FFFFC01B','FFFFBF4E','FFFFBE0E','FFFFBED9','FFFFC04C','FFFFBF8B','FFFFBDF4','FFFFBE5B','FFFFBFF8','FFFFBFFD','FFFFBEAD','FFFFBE67','FFFFBF33','FFFFBF4A','FFFFBEBE','FFFFBF41','FFFFBFF6','FFFFBEFD','FFFFBDE4','FFFFBEEA','FFFFC03C','FFFFBF6A','FFFFBE07','FFFFBEA3','FFFFC02B','FFFFBFAA','FFFFBE0E','FFFFBE2E','FFFFBFA4','FFFFBFF6','FFFFBF3E','FFFFBEFD','FFFFBF08','FFFF{'MA': 'RS3D-5-4.1','DF': '1.0','CN': 'EH2','TS': 0,'TSM': 0,'TQ': 45,'SI':  5000,'DS': ['FFFFBFA6','FFFFBE7B','FFFFBEC1','FFFFBFDE','FFFFBF90','FFFFBE61','FFFFBEEC','FFFFC053','FFFFBFC6','FFFFBE48','FFFFBE81','FFFFBFFB','FFFFBFF2','FFFFBEB0','FFFFBEB8','FFFFBFD2','FFFFBFB0','FFFFBE91','FFFFBEC4','FFFFBFD1','FFFFBF9C','FFFFBEC9','FFFFBF2A','FFFFBFF8','FFFFBF82','FFFFBE63','FFFFBEB7','FFFFBFF0','FFFFBFBD','FFFFBE93','FFFFBEFB','FFFFC016','FFFFBF96','FFFFBE5E','FFFFBEAB','FFFFC01B','FFFFC013','FFFFBEB8','FFFF{'MA': 'RS3D-5-4.1','DF': '1.0','CN': 'EH1','TS': 0,'TSM': 0,'TQ': 45,'SI':  5000,'DS': ['4252','4252','408B','4064','41D1','420C','40D8','407B','41EE','4280','40EA','4050','418A','41DE','40E3','4101','422A','41FC','404F','4046','4213','4256','40C3','4084','41DA','421C','40EB','4078','41AA','4205','40CF','40B8','4217','41FE','407B','4095','420C','421F','40BE','409A','420E','4233','40A8','4041','41BA','4204','40D9','40DB','422C','4227']}

these represent corrupted data that was impossible to interpret properly and has been thus discarded. The reasons could be multiple, but the general recommendation is to check every connection of the Shake to make sure that nothing is loose. Also, we recommend, after this check, to turn on the Shake again and to let it run for some time in the same conditions it was in the field, to see if such events happen again. If they do, the new logs could give us more insight on what is actually happening.