Make framer_open_p300 more robust

[hmueller01]

I have seen in my logs that the repeated sending of the sync sequence 0x16 0x00 0x00 is not enough if the EOT (0x04) was not received by vitronic.

[10520] Mon Sep 10 22:31:01 2018 : >FRAMER: open device /dev/vitoir0 ProtocolID 41
[10520] Mon Sep 10 22:31:01 2018 : Configuring serial interface /dev/vitoir0
[10520] Mon Sep 10 22:31:01 2018 : >SEND: 04
[10520] Mon Sep 10 22:31:03 2018 : <RECV: len=1 05 (1560.0 ms)
[10520] Mon Sep 10 22:31:03 2018 : <RECV: received 05
[10520] Mon Sep 10 22:31:03 2018 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_LINK_STATUS(05) (w
as FFFF)
[10520] Mon Sep 10 22:31:03 2018 : >FRAMER: closed
[10520] Mon Sep 10 22:31:03 2018 : >SEND: 16
[10520] Mon Sep 10 22:31:03 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:03 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:05 2018 : <RECV: len=1 05 (2010.0 ms)
[10520] Mon Sep 10 22:31:05 2018 : <RECV: received 05
[10520] Mon Sep 10 22:31:05 2018 : >SEND: 16
[10520] Mon Sep 10 22:31:05 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:05 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:07 2018 : <RECV: len=1 05 (2020.0 ms)
[10520] Mon Sep 10 22:31:07 2018 : <RECV: received 05
[10520] Mon Sep 10 22:31:07 2018 : >SEND: 16
[10520] Mon Sep 10 22:31:07 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:07 2018 : >SEND: 00
[10520] Mon Sep 10 22:31:09 2018 : <RECV: len=1 05 (2250.0 ms)
[10520] Mon Sep 10 22:31:09 2018 : <RECV: received 05
[10520] Mon Sep 10 22:31:09 2018 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_LINK_STATUS(15) (w
as FE05)
[10520] Mon Sep 10 22:31:09 2018 : >FRAMER: could not close (3 attempts)
[10520] Mon Sep 10 22:31:09 2018 : Error opening /dev/vitoir0

So I propose to send the EOT in all (currently 3) attempts first before sending the sync sequence. This helps in my case that P300 communication can be established.

[28424] Tue Sep 11 22:01:02 2018 : >FRAMER: open device /dev/vitoir0 ProtocolID 41
[28424] Tue Sep 11 22:01:02 2018 : Configuring serial interface /dev/vitoir0
[28424] Tue Sep 11 22:01:02 2018 : >SEND: 04
[28424] Tue Sep 11 22:01:04 2018 : <RECV: len=1 05 (2010.0 ms)
[28424] Tue Sep 11 22:01:04 2018 : <RECV: received 05
[28424] Tue Sep 11 22:01:04 2018 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_LINK_STATUS(05) (was FFFF)
[28424] Tue Sep 11 22:01:04 2018 : >FRAMER: closed
[28424] Tue Sep 11 22:01:04 2018 : >SEND: 16
[28424] Tue Sep 11 22:01:04 2018 : >SEND: 00
[28424] Tue Sep 11 22:01:04 2018 : >SEND: 00
[28424] Tue Sep 11 22:01:06 2018 : <RECV: len=1 05 (2010.0 ms)
[28424] Tue Sep 11 22:01:06 2018 : <RECV: received 05
[28424] Tue Sep 11 22:01:06 2018 : >SEND: 04
[28424] Tue Sep 11 22:01:08 2018 : <RECV: len=1 05 (2010.0 ms)
[28424] Tue Sep 11 22:01:08 2018 : <RECV: received 05
[28424] Tue Sep 11 22:01:08 2018 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_LINK_STATUS(05) (was FE05)
[28424] Tue Sep 11 22:01:08 2018 : >FRAMER: closed
[28424] Tue Sep 11 22:01:08 2018 : >SEND: 16
[28424] Tue Sep 11 22:01:08 2018 : >SEND: 00
[28424] Tue Sep 11 22:01:08 2018 : >SEND: 00
[28424] Tue Sep 11 22:01:08 2018 : <RECV: len=1 06 (10.0 ms)
[28424] Tue Sep 11 22:01:08 2018 : <RECV: received 06
[28424] Tue Sep 11 22:01:08 2018 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was FE05)
[28424] Tue Sep 11 22:01:08 2018 : >FRAMER: opened

PS: Sorry, I branched this from my previous formatting branch #36.

[speters]

Did you also try out a EOT;EOT; SYNC; SYNC scheme instead of your EOT;SYNC;EOT;SYNC?

I'm asking, because the Vitosoft Demo communications I logged show the former:

...
2017/12/05 21:32:11 term 05                       |.|
2017/12/05 21:32:13 term 05                       |.|
2017/12/05 21:32:15 tcp  04                       |.|
2017/12/05 21:32:15 term 05                       |.|
2017/12/05 21:32:16 tcp  04                       |.|
2017/12/05 21:32:18 term 05                       |.|
2017/12/05 21:32:18 tcp  16                       |.|
2017/12/05 21:32:18 tcp  00                       |.|
2017/12/05 21:32:18 tcp  00                       |.|
2017/12/05 21:32:18 term 06                       |.|
2017/12/05 21:32:18 tcp  16                       |.|
2017/12/05 21:32:18 tcp  00 00                    |..|
2017/12/05 21:32:18 term 06                       |.|
2017/12/05 21:32:19 tcp  41                       |A|
2017/12/05 21:32:19 tcp  05 00 01 00 f0 02 f8     |.......|
2017/12/05 21:32:19 term 06 41 06 03 01 00 f0 01  |.A......|
2017/12/05 21:32:19 term 01 fc                    |..|
2017/12/05 21:32:19 tcp  06                       |.|
2017/12/05 21:32:19 tcp  41                       |A|
2017/12/05 21:32:19 tcp  05                       |.|
...

[hmueller01]

No, I did not try this. This is really interesting. But does it really make sense? As far as I understand an EOT;SYNC sequence is needed to start communication. If a bit is wrong the sequence needs to be repeated. For me it makes no sense to send EOT;EOT;SYNC;SYNC. If the second EOT is wrong transmitted (e.g. 0x14) we have no reset and SYNC might not work (as shown in my logs). What do you think?

[speters]

In your sequence, a successful switch to P300 is depending solely on the last SYNC, as previous SYNC state gets reset by the preceding EOT.

So I have no preference. Let's stick to you sequence, as you already implemented it.

[hmueller01]

The for loop is stopped after the first successful (answer 0x06) of the EOT;SYNC sequence. So, if the communication path is stable only one EOT;SYNC block is send. If this fails another EOT;SYNC block is send and so on. Until a successful sync or the max. attempts are done. It is strange why Vitosoft Demo sends two SYNC frames, even the first SYNC is ACK (0x06). Sending two EOTs might making the stop more robust as there is no answer (the 0x05 answer is send by vito periodic). If you like I can try this.