Hans, Thanks or the information, and work on the driver! It's much appreciated by us 10Micron owners. :)

It sounds like maybe I don't want unattended flip. I don't want the mount flipping unless I give it a goto command on the other side of the pier. I'm guessing this is for automatic tracking of satellites and such when viewing visually? Seems that as it's tracking, it reaches the meridian limit then flips due to this setting. This would be my assumption.

I'll continue using no time sync, and let KStars control everything time wise, as I have no issues here using those settings with regards to meridian flips. It's only when I let the mount sync it's time and location to KStars that issues crop up.

Read More...

So the unattended flip update just lets the 10Micron automatically perform it's own flip when the goto command is issued and the driver detects that unattended flip is on? In other words, is there anything the end user needs to set up or configure differently for the driver change that is coming?

For the record, flips had always worked for me in the past. I did have unattended flip turned on in the mount controller. This new issue reported by Scott, I have been getting in version 3.5.0 as well where the mount attempts to flip every 4 minutes. I seemed to think this was a time mismatch between KStars and the Mount. When I let KStars control the time everything works. But to be honest, I've not had my 10Micron out since the very first day of the 3.5.0 release, and I didn't spend much time looking into whether or not previous time issues could be remedied by not syncing time either way between the controller and KStars.

Read More...

Open the web browser and go to the control panel. On one of the tabs you should find the option to switch to Beta. Once you said it to Beto run the update icon that’s on the desktop then reboot. When it loads KStars you should be able to go to the about menu and see if you’re on the beta. If you are on the beta then run that terminal command to get the latest drivers.

Read More...

You have to switch to the StellarMate beta and run the terminal command in Jasem’s post above to get the fixed driver.

Read More...

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.

Read More...

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?

Read More...

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.

Read More...

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 time. 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.

Read More...

Andrew Burwell replied to the topic '10Micron MGPBox?' in the forum. 3 months ago

I only have the MBox, because I got my mount with the GPS unit. I have the GPS unit attached to the Mount directly, and the Mbox feeds weather data to Michel's MountWizard through the Raspberry Pi running INDI Server or KStars.

Read More...

Thanks! Good to know. I don't suppose that will get integrated into the beta's? I don't really know how that process works.

Read More...

There's an SDK update from 11/20/2020 for ZWO cameras that enables the unlocked 44mp Bin 1 mode on the ASI294MM-Pro camera. I'd like to try this out with INDI to make sure it works. I'm on the StellarMate Beta and it doesn't appear this update is in there yet.

Thank you!!

Read More...

I'm attaching my log here. I may have a few issues going on here described below. It's the full log from the whole night. The meridian flip starts around 22:50 or so. The object passes the meridian at 22:52-22:53. I had the mount set to allow the flip at 0 degrees past the meridian. The reason for this is the Rainbow mount stops tracking at 0 by default. Issuing a goto command anytime after 0 should cause it to flip. You can see it start the flip at this time. It tries again several times saying flip failed, pier side not changed. I didn't set the flip after 0 because I didn't want guiding to lose the guide star and position because the mount would stop tracking at 0. All that said though, I did on the pervious night set it to flip at 5 minutes past 0, and I ran into all the same problems that happened tonight.

At some point prior to the flip the guide star keeps getting lost, some how tracking rate changed from sidereal to "guiding" which looks like a custom rate and the guiding system can't get a lock on a guide star because it's moving faster than sidereal. I've seen this before a bunch, and this must be a bug or issue with the Rainbow driver.

At some point after a bunch of failures and guiding issues due to the tracking rate change I think I correct the tracking rate by setting it back to sidereal in the Indi control panel. I issue a goto command to go to NAVI which was very west of the meridian at the time. The flip message was still there saying flip failed, retrying in x minutes. After this, I stop the scheduler, and quit EKOS. Restart it, and reconnect all devices, and we're back to normal again.

I'm not super good at deciphering the log, so I included the full log so you can see any settings or things that might be contributing to these problems.

log_18-15-23.txt.zip

Read More...

knro wrote: Thank you all for the reports. I'm going to try this today in my observatory with EQ8 while running the scheduler to see if I can replicate this. I don't run PHD2, but I don't think I need to do that to replicate the issue?


This happens with the internal guider as well.

Read More...