Weird timestamp behaviour when writing output file

[thclark]

Reproduced from gitlab - filed by Rafael Fischer on Jun 21, 2021 4:05pm GMT+0100

Bug report

What is the current behavior?

During the T1 Aventa test we did today, we sampled once for over 10 minutes and exactly after 10 minutes, when the first data file was written, the following appeared on the cli:

	Constat packet: 2265
	Constat packet: 2266
	Constat packet: 2267
	Constat packet: 2268
	Lost set of Mics packets: 4345173.096801933 ms gap
	Lost set of Mics packets: -4317922.26965332 ms gap
	Lost set of Baros_P packets: 27359.23461917446 ms gap
	Lost set of Baros_T packets: 27359.23461917446 ms gap
	Lost Acc packet: 27708.526611328125 ms gap
	Lost Gyro packet: 27708.526611328125 ms gap
	Constat packet: 2297
	Lost set of Constat packets: 28075.860595725317 ms gap
	Constat packet: 2299
	Constat packet: 2300
	Lost Mag packet: 28500.274658203125 ms gap
	Constat packet: 2301
	Constat packet: 2302
	Constat packet: 2303
	Lost set of Analog Vbat packets: 23995.330810546875 ms gap
	Constat packet: 2304
	Constat packet: 2305
	Constat packet: 2306

Note that the Constat messages were added temporarily by me to see when the connection is alive. They are sent on every constat packet that arrives together with its timestamp in seconds.

The packet losses with the huge gaps must have something to do with the file being written / the active file being changed.

You can find the produced files under [https://ostch.sharepoint.com/:f:/r/teams/TS-Aerosense/Freigegebene%20Dokumente/General/2_Implementation/21_WorkPackages/WP2_ResearchAndDevelopment/T2.3_Electronics/BLE%20performance%20tests/Measurements%20June%2021/424536?csf=1&web=1&e=Rvai4d]

Your environment

• Branch: feature/extended_constat
• Platform Windows

[thclark]

@time-trader can you grab the produced files off teams and add them here please?

[time-trader]

Fixed with #30