I'm not sure about minicom, the only way I communicate with the Celestron mount is using the serial port on the base of the HC. Even the USB port appears as a serial port.
It's possible to communicate with a GPS module if you have one by using the commmands in Andre's document and the AUX bus commands, these are sent using the
int CelestronDriver::send_passthrough(int dest, int cmd_id, const char *payload,
int payload_len, char *response, int response_len)
method.
dest is the device id cmd_id is the command and so on. There's an example of using this in the Pulse Guide command.

Personally I wouldn't bother with getting time or location from the GPS, the HC will connect to the GPS and updaate it's internal time and position. Also some mounts, such as the AVX don't have a GPS but do have a RTC. This can be read in a similar manner as the GPS but with a different device id.
I'm not sure why the time and date can't be retrieved when the mount is aligned. I don't hve a problem doing this. There's a recommendation that the time and location are not updated when the mount is aligned because these are used in calculating the local sidereal time and so changing them affects the alignment.
Looking at the logs both the log_starsense and log-nexstar logs are actually using a starsense HC. I can tell this from the controller version and variant.
The low version number seems to cause the driver to use the low precision 'E' command to get the ra and dec rather than the high precision 'e' command. This is fine with the starsense.
The third does use the nexstar HC. Incidentally earlier version of the HC dn't support the 'm' command and these will give a timeout error. Easy to trap and assume it's not Starsense.
I'm not sure how any of the logs are determining if the mount is aligned, there's a command that will do this - 'J', it returns 0 or 1.
Hope this hurried response helps, I'm going to have to get the QT environment set up and start learning how to debug.
Chris

I hadn't even tried connecting my AVX to the Pi, didn't anticipate any issues. BIG mistake.

When I tried it things are really strange. Slews are all over the place, the HC produces slew limit exceeded messages, KStrars doesn't display the correct, or expected, mount position. Errors in the status line at the base of KStars but practically nothing in the log files.
It looks as if the serial communication is very unreliable, what messages I do get seem to show lots of timeout errors.

The identical hardware plugged into my Windows machine works perfectly using my ASCOM driver. Not casting stones, just a data point.

What I've done is:
Start mount and do a Quick Align.
Use EKOS to get a connection to the CelestronGPS driver.
Back to KStars and point to various stars and slew to them. I'm currently using Altair and Vega.
The USB to serial interface is a fairly elderly FTDI, it's been rock solid for years.
Will persist some more tomorrow, maybe I will be able to get more out of the logs.

Chris

It looks as if the problem is with my hardware.

If I connect the USB to serial adaptor directly to my Pi it's fine, but if I connect the adaptor through a brand new 7 port USB hub then the serial communication seems to be unreliable. I see communcation failures and the mount does some very strange things. I guess that the commands being sent have been corrupted in some way.

Chris

Yes, that was applied long ago. Regarding the time/date, this is the code right here:
So AVX was disabled due to this. Now you can try recompiling this and removing && fwInfo.Model != "AVX" from celestrongps.cpp file to see if it would with your mount, but it was a report by another user that the AVX mout times out. Can you perform such a test and see if the problem remains there?

Thanks Jasem!

I will do it today and I'll keep you updated about results.
Lucian

I've enabled the 'h' command with my AVX running a StarSense HC version 1.19 and there's no problem reading the time. This isn't a surprise because the HC commands tend to follow the HC type and version, not the mount type.

Chris

I've updated the driver, can you pull and test it?

Your test will fail with StarSense HCs because their versions are less than 2.3. What I implemented is:
if (checkMinVersion(2.3, "read time"))
This uses a different version for the StarSense controllers.

Not sure I can pull your code into my branch but I'll try.

It won't fail because in checkMinVersion(...) it's checking if it is StarSense and will check if it >= 1.18 so it will pass.

Yes, we have implemented the same code, I got confused looking at the diff.

Hi Jasem,

Yes, I did it today, worked like a charm , thanks!

Regarding StarSense: I didn't had the time to do thorough tests, I had some mechanical issues with my mount, but I can't confirm yet that StarSense is working OK, i"ve noticed some issues and I think that on the sources are some extra restrictions in addition to the NexStar+, I will check that over the weekend. (I hope)

On the other hand, so far I can tell that NexStar+ works quite OK regarding the GPS module issue if recompiled with && fwInfo.Model != "AVX" removed.
I've noticed this: If kstars was stared and INDI server was started once, stopping the client - and RasPi (StellarMateOS) was kept running, then starting again kstars (locally on RasPi or/and remotelly on other linux client) produced driver error messages complaining about RA coordinates. After disconnect/connect AVX driver from INDI Control Panel, everything was fine. I can live with it

Nevertheless it was only a dry test battery - I've done Only QuickAlign then track to Polaris, but I assume that the driver works just nice. No other errors, no crashes.

I will greatly appreciate a "crash course" or a comprehesive tutorial link on how to :
- connect from a linux shell on serial to the NexStar/StarSense
- issue commands over connected terminal to the HC
It's pure curiosity
... for now! )

Btw, is there a list of dependencies for kstars building on opensuse? cousin google wasn't very helpful

Cheers,
Lucian