$Id: Readme.txt 2496 2017-09-18 14:56:52Z lendl $

This directory contains various Cube files that demonstrate test cases in the 
area of "leap second handling".

 Note: All ASCII dumps are in the same format as the GIPPtool 'cubeinfo'
       will produce.


Test 001 -- "Normal" leap second change during recording
--------------------------------------------------------

  This test covers the expected "correct" Cube behavior in case of a leap
  second event. It should simply continue to record and the TAIP blocks
  should contain correct (UTC) leap second information. Also, it should not
  matter if the GPS hardware is switched on or off during the leap second.

  The test files were recorded during the MOMANIC experiment and cover the
  leap second event of Dec 31st, 2016. The files were edited by hand to only
  contain a short fragment around the leap second event (file size!). In case
  of the "GPS off" test file, selected blocks (GPS, DELAY, PPS-SAMPLE) were 
  removed to simulate a leap second event while the GPS hardware is powered 
  off.

    001-gps-on.cube ... GPS powered on during the leap second event   
    001-gps-on.gps .... GPS strings obtained via 'cubeinfo --format=gps'.

    001-gps-off.cube .. Switched off GPS during the leap second event.
    001-gps-off.gps ... GPS strings obtained via 'cubeinfo --format=gps'.


Test 002 -- "Delayed" leap second change during recording
---------------------------------------------------------
  
  These files were recorded during the Longmenshan experiment. The leap second
  "jump" in this file is recorded at 04:16:09 (UTC) on July 28th, almost one
  month after the official leap second correction!
  
  Presumably the reason for the "delayed" recognition of the leap second change
  is that the Cube was switched off during the transition. When it was powered
  on later it started with its old (default?) settings until it could load the
  (new) current almanac. Once the GPS new about the new leap second setting,
  the time stamps were updated.


    002-long-delay.cube .. The GPS blocks in the file show the UTC leap second
                           correction (falsely) change from 15s to 16s on July
                           28th (instead of June 30th):
                           
                             Block #05561  GPS   gps-leap=+15s iers-leap=+16s
                             Block #05613  GPS   gps-leap=+15s iers-leap=+16s
                             Block #05665  GPS   gps-leap=+15s iers-leap=+16s
                             Block #05717  GPS   gps-leap=+16s iers-leap=+16s
                             Block #05769  GPS   gps-leap=+16s iers-leap=+16s
                             Block #05821  GPS   gps-leap=+16s iers-leap=+16s

    002-long-delay.gps ... GPS strings obtained via 'cubeinfo --format=gps'.

  Note: The GIPPtools will use the correct IERS leap second value, originating 
        from a build-in leap second table for processing!


Test 003 --Trimble Firmware Bug
-------------------------------

  A few Cubes contain a Trimble GPS unit from a bad batch containing an ugly
  firmware bug! The problem is that the leap second correction is applied the 
  moment an upcoming leap second event is announced via GPS satellite. 
  Unfortunately, announcements of a leap second events happen several months 
  before the actual event. As a consequence to this firmware bug, affected 
  Cubes return wrong times (exactly one second off) for several months!
  
  So, the UTC time, which includes leap second correction, returned by the 
  GPS hardware is not unconditionally reliable. Instead of relying on the 
  leap second information broadcasted via GPS satellite, the GIPPtools must
  use an internal table (provided by IERS) to apply leap second corrections.
  
    003-trimble-bug.cube .. Example for a Cube affected by the Trimble firmware 
                            bug. Beginning with block #1212 (recorded in 
                            February 2015!) the GPS hardware applies a leap 
                            second correction of +17s, although the actual leap
                            second event is not due until June 30th, 2015!
  
                              Block #0808  GPS  gps-leap=+16s iers-leap=+16s 
                              Block #1010  GPS  gps-leap=+16s iers-leap=+16s 
                              Block #1212  GPS  gps-leap=+17s iers-leap=+16s 
                              Block #1414  GPS  gps-leap=+17s iers-leap=+16s 

    003-trimble-bug.gps ... GPS strings obtained via 'cubeinfo --format=gps'.
  
    003-trimble-bug.txt ... Samples of the Cube file converted to text (using
                            'cube2ascii --resample=none --timing-control=none').
                            The times in this file use the correct leap second 
                            correction ('+16s').
  
  Note: So far, only a few Cubes sold by DiGOS GmbH to non-GFZ customers have 
        been affected by this bug. Unfortunately, it is not possible to "just 
        flash an update" on the affected Trimble modules. So, the problem must 
        be fixed by the GIPPtools software!

  