Programmers...Can't Live With Them...The end.

[JonCarleton]

I have been having a problem slewing running SynScan with Stellarium and an INDI driver.  However, switching to KStars with the same INDI driver, it was on target (+/-) every time.  Since the inaccuracy with Stellarium was about 15 degrees, I suspected a time issue, probably related to DST.  And therein lies the problem:

SynScan's time prompt asks for the 24 hour timestamp, which we can ASSUME is local time, then the UTC offset, and finally the Y/N for DST.  This, in itself may be subjective.  For example, I typically enter my 24 hour localtime, my standard UTC offset (-5 hours for Atlanta, Georgia) and currently, for the Spring/Summer DST YES.  This in the hopes that it is making a -4 hour correction for Spring/Summer.  It =seems= to be the correct approach.

KStars, seems to take localtime from the computer clock, which is good.  Like SynScan it seems to want a DST-independant -5 hours UTC Correction for Atlanta, Georgia, and asks for a "DST rule" that it apparently uses to convert to UTC.  I tend to prefer this method, as it seems clear (to me, anyway) what the programmer intended.

Stellarium wants a time zone, based upon cities and countries along a longitude line, then asks to enable or disable DST.  I run with Americas/NewYork and enable DST.  The onscreen display shows UTC -4, which is correct for this time of year. Stellarium also has an option for a "custom time zone," that I have not tried yet.  Like KStars, it takes localtime from the computer clock.

Since SynScan and KStars use more or less the same setup values, it isn't really a surprise that they work well together.  Even though the Stellarium setup -seems- to make sense, it is pretty clear that it somehow doesn't match what KStars is sending the INDI SynScan driver.

I suppose I could just use KStars and dump Stellarium.  But, I -like- Stellarium and some of its features.  Always the way it is, no?

 

 

Edited April 11, 2020 by JonCarleton

[MarkAR]

I would just fudge the time or UTC in stellarium and see if that works.

Could it be Stellarium is taking the corrected DST from your computer then adding the correction again?

[Aramcheck]

Or ditch the Synscan handset & use an EQDIR cable to connect laptop direct to mount. Then install the version of Stellarium here: https://www.cloudynights.com/topic/679620-stellarium-direct-ascom-support-testers-wanted/ which includes support for ASCOM.

I'm rather a newb to this - but when I tried it for the first time the other night it worked like a treat with both APT & Stellarium.

Cheers
Ivor

 

[JonCarleton]

1 hour ago, Aramcheck said:

Or ditch the Synscan handset & use an EQDIR cable to connect laptop direct to mount. Then install the version of Stellarium here: https://www.cloudynights.com/topic/679620-stellarium-direct-ascom-support-testers-wanted/ which includes support for ASCOM.

I'm rather a newb to this - but when I tried it for the first time the other night it worked like a treat with both APT & Stellarium.

Cheers
Ivor

 

Good idea...but there is one major flaw in that slaw...I am a member of the UNIX religion and do =not= run, nor own Windows. Nor do I care to.  I have only just managed to evolve ever-so-slightly away from Solaris to Linux in recent years, but that is, in my mind, only a minor transgression.

That said, I have considered running Stellarium with a serial connection in a more direct mode, I see that people have done that with some success.  But if I can find a solution to the misdirection I am getting from Stellarium vs. KStars, I can stay wireless.  I see that as a very big plus.  It may be that I'll have to do some packet sniffing and see what is actually being passed over the network.  It would, of course, be MUCH easier if I luck across someone who has already solved this particular issue  

 

 

 

[JonCarleton]

2 hours ago, MarkAR said:

I would just fudge the time or UTC in stellarium and see if that works.

Could it be Stellarium is taking the corrected DST from your computer then adding the correction again?

It seems possible that Stellarium is double-dipping the DST adjustment.  I need to spend some more time testing to find out exactly what's going on. Fudging the actual time zone or location is certainly on the table for testing.  I know that if I select a star in KStars and the same star in Stellarium, I get slightly different coordinates. 

The telescope locations for each software package are a few tiny fractions of a second off, due to some rounding that is done in storage and retrieval, but I don't think that's enough to yield the level of difference I am getting.  This is why I think it is a DST issue.

[JonCarleton]

I did some testing and find that my KStars and Stellarium do not agree on Az/Alt numbers.  Running simultaneously, I can pick a star in each package and get different numbers.  In each case the Az is as much as 2 seconds low and the Alt is up to 6-8 seconds low.

Where's my hammer............

 

[MarkAR]

If it was degrees and not seconds I would really be worried.

[JonCarleton]

1 hour ago, MarkAR said:

If it was degrees and not seconds I would really be worried.

Agreed..but seconds is enough to mess me up.  My camera has a really narrow FOV and I doubt I could get a position match from some of the little patches of dark to which I have been pointed.  More testing today...we'll see.

[MarkAR]

Good luck.