Borealis file timestamped Jan 1 1970

[tjk584]

Borealis at Saskatoon recently produced a file timestamped 19700101.0000.00. The file was generated on April 20, 2024.

The file is available in /borealis_nfs/borealis_data/conversion_failure/ at Saskatoon:

transfer@sasdist205:/borealis_nfs/borealis_data/conversion_failure> ls -l 19700101.0000.00.sas.1.*
-rwxrwxr-x 1 transfer users 1589768 Apr 20 13:37 19700101.0000.00.sas.1.antennas_iq.hdf5.site
-rwxrwxr-x 1 transfer users   52536 Apr 20 13:45 19700101.0000.00.sas.1.rawacf.hdf5.site

May be related to #189 #222

[RemingtonRohel]

There was another file whose sqn_timestamps field was full of timestamps from 1970, even though the filename was in 2024. The filename is made from the first sequence timestamp received from the usrp_driver.cpp module, which gets the timestamp from the USRP time (borealis_clocks.usrp_time = meta.time_spec, where meta is the rx_metadata_t struct returned by a call to recv() on the multi_usrp object). All that to say, for some reason the recv call returned a timestamp that was only seconds past epoch, instead of millions of seconds past.

[RemingtonRohel]

This could be caught by the radar before data is written to file, by inspecting the gps_to_system_time_diff field. The usrp_driver.cpp process creates the field originally, and could raise an error if the value is erroneously large (e.g. 1e9 for current the most recent 1970-timestamped files). This would crash the radar, and an automated restart would then likely rectify the discrepancy.