Re: adding IRIG time and time of day

["John Dill" <John.Dill () greenfieldeng com>]

> Message: 2
> Date: Tue, 5 Nov 2013 09:19:15 -0800
> From: Guy Harris <guy () alum mit edu>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] adding IRIG time and time of day
> Message-ID: <C698FBE1-0808-4DFC-B85A-F5DD597F6185 () alum mit edu>
> Content-Type: text/plain; charset=iso-8859-1
>
> > We have a CNIC-A2P3 board installed in a Compact PCI chassis.
>
> Unfortunately, GE won't let me get either the hardware manuals for their ARINC 664 devices or the cpcap manual.
>
> I'm guessing, perhaps incorrectly, from the "pcap" in "cpcap", that it provides a libpcap-compatible API.
>
> The folks at GE *could* have, somewhere in the path between the hardware and the caller of cpcap:
>
> gotten the current year number;
>
> calculated the number of seconds between January 1, 1970, 00:00:00 UTC and January 1, {current year}, 00:00:00 >UTC 
> (except for leap seconds - don't ask, that's why I say "seconds-since-the-Epoch" rather than "seconds since >the 
> Epoch");
>
> added that to the "fractions of seconds since the beginning of the year" value from the IRIG-synchronized counter;
>
> when the IRIG time stamp overflows into the next year, increment the year number and recalculate the "number of 
> > seconds since..." value;
>
> and provide *that* value as the packet time stamp (which they *especially* should have done if cpcap has what >they 
> intend to be a libpcap-compatible API!).
>
> *Did* they do so, or do they just provide a "fractions of seconds since the beginning of the year" value?

> From an excerpt from their manual describing the API
The Cpcap API is a relatively high level set of functions, much like libpcap, with a user-friendly abstraction of the 
traffic source.

---

They provided a set of sample driver programs that used the board's internal clock to timestamp packets, starting from 
0.  There was no sample (back then, there may be now) that demonstrated how to use the IRIG time signal from the board 
to synchronize the packet stream, or to populate the packet time with an Unix epoch timestamp (their API did at least 
document how to query the board for an IRIG time in seconds).

Condor Engineering (bought by GE) also provided a modified version of Ethereal (or Wireshark) that attempts to handle 
some of the extensions that AFDX provided in a different graphical representation.  It was difficult to understand and 
impractical to use for our needs.

The other data streams (ARINC-429 and MIL-STD-1553 were timestamped using IRIG-B without the year, and their BusTools 
applications that provided graphical introspection of the data did not support Unix Epoch time format as an option.  I 
decided to synchronize the packet stream to the IRIG-B so that all three bus modalities were synchronized to that same 
format.  At that time, I was not very familiar with the pcap-ng standard and made that decision based on my group's 
local needs.

I'm not sure if there's a good way to resolve the issue.  Changing the MIL-STD-1553 and ARINC-429 timestamps to Unix 
Epoch would break their compatibility with the GE tools, and we'd have to adapt our other software tools to handle 
mixed time formats.  There's several years worth of data that may or may not be politcally difficult to justify 
retroactively applying the Unix epoch just to make the capture files standard compliant.

It is what it is.

Best regards,

John D.

<<winmail.dat>>

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe