I guess there was a timestamp reset request at packet 10; however I don't understand why there is a very high timestamp at packet 9 - is this expected behaviour, or should I look at my code for decoding the timestamps?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this is correct. Timestamp reset is sent as a separate packet with only itself, to act as a separation point in the stream, and it gets the highest timestamp of the old stream, to ensure it's always at the end (or conversely, just before the new stream starts at 0).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm looking at an aedat file recorded by caer. Here is the progression of the main time stamp for the first few packets:
packet: 1; timestamp: 0
packet: 2; timestamp: 0
packet: 3; timestamp: 5221
packet: 4; timestamp: 8398
packet: 5; timestamp: 10002
packet: 6; timestamp: 10304
packet: 7; timestamp: 13448
packet: 8; timestamp: 20002
packet: 9; timestamp: 2147483647
packet: 10; timestamp: 104
I guess there was a timestamp reset request at packet 10; however I don't understand why there is a very high timestamp at packet 9 - is this expected behaviour, or should I look at my code for decoding the timestamps?
Ah: The number 2,147,483,647 is the eighth Mersenne prime, equal to 2^31 − 1 ...
So packet 9 contains just one special event - a timestamp reset event, and its timestamp is 7FFFFFFF - is this expected behaviour?
Yes, this is correct. Timestamp reset is sent as a separate packet with only itself, to act as a separation point in the stream, and it gets the highest timestamp of the old stream, to ensure it's always at the end (or conversely, just before the new stream starts at 0).