×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Celestron Motorised Focuser - Is it supported in EKOS yet

Pawel & Chris, thanks for the great feedback! So I agree with Chris we need to get this developed and available ASAP as many users have requested this.

Just now, I pushed celestron_work branch on Github with this commit: 06a254bc4584f7dbe5fe8765f3ae9a8814292bc4
git checkout celestron_work

Just checkout the branch and you'll find two files (celestron.[h,cpp]). It's skeleton ready to be filled with actual commands. I commented most of the code so (hopefully), it should be straight forward to edit. So I believe priority wise, we should work on the following:

1. Standalone focuser driver.
2. Adding focuser support to Celestron driver.
3. Adding focuser support to NexstarEvo driver.

#1 and #2 would probably cover 90% of the users, but once they're out of the way #3 shouldn't be hopefully too difficult.

Chris, please checkout the files. They're included in the CMakelists.txt and drivers.xml, so just compile and install. Let me know if you need any help.
The following user(s) said Thank You: Stefan
5 years 2 months ago #35112

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

  • Posts: 200
  • Thank you received: 57
Chris,

Are you saying that the new HC firmware implements separate commands for focuser control on the level of celestron protocol? Or your ASCOM driver just uses HC pass-thru to use AUX commands for the focuser?

You are absolutely correct that AUX and Celestron are completely different and act on different level. Combining the two is next to impossible - I know I have tried (and failed) to make HC into additional controller (like joystick) for the NSE driver. So we are not going to do that.

Please answer this (if you can):
1) Is there actual extension of the celestron protocol (new high level commands) implemented in HC firmware for focuser control?
or
2) Is focuser only controlable by AUX commands either by USB connection or HC pass-thru serial connection?

In the first case it would make some sense to add focuser to celestron driver and separately to NSE driver. It would still be duplication of some code but at least it would be justified.
If the second case is true I really see no reason to make three identical drivers which differ only in the communication channel.
The following user(s) said Thank You: Stefan
5 years 2 months ago #35113

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

  • Posts: 51
  • Thank you received: 12
Through the HC’s Menu->Utilities, you can get to an option for adding the focuser. I have been building a Arduino-GPS device that connects through the AUX port, and if you try to turn the focuser option on, you can see the serial traffic where the HC is searching for a reply from the focuser.

The HC broadcasts a “hey, are you there?” to all the AUX devices (that includes the motor boards) and only the appropriate one sends a reply.

I suspect most owners of this focuser will already be celestron mount owners. Consequently, they will probably already be connecting their PC through the HC for mount control, and the focuser will be connected via AUX. I’d “focus” on getting communication through the HC’s USB/serial port first. After that, move to a direct USB-focuser module.

I’m being a bit selfish since I plan on making and AUX-Arduino focuser that implements Celestron’s AUX protocol. If INDI’s control goes through the HC, I can ditch my current focuser’s USB and just have AUX/RJ12 cables to the mount.
The following user(s) said Thank You: Stefan
5 years 2 months ago #35117

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

  • Posts: 13
  • Thank you received: 2
I can give remote access to my Stellarmate with attached focusor so you can develop the driver and test it. Just tell me what ports you need open and give me an email address to send the connection details to
The following user(s) said Thank You: Craig, Stefan
5 years 2 months ago #35121

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

  • Posts: 554
  • Thank you received: 138
Thanks for the focuser skeleton, I've managed to check it out and made a start. I'll put all the control stuff in separate files to make it easier to move it elsewhere.

I don't need remote access because I have a focuser.

Chris
The following user(s) said Thank You: Jasem Mutlaq, Craig, Stefan
5 years 2 months ago #35139

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

  • Posts: 554
  • Thank you received: 138
I've got something built and running but it doesn't connect because I get tty error -2 from tty_write.
I've no idea how the serial communication works. The system seems pretty certain that the serial port is ttyACM0 and it doesn't fail until I try to write. All the error code says is that a write fails. The number of bytes written is zero.

I'm not sure what data would be useful.

I threw an ASCOM driver together for this using the same packet processing and it just worked. This seems to show that the principle is OK and my trivial command handling will work.

Chris
5 years 1 month ago #35328

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

  • Posts: 200
  • Thank you received: 57
Check if you have write access to the serial device. Usually you need to be in dialout group to have that right. You van check this using following commands:
ls -l /dev/ttyACM0
groups
Post the output here if you are not sure
The following user(s) said Thank You: Jasem Mutlaq, Chris Rowland
5 years 1 month ago #35342

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

  • Posts: 210
  • Thank you received: 104
Hi Chris,

In complement to checking the access right also be sure the device is not taken by ModemManager, this program as the wrong behavior to think that any ACMx device is for it's own exclusive use.
If you not use analog modem the best is to remove it: sudo apt-get remove modemmanager
The following user(s) said Thank You: Jasem Mutlaq
5 years 1 month ago #35343

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

It is worth noting that I recently made a change to indicom tty_connect. I don't think it affects this but it's worth mentioning here in case anyone else believes otherwise. So now immediately after connect, I use :
ioctl(t_fd, TIOCEXCL)

To make the port exclusive. Also, then the serial device is now opened, it is opened like this:
t_fd = open(device, O_RDWR | O_NOCTTY | O_CLOEXEC);

The O_CLOECEC removes the exclusivity on close. So the rational behind this is that when there are multiple serial devices on the PC, and INDI is set to "Auto Search", each driver will try to open a connection to each device and then the driver would try to perform a handshake to see if there is proper communication going through. If not, it moves on to the next port on the list.

This behavior turned out to be quite problematic since it makes several drivers interferring with each others as each compete to open and test a device. So after the change above, when a device is opened, it is made exclusive (by non-root processes anyway), and any attempt to open the serial port would result in EBUSY. Once the driver finishes the hankshake, it is either a successful hankshake in which the driver continues to use the port, or a failed handshake in which case the driver closes the port thereby ending the excluscivity lock. So far this behavior results in a more reliable connection experience and I can connect "blindly" to all my observatory serial devices with this method, while before the exclusivity bit one one or two devices connect and the rest fails.

This feature has yet to see more testing to see if it leads to any side effects.
Last edit: 5 years 1 month ago by Jasem Mutlaq.
5 years 1 month ago #35347

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

  • Posts: 554
  • Thank you received: 138
Thanks for the feedback, I'll try to answer the questions here and provide more information.
ls results:not sure what type c is.
Read and write access for the User and Group, no access for other
User is root, group is dialoutI have a dialout group.

I've removed the modem manager and restarted.

Nothing has changed, this is the kstars log data
And this is the relevant part of the kstars log file:It seems to connect.
The CS: line is the checksum calculation, this is OK.
The two data lines are the packet to be sent, these seem OK.

Then tty_write returns -2 with the number of bytes sent - br - as 0 so I fail.

The code that does this is:
void AuxCommunicator::Connect(int portFD)
{
    serialPort = portFD;
}
 
bool AuxCommunicator::sendPacket(AuxTarget dest, AuxCommand cmd, buffer data)
{
    AuxPacket pkt = AuxPacket(cmd, src, dest, data);
    buffer txbuff;
    pkt.fillBuf(txbuff);
    int br;
    int tty;
    int len = txbuff.size();
    char buf[len];
    fprintf(stderr, "buff len %x:", len);
    for (int i = 0; i < len; i++)
    {
        buf[i] = txbuff[i];
        fprintf(stderr,"%2X ", buf[i]);
    }
    fprintf(stderr, "\n");
 
    tcflush(serialPort, TCIOFLUSH);
    tty = tty_write(serialPort, (const char *)buf, len, &br);
    fprintf(stderr, "sendPacket br %x tty %x\n", br, tty);
    return tty == TTY_OK;
}
Is there a way to get more information about why the write failed? All that reply gives is TTY_WRITE_ERROR.
5 years 1 month ago #35349

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

  • Posts: 554
  • Thank you received: 138
This code works:
#include <iostream>
#include <stdio.h>   /* Standard input/output definitions */
#include <string.h>  /* String function definitions */
#include <unistd.h>  /* UNIX standard function definitions */
#include <fcntl.h>   /* File control definitions */
#include <errno.h>   /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */
 
using namespace std;
 
int main()
{
    cout << "Hello World!" << endl;
 
    int fd = open("/dev/ttyACM0", O_RDWR);
    if (fd < 0)
    {
        cout << "open fail " << fd << endl;
        return 0;
    }
    unsigned char outbuf[] = {0x3b, 0x03, 0x22, 0x12, 0xfe, 0xcb};
    int ws = write(fd, outbuf, 6);
    cout << "written " << ws << endl;
 
    unsigned char inbuf[20];
    int rd = read(fd, &inbuf, 10);
    cout << "read " << rd << ":";
    for(int i = 0; i < rd; i++)
    {
        fprintf(stdout, " %02X", inbuf[i]);
    }
    cout << endl;
    int cs = close(fd);
    cout << "close " << cs << endl;
    return 0;
}
The output is:I'm not even setting the baud rate, I suppose that was inherited from the previous tries.
5 years 1 month ago #35352

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

  • Posts: 554
  • Thank you received: 138
I've got communication going.
It turned out that I wasn't setting the port ID in my AuxCommunicator. I thought I could do it by passing PortFD to the AuxCommunicator once at connect time but the code to do this wasn't being called. Adding PortFD to the parameters for every call to the AuxCommunicator worked.
The move and/or position isn't working correctly but Abort works. Just a matter of debugging.
Always the way, it's the simple things that get you.
Chris
The following user(s) said Thank You: Jasem Mutlaq
5 years 1 month ago #35353

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

Time to create page: 1.098 seconds