Problem solved. I was incorrectly parsing the SHRFileHeader which had flow-on effects when parsing the SHRSweepHeader.

Thanks for your time!

Hi Andrew,

My apologies – the converter I was using was assuming seconds from epoch as input, not milliseconds, so your value does look correct.

I’ll double check my Python code.

Nick

Hi Andrew,

I’m also seeing a problem with the SHRSweepHeader timestamp when parsing a SHR capture. I’m using Python to read the timestamp field as a uint64 which produces huge values such as 14032183609892863189.

The timestamp you gave (1557420094000) also doesn’t appear to conform to any standard I am familiar with e.g. in UNIX time this corresponds to Sunday, March 7, in the year 4264073288 (!) at 12:00:00am.

Can you please confirm what format the timestamp is encoded in and double-check the correct value is being recorded in the SHRSweepHeader?

Nick

[Author]

Posts