command line tool: Check for livelog start byte
The current approach when reading livelog data is based on the assumption that there is no missing byte in between two calls to read_livelog(). With this assumption in mind, there is no need to check for the live log start byte 0xff in order to read the data out of the log consistently. However, a missing byte will mess up the data interpretation completely.
Such a misinterpretation can be triggered e.g. by two parallel reads of the same COM port.
Reproduce
Debug an ongoing measurement
rss2i -p /dev/ttyUSB2 debug -d 18and then read from the same parallel port /dev/ttyUSB2 using another application e.g. gtkterm.
Expected Behaviour
This is the (expected) output before the second application has started reading from the COM port:
c:00042683 f:004 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:005 l:055.38 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:006 l:058.27 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:097 l:056.50 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:098 l:057.20 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:099 l:056.59 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:100 l:056.91 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:101 l:056.47 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:102 l:056.73 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:103 l:056.27 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18
c:00042683 f:104 l:056.44 r1:-57.88 r2:-31.11 r3:-00.00 r4:-31.17 r5:-00.00 r6:-31.17 b:100 m:17 rb:95 rm:18
c:00042683 f:105 l:056.70 r1:-00.00 r2:-00.00 r3:-00.00 r4:-00.00 r5:-00.00 r6:-00.00 b:100 m:17 rb:95 rm:18Actual Behaviour
This is the messed-up output after the second application has stopped reading from the COM port:
c:08495733 f:165 l:132.31 r1:-162.06 r2:-39.16 r3:-152.01 r4:-162.16 r5:-135.54 r6:-70.65 b:53 m:-102 rb:138 rm:15
c:02388611 f:238 l:149.12 r1:-37.03 r2:-250.16 r3:-178.16 r4:-111.01 r5:-69.37 r6:-165.01 b:162 m:-1 rb:33 rm:-97
c:11649300 f:007 l:167.02 r1:-130.01 r2:-240.79 r3:-21.35 r4:-232.38 r5:-107.10 r6:-103.63 b:132 m:-64 rb:38 rm:79
c:06759557 f:032 l:036.75 r1:-70.63 r2:-165.05 r3:-170.37 r4:-198.80 r5:-225.51 r6:-34.62 b:38 m:-11 rb:113 rm:47
c:10555562 f:096 l:194.27 r1:-103.71 r2:-232.04 r3:-38.88 r4:-37.12 r5:-32.00 r6:-177.04 b:197 m:88 rb:152 rm:-73
c:05465124 f:053 l:129.45 r1:-227.29 r2:-86.46 r3:-132.37 r4:-54.30 r5:-193.13 r6:-07.34 b:42 m:-49 rb:213 rm:62
c:09536251 f:046 l:101.03 r1:-16.53 r2:-163.02 r3:-16.02 r4:-172.15 r5:-133.30 r6:-13.09 b:69 m:-61 rb:16 rm:100
c:01081829 f:161 l:235.09 r1:-214.03 r2:-04.12 r3:-154.31 r4:-203.32 r5:-251.41 r6:-106.16 b:161 m:80 rb:13 rm:32
c:09543988 f:101 l:001.01 r1:-164.16 r2:-24.08 r3:-44.42 r4:-07.21 r5:-137.34 r6:-132.80 b:224 m:-69 rb:05 rm:-65As you can see, the livelog data is completely misinterpreted although the second application was stopped.
Possible Solution
The start byte 0xff should be located within the read live log data in order to "synchronize" the data interpretation. This should be done after every call to read_livelog().