Well, let me update: I still thank you, but it actually did not work. It only works in some cases. Apparently MDPD drivers cannot be aliased. I am not 100% sure what a MDPD driver is, but I am guessing it is one supplied as an object file rather than as source. Anyhow, the 'ASI EFW' driver is supplied by ZWO and it tagged as MDPD so it cannot be aliased and I cannot do what I had hoped to do using aliases.

That is where things currently stand.

Can anyone confirm what an MDPD driver is and why it cannot be aliased?

Read More...

Thanks so much. That worked!

Read More...

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?

Read More...

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

 

Read More...

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).

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.
 

Read More...

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.

$ 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

     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.

Read More...

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);

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;
    sum++;
    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:
     www.planewave.eu/fileadmin/Daten/produkt...cation_protocols.pdf

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.
 

Read More...