Potential incorrect "Time Resolution of Time Stamps" with spec 3.0
dipterix opened this issue · comments
Not readNSx problem though, but I need to re-consider how to generate event files with correct timestamps... Just sent BR support team this email querying about the following issue.
Original message:
We have recently upgraded our system to using NEV/NSx 3.0 specification. When we try to parse the nev file, we noticed that basic header "Time Resolution of Time Stamps" value has changed. Instead of expected 30000, its value became 108. As "This value denotes the frequency (counts per second) of the global clock used to index the time samples of the individual data packet entries", I highly doubt that 108 is the correct value. When I looked into the raw bytes of the nev file, the first 28 bytes showed:
42 52 45 56 45 4e 54 53 03 00 01 00 90 67 00 00 6c 00 00 00 6c 00 00 00 30 75 00 00
Following the NEV 3.0 specification,
42 52 45 56 45 4e 54 53 -> BREVENTS (File Type ID)
03 00 -> 3.0 (File Spec)
01 00 -> 1 (Additional Flags)
90 67 00 00 -> 26512 (Bytes in Headers)
6c 00 00 00 -> 108 (Bytes in Data Packets)
6c 00 00 00 -> 108 (Time Resolution of Time Stamps)
30 75 00 00 -> 30000 (Time Resolution of Samples)
I wonder if 108/s is the correct time resolution of time stamps, or is this entry ever useful? It happens to be the same as "Bytes in Data Packets", so I wonder could it be that the system accidentally repeated the same bytes?
This is a bug from BR somewhere along the line in Central, this header is being distorted and subsequently reports the wrong value. I force the resolution to be 30000 when irregular srate is reported.
Fixed as of v0.0.2