Date   

Re: Problems with Park

Dan Gray
 

Can you send me your SiTech.cfg file?
Dan


On Thu, Apr 30, 2020 at 4:16 AM Franklin <f@...> wrote:

Don W & Yann-Eric,

The short answer is 'Yes', I did absolutely reset the park positions after 0.94G. I use the 3 park positions simply to "back-up" the original Park Position.

Frank

Did you redefine your park positions after upgrading to .095G ?

I think I read we have to this before using Park.

 

Yann-Eric


Re: Problems with Park

Franklin
 


Don W & Yann-Eric,

The short answer is 'Yes', I did absolutely reset the park positions after 0.94G. I use the 3 park positions simply to "back-up" the original Park Position.

Frank

Did you redefine your park positions after upgrading to .095G ?

I think I read we have to this before using Park.

 

Yann-Eric


Re: Problems with Park

Don W
 

Hi Frank,

The fact that the cfg file has a rotation between Parks (1,2,3) says you need to reset your park positions.  I don't understand why you are using Park2 and Park3.  Those are there for convenience of alternate Park sites, for instance a Park2 to aim at a Flat Target to do flats.  Park 1 should be your primary park position (it is the default park position) and using CCDC you can only park to Park1.

Don W


Re: Problems with Park

Yann-Eric Boyeau
 

Hi Franklin,

 

Did you redefine your park positions after upgrading to .095G ?

I think I read we have to this before using Park.

 

Yann-Eric

 

De : Sitechservo@groups.io <Sitechservo@groups.io> De la part de Franklin
Envoyé : jeudi 30 avril 2020 13:54
À : Sitechservo@groups.io
Objet : [Sitechservo] Problems with Park

 

[Edited Message Follows]

Hi All,

I am using 0.95G, however I have had this issue for about a year and finally I can replicate it reliably. Basically about half of the time I send my scope a Park command and/or click the Park button, the following happens (see the video - link below). It seems to happen more after a full night's imaging that includes a meridian flip. The scope travels to the correct park position and the motors stop (thus the non-moving Hour Angle), but Sitech.exe stays in this loop...

http://www.my-spot.com/obs/0.95GWin2020-04-28_11-19-09.mp4

I can now easily replicate it and so, I hope, can anyone who wishes to load my SiTech.cfg.

http://www.my-spot.com/obs/SiTech_no_park.cfg.txt

Directions: (Using my SiTech.cfg file above)

  • Start SiTech
  • Click "UnPrk"
  • Right-Click "Park"
  • In the pop-up, click "Park2"
  • (Scope will move ≈1.5 Hours in RA and stop, but Sitech never thinks that it is Parked. Watch it loop...)
  • Click "Stop"
  • Click "Park"
  • (Scope will move ≈1.5 Hours back in RA and stop and will show "Scope Parked")

I really think this one needs a quick bit of programming by Dan to fix. If you look at the ParkRaw3RaAz & ParkRaw2RaAz they differ by 9216000 which is exactly one full RA revolution, -1535613 vs 7680387 even though they were set from the exact same position. Once or twice the scope tried to move there by making one full extra revolution, and ripped out cables in the process. I "fixed" that by setting the "Primary Axis Limits" (the LimitAnglePrimaryCCW & LimitAnglePrimaryCW in SiTech.cfg), but after that I started to have this parking issue. Under the hood, I imagine Sitech properly sends the Motors to -1535613 (ticks with offset) but the part of the program that is evaluating if the scope has actually reached park (maybe a different thread?) is waiting for the value to reach 7680387 (9216000-1535613) and it never does. In any case, somewhere along the way, the value gets a full rotation added (9216000) even though the scope actually never stops pointing in the right location.
Note that all three park positions were the same but ParkRawRaAz got changed somehow to be about 1.5 hours RA different. That, I fear, is another story that I really don't wish to get into. In any case, it works well to illustrate the above issue.

Thoughts?

Frank


Problems with Park

Franklin
 
Edited

Hi All,

I am using 0.95G, however I have had this issue for about a year and finally I can replicate it reliably. Basically about half of the time I send my scope a Park command and/or click the Park button, the following happens (see the video - link below). It seems to happen more after a full night's imaging that includes a meridian flip. The scope travels to the correct park position and the motors stop (thus the non-moving Hour Angle), but Sitech.exe stays in this loop...

http://www.my-spot.com/obs/0.95GWin2020-04-28_11-19-09.mp4

I can now easily replicate it and so, I hope, can anyone who wishes to load my SiTech.cfg.

http://www.my-spot.com/obs/SiTech_no_park.cfg.txt

Directions: (Using my SiTech.cfg file above)
  • Start SiTech
  • Click "UnPrk"
  • Right-Click "Park"
  • In the pop-up, click "Park2"
  • (Scope will move ≈1.5 Hours in RA and stop, but Sitech never thinks that it is Parked. Watch it loop...)
  • Click "Stop"
  • Click "Park"
  • (Scope will move ≈1.5 Hours back in RA and stop and will show "Scope Parked")
I really think this one needs a quick bit of programming by Dan to fix. If you look at the ParkRaw3RaAz & ParkRaw2RaAz they differ by 9216000 which is exactly one full RA revolution, -1535613 vs 7680387 even though they were set from the exact same position. Once or twice the scope tried to move there by making one full extra revolution, and ripped out cables in the process. I "fixed" that by setting the "Primary Axis Limits" (the LimitAnglePrimaryCCW & LimitAnglePrimaryCW in SiTech.cfg), but after that I started to have this parking issue. Under the hood, I imagine Sitech properly sends the Motors to -1535613 (ticks with offset) but the part of the program that is evaluating if the scope has actually reached park (maybe a different thread?) is waiting for the value to reach 7680387 (9216000-1535613) and it never does. In any case, somewhere along the way, the value gets a full rotation added (9216000) even though the scope actually never stops pointing in the right location.
Note that all three park positions were the same but ParkRawRaAz got changed somehow to be about 1.5 hours RA different. That, I fear, is another story that I really don't wish to get into. In any case, it works well to illustrate the above issue.

Thoughts?

Frank


Re: Compatibility With SharpCap

Dan Gray
 

Ok, back to []1
Dan


On Tue, Apr 28, 2020 at 7:17 AM Ned Smith <smithned753@...> wrote:

No luck.

SharpCap can do: Stop and Start tracking, Park and Unpark.

Available tracking rates are still zero.  Any mount motion: Up, Down, Right, Left, does not work.

On 4/27/2020 7:33 PM, Dan Gray wrote:
Ned, I think I fixed it, but I'm not sure, can you replace your SiTechExe.exe file with this one?

THen test, and let me know.
Dan


On Mon, Apr 27, 2020 at 8:46 AM Ned Smith <smithned753@...> wrote:
Dan,

Hope the issue of compatibility with SharpCap 3.2.X is on your list.

--
Ned Smith 34.893N, 85.471W



--
Ned Smith 34.89N, 85.47W


Re: Compatibility With SharpCap

Ned Smith
 

No luck.

SharpCap can do: Stop and Start tracking, Park and Unpark.

Available tracking rates are still zero.  Any mount motion: Up, Down, Right, Left, does not work.

On 4/27/2020 7:33 PM, Dan Gray wrote:
Ned, I think I fixed it, but I'm not sure, can you replace your SiTechExe.exe file with this one?

THen test, and let me know.
Dan


On Mon, Apr 27, 2020 at 8:46 AM Ned Smith <smithned753@...> wrote:
Dan,

Hope the issue of compatibility with SharpCap 3.2.X is on your list.

--
Ned Smith 34.893N, 85.471W



--
Ned Smith 34.89N, 85.47W


Re: Compatibility With SharpCap

Dan Gray
 

Ned, I think I fixed it, but I'm not sure, can you replace your SiTechExe.exe file with this one?

THen test, and let me know.
Dan


On Mon, Apr 27, 2020 at 8:46 AM Ned Smith <smithned753@...> wrote:
Dan,

Hope the issue of compatibility with SharpCap 3.2.X is on your list.

--
Ned Smith 34.893N, 85.471W




Re: Generic camera control option

paul K
 

Just to chip in about sequence generator pro (SGP). I have used it and the Sitech II controller with a MESU 200 mount and the SBIG STT8300 mono camera with filter wheel for 5 years or so. I Image galaxies mainly. SGP is provided by Mainsequence software and it is very comprehensive in terms of drawing together all the components required for astro imaging (camera, mount, focuser, platesolve, autoguider, dome control , camera rotator etc. I find it very straightforward to use, and the support forum is well supported by Ken and Jared (the originators and developers) and other knowledgeable folks. I think there is a no cost version which is good to try, but I bought the 'pro' version, just to support the development effort rather than needing the functions really. SGP is interactive too, you can see images integrating and view when they download. It has a nice notification system to keep you posted on progress on your mobile via text/ email and a framing and mosaic wizard to help selecting and framing targets.
I find that with the support here from Dan and Don and others, and that which I get from the SGP folks, it serves me really well for my galaxy imaging exploits. The only other software I've used for camera control years ago was Nebulosity, but it's features are not nearly as sophisticated as SGP - the two are different beasts really, and I like Nebulosity for processing. I know that MAXIM is good too, but I have never tried it.
I hope this helps.
Paul


Re: Generic camera control option

Ross Salinger <rgsalinger@...>
 

I thought that sitech now supported sequence generator pro which is cheap and comprehensive when it comes to camera control?  

FWIW the problem this weekend is that a camera was disconnected physically without connecting MDL first. When MDL tries to access it, the USB drivers in the OS kernel go into a wait state and MDL hangs. Usually you can just kill the process. In this case I suggested to Sina that he reboot the computer completely. That was just to be on the safe side.


Re: Generic camera control option

jmgoldba
 

If you have ideas.
My thinking was that you would add a provision for calling user written scripts with defined inputs and outputs. So it only works with camera control software that supports user scripting. Is there some way you can generalize what you're doing supporting the existing programs? The issue with ASCOM only camera software is that there's no 'last mile' provision, as it were, of writing FITS files to disk, though it just dawned on me that maybe SiTech doesn't need that provision for its purposes of plate solving, focusing and guiding. If SiTech needs FITS files another possibility is to add that functionality as yet another 'extension' to your existing ASCOM driver.

they think we're a competitor.

There is no need for autofocus, guiding, plate solving.
The second quote is from the Prism website. Those features look familiar?

recommendation for an "up to date" camera control software.
Honestly I don't have one. We've been using MaxIm all this time and its been okay. (It gave us issue the other night and it seemed the only solution was to literally power everything down and back up.) We're open to alternatives and in this day and age there are several with a cost an order of magnitude less than MaxIm maintenance. I'm looking into APT for a basic backyard DSLR setup and the developer was helpful when I posted camera questions on his forum. My thinking was that if an alternative looks feasible on one of our smaller setups then we'd like the option to migrate to it on our main scope or use it if we acquire another SiTech based scope.

Jesse


Compatibility With SharpCap

Ned Smith
 

Dan,

Hope the issue of compatibility with SharpCap 3.2.X is on your list.

--
Ned Smith 34.893N, 85.471W


Re: Generic camera control option

Dan Gray
 

I've been working on something for a couple years, progress is slow.
If you have ideas, it would be helpful.
Sounds like ascom camera would be a good way, and I've already had ascom camera work in other applications, so that is on my list.
What would be your recommendation to an "up to date" camera control software?
Prism has refused to give me their new TCP protocol for their camera control, they think we're a competitor.

Dan



On Sun, Apr 26, 2020 at 1:37 PM jmgoldba via groups.io <jmgoldba=yahoo.com@groups.io> wrote:
Is it possible to provide a generic camera control template so that a user can roll their own script that'll enable SiTech to talk to whatever camera control software they may be using? There are many astronomical camera control applications available nowadays and it would be nice if SiTech wasn't limited to a few legacy applications. Nebulosity v2? Anyone? Anyone? -Jesse


Re: Help with Scope Encoders on a newly constructed GEM

Don W
 

Hi Mark,

Congratulations on building a GEM mount.  That is a very significant achievement.

Since the mount is new, I am guessing that your problems slewing and tracking with the mount encoders active may very well be a mismatch of tics per rev.  If the tics/rev of the servo does not match the tics/rev of the mount encoder, the mount will lock up when the difference reaches a limit.  So double check your tics/rev for both RA and DEC servo encoders.  It is not easy to measure the tics/rev accurately, the best way is to calculate knowing the gear ratio of the servos and the ratios of the worm and main gear, as well as any intermediate ratio like a gear or belt drive.  Also remember the servo encoders read in quadrature, which means the servo may have a 500 cpr encoder, but quadrature reads that as 2000 tics/revolution.  The actual tics ratio for Pittman servos is listed in the SiTech Setup Manual.

Check in ServoConfig that the tics go in the same direction for both the servo encoder and mount encoder when you move each axis.  Polite mode on the DEC is the proper setting for using a 10K Dec encoder.  it will thten only be active when you slew, not when you are tracking.

Don W


Help with Scope Encoders on a newly constructed GEM

Mark Navarro
 

I have built my new GEM and I am having some challenges with the scope Encoders and challenges with slewing accuracy. I did semi- fine polar alignment.  On the Dec encoder (10k US Digital on the Dec shaft) I cannot get it work cooperatively with the motor encoder.  In Polite mode It stops and I have to disable the scope encoder to make it slew.  I have tried reversing the scope encoder made it worse. I have checked the wiring continuity and it looks good.  In Servo config it increments and decrements. I did a first CAL stars with 19 fixes I did not have the scope encoder enabled when I built the Cal Stars is this part of the problem?

 

On RA I have a 500K Gurley (tick management) and it works for awhile. Sometimes after slew is over the scope will start do a RA bounce and it will not stop until I disable the encoder. I noticed last night that It stopped (RA encoder error) on a slew that went close to Polaris.  Any suggestions on any of this. Building a new mount has been fun and provided many challenges – it runs but there are still challenges


Generic camera control option

jmgoldba
 

Is it possible to provide a generic camera control template so that a user can roll their own script that'll enable SiTech to talk to whatever camera control software they may be using? There are many astronomical camera control applications available nowadays and it would be nice if SiTech wasn't limited to a few legacy applications. Nebulosity v2? Anyone? Anyone? -Jesse


ONAG

Ned Smith
 

I would like to chat with anyone who is using SiTech with SkyGuard .  I asked this a few weeks ago and got a response but I have lost it.

Apologies for asking again.

--
Ned Smith 34.893N, 85.471W


Re: Update from 0.94N to 0.95G

CandCShaw
 

Look at the fits header of the image for the exposure to see if it is numbers. 


On Apr 22, 2020, at 1:31 PM, ivodinev@... wrote:

Thank you for the detailed answer! I downloaded and put UCAC3PS and PlateSolve3Catalogs in C:/ProgramData/SiTech.
But encountered a problem trying to solve a picture (.fits)  from my HDD. I got "An error occurred reading one of the FITS parameters. Unable to open image: Non-numeric EXPTIME parameter" Camera used was ASI174mini.
Maybe it is not the right topic for such questions, so please excuse me but didn't find something similar.
Thank you very much!

Ivo


Re: Update from 0.94N to 0.95G

ivodinev@...
 

Thank you for the detailed answer! I downloaded and put UCAC3PS and PlateSolve3Catalogs in C:/ProgramData/SiTech.
But encountered a problem trying to solve a picture (.fits)  from my HDD. I got "An error occurred reading one of the FITS parameters. Unable to open image: Non-numeric EXPTIME parameter" Camera used was ASI174mini.
Maybe it is not the right topic for such questions, so please excuse me but didn't find something similar.
Thank you very much!

Ivo


Re: Downloading Comets

ivodinev@...
 

Thank you for the update! I thought it is my fault as I could'n do the update. Now it worked in seconds!

Ivo

2961 - 2980 of 34431