×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

At an impasse with CGEM/NexStar USB

  • Posts: 51
  • Thank you received: 0
Has anyone been successful using the Stellarmate with a CGEM or any other Celestron mount with a NexStar hand controller with a USB port connection to the Stellarmate?

The core issue that is blocking operation at this point is what appears to be a conflict in the NexStar hand controller with the USB connection to the Stellarmate or a USB hub.

My equipment:
Raspberry PI 4B, 3B, 3B+
Stellarmate 1.4.4
USB Hubs: D-Link DUB 1340, Sabrent HB-U390, Amazon Basics 4 Port USB 3.0 HUB, High Power Supply System USB3.0 HUB
Mount: Celestron CGEM with NexStar USB hand controller with the latest firmware versions
Operating in local mode with 15 inch 1080P display, wireless keyboard, USB mouse connected
Using 3.5 amp power supply supplied with the RPI4 and the USB hub supplies provided with the hubs

The latest testing has been primarily with the RPI4. It boots very inconsistently and sometimes boots then restarts multiple times before stabilizing. Frequently the USB devices must be disconnected to reboot successfully.

After it has rebooted successfully, it often takes many attempts to connect with the CGEM mount.

The CGEM + NexStar hand controller operate consistently with the hand controller not connected to the Stellarmate/USB hub. When the hand controller is connected to a USB hub or the RPI directly, it does not operate correctly. Commanding motion from the hand controller always results in "No Response 16 or 17" errors, indicating failure communicating with the motor controller. If the hand controller is not used for commanding motion after the USB connection is made, and if the PC connection is made successfully, then the Stellarmate sometimes controls the mount correctly until the "No Response 16 or 17" error is displayed. On one occasion operation was successful for an extended period of time until the Stellarmate was shut down to try another configuration. I have not been able to repeat that success. Testing has been done with multiple USB cables to rule out the possibility of a faulty cable. With one of the cables I cut the 5V wire since that appeared to be connected directly to the 5V power in the NexStar hand controller that was supplied from the mount head. Testing has also been done with a 12vV to 5V converter capable of supplying 5 amps. The supply voltage was monitored with a digital voltmeter.

I have discussed this issue with Celestron technical support. They concluded the problem must be in the Stellarmate. I have requested to be connected with a contact in the NexStar hand controller design team to ask for assistance in diagnosing the problem. If the cause of the problem can be found, I may be able to devise a solution that could be implemented outside the hand controller. I have not received a response yet.

The core problem is that something in the USB hub or the RPI interferes with the communication from the motor controller to the NexStar hand controller. I really want to make this work and am willing to spend some time and effort resolving the issues. All suggestions would be appreciated.

Ed
4 years 5 months ago #44011

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

Hello Ed,

Sorry to hear about your troubles. It is very peculiar because this driver is one of the most used drivers in INDI/StellarMate with numerous users utilizing it on daily basis, myself included.

So it is most likely not an issue in INDI. I actually recall just one user reporting "No Response 17" before and he was using a very old firmware. Can you please specify the firmware version? Also, can you enable the logs (Mount) and attach them after you attempt to connect?
Last edit: 4 years 5 months ago by Jasem Mutlaq.
4 years 5 months ago #44014

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

  • Posts: 51
  • Thank you received: 0
Here is the log file.
4 years 5 months ago #44046
Attachments:

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

  • Posts: 51
  • Thank you received: 0
The attached log file shows activity including slewing to targets even after the hand controller displays the "No Response 16" error.
4 years 5 months ago #44047

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

  • Posts: 51
  • Thank you received: 0
I looked at the log. It appears that there aare no errors reported to Stellarmate but the RA-DEC positions reported afer the error is displayed on the hand controller are incorrect. The mount appears to execute the slew commands correctly and the mount goes to the correct destination, then stops.

This supports my thought that the problem is a hardware issue with the communication path from the mount to the hand controller. It behaves like that communication line is impacted when the USB port is connected to a USB device - RPI or hub.

Do you know how the the hand controller USB port is connected to the link to the mount?
4 years 5 months ago #44050

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

There are no communication issues with the mount. I see however a firmware issue:
[2019-09-29T13:56:20.085 PDT INFO ][           org.kde.kstars.indi] - Celestron CGEM :  "[INFO] Mount model: GPS Series "
[2019-09-29T13:56:22.479 PDT INFO ][           org.kde.kstars.indi] - Celestron CGEM :  "[WARNING] Failed to retrive firmware information. "
[2019-09-29T13:56:22.481 PDT INFO ][           org.kde.kstars.indi] - Celestron CGEM :  "[WARNING] Mount firmware does not support getting pier side. "

So again what firmware is exactly being used? The log debug didn't show this information. Here is what I suggest you edit.

1. Edit the Ekos profile.
2. Uncheck Auto Connect
3. Save profile

Now connect, and in Celestron tab in INDI control panel, go to Options tab and make sure all debugging checkboxes are checked. Then go to main control panel, and click Connect, then try to slew somewhere and then attach the log. This log should be more complete.
4 years 5 months ago #44063

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

  • Posts: 554
  • Thank you received: 138
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.

Chris
The following user(s) said Thank You: Jasem Mutlaq
4 years 5 months ago #44067

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

  • Posts: 51
  • Thank you received: 0
Firmware Versions
HC:GEM 5.31.9102
MC:6.51 6.51

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?
4 years 5 months ago #44090
Attachments:

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

  • Posts: 51
  • Thank you received: 0
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.
4 years 5 months ago #44098

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

  • Posts: 554
  • Thank you received: 138
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.

Chris
4 years 5 months ago #44100

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

  • Posts: 51
  • Thank you received: 0
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.
4 years 5 months ago #44101

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

  • Posts: 554
  • Thank you received: 138
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.

I'll try to see wat I can do tomorrow.

Chris
4 years 5 months ago #44103

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

Time to create page: 1.089 seconds