Losmandy Slew goes haywire

Hi,

I've been having trouble with slews on my GM811G going haywire. It seems to happen later in the night after I've done several slews and imaging. I've collected the logs using -vvv for verbose logging. I've attached two files, one with an example of a good slew that happens just before things go bad, and one of the bad slew where things do go bad. I've manually deleted all the "blob" entries to keep the files from being huge. One thing that I noticed is that the bad log has several timed guides that happen after the slew starts, and before it ends. I don't know if this is an issue or not.

My setup is a RPI4 running ubuntu with all software compiled from source. Here's the tags / hashes for the builds:
phd2: git checkout tags/v2.6.8
kstars: cb09caa450bd34dca287ecf4be66ca15aba35cd8
indi: c144a26516796b62ad5a47d199752c39d271c580
indi-3rdparty: c823a373521f35214b2d651858bb87057ad7c49f


I'm running kstars and guiding with phd2. I've set phd2 to not guide during slews, but it seems to be doing some guide commands anyway.

Here's a link to a discussion I started on the Losmandy Group, hope this link works:

groups.io/g/Losmandy_users/topic/tcp_con...ky,,,20,2,0,74343653

Sounds very much like what Magnus was seeing on his G11.

indilib.org/forum/general/6995-help-unde...t-happened-here.html


Chris and Jasem found a reproducable problem within the Gemini mount:

indilib.org/forum/general/6995-help-unde....html?start=12#54689

Thanks for that link. That does seem to be the same issue. I have also discovered something tonight. From the logs of successful vs unsuccessful slew a difference that I noticed is that the failed slew has guide pulses happening after the slew is issued. I use PHD, and have checked the "don't guide while slewing" box, but somehow guide commands are still getting through. I tested the idea that the guide pulses are triggering this bad behavior, and was able to confirm it. I did almost a dozen slews around the sky with no problems. I then started guiding, and did a single slew, and it went haywire. It seems that the mount/gemini is supposed to handle this gracefully, but it does not. It also seems that phd2 is not supposed to be sending guide pulses if a slew was started.

amendolajamie wrote: Thanks for that link. That does seem to be the same issue. I have also discovered something tonight. From the logs of successful vs unsuccessful slew a difference that I noticed is that the failed slew has guide pulses happening after the slew is issued. I use PHD, and have checked the "don't guide while slewing" box, but somehow guide commands are still getting through. I tested the idea that the guide pulses are triggering this bad behavior, and was able to confirm it. I did almost a dozen slews around the sky with no problems. I then started guiding, and did a single slew, and it went haywire. It seems that the mount/gemini is supposed to handle this gracefully, but it does not. It also seems that phd2 is not supposed to be sending guide pulses if a slew was started.

I have not read any posts about PHD2 not suspending guiding during slew with any mounts. I am ignorant on this subject due to no experience with PHD2 and StellarMate as I use 'pulse' guiding.

Have you tried using pulse guiding and see if it does the same?

Cheers
Jim

Hey, G11 and G8 owner, here.
Do you have a real time clock on the Pi4? With StellarMate on Pi3, once I made sure my RTC was configured, the issue with the G11 resolved.
I ran into the same problem with Astroberry on Pi4 and G8, but this time with RTC, found that once I switched cables with the G11, it was good, so my cables are faulty on the G8- waiting to replace them. Are you using the latest firmware update on the Gemini2? USB or LAN? I've always stuck with the USB-B. Are you using the newer Gemini2 (with only one 12V input)?
I also had issues with the G11 after RTC issue resolved them, but that was back when I was grabbing nightly builds whenever and it resolved after reverting to last stable build, if I even remember that situation correctly- this was also with StellarMate on Pi3.

I have issues with my Losmandy mounts often- I boil it down to half me and half mount/OTA. Really not sure why I stick with it, but I see others with such great success, leaves me confused often.

Best of luck, I'm curious to see how it turns out for you. I'm currently on a mission to get the PiZeroW powered by the Gemini USB-A port with dongle and connected to the USB-B input to run the mount over bluetooth with the Pi4- one less wire up to the OTA always sounds appealing. I've only made it as far as testing power from the Gemini to make sure it can handle it but looks good- I blab all of this because learning more about the general Gemini issues will be a positive experience for us all, I hope. Sorry for the semi-hijacking, please do let us know what you find.

Thanks for the ideas, I'll look into the rtc, but this is connected to my home network and I expect it's using timed. I'm using pulse guiding over the network, and I generally have no problems at all. I'm really happy with the mount, it normally works perfectly. I've been able to reproduce the issue 100% if guiding while slewing.

OH, so I don't think that the RPI4 has a RTC. It is using the time daemon though. I noticed it's time is behind when I first boot it. After about 1 min, the time updates to be perfect so It's probably taking a min to sync. A quick google shows that I'd need to add hardware to have a RTC, so I don't think I'm going to go to the trouble.

root@raspberrypi:/# timedatectl
Local time: Sat 2020-05-30 15:01:50 PDT
Universal time: Sat 2020-05-30 22:01:50 UTC
RTC time: n/a
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

I'm going to start by switching to stable tags for each component in the software stack, and see if it's still an issue...

I switched to stable and it still happens 100% of the time. I don't know why I don't hear complaints about this on the Losmandy group.

I have discovered the cause and have a fix. I've never contributed to the indi source, so I'm not sure how to do that. The issue is with sending guide commands during a slew. If that ever happens then the mount goes haywire. The simple fix is to return an error within each of the Guide<direction> calls in drivers/telescope/lx200telescope.cpp

Like this:

IPState LX200Telescope::GuideNorth(uint32_t ms)
{

if(TrackState == SCOPE_SLEWING){
return IPS_ALERT;
}

I tested this last night and everything is working perfectly now. It never does a wild slew. I don't think that there would be any side effects to this, but I'm not sure. I can't imagine a use case where a guide command should happen during a slew.

Jamie