There are commands sent to the mount at start up which identify the HC version, the HC type, the mount model, if it's a GEM or not and the motor controller versions. These are used to determine what the mount is capable of. The verbose logging was turned on after the mount was connected so the detail of this wasn't shown.
The "Failed to retrive firmware information" warning indicates that for some reason the HC didn't respond to the "V" command used to read the HC version, I don't know of a reason this woud happen for any HC produced by Celestron in the last 15 years.
That causes the communication to revert to the simplest mode, the low precision "E" command to read the position confirms this but that these commands work indicates that some sort of HC is connected.
We need a full, verbose log from the start of the connection attempt AND the exact HC version read from the HC display using the menu commands. "The latest" is not good enough.
I reflashed the sdcard. The date in the logs is not correct.
All verbose logging was enabled.
Note that the error, "No Response 16", is displayed on the hand controller before kstars is started. When the RPI4 is started, kstars starts automatically. I terminated kstars, connected the hand controller to the RPI4, observed the error, cleared the error, then restarted kstars.
The error does not occur when the hand controller is connected to my Windows laptop. Because the error occurs when the hand controller is connected to the RPI4 when kstars is not running, it would seem that the problem is with the physical connection and unrelated to the kstars/INDI software. Can we connect with the RPI4 design team to ask for assistance?
For several years I worked on interopability testing in the wireless communications field. This looks like a classic case where both sides of the communications link work with everyone else's equipment, but they don't work together. Getting the teams on both sides to work together to investigate and resolve a problem experienced by one retail customer is highly unlikely.
I would like to know if any other people have used StellarMate with a NexStar USB hand controller. I suspect that most folks use the NexStar hand controller with an RJ11 port that requires an external USB to serial RS232 converter.
Looking at your log file:
[2019-09-19T14:12:08.136 UTC INFO ][ org.kde.kstars.ekos] - Celestron CGEM Version: "3.2" Interface: 5 is connected.
[2019-09-19T14:12:08.237 UTC INFO ][ org.kde.kstars.indi] - Celestron CGEM : "[INFO] Controller version: 5.31 "
That's good, NS+ HC version 5.31
There's no mount communication information, that's a problem because the next mount information is:
[2019-09-19T14:12:10.123 UTC INFO ][ org.kde.kstars.indi] - Celestron CGEM : "[WARNING] Unrecognized model (-1091685556). "
[2019-09-19T14:12:12.518 UTC INFO ][ org.kde.kstars.indi] - Celestron CGEM : "[WARNING] Failed to retrive firmware information. "
[2019-09-19T14:12:12.520 UTC INFO ][ org.kde.kstars.indi] - Celestron CGEM : "[WARNING] Mount firmware does not support getting pier side. "
The lack of mount communications is a problem because the model number is critical, this should be a fairly small positive integer. I'm not sure how to force the verbose debugging earlier in the connection process.
Verbose logging doesn't happen until later:
[2019-09-19T14:12:22.022 UTC DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[DEBUG] Toggle Debug Level -- Scope Verbose "
[2019-09-19T14:12:22.823 UTC DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[DEBUG] CMD <E> "
[2019-09-19T14:12:27.438 UTC DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[DEBUG] RES <D6FE,0BD1#> "
[2019-09-19T14:12:27.439 UTC DEBG ][ org.kde.kstars.indi] - Celestron CGEM : "[SCOPE] RA-DEC (20:09:20,16:37:01) "
What this tells us is that there's no obvious problem with mount to driver communication but there seems to be a problem with reading the initial mount properties. I'll try to see what I can do about getting more information but I don't have the same mount. It may be possible to trigger the verbose logging a bit earlier that would help.
However in the light of your latest rather snide comments you would rather I didn't bother I quite understand. It's going to be a bit of work because I don't happen to have a development environment at the moment.
Sorry. It was not intended to be a snide remark but a statement of the difficulty of resolving an interoperability problem. The stellarmate team has been exceptionally responsive to questions and comments. When I first tried the RPI4 and experienced problems working with my Canon DSLR, Jasem connected with my SM using TeamViewer to diagnose the problem.
It sounds like the log confirms that the communication between the RPI and the hand controller appears to be working correctly but there is a problem with the communication between the hand controller and the mount head motor controller.
It's difficut to say what is happening. The log shows problems with connecting at startup but the lack of logging of what bytes are actually returned is a problem. The message that is giving the incorrect value doesn't in itself communicate with the mount but is relying on messages it has obtained from the mount. No Response messages on the HC indicate some sort of problem with communicating with the mount.
All I can do is try to get information from my AVX mount to see if there's a way I can suggest getting more information.
I'm not sure what you mean by what you are writing about connecting the HC do you mean to the mount?
I would start by having the HC connected to the mount and the RasbPi connected to the HC. All the physical connections made. Then turn the power on to everything and do an alignment. A quick align is good enough. Then start Kstars and connect to the mount.
It's possible to set EKOS and the driver to get verbose logging of the startup commands in the driver this is what I did:
Edit the profile so the drivers do not start automatically.
Set the logging in the EKOS setup to verbose and to file for the mount.
Start the INDI Control panel and in the Celestron GPS and Options tab enable logging and check all the debug levels, logging levels and log levels.
Save the configuration.
Only now connect the driver.
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.
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?
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.