×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Problem connecting to PlaneWave EFA - Handshake fails

  • Posts: 29
  • Thank you received: 11
I am trying to connect to the PlaneWave EFA (focuser) unit, which connects via a labyrinthine 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.


Additional info: I tried a different serial-to-USB connector I had laying around and obtained the same result (handshake fails). So the Digitus unit is not the culprit.

 
Last edit: 2 years 6 months ago by John Mocenigo. Reason: clarity
2 years 6 months ago #75947
Attachments:

Please Log in or Create an account to join the conversation.

Does it work with their official software using the same baud rate?
2 years 6 months ago #75968

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
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);
}
2 years 6 months ago #75978

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
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.

 
2 years 6 months ago #75995

Please Log in or Create an account to join the conversation.

So the EFA was previously tested already on a couple of real devices and it works OK. Is there some sort of firmware update available for your unit?
2 years 6 months ago #76002

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
     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.
The following user(s) said Thank You: Jasem Mutlaq
2 years 6 months ago #76036
Attachments:

Please Log in or Create an account to join the conversation.

Can you debug the driver and step-in in sendCommand function to see what's going on? I see a bunch of RTS/CTS actions, could they be related?
2 years 6 months ago #76040

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
I just made some progress and got version information back (in one of my many attempts to try different things I changed the baud rate and forgot to put it back).

Things are not entirely working so I will play with it some more and report back in the next 24 hours or so.
Last edit: 2 years 6 months ago by John Mocenigo. Reason: Corrected entry to remove outdated information made irrelevant.
2 years 6 months ago #76060

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
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.
 
The following user(s) said Thank You: Jasem Mutlaq
2 years 6 months ago #76076

Please Log in or Create an account to join the conversation.

So what was it? not just baud rate?
2 years 6 months ago #76102

Please Log in or Create an account to join the conversation.

  • Posts: 29
  • Thank you received: 11
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.
The following user(s) said Thank You: Jasem Mutlaq
2 years 5 months ago #76116

Please Log in or Create an account to join the conversation.

Thank you for your detailed and through investigation of this issue, it's greatly appreciated! Looking forward to the PR whenever you feel it is ready!
2 years 5 months ago #76154

Please Log in or Create an account to join the conversation.

Time to create page: 0.661 seconds