I could not find this discussed, so posting this question.

I have two ASI EFWs. I use one with my monochrome camera and one with my color camera. I have separate profiles for monochrome and color, but I don't know how to have two ASI EFW config files (namely ~/.indi/'ASI EFW_config.xml'). Consequently I have to re-enter filter names for the filter slots whenever I switch between color and monochrome.

Since the "ASI EFW" name seems to be determined via selecting it from the pull-down menu for filter-wheels when building a profile, what is the proper technique to allow for distinct config files?


The skies were not clear as had been forecast last night, but I was able to at least exercise it enough to feel it will be OK.

I submitted a pull request here: github.com/indilib/indi/pull/1540



Definitely not just baud rate.

I was planning to give a complete report once I know that it is truly working in the field, which will be tonight, hopefully.

However, since you ask, there were definitely at least two bugs:

  1. The missing minus sign in the checksum calculation that I mentioned earlier
  2. The GET_MTR_POS request was missing a byte.
  3. I added code to rigorously clear RTS since if it is left laying around, the focuser hand controller is locked out (that definitely happened to me).
In addition, I believe (and I guess PlaneWave does, too, per their python script) that the better, safer, approach to reading packets is to go byte at a time so as to get the embedded data length, which also allows a check that there is enough buffer space, and then read that many bytes. Also byte at a time allows gibberish, should it appear (as it does when baud rate is wrong), to be discarded safely.

Finally, I added some sanity checks per the python script to confirm that the packet to be used is indeed the response to the request sent.

The vast majority of the driver code is bug-free and correct, and I certainly am extremely thankful for it - all of which is to say it is not a criticism when I say that in its current state I cannot see that anyone ever used this driver on a PlaneWave EFA unit. FYI: DeltaT Dew Heater code works fine.

I will provide you the changes I made via the git process once I confirm that this version works.

Again - extremely heartfelt thanks for INDI, KStars and EKOS... what a joy to use this software.


I have a working version now, finally.

It may be clear skies tomorrow night, so I can see if it will actually auto-focus.

I will let you know here.


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
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]


     I am attaching a python2 (2.7) script from PlaneWave. When I run that on my equipment, it interacts with the EFA properly, so I would say that indicates that there is not a problem with the connection between my NUC and the EFA nor with the EFA itself.

     I then modified planewave_efa.cpp and planewave_efa.h in an attempt to mimic the protocol used in the python script. I am also attaching those two modified files, which do compile and run. I can successfully write the handshake (get-version request) and I receive back the echo (EFA echoes everything sent to it), but when I then try to read the packet with the real response in it that should be the next thing on the connection, I get a timeout. Yet if I again run the python script, it has no problem requesting and returning the version information.

     I am stumped.

    Note: the three files are contained in the attached zip file.


To follow on to my last reply. I can now communicate with the EFA, but the communication protocol is confusing and not documented beyond the sort of summary that is provided by this document . Do you happen to have something more in-depth on the protocol?

I receive back the echo of the command I send, but when I try to read the real information then I get a timeout error (-4) from that second tty_read.

If I accept the echo as a sufficient handshake, then as the loading proceeds, some requests go through, but others hit the timeout. I expect none of that can be trusted until the Handshake works properly (i.e., the version number is returned).

I will keep at it, but the mysteriousness of the protocol is annoying. Any suggestions appreciated.

P.S. As you probably realized immediately, just changing the current return statement on the calculateCheckSum function to:

return ((-sum) & 0xFF);

Namely just adding the minus sign, fixes it more succinctly.



Getting into a Windows environment is non-trivial for me so I want to exhaust other avenues before climbing that mountain. I did try all baud rates on INDI. Their documentation suggests 19200, though.

I did notice that the checksum calculation in INDI's planewave_efa.cpp does not match the PlaneWave documentation, but that in itself did not solve my issue as I am not getting two-way communication with the EFA unit at all. I am experimenting in the code to try and establish some communication with the EFA for starters. I am not ready to give up on that yet, but when I do, I will be forced to give Windows a try (the PlaneWave help desk advised the same thing - naturally - since they don't support non-Windows environments).

Anyhow, the calculateCheckSum() function was not calculating the 2's complement, so I added two lines before the return statement to do that:

uint8_t EFA::calculateCheckSum(const uint8_t *cmd, uint32_t len)
    int32_t sum = 0;
    for (uint32_t i = 1; i < len - 1; i++)
        sum += cmd[i];
    sum ^= 0xFFFFFFFF;
    return (sum & 0xFF);


I am trying to connect to the PlaneWave EFA (focuser) unit, which connects via a byzantine USB-to-serial connection using a product called "DIGITUS USB 2.0 serial adapter," which PlaneWave supplied.

The connection itself seems to be working based on output from "lsusb" and "dmesg" as well as the kstars log reporting a successful connection to the port.

The handshake, however, fails. What INDI sends to the EFA for the Handshake (getting the Version) appears to me to match what the protocol requires as documented here:

I set the baud rate to 19200 as the above document suggests.

I am running under Ubuntu 21.04 on a NUC. The Digitus product says it works with Linux.

I am at a loss to know how to proceed. Has anyone out there had success? Any suggestions for things to try?

The attached files have what I think are all the relevant lines from the KStars log, lsusb and dmesg.


Hi. I am confused as to the current status of what is fully fixed and available. For me, building from latest GitHub on Ubuntu 20.10 amd64 still has at least the Pegasus drivers broken. Reviewing this thread there are conflicting statuses. In somer instances the problems are pegged to bad packages, but building from source supposedly works (not my experience); other entries point to possible C++ inheritance issues (so building wouldn't fix that).

Can Jasem or other knowledgeable individual please recap the current status and whether those of us still out-of-luck should be looking for a source update from which to compile a working version or if it is best to look to nightly builds.

Just to confirm that I am building properly on Ubuntu 20.10 amd64, my steps are:

  1. Make sure environment is up-to-date (sudo apt update && sudo apt full-upgrade -y)
  2. Install all required build pre-requisites as well as ccache
  3. Then perform the following (completing the set of operations for each package before proceeding to the next package):
    1. Clone (or pull latest) master branches from the following links:
      1. indi: github.com/indilib/indi.git
      2. indi-3rdparty: github.com/indilib/indi-3rdparty.git
      3. kstars: github.com/KDE/kstars.git
    2. cmake options:
      2. 3rdparty-library: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DBUILD_LIBS=1 "$SRCROOT/indi-3rdparty"
      3. 3rdparty-drivers: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DWITH_FXLOAD=1 "$SRCROOT/indi-3rdparty"
      4. kstars: cmake -DCCACHE_SUPPORT=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo "$SRCROOT/kstars"
    3. make -j $NCPU
    4. sudo make install
Any info or insights appreciated.


FYI: I am running Ubuntu 20.10 (amd64) and tried building from latest source, but it cannot connect to my Pegasus units (PPBA and DMFC). Fails in HandShake (gets no response).