I just did the following:

  1. Used gdb and stepped through sendCommand; no spurious RTS activity; nothing remarkable
  2. I tried moving where the RTS-clear operation occurs
    1. Currently it is between the read for the echo and the read for the real data (that is where the python script had it occurring). Timeout occurs when trying to do the second read, the one for the real data.
    2. I moved the clear operation after both reads, timeout still occurred at the second read.
    3. I moved the clear operation before both reads, then the blocking occurred before the echo, which might mean something except that moving it after the second read didn't change blocking AT the second read.
  3. I changed the read behavior so it always reads 1 byte at a time, which is what the python script does. It made no difference (which was reassuring).
  4. I tried only one timeout check and put it just before the first read instead of before each read and then (not surprisingly) blocking (rather than a timeout) occurred at the second read.
  5. I tried both TIOCMSET, which was what was originally in the code, and TIOCMBIS, which is what python appears to use, to set RTS. No difference.
I cannot think of what else to try.

If the python script did not work, I would say that the EFA was not sending the version information, but the EFA does send the version information to the python script, so I just don't get why doing it in INDI times out (or blocks) waiting to read the version info.

Here are the first few lines of the python script output (with debugging output turned on) where it successfully gets the version info...
$ python2 efalib.py
Version:
Send: '3B 03 20 12 FE CD'
Echo: '3B 03 20 12 FE CD'
Resp: '3B 05 12 20 FE 01 06 C4'
CHK Calculated: C4  Received: C4
Response: FOC_TEMP -> PC: GET_VERSION (1, 6)  [value: 262; checksum: OK]
[hex: 3B 05 12 20 FE 01 06 C4]
1.6


Read More...