Fix data parser

[nitin710]

Description

Fixes for data parser

Issues referenced

• Fixes DataParser: Fix timeSync parsing #97
• Fixes DataParser: Verify all RD expected outcomes are being covered #99
• Fixes DataParser: Change init value of TimeSyncMap #100
• Fixes DataParser: Implement a check for generated TimeSyncMap #101
• Fixes DataParser: false "missed packet error" #103
• Fixes DataParser: false "malformed" packet detected #104
• Fixes DataParser: verify we are parsing Aperiodic signals correctly #105
• After Review 1
• Fixes DataParser: Enable parsing if 0 or 1 timestamps are received #110
• Fixes DataParser: Improve user instructions when too few timesyncs are found #111

Tests

• Refer Each issue to review the test and corresponding result

[produceconsumerobot]

@nitin710 I'm unsure why the 2 nearest RTTs are being used instead of the 262351 and 2377788

2022-04-14_16-10-23-397219.csv

[produceconsumerobot]

@Nitin we need to look at parsed timestamp difference histograms that prove the timestamps are being parsed correctly.

[produceconsumerobot]

@Nitin we need to look at parsed data timestamp difference histograms that prove the timestamps are being parsed correctly.

[produceconsumerobot]

@nitin710 I thought we were adding some smarts about Q1, Q2, Q3, Q4 selection in calculateTimeSyncMap() in this PR. Is that not the case?

[produceconsumerobot]

Code generally looks good!
Biggest comment is that we should always parse data AND give instructive feedback to the user when timesyncs are limiting.
Additional comments:

• We need to look at parsed data timestamp difference histograms that prove the timestamps are being parsed correctly.
• I thought we were adding some smarts about Q1, Q2, Q3, Q4 selection in calculateTimeSyncMap() in this PR. Is that not the case?

[nitin710]

Addressing Review Comments

• I'm unsure why the 2 nearest RTTs are being used instead of the 262351 and 2377788
  • [?]
• we need to look at parsed timestamp difference histograms that prove the timestamps are being parsed correctly.
  • [?
• I thought we were adding some smarts about Q1, Q2, Q3, Q4 selection in calculateTimeSyncMap() in this PR. Is that not the case?
  • [?]
• give the user instructive feedback on what went wrong, how it might impact their timestamps, and how to record better data next time
  • [?]
• Fix data parser #106 (comment)
  • [?]

Changelog

• ✔️ Added parsing for 0 timestamps received
• ✔️ Added parsing for 1 timestamp received
• ❌ smarts about choosing timestamps from quadrants
• ✔️ Improved messaging
• ✔️ parsed data timestamp histograms

[nitin710]

Timestamp Testing and analysis

File	Condition	TimeSync histogram PI	Timesync histogram AX	Timesync histogram EA	Tiemsync histogram TH
Good example	Always connected, healthy amount of timestamp received
bad example	1 timestamp received in the beginning
bad example	1 timestamp received in the end
bad example	0 timestamps received

Conclusions

• The parsed timestamps diff histograms suggest that the inter-sample time in the parsed data is close to expectation.
  • Histograms created for
    • TH(sampling rate = 7.5Hz, Time period=0.13S): hist. mean timestamp ~ 0.1S, 0.2S
    • PI(sampling rate = 25Hz, Time period=0.04S) : hist. mean timestamp ~ 0.04S
    • AX(sampling rate = 25Hz, Time period=0.04S) : hist. mean timestamp ~ 0.04S
    • EA(sampling rate = 15Hz, Time period=0.06S) : hist. mean timestamp ~ 0.06S
• The new parser was tested on the following cases
  • data with no timestamp ✔️
  • data with 1 time stamp towards the beginning ✔️
  • data with one tiemstamp towwards the end ✔️
  • data with sufficient timestamps ✔️
• Updated the user message in case < 2 timesyncs are recorded
  • 
• ❌ smarts about choosing timestamps from quadrants
  • This will be pushed to the next patch