I will be out of town until 10/12 so I will not be able to do any testing on the RPI/mount until then.

There was a question about what I meant about the connection from the NexStar hand controller PC port to the mount. The 2 ports - HC port and AUX port - on the mount serve identical purposes. The HC and GPS can be connected to either port and the HC can also be connected to another port on the SkySync GPS. My question is about the internal connection between the PC port on the HC and the cable on the HC that connects to the mount. It obviously can't be a direct connection because the PC port is a USB input and the connection to the mount is something else - maybe RS232 serial but with the levels translated to 5V only instead of the bipolar signals of an RS232 port. But there is definitely some interaction between those 2 connections. And what I have heard about bypassing the HC and connecting the PC directly to the mount suggests that the communication protocol from the PC is equivalent whether the PC is connected to the HC PC port or the mount HC port. So the HC must simply be passing traffic between the two ports. Is this correct?

There's nothing more to do until you can provide the data I asked for.

Most of whay you are assuming about hw the various connections work is incorrect.
The AUX and HC ports on the mount are the same, They are connections to the mount internal bus this is RS232 style using TTL signal levels and running at 115000 baud. It uses an internal protocol which we do not use. The USB port on the mount also connects to this AUX bus and it shows as a serial port.

The connector on the base of the HC is a RS232 serial port running at 9600 baud using the published NexStar protocol. If the HC has a USB connector there is a USB to serial adaptor in the HC, if a J type connector then there is a converter to RS232 signal levels in the HC and a Rs232 to USB adaptor will be needed. There is not other difference.

The HC provides a lot of the computing, and provides data such as RA and Dec, slew control, side of pier, location, time etc. There is a passthrough command that allows the HC communicate with devices on the AUX bus to get thing such as axis position and to sent the guide commands to the hour angle axis motor.

The Celestron GPS driver can only connect to the port on the base of the HC. It doesn't matter if it is a RS232 port or a USB port, they are, to the software, they same, a serial port.

There are applicatons that can connect to the AUX bus, Celestron's CPWI for example, but these applications have software that does the work of the HC. The Celestron GPS driver does not do this, it is designed to communicate with the HC.

Anyway, nothing more to do until you can get some log data to me. I'm away from October 12th to 28th so it may be November before much happens.

Chris

Chris,

Thank you for the detailed information about the functionality of the different ports. I had not been able to find that information anywhere.

That opens some questions about the EQMod software. Does it work only with mounts that have the required computational functions in the mount head? Or does it provide this functionality in the software?

Ed

EQMod is for Skywatcher mounts, not Celestron isn't it?

The Skywatcher mounts operate in the same way, an internal bus that connects the HC to the axis motors and only handles low level commands such as axis pposition, move to axis position, move axis at a fixed rate. EqMod communicates directly with this bus, replacing the functionality of the HC.

AFAIK no one has done a version of EqMod that will handle the Celestron mounts but in theory it should be possible. There is also a 3rdParty NexStar Evolution driver that atempts to communicate with the motors directly and handles the mount alignment model. I don't think it has been implemented for equatorial mounts, just Alt Az.

Chris

Chris,

Here is a new log file with the procedure you requested. It still looks like the mount does not report the firmware versions correctly. Is this helpful?

Ed

The log shows communication with the HC but mount type reported is 0 which is th earliest NexStar GPS and the only command to read the hardware version fails. As a result the driver assumes that the mount i the mount is the very simplest type.
It looks as if communication between the HC and the mount is flaky, the No Response 16 or 17 messages on the HC are another indication of that. This communication is up to Celestron and there's nothing I can do. You need to get back to Celestron, The No Response messages are the key. It would help if you can provoke those messages just using the HC with no connection to anything else. That will help Celestron sort this out.

Chris

That confirms my earlier conclusion that the connection to the RPI causes a failure of the communication between the mount and the HC. I have opened a topic on the Team Celestron forum.
teamcelestron.com/viewtopic.php?f=69&t=1551

Ed

I can't think of a reason that connecting to the port on the HC stops the mount to HC communication. One thing to try is the ASCOM driver, that sends much the same commands as the iNDI driver, if anything more commands through the HC to the internal bus. A log of the ASCOM startup sequence could be useful for comparison.

Also lots of other people are using the INDI driver so it really doesn't look like a generic problem.

I'm on holiday and don't have access to TeamCelestron at the moment, nor any hardware or a development environment but will have a look in November.

Chris

I thought the ASCOM driver was a Windows driver. Is there a version that works with the Stellarmate? If so, how can it be selcted?

There appear to be 2 drivers that may be associated with the CGEM mount. One is listed as 'Celestron CGEM', and the other is listed as 'Celestron NexStar'. Which one should I be using? The same problem is seen with both drivers.

After performing a series of diagnostic steps requested by Celestron Technical Support, they had concluded from my description of the problem and the results of the diagnostic steps, that the problem must be with the Stellarmate software. Chris, you have been extremely helpful with investigating the issue. And the logs support my conclusion that although the problem is experienced when the mount is connected with the Stellarmate, the failure is in the communication between the Celestron mount and the Celestron hand controller. I am not yet willing to give up on Stellarmate because it is the best tool for my requirements. And I am not ready to dump the CGEM and purchase a different mount. As a retired engineer with hardware design and software development and testing experience, I know that this is a solvable problem and one I can solve if I have the appropriate tools. Celestron has agreed to provide me with a NexStar hand controller with a serial port to test. In addition to that, I plan to probe the Celestron internal communication bus with an oscilloscope to see if there any apparent electrical changes when the Stellarmate is connected. Beyond that, I would need guidance and diagnostic tools from Celestron to investigate the issue. It remains to be seen how much support they would be willing to provide.

Chris, Thank you for your help. Let me know if you have any connections with Celestron that might have the knowledge to assist with this investigation.

Ed

Thank you for your exhaustive testing. I might have an idea of something that might help. Can you please open a ticket at stellarmate.com? or send email to This email address is being protected from spambots. You need JavaScript enabled to view it. to get this issue resolved. We'll try different ideas and then if something works we'll announce it back here.

A ticket has been opened.

Ticket Details
Title CGEM/NexStar+ USB communication failure when connected to StellarMate
Reference EOWB-000488
Product StellarMate
Category StellarMate App

The ASCOM driver is for Windows, and works on a Windows system, not a RPi. It's just another way to see if using the HC port affects the internal communication.

I can't do any more until November.

Chris