Date   

Complete Si Tech GoTo System for Sale or Trade #ascom

 

Si Tech GoTo System  hardware for Sale ($1000) or Trade possible  

I have decided "Push-to" control for my 14" Hubble Optics Dobsonian  and am selling the Si Tech Goto hardware and controls that I've written about in various forums, e.g., https://www.cloudynights.com/topic/448970-show-us-your-dobsonian/page-43

Original cost was $2544 = $1995 + $549 for added hand controller an battery hardware

I'm selling for a couple of reasons.  First, I've decided that I like my Dob to be fast and simple to set up, so I can spend maximum time observing visually.   The SiTech system is amazing, but adds weight and complexity, which I don't need for visual observation.  Second, I've already purchased an HNA  optics set from Tong (12" hyperbolic primary + 3.5" elliptical secondary +motor controlled 3.5 focuser with Rosin corrector) which I plan to put into a CarbonScobeTubes tube, following the plan of Paul Zelichowski's "Starbase" scope.  My plans suggest this should give me a 42mm fully corrected-illuminated field for astrophotography, in  ~40 lb. package that can be mounted on my G-11;  so I can use something like a QHY 367C color camera.

The Si Tech is a great system. All of the electronics work right out of the box, and the mounting hardware is precise and sturdy, though some of the hardware would have to be changed, mainly to accommodate the bearing attachments, since currently they fit my HO14". Slew speeds can be made very fast (everything is programmable in the SiTech setup), as you can see in this video [url="""][/url]. I'm particularly impressed with the wireless hand controller which operates at 465 MHz (like garage door openers and key fobs ... so no interference from 2.4GHz devices). Computer communication is through Bluetooth which shows up as COM4 on my Surface laptop. Encoder and motor specifications are set up with a configuration utility, ServoConfig1.3, that is available on SiTech's site. ServoConfig lets you set parameters and read and write them to the servo controller hardware.

I'm controlling the telescope with SiTechExe and Cartes du Ciel or Starry Night Pro. Once you have SiTechExe up and running, it reliably connects to the planetarium program. You can use a Surface tablet or PC to track, select and GoTo objects to observe; combined with the handpad (which doesn't interfere with the Bluetooth COM4 port on the Surface) you have a truly optimal wireless interface design. The hardware is 'observatory quality' and the software provides me with more flexibility and control than I could ever get with an 'off-the-rack' GoTo system.

Additional components included:

Wireless Handpad: 

- Has a built in astronomers adjustable LED flashlight
- Glow in the dark keypad.
- Has a keyboard Lock feature, so only the arrow keys work. This is great for handing the transmitter to the general public, so they can pan the moon for instance. They won't be able to do any harm!
- Addressable! Many scopes on the same telescope field can use the handpad at once. No interference between scopes, and you won't be controlling the wrong scope!
- Instant Action! With the SiTech system, wired or wireless, there is imperceivable delay between the pressing of a button and movement of the scope! Great for centering objects without any overshoot!
- Built in auto guider port.

Bluetooth Serial Adapter

12V Battery Holder

12V to 24V DC converter


Re: Meridian Limit and Unpark Question

MartinC
 

No problem, it was good that there was a solution.

Best wishes
Martin


Re: Meridian Limit and Unpark Question

Don W
 

Hi Josh and Martin,

Yes, I see that 095P does allow negative limits.  I just tried setting the West limit to -5 degrees, and the mount stops tracking at 5 degrees before the meridian.

Josh this is your answer - it works!

Thanks Martin for trying this.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

Jose Ignacio Sanchez Rodriguez
 

Hello Don,

Sorry it took some time to answer, but we are building at home adn this is a mess. I think you made a very good summary of the situation.
All mounts are prone to have problems, the important thing it to have the manufacturer by your side in order to solve them. As  users we need to offer the manufacturer some sort of evidence of the problem we claim we have. Given the nature of our hobby this might be a difficult and lengthy process. It is a well known fact that customers who have issues are more vocal about their experience with the product than customers who don´t have issues...I guess they are out there imaging, instead;) So I think it is easy to take things out of proportion and assume, out of a few cases, that these issues are general to the product. We are only looking at the numerator here. The denominator is hundreds of mounts out there that produce high quality images and make their owners very happy. Let´s not forget that.

There is a story from when Lucas first started to produce the MKI that involved a problem with a part from a third party supplier. Lucas ended up traveling around Europe to the affected owners houses to personally change the part and assure everything was ok. As I have mentioned before, so far the level of service I have received from Lucas has been at that level. So even if I´m not at a happy place right now, I feel confident we´ll find a solution.

Thanks all for your help and have a nice week,

Jose


Re: Meridian Limit and Unpark Question

MartinC
 

Hi Josh,

I don't mean to intrude but I'm currently looking at a different issue I have with Meridian limits - hence my interest in your question.

I believe you can stop your tracking before the meridian. I have just tried it on my mount.

Since version 95M you have the ability to set the meridian limits anywhere, pos or neg. You can also set the tack past limit to any positive number but not negative.

So I've set mine as per the attched images & it works. I'm sure you can experiment to suit your exact needs. I've not tried for Under the pole but I gues the same will apply.

Hope this helps

Best wishes
Martin


Re: Meridian Limit and Unpark Question

Joshua Hufford
 

Hi Don, I'm using a longer scope now that I was previously, and with my large 8 position filter wheel if I track all the way to the meridian my wiring gets awfully tight at the pier, might have to figure out something different, however a 3 degree limit on each side gives a decent amount of a safe zone. 

Thanks for the explanation of the Park, it seemed to work fine. I just didn't remember getting that message before. 

Looking forward to hopefully posting some new images soon. 

Josh

On Sun, Apr 11, 2021 at 2:21 AM Don W <westergren@...> wrote:
Hi Josh,
It is good to hear from you again. In answer to your question about stopping tracking before the meridian, I think the answer is NO.  Why do you want to do this - maybe there is a work-around?

The latest SiTech is 095P at:
http://siderealtechnology.com/SiTechSetup095P.exe

SiTech records a note in the SiTech.cfg file about the park situation.  All that is - is a 0 for not parked and a 1 for parked.  when you start up SiTechexe, it simply reads that cfg file entry, but that really doesn't do anything.  If the mount is in your park position, then go ahead and UNPARK.

Don W


Re: Meridian Limit and Unpark Question

Don W
 

Hi Josh,
It is good to hear from you again. In answer to your question about stopping tracking before the meridian, I think the answer is NO.  Why do you want to do this - maybe there is a work-around?

The latest SiTech is 095P at:
http://siderealtechnology.com/SiTechSetup095P.exe

SiTech records a note in the SiTech.cfg file about the park situation.  All that is - is a 0 for not parked and a 1 for parked.  when you start up SiTechexe, it simply reads that cfg file entry, but that really doesn't do anything.  If the mount is in your park position, then go ahead and UNPARK.

Don W


Meridian Limit and Unpark Question

Joshua Hufford
 

Hello everyone, after a hiatus from imaging do to mount motor failure and just general life getting in the way I'm getting my imaging setup back up and running again. My MI-250 is now running with Pittman 9000 series servo motors instead of the stock Losmandy Gemini motors, should be a big improvement. 

First question about the meridian limit, is there a way to prevent the mount from tracking a few degrees before it hits the meridian? I tried entering a negative number in the meridian overlap setting, however it wouldn't accept it. I'd like to have my mount stop tracking three degrees before the meridian if possible. I'm guessing the Meridian Limit east and west boxes are where I would set this, but I'm not exactly sure what I need to input here. 

Also I have my park position set, however when I click UnPark I get a message saying the scope is not officially parked. Any idea why that is?

Lastly I'm running version .94N. Is this the latest version? If not what is? 

Thanks!

Josh


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin, I had some clear tonight so at 10 pm I set up M95 (east of meridian at that time) as a sequence in SGP.

On this occasion in Sitech I set the scope horizontal pointing Az 90 and parked it there. So my process was as follows:

unpark the mount (I used Sitech interface to do this)
In SGP, tick slave dome to scope, then in target settings click 'Centere now'

Findings:

Scope moves quite quickly to target (as usual for me) - no pier flip.
Dome takes a while to catch up and before it does, SGP's centre now routine is taking an image of the inside of my dome.

I repeated this process three times with the same result each time.

So that wasn't particularly useful, it's similar to what you found, but I had no pier flip from Sitech up to that point of failure.

If it's clear again tomorrow night I'll park at Az 270 and centre on a target west of the meridian to see if the same happens on the west side.

I must admit I'll be surprised if it fails to wait on the west side as that's where I image mostly, and I'm sure I'd have spotted the problem before. I will check though.

Also tomorrow I'll post a pic of my mount parms dialog from Sitech.

Best wishes
Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi JonK,
I also agree that imaging under the pole can be of interest and should be straightforward with a bent knee pier.

One thing I've noticed if you set your limits on top of each other is that the RA axis gently oscillates at the end of a slew instead of tracking. Like a PID controller that's not quite tuned.

If you don't mind being weights up then perhaps you could take it out of GEM mode. That will get rid of the limit settings.

Unfortunately for dimensional and spacial reasons I need to be weights down when begin to image; be that in the East or the west. Which means that ultimately Don's suggested settings won't work for me if I choose to begin imaging looking west. I need the mount to function as a GEM.

But I'm going to try Don's settings to check if they illuminate the unwanted slewing during plate solving in the east. Either way it will be an important test.

I shall also try with APT instead of SGP, a different plate solver and a different camera. That should rule in\out any possible equipment compatibility issues.

I shall also test using the ASCOM camera simulator. You can load an image into it and run a real sequence which means I can test during the day.

Hopefully soon I'll have some test results.

Best wishes
Martin




Re: Offset Init & flip during SGP sequencing

Jonk
 

I'd like to agree with MartinC and Paul K.

I also have a bent knee pier, designed mainly to avoid meridian flips and any possibility of crashes, and I asked the question about setting limits before on a separate thread.

What I have done is set all limits to +/- 180 degrees, essentially moving everything to be between the ncp and the N horizon. I know this will probably be frowned upon, but in testing this appears to be all I can do to 'remove limits'.

I would like to see a simple switch in the software, turning limits off, with a simple pop up message 'are you sure, damage may result if incorrectly used' or similar, as is in use on other mount control systems I have seen. This would cater for people who do have the possibility of a pier crash.

I also disagree with the comment above about not imaging under the pole - ok, for people with a pier crash possibility, this is sound advice, but people have to take responsibility for their own actions. For people without this issue, there's no reason not to - ok, it's not abundant with targets for imaging, but take last year for example - Comet Neowise - a perfect example of set in the NW and rise in the NE. My observatory location has a fairly good NW to NE view so I would certainly look to be pointing in that area.

But, it's not always about imaging - I am an occasional observer and with my large refractor, I simply remove the imaging gear and fit a diagonal and eyepiece. If I want to point to the N, which I probably will do frequently as it's the darkest part of sky for me and is probably my best horizon taking into account the low skyline and lack of serious light pollution, then the advice of 'don't image' (or observe) under the pole doesn't work for me. Especially with a bent knee pier. Again, Comet Neowise would be a perfect example.

Regarding the initial error discussed about the plate solve then the mount slewing to a mirror opposite without any input from SGP, I am very interested to see if this is a bug. Unfortunately, my equipment is not set up so I can't run my Mesu e200 / SGP combination to see if it does the same, but look forwards to the resolution.

In conclusion, a 'switch off mount limits' button would be great, as I don't really care whether I am weights up or down for the majority of what I want to do.


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi Paul,
Slippage anywhere in the drive is bad.  All slippage is dependent on the load and the level of friction.  Slippage is by definition when the friction is overcome and the two parts allow movement when you don't want any movement there.

So Slippage can be the friction drive wheel (like the Mesu Mount drive), it could be a set screw in a coupling or belt drive hub, or as Chuck mentioned the output drive gear in Pittman Servos is staked to the output shaft. Any and all of these cases "could" occur in a localized place in the sky - for instance due to balance where in part of the sky the motion is working against the balance load.  The cause of slippage doesn't know or care where you are pointing in the sky - it just slips when the friction isn't enough.

Generally the SiTech servos will be applying torque when tracking similar to when slewing.  The acceleration and deceleration of a heavy and especially a long refactor (lots of moment of inertia) is where the loads on the drive are higher.  If slippage is marginal during acceleration then SiTech can be set to reduce the acceleration forces.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

paul K
 

Just to ask the question to try to help, would the slippage Chuck describes be positional as per Jose's problem? Or given the gearing ratio (motor to mount)  would it be more evident i.e not just one place in the sky?

Paul


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi Chuck and all,
Chuck has a good point that slippage might be IN THE SERVO.  But that would also affect slewing.

A test for this (or any slippage) would be to slew between two stars (about 10 degrees or more apart) with a camera recording the positions at each star.  Do this a few times and the images will confirm if there is any slippage.
Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

CandCShaw
 

One more thought..... if the servos have built in gear reducers on them, the spur gears may be slipping at the armature gear or at the output gear.  Quite a few years ago I had what I thought was drive slippage, but my clutches were confirmed to not be slipping. Turns out, it was the spur gear that was “staked” to the output shaft that was slipping under load. The motor was one I had obtained from Dan.  This was a low odds failure, but the lesson is not to rule out things without solid evidence. 

Chuck 


On Apr 8, 2021, at 2:42 PM, Don W <westergren@...> wrote:

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

CandCShaw
 

Don, servo config has an excellent routine for determining tics per rev for friction drives. It does not require any “mount” encoders, just the Motor encoders. 

Chuck


On Apr 8, 2021, at 2:42 PM, Don W <westergren@...> wrote:

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Mesu 200 Mk2 Tracking stops close to equator

Don W
 

Hi All,
I am a SiTech user since 2008 and one of the authors of the SiTech manuals (not written by Dan) in 2009.  I am also a moderator of the forum, along with Dan and Chuck Shaw.  I try to answer all questions that come up on this forum.  Over the years I have been in personal contact with Mesu users and with Mr Mesu himself.  The recent problems discussed here now are apparently mostly with the newer Mk2 version.

I believe Mr Mesu stands firmly behind all his products, just as Dan stands behind all the SiTech products.  The more products produced and sold means there will be some products that have "problems".  These are also complex products, which have "learning curves" so many times the answers are in the settings and use of controls.  Also many times the "problems" are caused by users using other programs which interact with SiTech and the mount.  A large number of problems occur when settings in two or more software try to control the same operation - you and I don't know which is the culprit.

In Jose's case, the SiTech logs show that the servos are moving properly, but the camera proves the mount is not moving properly.  With a friction drive, there "CAN" be slippage and that is what is indicated.  That is a mount problem, pure and simple.  Mr. Mesu has produced a lot of mounts over the years using friction drives and they "work".  I have never seen a Mesu Mount, but I understand the setup of the friction drives is something the user doesn't normally do.  Only Mr. Mesu does that.

All friction drives have the possibility of slippage.  Dan programmed into SiTech ways of using mount axis encoders to detect and handle "slippage".  The Mesu mounts are the only ones I know of now being produced with friction drives.  All the early Mesu Mounts used to have mount encoders.  Now they don't, so Mr. Mesu must be confident that slippage is not a problem.  but as always, with many many products produced, a few will have problems.  I think that is what we have here.

Don W


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

 

Thanks for the confirmation & offering to test in the east.

 

My procedure is the same as yours but on the opposite side of the meridian in the east. The only other difference is that I’ve not made a habit of a ‘pre-initialisation’ during the day as you do because I tend not to shut down the drive but leave it energised. If I do and have previously parked then it remembers where it is anyway. I have tried powering it off and re-initialising though but it makes no difference to the outcome.

 

As you say imaging opportunities are rarer these days which is why it’s so important everything works as expected.

 

That’s why I invested in the Mesu\SiTech combination; and it is good. I like the construction and the software and tracks & guides very nicely.

 

This issue can’t be down to SGP otherwise I’d see the same problem in the West and you would too. SiTech-wise the only real difference between us is our Meridian limit settings (because of our different pier arrangements) but I just don’t see why (in the east) that should cause the mount to slew to the exact mirror position on the opposite side of the meridian during plate solving?

 

Hopefully Don’s solution will resolve this & I can hold up my hand and apologise profusely.

 

Best regards

Martin


Re: Long term alignment (new user)

jmgoldba
 

On Wed, Apr 7, 2021 at 01:54 PM, Mark Copper wrote:
The hardware is a thousand miles away.
Okay, I'm just under 500 miles away. Though I rely on others, like Don, who live closer for hands-on I do run the software at home in a simulator mode.

There are two things going on: configuration and control. The 'Using Nexus...' document should really be called 'Configuring Nexus...'. All off the shelf control programs typically have some planetarium functionality. SiTechExe has SkyView.

I'm still not clear how you're planning to control your mount, as in point at targets, using the Nexus. On Linux I suppose you can use KStars with a Nexus Indy driver or maybe Nexus has some mount operation program that's going to include a Park option, where the Nexus program effectively hides the SiTech interface from the user after its been configured.

Jesse


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin,

Yes I initialise (and park) at Az 270. Each session (there's usually quite a lot of time between them these days) I initialise using skyview to get an offset init @ Az 270 with the scope horizontal. (I usually do this sometime during the day). I then slave the dome to the scope in SGP at the start of an imaging run and use the Sitech handpad to slew to a random location west of the Meridian, and platesolve to get an accurate offset init. I then use centre now or 'run sequence' in SGP, BUT I've always done the first platesolve west of meridian, just 'cos of trees to N and to E.

However, as I mentioned I'm moving my obs to a field with no obstructions and my plan there is to set everything up in SGP and let it start by itself, so if my target was E of meridian, when a timed sequnce starts in SGP, the first platesolve will be in the east.

I do have a bit of visibility slightly E of meridian at my current location, so I'm going to try a 1st platesolve in the East next clear night just to check this out. I'll post back.
Best wishes
Paul

261 - 280 of 33143