Thanks Fabrizio! I suggest we discuss the code at github. The changes are substantial - thus we need to make sure the driver keeps working for the TCP connection users. I would really like to avoid any functional regressions. Please, be patient with me - I have a lot on my plate at the moment but will try to work on this PR as much as possible.
Great! That was on my todo list for months now. Would it be too much to ask from you to provide a standard pull-request against the 3rdparty indi repo? If you do not know how to do it i will generate one based on your changes - but tracking-wise it would be beter to heave you do it. You need to basically fork the repo to your github, copy your changes over it and generate the PR from the repo. The driver development really suffers from the lack of testers and developers. So any help is appreciated!
I am really glad you succeeded to set up the driver in this untested configuration. Regarding the speed of approach: this is controlled by the motor controllers' firmware. It is supposed to move with normal (full speed) to the position shifted by constant angles in both axis from the target and then approach the target by slow goto. The speed of both is generally not controlled by the driver (you can set the speed of fast goto).
I am not sure I get the problem. Maybe you can make a movie of your scope executing the goto and upload it to youtube?
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
Post the output here if you are not sure
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?
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.
Jasem, should this be a library or some kind of driver? I do not know the INDI architecture well enough to decide which is better. What would you suggest?
BTW I wonder if the USB connection gets all the messages on the AUX bus or only the focuser's?
If it gets all traffic from the AUX bus this will be another way to connect to AUX bus without any additional hardware converters.
Exactly Jasem. We would need to remove and use the AUX protocol implementation from the NSE driver, add serial line and HC-pass channels and make it into kind of server for the drivers. The usb case should be handled by starting separate instance of the server for this connection. The drivers will just get the data they register for, this should not be very difficult.
We have a similar case with the GPS emulator implemented inside NSE. Sometimes you just need a GPS for your scope but you need to load the mount driver for it and risk interference with HC operations. I would separate theis emulator into separate driver as well.
Chris, there is no target arbitration in the AUX protocol. All messages are broadcast over all devices and sockets. The HC pass-thru filters responses so you get only replies to your commands (you cannot snoop messages of other devices) - this will make gps emulator in nextstarevo not working over HC serial connection. But you cannot connect two drivers to one serial line they will disrupt each others' communication by eating characters from the buffer. It will be the same for the NSE driver (it uses TCP for comms UDP is just the scope detection) - the WiFi chip in the scope can serve only one connection at the time. The focuser would need to be implemented inside standard celestron driver, separately and inside nexstarevo driver. Only driver using usb would not conflict with others since this is a separate physical connection and usb layer handles the switching.
Adding the focuser to the nexstarevo would be simple.
Add new target and commands in NexStarAUXScope.h, add next axis in the processCmd selector for motor commands in NexStarAUXScope.cpp, and either process them the way emulateGPS is implemented or rather as one more axis. The rest is adding Focuser API
to nexstarevo.cpp/h using the additional axis in NexStarAUXScope.
But let me note that this will force everyone to load the nexstarevo for the focuser. This is non-intuitive and suboptimal. Three separate drivers is even worse - they will conflict with each other and will contain unnecesary duplication of code. I think that the factorization of tcp/serial code done some time ago by Jasem should be our model here. The rest is just a driver keeping track of motor position/movements and the INDI API/GUI.
I "bet" it is just usb->serial converter connected to aux bus. This is the way Celestron does things. It would simplify things. We would not need three drivers just one and the abstraction leyer for the communication. As a side effect It would make implementing support for other mounts in nexstarevo driver trivial. And the protocol part is ready in nexstarevo driver.
We need common communication "server" inside INDI. I just do not know how to go about it.
Jasem - any ideas? Is there a driver model we can use or should it be a library providing singleton object menaging comms?