×

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

Bi-monthly release with minor bug fixes and improvements

Inconsistent Time & Location in indi_lx200_10micron (was 3.5.0 Flip Failure)

  • Posts: 300
  • Thank you received: 57
There appears to be a time and location conflict in the indi_lx200_10micron driver when the mount is updated from its own GPS (MGPBox), resulting in a range of bad behavior including failed meridian flips, bad pointing, and horrific tracking when the mount and INDI and KStars fight over precise geographic coordinates and time.

I build a mount model in separate software (ModelWizzard 4) that leads to incredibly precise pointing without KStars and 2-axis tracking using built-in encoders. But when doing production imaging in KStars I get horrible arcMINUTE-scale star trails as the mount and software fight over the time & location (see example images attached below).

The time mismatch between GPS/10Micron and Kstars frequently leads to failed meridian flips as the mount reaches a safety stop before KStars realizes it's time to flip.

Another symptom is that the reported geographic site position in the INDI driver doesn't retain arcseconds in geographic coordinates (for consistency with LX200?) but the GPS-reported coordinates in the mount keypad does. This was reported by fenriques in this thread. It may be that the arcseconds numbers are just not being reported in the GUI, but the rest of the symptoms suggest that the actual geographic coordinates are being *truncated* in the driver, resulting in the DEC thrashing I see in my subs (unless I just ignore the mount coordinates).

As Andrew points out in this thread , I can get pretty good results by just ignoring all the time & location info in the mount and GPS. To do this I have to turn off the MGPBox syncing in the mount hand controller set the geographic coordinates by hand, and set "KStars updates mount" in the Ekos settings. But I get nearly PERFECT results in TheSkyX by just trusting the mount to do its own thing and not trying to second-guess it in software.

This is a tough issue to diagnose because it involves the mount computer as well as the INDI driver and KStars/Ekos. I can save logs but not sure which logs are involved. Maybe I need to collect a mount log from the 10micron computer and report it to the vendor? But pretty sure this is cross-talk between INDI and 10Micron so hard to know what info to provide to whom.

Attached are two unguided 180-second subs of M74. Polar alignment is identical in these two unguided subs (well under 1 arc minute PA error). The first (with coordinates overlaid) shows INDI and the mount fighting over the time and location. The second shows good 2-axis tracking with all GPS info disabled. It gets even better (eccentricity under 0.3) when I use other software like TheSkyX that just leaves the mount alone to do its own thing. Everything I report here is for KStars 3.5.0 (regular ppa, not nightly) on ubuntu 20.04.1 running on R Pi 4.

This post is following up on three other related threads which I suspect are due to the same issue:

indilib.org/forum/general/8328-3-5-0-flip-failure-10micron.html

indilib.org/forum/general/7928-why-is-th...y-mount.html?start=0

indilib.org/forum/general/7928-why-is-th...y-mount.html?start=0

The following user(s) said Thank You: Jasem Mutlaq
Last edit: 3 years 3 months ago by Scott Denning.
3 years 3 months ago #64490
Attachments:

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

  • Posts: 527
  • Thank you received: 139
I've seen trails in my images only in one instance very similar to your top image. That's when I unpark the mount from within KStars after initial boot. For some reason when _any_ software unparks the mount after boot it puts the mount into a custom tracking rate denoted by a comet icon on the hand control. This tracking rate is not apparent when running a model, calibrating guiding, etc. It only appears once the mount is tracking an object. To fix this, make sure you have no comet icon, and if you do set the mount back to sidereal tracking rate. But for me personally, in both instances you list above, I was always able to get good tracking, but not meridian flips unless I let KStars control everything including time and location. With KStars controlling everything my pointing goes downhill, but flips work properly (I can keep pointing in check, by re-running a new model every time before I image for the evening). When the mount controls time and location, pointing is perfect, but flips stop working.
Last edit: 3 years 3 months ago by Andrew Burwell.
3 years 3 months ago #64523

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

  • Posts: 300
  • Thank you received: 57
The thing is, KStars should stay the heck out of updating the mount. There's a computer in the mount that controls time, location, refraction, pointing, and real-time adjustments to tracking in both DEC and RA so that guiding is superfluous. I get near-perfect results in software other than KStars when I just let the mount track the way it's supposed to, with eccentricity under 0.3 for 3-minute subs.

But KStars tries to update the site location and time and god-knows-what-all else *during images* while tracking, so the mount does these little micro-slews, especially in DEC. It's not every sub. There's a 15-minute smoothing window in the mount control computer that puts most of KStars corrections into one sub and then less and less for the next 3 or 4, then I'm back to gorgeous round stars for awhile until another "correction" comes in.

Yes, like you I can get decent results by just turning off all the GPS and refraction data. But I don't want to. I want "Mount updates KStars" to just let the mount work on its own without any cross-talk about time and location.

I could switch back to windows and TheSkyX or NINA but I really *like* KStars and running the mount on the pi.
3 years 3 months ago #64526

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

  • Posts: 527
  • Thank you received: 139
I agree. The mount is all knowing...at least in the case of 10Micron mounts. And I too love KStars/EKOS. I find it's way more intuitive than most PC programs, and the scheduler is awesome. This is a key missing ingredient on the PC side of apps.

I re-read my thread on the time issue, and I never went back to re-examining all possible time options in the mount vs. what sync's across compared to KStars/EKOS time in the logs. But I had intended on testing straight up UTC time with no offsets. My local UTC time with -5 offset, then local UTC with DST on and OFF to compare. And now we're actually out of DST so that should actually no longer be an issue, possibly simplifying the underlying problems and options available with time sync. I wouldn't mind someone else testing themselves to confirm what I found earlier. Michel (MWOrion) said he's not had these issues where he is, but he's clearly more knowledgeable than I am when it comes to the working of the mount and using INDI.
3 years 3 months ago #64528

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

You can control whether KStars updates INDI drivers. Settings --> Configure KStars --> INDI, and turn off update time and location.
The following user(s) said Thank You: Scott Denning
3 years 3 months ago #64535

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

  • Posts: 527
  • Thank you received: 139
What's the implication of doing this? In this case, KStars updates nothing in the mount, and the mount updates nothing in KStars. Their clocks will still have a mismatch correct? I've never tried not sync anything, but I suppose as long as they are correct within a second this should not have any real issues?
3 years 3 months ago #64542

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

  • Posts: 300
  • Thank you received: 57
Smacking myself in the head -- thank you! Why didn't't I think of that?!

I suspect this is indeed the correct solution. Otherwise there are two computers fighting over the precise positioning of the mount and chaos ensues.
3 years 3 months ago #64584

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

  • Posts: 527
  • Thank you received: 139
If you get a chance to test it out, let me know how it goes. Cloudy nights here for the next week or so. Crossing my fingers this does the trick.
3 years 3 months ago #64585

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

  • Posts: 85
  • Thank you received: 40
Hi airscott,
Sorry to hear you ran into these coordinate and time problems.
I see there's a workaround for that already (by not making kstars update the mount's coordinates and time).
I just started to fix some open issues in the 10micron INDI driver. I'll follow-up on the coordinate second in the thread about it, and about the meridian flip in its thread.
It's good to now have users that actually point me to these issues ;-) So thanks for that.
I do not have an MGPBox myself so could not test this combination.
Is this issue now fixed for you ?
-- Hans
3 years 3 months ago #64908

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

  • Posts: 4
  • Thank you received: 0
I'm running kstars on a stellarmate os rpi. I have 10 micron connected via ethernet and mgbox2 circuit to the mount. I control the rpi via hotspot using vnc on my MacBook. I run this not connected to the internet as I image from remote sites.

I have set mount updates kstars and it seems to work fine.

However I really want kstars to also update the rpi system date and time from the mount data. Not because of any tracking issues but just to get my images saved with the right date and time. I save directly to a usb ssd connected to the rpi.

I previously configured chrony to update rpi date and time from a separate gps dongle (before I got my 10m & mgbox). So it must be possible.

Any ideas?



Sent from my SM-G965F using Tapatalk
3 years 1 month ago #67573

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

Time to create page: 1.906 seconds