A lot of this makes sense. In the list of timestamps you posted, the negative ones increment by the same 2133/2134. The incrementing must happen in the LimeSuite library on the host computer. Then half way through the negative time stamps, they jump back again - since another packet is received that contained the same negative timestamp as the first one. Everything is a bit confused though because of the misalignment of the 128 sample buffers with the 680 sample packets.
So for the negative timestamps to make sense, we need the buffer size to be aligned with the native packet size (which actually depends on the data format. Its 1360 samples for 12bit samples, but 1020 for 16 bit samples). Its ok if you use a buffer size that is an integral multiple of the packet size. The pulse on GPIO0 needs to be at least one buffer size long, and yes, you will sometimes see one negative timestamp and sometimes two.
I’m confused though about why your stamps increment by 2133/2134. I would have expected the timestamps to increase simply by 128 each time? Are you doing the multiplying by 1000/60?
If so, by doing that, you make it much harder to figure out when the GPIO actually went high.
If you take out the leading bit of: -6148914689475294922, you get a number that doesn’t make any sense as a timestamp. If you go back to what I would expect the raw timestamps to be:
105672176 (your first one multiplied by 1000/60)
105672304
105672432
105672560
First negative was then approximately at stamp 105673328. If you then set the msb: (1<<63) that gives -9223372036749102480
which, if you then /60*1000 gives: -6148914689475295072 which is in the ballpark of your first
negative number. Going backwards is going to be really tough.
I’d suggest not multiplying by 1000/60 till after you’ve sorted out the negative timestamps, then you can just remove the leading bit, and what’s left tells you the correct time value.