Date   

Re: Need some financial assistance

Chuck
 

As listserver owner,  posting non-astronomy related postings, and especially postings that solicit anything are “normally” not allowed.  The reason is simple, this is a haven safely tucked away from the “real” world that we can share our interest in things Sitech (thank you Dan for coming up with all of this!!!)  and to mutually help each other with learning to use it and solving problems.

 

Don D has been an integral part of our Sitech community for  many years.  He has actively supported the goals of our community and has been key in solving sometimes difficult problems.    I think its nice to have someplace where you can get help from your peers in solving issues or simply just explaining how things work.

 

So,  I think it is not a misuse of the “normal” mission of our listserver to have someone that has been a key supporter and a friend in our community to want to let his astronomy friends that he has helped in the past know he now needs help, even though its not help with a Sitech issue… but a much more serious one.

 

NO ONE on the listserver should even begin to think there is any pressure to help Don D and his father, and I am in no way involved with his posting his situation and request for help on the listserver.   That would truly be a misuse of the listserver!   But I do think that when I have a friend having troubles, that I want to at least be made aware they are having troubles so I can  at least think of them.     And that is the spirit of why I am sending this note….. and the reason I am willing to risk setting a dangerous precedent by not removing Don D’s request for help.

 

I have been in contact with Don D, and know for a fact this is not a sham or phishing attempt.  I think “GoFundMe” is a good way to provide a simple approach to provide him financial assistance.   The “GoFundMe” type of approach counts on the concept that even an avalanche is made up of a lot of small flakes of snow.    I know anything anyone wants to chip in will be appreciated (much like the assistance is appreciated by those of you that Don D has helped through the years)

 

 

On a totally different  topic……  the problems we have had with Yahoo Groups for our listserver seem to have been decreased.    Don W speculates the new Yahoo owners are actually seriously trying to improve their service.   However, to let everyone know, I have settled on migrating our listserver over to Groups.io if the Yahoo Groups  support becomes inadequate.      I have talked to Groups.io, and other listserver owners (like the Deep Sky Stacker forum owners).   We do have an upper limit on storing files for free with them, but in the process of accumulating files on our Yahoo Group, we could transfer ALL of them and still be well below their free limit.   I attached an email of Groups.io if you want to hear about their transfer experience to Groups.io from Yahoo Groups.

 

Currently, there are no plans or schedule to migrate us to Groups.io unless we start having problems again with Yahoo Groups.  But, its nice to know we have what I believe is a very viable alternative!  So if you start having Yahoo Groups issues, PLEASE let me know!!!

 

And if you want to contact me about Don D’s topic, please feel free to do so at my private email rather than cluttering up the listserver.

 

Regards to all!!!

 

Chuck

 

 

Chuck Shaw

 

321-506-5778  (mobile)

 

candcshaw@...

 

 

 

 

 

 

From: SiTechservo@... [mailto:SiTechservo@...]
Sent: Wednesday, July 18, 2018 3:51 AM
To: SiTechservo@...
Subject: Re: [SiTechservo] Need some financial assistance

 

 

I have created a GoFundMe to help my dad. Here's the link.

https://www.gofundme.com/help-my-father-stay-in-his-home

Thanks for any help.
Don D

----- Original Message -----
From: "'Don Degidio' djd521@... [SiTechservo]" <SiTechservo@...>
To: <SiTechservo@...>
Sent: Tuesday, July 03, 2018 11:20 AM
Subject: [SiTechservo] Need some financial assistance

> Have been on the group a long time and need some quick financial assistance. My dad and I received
> a
> letter from the bank last week that we are in foreclosure. First time since we moved to our home
> in
> 1955. My dad will be 93 on Thursday and has some medical conditions that require my constant care.
> Social Security is his only income besides a small pension. I have been disabled due to several
> auto
> accidents and SS Disability is my only source of income. Have constant low back pain.
>
> We are in need of $3900 by the end of July to help stave off foreclosure. I have tried several
> sources for loans, and been turned down because either disability not considered income, or income
> insufficient for loan amount.
>
> I'm asking if any group members can make some contributions to my Paypal account, or mail me what
> you can offer. Please contact me off list for more info. Here's my email.
>
> djd521 @ verizon . net just remove the spaces. My email is also my Paypal account.
>
> Thanks,
>
> Don D
>
>
>
> ------------------------------------
> Posted by: "Don Degidio" <djd521@...>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>


Re: DEC wiring issue

Jeff Ross
 

Hi Don,

Dang, I did that a couple of times and forgot to mention it.

My gut instinct still says controller but I hope I'm wrong.

Jeff


On 7/22/18 6:21 PM, 'Don Degidio' djd521@... [SiTechservo] wrote:
 

Jeff,

I would try inverting the DEC motor encoder in ServoConfig.

Don D

----- Original Message -----
From: "Jeff Ross jross@... [SiTechservo]"
To:
Sent: Sunday, July 22, 2018 7:43 PM
Subject: [SiTechservo] DEC wiring issue

> Hi all,
>
> I am having the devil's own time wiring my Pitman servo DEC motor that I
> bought from SiTech to my Servo 1.
>
> The symptoms don't really match any that I've found in searching so here
> goes.
>
> On controller power on, both motors appears fine. Sitech config shows
> both in Auto, RA is tracking, DEC is not easily turnable by hand so must
> be under the Servo1's control.
>
> RA works perfectly--slew speeds are brisk, pan speeds less so, guide
> speed just barely above the tracking speed and that's in both directions.
>
> DEC is not at all. Touching either the real handpad's UP or Down button
> or the virtual hand pad in Sitech Config causes the DEC motor to move in
> the correct direction but at full speed until controller reset.
>
> I've tried slashing the values I'd set last time before this re-wiring
> but the motor still takes off at full speed, suggesting from the fine
> manual that the motor encoders are not being read correctly.
>
> I've rebuilt the motor cable probably 4 times now and either I'm
> repeating the same mistake over and over and expecting a different
> result, or my Klein pliers have a bad tooth, or...something else like
> the DEC side of the controller is wonky. In all of these rebuilds the
> RA motor works as expected so I don't think the DEC motor is cabled wrong.
>
> To make sure I wasn't completely crazy, as a test, I took the RA motor
> encoder end and plugged it into the DEC motor encoder socket, then
> switched the RA and DEC power leads. Now, the handpad left and right
> buttons should move the DEC motor and by golly they do, in all speeds in
> both directions, no controller reset.
>
> My DEC encoder wire is too short to reach the RA motor now so I can't do
> the reverse test.
>
> I've run out of ideas on how to debug this further and would sure
> appreciate any other suggestions.
>
> Many thanks,
>
> Jeff Ross
>
> Townsend, MT
>
>



Re: DEC wiring issue

Jeff Ross
 

Hi Josh,

Thanks for the reply!

I think I did that same thing by swapping the encoder and power wires and seeing that the DEC motor worked as expected.  I'm not sure how easy it would be to swap the motor encoders but I'm adding that to my list of things to try.

Jeff

On 7/22/18 6:15 PM, Josh Hufford joshhufford@... [SiTechservo] wrote:
 
Can you swap the motors between RA and DEC and see if the problem follows the motor? Or possibly swap the encoders on the motor?

I would use the process of elimination to track it down. 

Josh

On Sun, Jul 22, 2018 at 6:43 PM, Jeff Ross jross@... [SiTechservo] <SiTechservo@...> wrote:
 

Hi all,

I am having the devil's own time wiring my Pitman servo DEC motor that I bought from SiTech to my Servo 1.  

The symptoms don't really match any that I've found in searching so here goes.

On controller power on, both motors appears fine.  Sitech config shows both in Auto, RA is tracking, DEC is not easily turnable by hand so must be under the Servo1's control.

RA works perfectly--slew speeds are brisk, pan speeds less so, guide speed just barely above the tracking speed and that's in both directions.

DEC is not at all.  Touching either the real handpad's UP or Down button or the virtual hand pad in Sitech Config causes the DEC motor to move in the correct direction but at full speed until controller reset.

I've tried slashing the values I'd set last time before this re-wiring but the motor still takes off at full speed, suggesting from the fine manual that the motor encoders are not being read correctly.

I've rebuilt the motor cable probably 4 times now and either I'm repeating the same mistake over and over and expecting a different result, or my Klein pliers have a bad tooth, or...something else like the DEC side of the controller is wonky.  In all of these rebuilds the RA motor works as expected so I don't think the DEC motor is cabled wrong.

To make sure I wasn't completely crazy, as a test, I took the RA motor encoder end and plugged it into the DEC motor encoder socket, then switched the RA and DEC power leads.  Now, the handpad left and right buttons should move the DEC motor and by golly they do, in all speeds in both directions, no controller reset.

My DEC encoder wire is too short to reach the RA motor now so I can't do the reverse test.

I've run out of ideas on how to debug this further and would sure appreciate any other suggestions.

Many thanks,

Jeff Ross

Townsend, MT




Re: DEC wiring issue

Don Degidio
 

Jeff,

I would try inverting the DEC motor encoder in ServoConfig.

Don D

----- Original Message -----
From: "Jeff Ross jross@openvistas.net [SiTechservo]" <SiTechservo@yahoogroups.com>
To: <SiTechservo@yahoogroups.com>
Sent: Sunday, July 22, 2018 7:43 PM
Subject: [SiTechservo] DEC wiring issue


Hi all,
I am having the devil's own time wiring my Pitman servo DEC motor that I bought from SiTech to my Servo 1.
The symptoms don't really match any that I've found in searching so here goes.
On controller power on, both motors appears fine. Sitech config shows both in Auto, RA is tracking, DEC is not easily turnable by hand so must be under the Servo1's control.
RA works perfectly--slew speeds are brisk, pan speeds less so, guide speed just barely above the tracking speed and that's in both directions.
DEC is not at all. Touching either the real handpad's UP or Down button or the virtual hand pad in Sitech Config causes the DEC motor to move in the correct direction but at full speed until controller reset.
I've tried slashing the values I'd set last time before this re-wiring but the motor still takes off at full speed, suggesting from the fine manual that the motor encoders are not being read correctly.
I've rebuilt the motor cable probably 4 times now and either I'm repeating the same mistake over and over and expecting a different result, or my Klein pliers have a bad tooth, or...something else like the DEC side of the controller is wonky. In all of these rebuilds the RA motor works as expected so I don't think the DEC motor is cabled wrong.
To make sure I wasn't completely crazy, as a test, I took the RA motor encoder end and plugged it into the DEC motor encoder socket, then switched the RA and DEC power leads. Now, the handpad left and right buttons should move the DEC motor and by golly they do, in all speeds in both directions, no controller reset.
My DEC encoder wire is too short to reach the RA motor now so I can't do the reverse test.
I've run out of ideas on how to debug this further and would sure appreciate any other suggestions.
Many thanks,
Jeff Ross
Townsend, MT


Re: DEC wiring issue

Joshua Hufford
 

Can you swap the motors between RA and DEC and see if the problem follows the motor? Or possibly swap the encoders on the motor?

I would use the process of elimination to track it down. 

Josh

On Sun, Jul 22, 2018 at 6:43 PM, Jeff Ross jross@... [SiTechservo] <SiTechservo@...> wrote:
 

Hi all,

I am having the devil's own time wiring my Pitman servo DEC motor that I bought from SiTech to my Servo 1.  

The symptoms don't really match any that I've found in searching so here goes.

On controller power on, both motors appears fine.  Sitech config shows both in Auto, RA is tracking, DEC is not easily turnable by hand so must be under the Servo1's control.

RA works perfectly--slew speeds are brisk, pan speeds less so, guide speed just barely above the tracking speed and that's in both directions.

DEC is not at all.  Touching either the real handpad's UP or Down button or the virtual hand pad in Sitech Config causes the DEC motor to move in the correct direction but at full speed until controller reset.

I've tried slashing the values I'd set last time before this re-wiring but the motor still takes off at full speed, suggesting from the fine manual that the motor encoders are not being read correctly.

I've rebuilt the motor cable probably 4 times now and either I'm repeating the same mistake over and over and expecting a different result, or my Klein pliers have a bad tooth, or...something else like the DEC side of the controller is wonky.  In all of these rebuilds the RA motor works as expected so I don't think the DEC motor is cabled wrong.

To make sure I wasn't completely crazy, as a test, I took the RA motor encoder end and plugged it into the DEC motor encoder socket, then switched the RA and DEC power leads.  Now, the handpad left and right buttons should move the DEC motor and by golly they do, in all speeds in both directions, no controller reset.

My DEC encoder wire is too short to reach the RA motor now so I can't do the reverse test.

I've run out of ideas on how to debug this further and would sure appreciate any other suggestions.

Many thanks,

Jeff Ross

Townsend, MT



DEC wiring issue

Jeff Ross
 

Hi all,

I am having the devil's own time wiring my Pitman servo DEC motor that I bought from SiTech to my Servo 1.  

The symptoms don't really match any that I've found in searching so here goes.

On controller power on, both motors appears fine.  Sitech config shows both in Auto, RA is tracking, DEC is not easily turnable by hand so must be under the Servo1's control.

RA works perfectly--slew speeds are brisk, pan speeds less so, guide speed just barely above the tracking speed and that's in both directions.

DEC is not at all.  Touching either the real handpad's UP or Down button or the virtual hand pad in Sitech Config causes the DEC motor to move in the correct direction but at full speed until controller reset.

I've tried slashing the values I'd set last time before this re-wiring but the motor still takes off at full speed, suggesting from the fine manual that the motor encoders are not being read correctly.

I've rebuilt the motor cable probably 4 times now and either I'm repeating the same mistake over and over and expecting a different result, or my Klein pliers have a bad tooth, or...something else like the DEC side of the controller is wonky.  In all of these rebuilds the RA motor works as expected so I don't think the DEC motor is cabled wrong.

To make sure I wasn't completely crazy, as a test, I took the RA motor encoder end and plugged it into the DEC motor encoder socket, then switched the RA and DEC power leads.  Now, the handpad left and right buttons should move the DEC motor and by golly they do, in all speeds in both directions, no controller reset.

My DEC encoder wire is too short to reach the RA motor now so I can't do the reverse test.

I've run out of ideas on how to debug this further and would sure appreciate any other suggestions.

Many thanks,

Jeff Ross

Townsend, MT


Re: Replacement DEC power socket on Servo I

Jeff Ross
 

As a follow up, the part is from Digi-Key and the part number is CP-002AH-ND.

https://www.digikey.com/product-detail/en/cui-inc/PJ-002AH/CP-002AH-ND/408446

Jeff

On 7/14/18 3:48 PM, Jeff Ross wrote:

Thank you Don!  I will do that.

Jeff


On 7/14/18 2:40 PM, westergren@... [SiTechservo] wrote:
 
Hi Jeff,

Taj or Dan are the best people to help you.  Their phone number is listed at the Sidereal site http://www.siderealtechnology.com/

Taj may be off for the weekend, so call Monday.

Don W


---In SiTechservo@..., wrote :

Hi all,

I'm almost done re-wiring my NGT-18 but somehow in the process I broke the power socket for the DEC motor.  The grounding pin that is soldered to the circuit board broke off inside the socket.  I was able to add a jumper from the circuit board to the 3rd pin (also ground) that normally pokes through an open hole in the circuit board.

However, I can't get a response of any kind from the DEC motor so I think I'll be better off replacing that socket. Does anyone happen to know what supplier and  part number I can use to source one of these?  I tried finding it based on the DigiKey cable part number from the manual but nothing looks correct.

I e-mailed Taj but haven't heard back so I thought I'd go to the group.

Thanks,

Jeff Ross




Re: SiTech, MaximDL 6.16 and Merdian Flipping

Don W
 

Hi Ross,

First, SiTech doesn't "grabs" the cameras and performs an offset init.  Using Maxim to do a refined slew eans that Maxim takes an image and solves it via PinPoint, THEN Maxim tells SioTech to use the PinPoint solution to do an OffsetInit.  So then SiTech knows where it is pointed according to the PinPoint solution.  Your statement that the OffsetInit succeeded proves that with the "second slew".

What is the error message?  It undoubtedly comes from Maxim.  I can only guess that there is some form of communication problem between Maxim and SiTech via ASCOM.  Maybe Dan can fix that, but maybe you need to go to Doug George at Maxim - it really depends on what the error message is and what triggers it.  Note you can record the SiTech logs of ASCOM and Serial communications and maybe detect what is going on.

Why are you using Maxim to automate your night, when you have CCDAP, which is a more powerful automation software???  I have used CCDC to control the mount and imaging without problems slewing, platesolving, reslewing to center the target then imaging, even after a meridian flip.  But in my case I was NOT using Maxim "refined slew".

If you use CCDAP you will probably eliminate all your problems.  I know CCDC can do platesolves,using PinPoint LE or PinPoint Full, plus TheSkyX, but not PointXP.  CCDC can run a script, which could do a SiTech PointXP Platesolve and automatic OffsetInit.  The OffsetInit in SiTech is required for SiTech to update it's sky position whether it comes from Maxim or from in SiTech.  I think CCDAP is very similar.

Don W


---In SiTechservo@..., <rgsalinger@...> wrote :

I am having a strange problem with SiTech and MaximDL working together. I am wondering if there is a workaround or if my settings might have gotten corrupted. Here's the situation. I am running .92ge. I am running MaximDL 6.16. It's a big old custom mount with absolute encoders (but that's not relevant).

I have MaximDL set to perform a "refined slew". That means that I want it to use Pinpoint to do a plate solve and sync after any slew and then slew one more time to the target. When I do that, what happens is the SiTech "grabs" the cameras and performs an offset init. That means the Pinpoint has no access to the image and so it throws an error message and the refinement never happens.Since the offset init has succeeded a second slew to the target (while generating the same error) gives me perfect centering.

This is just annoying when running our system manually. I could even just use the OFFSET INIT instead. However, it gets more than annoying since I want to automate my imaging runs and go to sleep. When I do an automated meridian flip (MaximDL can do these now) everything goes smoothly at first. When the scope gets close to the meridian (timed by the length of my exposures) it plate solves the location. Since this is not a slew it works perfectly. Then tracking is turned off. I have it set to then wait until the target is 5 minutes past the meridian. When the target reaches that point, the scope flips just as it should. Then, because this is a slew, when MDL tries to take an exposure SiTEch intervenes and the whole process fails.

I noticed that there is an option under Misc settings to run a script after a slew. Can I just write a script that does nothing and check that box to stop SiTech from doing an offset init? If the settings file is corrupt, where would I see the setting that's telling SiTEch to do an offset init after every slew. Is there any not obvious reason why this is not a bug - maybe using a PXP model causes this to happen. If I can't fix it I can't use any form of automation at all. This can't be normal behavior. Any/all help here greatly appreciated.

Rgrds-Ross Salinger



SiTech, MaximDL 6.16 and Merdian Flipping

Ross Salinger
 

I am having a strange problem with SiTech and MaximDL working together. I am wondering if there is a workaround or if my settings might have gotten corrupted. Here's the situation. I am running .92ge. I am running MaximDL 6.16. It's a big old custom mount with absolute encoders (but that's not relevant).

I have MaximDL set to perform a "refined slew". That means that I want it to use Pinpoint to do a plate solve and sync after any slew and then slew one more time to the target. When I do that, what happens is the SiTech "grabs" the cameras and performs an offset init. That means the Pinpoint has no access to the image and so it throws an error message and the refinement never happens.Since the offset init has succeeded a second slew to the target (while generating the same error) gives me perfect centering.

This is just annoying when running our system manually. I could even just use the OFFSET INIT instead. However, it gets more than annoying since I want to automate my imaging runs and go to sleep. When I do an automated meridian flip (MaximDL can do these now) everything goes smoothly at first. When the scope gets close to the meridian (timed by the length of my exposures) it plate solves the location. Since this is not a slew it works perfectly. Then tracking is turned off. I have it set to then wait until the target is 5 minutes past the meridian. When the target reaches that point, the scope flips just as it should. Then, because this is a slew, when MDL tries to take an exposure SiTEch intervenes and the whole process fails.

I noticed that there is an option under Misc settings to run a script after a slew. Can I just write a script that does nothing and check that box to stop SiTech from doing an offset init? If the settings file is corrupt, where would I see the setting that's telling SiTEch to do an offset init after every slew. Is there any not obvious reason why this is not a bug - maybe using a PXP model causes this to happen. If I can't fix it I can't use any form of automation at all. This can't be normal behavior. Any/all help here greatly appreciated.

Rgrds-Ross Salinger



Re: Need some financial assistance

Don Degidio
 

I have created a GoFundMe to help my dad. Here's the link.

https://www.gofundme.com/help-my-father-stay-in-his-home

Thanks for any help.
Don D

----- Original Message -----
From: "'Don Degidio' djd521@verizon.net [SiTechservo]" <SiTechservo@yahoogroups.com>
To: <SiTechservo@yahoogroups.com>
Sent: Tuesday, July 03, 2018 11:20 AM
Subject: [SiTechservo] Need some financial assistance


Have been on the group a long time and need some quick financial assistance. My dad and I received
a
letter from the bank last week that we are in foreclosure. First time since we moved to our home
in
1955. My dad will be 93 on Thursday and has some medical conditions that require my constant care.
Social Security is his only income besides a small pension. I have been disabled due to several
auto
accidents and SS Disability is my only source of income. Have constant low back pain.

We are in need of $3900 by the end of July to help stave off foreclosure. I have tried several
sources for loans, and been turned down because either disability not considered income, or income
insufficient for loan amount.

I'm asking if any group members can make some contributions to my Paypal account, or mail me what
you can offer. Please contact me off list for more info. Here's my email.

djd521 @ verizon . net just remove the spaces. My email is also my Paypal account.

Thanks,

Don D



------------------------------------
Posted by: "Don Degidio" <djd521@verizon.net>
------------------------------------


------------------------------------

Yahoo Groups Links



Re: Meridien Goto limits not observed after mount has tracked past the meridien

Bill G
 


Re: PointXP script search pattern

Russell R
 

Hi Don,

Thank you for the instructions on building a new script.  Definitely will look into doing just that and will be interested to see if the two types of script searches will have the same results.

Thanks always!
Russell R.


Re: PointXP script search pattern

Don W
 

Hi Russell,

You used to be able to specify where to start, but that is no longer available in SiTech.  The current plan is to start in the south east and do CalStars counter clockwise.  This was one of my suggestions to Dave Rowe years ago when the PXP model was first introduced in SiTech.  The reason was I use a dome, and the dome rotation was bouncing back and forth until the pattern was counter clockwise, passing through zero azimuth (effectively doing a meridian flip) - all for the benefit of a GEM.

Maybe Dan will see this ppost and bring back the option of the CalStar order builting a script.

You can make a script that does the CalStars in the order you want.  However you will have to do some text editing to create the new order and then save it so you can use it again and again.  Here is how:

The PXP script always moves the mount to alt-az positions, so it will work on any date and at any time of day (OK, night).  Create a PXP model run with th number of Calstars you want, say 30 of them.

Save the script (on the script tab, press Save Script.  That brings up the dialog box to save the script file - select where to save it and give it your name (PXP30 model).

Open that file in a text editor- Notepad, Wordpad, Word, etc.  I use a program called Notepad2.exe which shows the line numbers of the script - this program is available on the web at https://download.cnet.com/s/notepad2/

The line numbers are used in the script, but I don't know if that is important.

Look at the SkyView, showing the Future Calibration Points.  They are numbered, so you can choose the order and copy and paste to create a new PXP model.  I suggest you copy the Calibration points data for each cal point to a new file (another copy of Notepad2) in the order you want, until you have a complete new model.

You can then go through the model and change the calibration point numbers and line numbers to match the new order, then save that script (Russell 30PXPscript.script).

Now you can call up that script any time to do a PXP model.  It is a bit of work, but you only have to do it once.

OK, I use 30 stars as a sample, you can use what ever number you want.

Don W




---In SiTechservo@..., <rem.64@...> wrote :

Don W or Dave Rowe,

My mount is portable and so I let PXP and platesolve do all the heavy lifting in terms of initialization. When I do a PXP scripted run, the script calculates the cal star positions, then locates and solves them on one side of the meridian before moving to the other side and locating those cal stars.  Can the script be changed to say start in the north and work south through the meridian?  The mount is equatorial and is not a GEM, but the scope has some mirror flop.  I just think it might work better this way, at least it "seems" to when I do it manually.  Is there any benefit to model if it where done this way instead of loading up cal stars on one of side the meridian before the other? 

Russell R.



PointXP script search pattern

Russell R
 

Don W or Dave Rowe,

My mount is portable and so I let PXP and platesolve do all the heavy lifting in terms of initialization. When I do a PXP scripted run, the script calculates the cal star positions, then locates and solves them on one side of the meridian before moving to the other side and locating those cal stars.  Can the script be changed to say start in the north and work south through the meridian?  The mount is equatorial and is not a GEM, but the scope has some mirror flop.  I just think it might work better this way, at least it "seems" to when I do it manually.  Is there any benefit to model if it where done this way instead of loading up cal stars on one of side the meridian before the other? 

Russell R.



Re: Replacement DEC power socket on Servo I

Jeff Ross
 

Thank you Don!  I will do that.

Jeff


On 7/14/18 2:40 PM, westergren@... [SiTechservo] wrote:
 
Hi Jeff,

Taj or Dan are the best people to help you.  Their phone number is listed at the Sidereal site http://www.siderealtechnology.com/

Taj may be off for the weekend, so call Monday.

Don W


---In SiTechservo@..., wrote :

Hi all,

I'm almost done re-wiring my NGT-18 but somehow in the process I broke the power socket for the DEC motor.  The grounding pin that is soldered to the circuit board broke off inside the socket.  I was able to add a jumper from the circuit board to the 3rd pin (also ground) that normally pokes through an open hole in the circuit board.

However, I can't get a response of any kind from the DEC motor so I think I'll be better off replacing that socket. Does anyone happen to know what supplier and  part number I can use to source one of these?  I tried finding it based on the DigiKey cable part number from the manual but nothing looks correct.

I e-mailed Taj but haven't heard back so I thought I'd go to the group.

Thanks,

Jeff Ross



Re: Replacement DEC power socket on Servo I

Don W
 

Hi Jeff,

Taj or Dan are the best people to help you.  Their phone number is listed at the Sidereal site http://www.siderealtechnology.com/

Taj may be off for the weekend, so call Monday.

Don W


---In SiTechservo@..., <jross@...> wrote :

Hi all,

I'm almost done re-wiring my NGT-18 but somehow in the process I broke the power socket for the DEC motor.  The grounding pin that is soldered to the circuit board broke off inside the socket.  I was able to add a jumper from the circuit board to the 3rd pin (also ground) that normally pokes through an open hole in the circuit board.

However, I can't get a response of any kind from the DEC motor so I think I'll be better off replacing that socket. Does anyone happen to know what supplier and  part number I can use to source one of these?  I tried finding it based on the DigiKey cable part number from the manual but nothing looks correct.

I e-mailed Taj but haven't heard back so I thought I'd go to the group.

Thanks,

Jeff Ross


Replacement DEC power socket on Servo I

Jeff Ross
 

Hi all,

I'm almost done re-wiring my NGT-18 but somehow in the process I broke the power socket for the DEC motor.  The grounding pin that is soldered to the circuit board broke off inside the socket.  I was able to add a jumper from the circuit board to the 3rd pin (also ground) that normally pokes through an open hole in the circuit board.

However, I can't get a response of any kind from the DEC motor so I think I'll be better off replacing that socket. Does anyone happen to know what supplier and  part number I can use to source one of these?  I tried finding it based on the DigiKey cable part number from the manual but nothing looks correct.

I e-mailed Taj but haven't heard back so I thought I'd go to the group.

Thanks,

Jeff Ross


Re: Using TheSkyX Pro with SiTech. exe and SiTech’s Servo Controller II

Don W
 

Hi Jay,

I don't have TheSkyX, but in TheSky6, under the Telescope tab clicking on Server Settings brings up a dialog that allows Parking and many other functions.  Look in TheSky help.

Don W


---In SiTechservo@..., <jaysenter0340@...> wrote :

You are correct. I have been confused, but your description helped a lot. 
Regarding your comment that "You can Unpark from SiTech or from TheSky (you must set TheSky to allow parking and unparking)", how do I set TheSky to allow for parking and unparking? 

On Wed, Jul 11, 2018 at 3:30 PM, westergren@... [SiTechservo] <SiTechservo@...> wrote:
 

Hi Jay,

I think you have some misconceptions of how SiTech and TheSky work together.  Obviously you must have the PC communicating with SiTech as Dan mentioned.

But when you start SiTech, regardless if TheSky is running or not, SiTech doesn't know where it is pointed until AFTER you do an UNPARK.  So every time SiTech starts, it will say "not intialized".  You can Unpark from SiTech or from TheSky (you must set TheSky to allow parking and unparking).  Remember TheSky has no idea where the scope is pointed until it gets that info FROM SiTech.

TheSky doesn't do everything!  It must work WITH SiTech.  SiTech controls the servos and reads the encoders and does the commands to move the mount to ALL positions.  SiTech responds to commands from TheSky equally with you inputs through the SiTech software on the PC.  So a command to "Park" from either TheSky or SiTechexe will work, but only if you set them up ahead of time.

Don W


---In SiTechservo@..., <jaysenter0340@...> wrote :

I am still confused about using TheSkyX Pro (Ver. 10.5.0 Build 11485) with SiTech (0.92 ge) and SiTech’s Servo Controller II. Last night, I started SiTech.exe and did not initialize SiTech. I have learned that you can’t initialize Sitech.exe if you want to use TheSkyX Pro as your main planetarium program. Then, I went to TheSkyX Pro and synched on a star to get TheSkyX initialized. Then, I did a 50 star calibration run, and TheSkyX worked great.  I used Closed Loop Slew to slew to the Ring Nebula and took a nice picture of the nebula.  Then I did “Set Park” and Parked the scope, using SiTech.exe, because the buttons are grayed out in TheSkyX and you can’t park the scope from there.

               Tonight, when I started SiTech.exe, it acts like it wants me to initialize SciTech. It is in the “blind tracking”mode and says it is Not Initialized, Below Horizon Limit, Faking Servos, Reading Servo Prams, Bad Scope Command, etc. I unparked the scope in SiTech.exe, which didn’t help.  TheSkyX Pro says it is “Tracking at sidereal rate”, but doesn’t know where it is.  The cursor slews to a target, but the scope doesn’t move.

               I think the problem is in SiTech.exe, which shouldn’t have to be initialized if I am using TheSkyX Pro as my main planetarium program.

               Any idea what I am doing wrong?




Re: Using TheSkyX Pro with SiTech.exe and SiTech’s Servo Controller II

James Senter
 

You are correct. I have been confused, but your description helped a lot. 
Regarding your comment that "You can Unpark from SiTech or from TheSky (you must set TheSky to allow parking and unparking)", how do I set TheSky to allow for parking and unparking? 

On Wed, Jul 11, 2018 at 3:30 PM, westergren@... [SiTechservo] <SiTechservo@...> wrote:
 

Hi Jay,

I think you have some misconceptions of how SiTech and TheSky work together.  Obviously you must have the PC communicating with SiTech as Dan mentioned.

But when you start SiTech, regardless if TheSky is running or not, SiTech doesn't know where it is pointed until AFTER you do an UNPARK.  So every time SiTech starts, it will say "not intialized".  You can Unpark from SiTech or from TheSky (you must set TheSky to allow parking and unparking).  Remember TheSky has no idea where the scope is pointed until it gets that info FROM SiTech.

TheSky doesn't do everything!  It must work WITH SiTech.  SiTech controls the servos and reads the encoders and does the commands to move the mount to ALL positions.  SiTech responds to commands from TheSky equally with you inputs through the SiTech software on the PC.  So a command to "Park" from either TheSky or SiTechexe will work, but only if you set them up ahead of time.

Don W


---In SiTechservo@..., <jaysenter0340@...> wrote :

I am still confused about using TheSkyX Pro (Ver. 10.5.0 Build 11485) with SiTech (0.92 ge) and SiTech’s Servo Controller II. Last night, I started SiTech.exe and did not initialize SiTech. I have learned that you can’t initialize Sitech.exe if you want to use TheSkyX Pro as your main planetarium program. Then, I went to TheSkyX Pro and synched on a star to get TheSkyX initialized. Then, I did a 50 star calibration run, and TheSkyX worked great.  I used Closed Loop Slew to slew to the Ring Nebula and took a nice picture of the nebula.  Then I did “Set Park” and Parked the scope, using SiTech.exe, because the buttons are grayed out in TheSkyX and you can’t park the scope from there.

               Tonight, when I started SiTech.exe, it acts like it wants me to initialize SciTech. It is in the “blind tracking”mode and says it is Not Initialized, Below Horizon Limit, Faking Servos, Reading Servo Prams, Bad Scope Command, etc. I unparked the scope in SiTech.exe, which didn’t help.  TheSkyX Pro says it is “Tracking at sidereal rate”, but doesn’t know where it is.  The cursor slews to a target, but the scope doesn’t move.

               I think the problem is in SiTech.exe, which shouldn’t have to be initialized if I am using TheSkyX Pro as my main planetarium program.

               Any idea what I am doing wrong?




Re: New Scope

Roy Diffrient
 

Thanks Russell.  That’s my very understanding wife modeling the scope, of course.  I’m sure she is very glad it’s finished.
 
The compensation scheme originated during the preliminary design phase.  I knew I wanted a separate cell, and I was thinking about how to mount it.  It occurred to me that I might have nearly everything needed to do truss flex compensation.  I looked up some “cookbook” beam flex formulae, made a few preliminary calculations using various size beams, and concluded that what I had tentatively planned would do nicely with few changes.  The formula I thought most appropriate was for a simply supported beam, and since mine would be part of the mirror box, it would have welded ends, so I wondered about errors.  But it turned out very well -- In the finished telescope the error caused by the slightly stiffer welded beam is small, and well within the adjustment range, which can easily cover more than a factor of four in flexure.  This scheme is simple enough that I don’t understand why it hasn’t been done previously.  It doesn’t fix collimation errors, of course, but helps maintain whatever collimation you’ve managed to achieve.
 
The SiTech system incorporation was straightforward.  Both axes are friction drives using timing belts.  The alt axis belt pulley is mounted on the one inch diameter hard-anodized aluminum shaft under the mirror box.  The az drive uses a long timing belt around the ground board, with a compression spring keeping tension on it.  The spring is typically adjusted to provide just 35 - 40 pounds tension on the belt, but that seems to be enough.  The scope encoders (40K ticks/rev) are mounted on the axes, so maybe that and a large error allowance helps.  Both SiTech drive units are at one end of the rocker, with an oversize battery at the other end helping the balance.  Seems to work very well -- The SiTech controller has never gone into “blinky” mode, and the power required for tracking is less than one watt.  The only significant change during checkout was to change the mounting of the wireless hand pad receiver so that I could better see the LED’s on it.
 
The SkyFi box is connected to the second serial port of the Argo Navis, with serial port number one connected to the SiTech controller, as usual.  Both AN and SkyFi are set to emulate the serial format of a Meade LX-200.  After the usual two-star alignment, the AN is then set to “From Planetarium” Catalog mode, which allows observing targets to be sent via Wi-Fi from my iPad running SkySafari.  Once a target is sent, the goto is then initiated by the SiTech key pad as usual, just as if everything was being done through the AN without the SkyFi.  The AN can still be used to pick targets of course, but the addition of a planetarium program interface adds a lot of fun, visibility and convenience, to say the least.
 
Roy Diffrient
 

Sent: Wednesday, July 11, 2018 12:27 PM
Subject: [SiTechservo] Re: New Scope
 


Hi Roy,
 
Nice work!  I use a tube Newt. on a equatorial mount, but would like to see how you managed the flex compensation and how you incorporated SiTech into the system.
 
Good Job!
 
BTW, is that you in the photo? :-)
 
Clear skies your way!
Russell

4441 - 4460 of 33952