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.
From what I can see my focuser has a vendor id of 15A2, product Id A50F and product Celestron Focuser. It appears as ttyACM0.
I'm going to have to leave much of this to you Jochym and Jasem. Your discussion has lost me.
A couple of things:
There are basically two different connection methods:
1) The connection to the serial/usb serial post on the base of the HC. This communicates with the mount using the hand control. It is the normal way that people control these scopes using the pointing model implemented in the HC.
2) The connection to the Aux bus. this communicates directly with the motors and does not involved the HC. It does not use the HC mount model at all.
These two control methods use totally separate control methods, they may both be serial but that's where the resemblance ends. They use different baud rates and different packet structures even for commands that are sent directly to the motors.
I think that trying to combine these would be so complex that it isn't worth it. All that can be considered to be common is the device Ids and commands, a couple of enums.
What I'd do is add the focuser to the current celestron telescope driver. That allows people who want to control the telescope and focuser through the serial port on the HC to get going. It sholdn't be difficult and is what I did to add the focuser to the ASCOM telescope driver.
Nexstarevo isn't currently mainstream so I would start with a separate Celestron USB focuser driver. This is intended to be used when the focuser has it's own separate connection but with sensible development and testing can be merged with naxstarevo when it becomes main stream.
This may not be totally optimal but should get a focuser driver in the hands of the users rather faster. Trying to combine the Hand Control and Aux Bus control will I believe be more complex than the small amont of saved code will justify.
Celestron seems to manage multiple devices working on the same aux bus by using a hardware method that is based on the hardware lines RTS and CTS. This doesn't involve the aux bus protocol. This seems to avoid most collisions because a device won't transmit if it sees that something else is using the bus. Any that are left are managed by timeouts and retries.
They must have got this sorted because they have been operating perfectly happily with situations where there are multiple controllers, such as a Hand control and a PC program such as NexRemote running the same mount at the same time.
Hope this makes sense, I can see that you have been having quite a lot more conversation while I've been composing this.
Thanks Jasem, I'll look out for the new branch.
I think you are right, it needs a dedicated Celestron USB focuser driver and ideally adding a focuser to the nexstarevo and Celestron telescope drivers.
I'm not sure how the focuser is seen by Linux but in Windows it is a serial port. It seems to use the same connection as the USB port on the mount. I guess that the tty commands should work. The baud rate is 19200.
I'm not sure how the system prevents commands from different devices stepping on each other, I think it's by using the flow control lines CTS and RTS. This won't be an issue for a single controller connected to a single device.
Nexstarevo seems to use a UDP socket, however that seems to be because it only uses the WiFi connection.
I have a Celestron focuser that I will be able to use for testing once there's some code to try.
I can help because I implemented the combined ASCOM telescope and focuser drivers. Celestron provided me with a beta version of the focuser.
There are a number of possibilities for connecting:
a) Connect the focuser to the mount and use the connection to the AUX bus for the telescope and the mount. That could be an extension to the nexstarevo driver.
b) Connect to the focuser independently of the telescope using the focuser's USB port. This also used the AUX bus connection.
c) Connect the mount and focuser using the AUX bus connector, not the focuser USB connection, and use a connection to the base of the HC to control both the telescope and focuser. that uses the same commands but through the HC passthrough engine.
I described some commands a few days ago, some more are:
// Focuser commands
FOC_ENABLE_CALIBRATE = 0x2A, // send 1 data byte 1 to start calibration, 0 to stop
FOC_IS_CALIBRATED = 0x2B, // return 2 bytes,  != 0 for calibrate complete,
//  is calibrate step, up to 12
FOC_GET_HS_POSITIONS = 0x2C, // returns 2 uints,  is low and  is high
I'm not an expert with INDI or C++ so setting up the structure of the various drivers is something that would be better left to the experts but once there's something there I should be able to help with debugging adding functionality.
The packet protocol is:
3b - signal the start of a packet
03 - number of bytes up to the checksum
22 - the transmit device ID
12 - the receive device ID in this case the focuser
fe - the message ID, fe is get firmware version
cb - a checksum, there is no data
The reply is similar, there are now 7 bytes and the send and receive are reversed.
There are 4 data bytes, 07 0f 20 30, not sure how this is parsed.
These 2 sequences start the focuser talking:
3b 03 22 12 fe cb --connect -->3b 07 12 22 fe 07 0f 20 30 61
3b 03 22 12 40 89 --?????? -->3b 04 12 22 40 00 88
That's command 40, I think that's reading the backlash, reply is 1 byte giving zero backlash
Focuser continues to send this while you are connected.
3b 03 22 12 01 c8 -->receive 3b 06 12 22 01 ignore last 4 bytes, appears to be counting (3b 06 12 22 01 00 83 59 e9 ) or timestamp
Command 01 is get position and the reply is the focuser position as 3 bytes, a 24 bit number.
Commands 24 and 25 are move at a rate 0 to 9 with zero being stop 24 is positive move, 25 is negative.
Command 02 is move to position, the next three bytes are the position.
Hope that helps.
Yes, using the same port as used by the telescope in much the same way as the Meade does.
Yes, it's the same passthrough commands as the telescope axis motors. I chose not to implement backlash and calibrate, I see calibrate in particular as something that's better done by the Celestron software. What it does is to move to each end of the range looking for the hard stops. When it finds them it remembers their position.
For the question about using an Arduino based focuser, in theory it would be possible to connect it to the mount internal bus and reverse engineer Celestron's internal bus protocol but I don't see any benefit, especially as the Arduino already has a perfectly good USB interface that allows it to connect independently. The internal protocol uses the same commands but is different to the passthrough protocol used by the HC.
I implemented the ASCOM driver for this focuser connected through the serial port on the base of the hand controller. Celestron did their own ASCOM driver for when it's connected independently using the USB port on the focuser.
The focuser motor uses the same commands as the other motors and is controlled using the same pass through method as used by the telescope driver. This works as follows
The focusMotor device ID is 0x12
Command MC_GET_Position = 0x01 This sends no data and returns 3 bytes containing a 24 bit unsigned integer with the position.
Command MC_GOTO_FAST = 0x02. Three data bytes containing the position as a 24 bit unsigned integer. It's an absolute move only.
Command MC_SLEW_DONE = 0x13. This returns 1 data byte, if it is 0xFF then the slew has completed
Command MC_MOVE_POS = 0x24 with 1 data byte containing 0. The data byte could contain values 0 to 9 where the value is the various rates with zero being stopped. Ant movement is in the positive direction, there is a corresponding MC_MOVE_NEG command which will move in the negative direction. I only use this with 0 to halt movement.
Command FOC_GET_HS_POSITIONS = 0x2C. Returns 8 data bytes containing the low and high limits as 2 32 bit uints.
The data byte order seems to be the opposite way rount to what the PC uses.
I check the focus motor exists usingthe get version command.
Normally a user will want to control the telescope as well and so the focus and telescope driver have to be integrated, I'm not sure how that would be done in INDI.
All that NexRemote does is provide an emulation for a handcontrol, it can only run the legacy NexStar controller code, up to version 4.22. It only runs in Windows. I'm not sure this would help.
The short answer is that it isn't possible to do an alignment remotely beause the align commands are'nt available in the command set. By align I mean the sort of alignment using pointing to multiple objects in the way that you do using the HC. Also the alignment depends on the mount starting at the home position with the hour angle axis at 6hrs and the dec axis at +90 deg.
There are things that you can do.
The current Park and Unpark processes do to samr as the HC hibernate and Wake up, this allows an alignment that has already been done to be recovered.
The snag with this is that it requires that the mount is parked before the power is turned off, if the power is just turned off then the mount position is unknown.
With most mounts there is very little that can be done because the starting position of the mount is unknown. It's assumed that the position is +90 in Dec and 6/18 hrs in hour angle.but there's no way to tell or in most cases to get there. The exception is for the mounts that have home switches where a command exists to drive to the home switch position. with this it should be possible to do the equivalent of a quick align by driving the motors to the home switch position and setting the axis positions. It's possible to operate from that by doing a solve and sync to get a good local alignment.
Doing a solve and sync from where the mount happens to be pointing might work but only if the scope can see the sky and in the case of a mount in a dome the scope may not be able to see out. There's also a pathological case if the mount happens to have tracked past the meridian.