Date   

Re: scope and motor encoders fighting?

Huw O
 

Thank you both, looks as if it's going to be cloudy tonight, will experiment when I get some stars and see what happens.
Incidentally, I read somewhere on this forum that Scope Encoder and Motor Encoder should match within about 12 arc seconds or so.
Mine in normal tracking is anything up to 30 arc seconds or so out, I'm putting it down to bad PE on my worm. When I slew Westwards the error keeps relatively the same, but when I slew East it goes up to quite a few arc minutes.

Huw


Re: Offset Init & flip during SGP sequencing

MartinC
 

 

Hi Don,

Apologies for the delay getting back to you. I’ve been conducting a variety of tests using my meridian settings compared against the settings that you kindly suggested, along with the default settings. I have some interesting findings to report back. But firstly may I just clarify my position, my requirements & hopefully better explain my problem.

I recently purchased the brilliant Mesu e200\Sitech combination for the following reasons:

  •          I’ve never read a bad word about either product
  •          I know the customer support for both products is second to none
  •          Both products receive nothing but praise & excellent reviews
  •          Superb tracking & guiding
  •          Excellent reliability
  •          No need for Meridian flips
  •          It simply just works out of the box
  •          Also with a bent knee pier I can image under the pole (within reason)

The e200 mount can be used as an Alt\Az, EQ or GEM purely depending upon how it is mounted. Mesu also sell a bent knee pier for ‘flip-less’ anti-collision operation. I opted to build my own bent knee pier to suit my dome.

SiTechExe can also be configured for Alt\Az, EQ or GEM mode of operation. So as I see it, it’s simply a case of matching the mode of operation to your type of pier.

My specific requirement is for ‘flip-less’ operation but strictly in conventional GEM mode.

Why? Because my dome is small and the scope’s dew shield only just clears my dome walls. Also my shutter opening is quite high. If I begin imaging in a counter-weights up situation compared to a counter-weights down situation my dew shield can be in the order of 1.6m closer to the ground. Unless I’m imaging close to the zenith this means my target quickly becomes unobservable or not observable at all, because the scope can’t ‘see’ over my shutter threshold.

Therefore when I acquire a new target I need the scope to act as a GEM & flip if I slew from east to looking west; and flip if I slew from west to looking east. I.E. for a new target on either side of the meridian I always need to begin counter-weights down.

I would like my mount to track past the meridian without being stopped or flipped by any limit or threshold setting.

I need the mount to only flip on goto’s & not during tracking.

Also, for goto’s, I need it to flip at the genuine meridian. Not at a meridian that has been artificially moved to a different part of the sky.

 

I soon discovered that once the track-past threshold was breached the mount automatically either flipped or stopped, depending on the “GEM Auto Flip Track” setting. 

Because my sequencing software does not initiate this instruction it has no idea it is happening which causes problems.

I couldn’t find a set of meridian & track-past settings that worked for me without the mount flipping at an unwanted place or being counter-weights up when I didn’t wish it to be.

A few weeks ago I spoke with Dan & explained my situation. He was very understanding & quickly produced the 95MWin version that allowed a free rein of the meridian & track past settings.

I found that with the settings I posted at the beginning of this thread the mount flipped & tracked exactly as I needed & I confidently reported back to Dan that my problem was resolved.

Unfortunately I now realise I spoke too soon as (with those settings) I’ve discovered a caveat which only manifests during plate solving in the east.

 

My findings:

Please refer to the attached diagram as this helps to picture my testing method. I’ve borrowed the diagram from the ASCOM side of pier behaviour document by Peter Simpson.

I have tested using both my dome PC (W10) and my laptop (W7), SitechExe.95M, SGP, two different plate solvers, two different cameras & the ASCOM simulator V2 camera. I have tested with the ‘GEM Auto Flip Track’ check box both ticked & un-ticked.

Under real imaging sequence conditions and\or ASCOM simulation I have tested plate-solving at sky location points A, B, C & D.

For each of those 4 plate-solving locations I have use 3 sets of Meridian settings:

  1. My original settings:- over pole W = 4, over pole E = 2, under pole W = -176, under pole E = -178, track past = 178
  2. Suggested settings:- over pole W = 90, over pole E = 0, under pole W = -178, under pole E = 178, track-past = 90
  3. Default Settings (as shipped with mount):- over pole W = 2, over pole E = -2, under pole W = -178, under pole E = 178, track-past = 2

W   With my original settings & looking east, when plate solving point ‘A’ the mount will slew to point ‘D’, re-plate solve, slew back to point ‘A’ and continue imaging as if nothing has happened. The same applies if I plate solve at point ‘C’, the mount will slew to point ‘B’, re-plate solve, slew back to point ‘C’ & continue as if nothing has happened.

·        Looking west and plate solving points ‘B’ or ‘D’ is fine. There’s no unwanted slew.

If I were operating in the open air or with a roll-on\roll-off roof then none of this would be a problem. But I’m in a dome with a shutter. My sequencing software has not initiated the unwanted slew & therefore does not ‘know’ the mount has moved. Therefore my slaved dome does not follow the mount. So the second plate-solve fails because the camera is imaging the inside of my dome & my sequence aborts.

·        I then repeated the same tests but this time using the settings suggested to me.

Don, you are quite correct, my mount will then track past the meridian, but unfortunately as you also state, if I acquire a new target in the west then I’m counter-weights up. This is no good for me unless the target is up near the zenith.

·        ALSO VERY INTERESTING is that with the suggested settings I’ve noticed that the plate solving problem is still present but has simply moved round to the next quadrant of the sky. If my target is at point ‘C’ when plate solving the mount will now slew to point ‘B’, re-plate solve, slew back to point ‘C’ and continue as if nothing has happened. If I plate solve at point ‘B’ the mount will now slew to point ‘D’, re-plate solve, slew back to point ‘B’ and continue as if nothing has happened.

·        I reverted to the standard default meridian & track-past limits that my mount was shipped with:

Then plate solving in all parts of the sky works correctly without any unwanted slews & my mount flips at the meridian for goto’s.

But the problem for me is I’m then back to unwanted auto-flips or halted tracking when the track past threshold is breached.

·        I found that parking and\or initialising either east or west does not make a difference.

·        A different PC\laptop & operating system made no difference.

·        A change of camera produced the same results.

·        A change of plate solver also produced the same results.

·        I believe I can rule out SGP because I find that the plate solving behaviour depends only on how my meridian & track past limits are set.

 

My Conclusions:

Both my original & the suggested settings appear to just move the problem elsewhere in the sky. 

I find the default settings do not suffer from the unwanted slew(s) during plate solving but I cannot avoid breaching a track past limit at some point. This causes the mount to auto-flip or stop depending upon how the “GEM Auto Flip Track” tick box is set.

I find that moving the meridian limits introduces an unwanted counter-weights up scenario and\or unwanted slews during the plate solving routine depending upon what the Meridian settings are exactly & in which sky quadrant the target resides.

 

I do not believe that flip-less GEM operation should be considered an invalid configuration?

In addition to the above I have experimented with many other values for the Meridian settings.

So far I have been unable to find settings which cater for true flip-less GEM operation.

So where does this leave me & what is the solution?

Many thanks & regards

Martin

 


Re: scope and motor encoders fighting?

Don W
 

Hi Frank,
That is enlightening, setting the Comm Loop time to 100 is recommended.  I had not heard that longer times caused problems.  I have always used 100.

Hi Huw,
Try Franks solution, it might fix your spikes.

Another thought I have is to check your PC to see if there is another program running that periodically (every hour) runs - possibly causing SiTechexe to spike.  Programs like anti-virus scans or data backups that run every hour might be the cause if Frank's comm setting doesn't work.
Don W


Re: Guide Setting

Don W
 

Hi Ned,
The guide speed is the speed that guiding uses to correct the position - only with a guide camera.  Usually the guide speed is equal to the sidereal rate = 15 arc-seconds per second.  Autoguider software usually have a factor called aggressiveness which can reduce the guide speed.  Also some users set the guide speed to about half sidereal to minimize excursions of their mount.  That is equivalent to setting the aggressiveness to 5 (on a scale of 0 to 10).

From your description, you must be doing unguided imaging.  Unfortunately, the motion of stars varies across the sky, mostly due to refraction.  Pure sidereal rate is only near the zenith.  The movement due to refraction is mostly i the east and west ( I think it is slow in the east and fast in the west).  This effect is strongest at low altitudes.  This is why it is generally recommended that imaging be at altitudes greater than 30°.

Don W


Guide Setting

Ned Smith
 

I have used SiTech for years and have had very little trouble.  I have always ignored the "Guide" speed.  Don't really know what it is for.
Now I am finding that in long exposures the image slowly drifts off the screen. Can the Guide speed be used to overcome this drift?  How?  

--
Ned Smith


Re: scope and motor encoders fighting?

Franklin
 

Hi Huw,

I had a similar looking issue two or three years ago. After I had ruled out every mechanical and electrical cause, the spikes kept happening. Eventually I found I could eliminate the problem with a simple config change. You can read all about it here...
https://groups.io/g/Sitechservo/message/29818
I don't know if this issue was addressed in later sitech.exe builds, but at least it is something to look into.

Frank


Re: scope and motor encoders fighting?

Don W
 

Hi Huw,

Wow, those are really bad spikes in RA.  However they look just like a sample in one of the PHD2 PDF's on Analyzing PHD2 Guiding Results – A Basic Tutorial.  I downloaded that PDF a couple years ago ( I don't have the URL now).  The PDF said that such spikes are generally caused by outside events (not caused by the controller nor the guiding).  Here is an excerpt from that PDF:

We see that guiding was going normally on the left-hand side of the graph before the big upward
spike. In particular, there was no huge guide pulse that caused the star to move so far on the
sensor. Instead, you see PHD2 reacting *after* the guide star moved off-target by sending a
stream of 9-10 RA guide pulses in the opposite direction. So “something just happened” to cause
this problem – some sort of mechanical event that started the whole thing, not something caused
by PHD2. Unfortunately, this is a very common problem, particularly for set-ups that aren’t
permanently installed in an observatory. Worse still, the guide log doesn’t give you much help in
figuring out what caused the original deflection, and the possibilities are seemingly endless. One
thing that can help is to get a mental calibration of how little motion is required to trigger these
events, particularly if you’re using a longer focal length set-up. Position your monitor so you can
see it from near the telescope, then start looping on a star. Now gently push on various parts of
the guide scope assembly and tug gently on the various cables. You’ll usually see a little goes a
long way, and it’s very easy to create large guide star excursions.
Here are some of the more common causes of these problems:
1. Any sort of looseness in the mount, tripod, pier, or scope assemblies
2. Dragging cables
3. Wind gusts
4. Anything that jostles the scope, camera, pier, or tripod such as moving around near the
scope
Dragging cables are a particularly common problem, which is why experienced imagers do a
careful job of routing and securing them. Especially in cold weather, these cables become stiff
and unyielding, so if they touch or rub against a stationary surface you will probably see guiding
problems.
Obviously, the list of possibilities is endless. Some of the reported causes can be pretty funny
assuming, of course, it’s someone else’s problem. Here are just a few real-world examples:
1. The family cat poking around in the observatory at 3:00 in the morning
2. Owls landing on the end of the telescope tube
3. Leaving a rolling observatory chair near the end of the declination axis (ok, that was me)

I see that the period is VERY regular, the same period between spikes.  This is an important clue - saying that whatever the cause is happening at a regular interval.  So look for something that is happening every hour (maybe a power spike, or a flashing light, not likely an Owl landing on the scope).

This may be a tough one to solve.

Don W


scope and motor encoders fighting?

Huw O
 

My mount is a traditional worm driven fork mount, with motor encoders. The RA worm wheel had really bad periodic error, so a Gurley encoder was mounted on the RA axis.
I have finally got this encoder behaving, but I now have what I believe is a situation where there are two feedback paths fighting.
I have some strange "bumps" in RA guiding, which were not there before the scope encoder was fitted
I attach a PHD graph from last night : (Capture 15.04.21.JPG) The encoders during this run were differing by about 5-8 minutes of arc according to the 'Controller information window', and the pulses were at approx one hour intervals.
I can see no obvious period corresponding to one hour in the RA drive train
Tonight, I zeroed the difference between both servo systems before of the imaging run, and had no pulses for the first three hours, then two within 20 minutes. (Capture 16.04.21.JPG)

The drive is as rigid as I can make it, is there something I am not taking into account?

Huw


Re: Meridian Limit and Unpark Question

Joshua Hufford
 

Thanks for the info Don, I'll post an update after I try this out. 

Josh

On Mon, Apr 12, 2021 at 12:00 PM Don W <westergren@...> wrote:
Hi Josh,

I am finding out that 095P has some weird response to setting negative limits.  So be very careful with your settings and check those settings after you close ChangeConfig by opening ChangeConfig again.

When I set the West limit to -03:00:00, my East limit sets to -04:00:00 automatically (I can't change it).  With GEM Auto Flip Track unchecked, the mount will track to that -3 degree setting and stop.  This is what you want.

With GEM Auto Flip Go To checked, the mount will flip if you choose a target at less than 3 degrees EAST of the meridian.  I think you don't want that, so you just have to be careful.  You will control where the mount goes with GOTO's to avoid the ±3 degrees of the meridian.

I think this all will work for you, since you only track east to west (above the pole).

Good luck,
Don W

All of this is with the setting for Track Past Meridian Overlap set to zero.  If you don't have that = zero, then your mount will track past your -3 degrees.


Re: Offset Init & flip during SGP sequencing

MartinC
 

Thank you Paul,

I believe 'P' is the latest
http://siderealtechnology.com/SiTechSetup095P.exe

Best wishes
Martin


Re: Offset Init & flip during SGP sequencing

paul K
 

ok no probs, I like to keep my s/w upto date, so I'll download 'M' tomorrow. If there's some clear I'll try the settings, it only takes 15 mins or so.
best wishes
Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

Ah that's because you need at least .95M to be able to exceed those limits.

Thank you again for your interest and testing on my behalf but please do not do anything you're not comfortable with. You may be quite happy with .95G so don't change it if you are happy with it & it works for you.
And once again please be careful if you do experiment. My scope cannot crash into my pier but yours can.

Best wishes
Martin


Re: Offset Init & flip during SGP sequencing

paul K
 

perhaps my version of .95Gwin is not the same as your Martin?

When I tried to enter the track past meridian overlap value Sitech will not allow a number > 90 degrees The other values were allowed as per your image. If I try to enter 178, when I leave the field it reverts back to my original number which was 5.

Paul


Re: Offset Init & flip during SGP sequencing

paul K
 

if the cloud holds off Martin I'll give it a try with those settings tonight (U.K. time).
best wishes
Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,
I've just thought about what you said & I think the dome movement is not so relevant here because it's under the control of SGP, not SiTech.

In my case the 2nd plate solve taking place without the dome moving is just 'collateral damage'. If I had a roll-on/roll-off roof or was in the open air it wouldn't matter because on the 2nd plate solve it would get a real image & slew back to where it should be.

I made a mistake in my previous reply. Instead of "Don's recommended settings" I mean't to say my original settings - that is the ones in the image I posted at the beginning of this thread.

But only if you have time.

I've been testing using the ASCOM Camera V2 Simulator. You can just enter your sensor details and load a jpg image taken with your camera from a previous occasion. So you can test regardless of conditions & even during the day if you choose an image of what's actually in the sky at that particular time.

Best wishes
Martin


Re: Meridian Limit and Unpark Question

Don W
 

Hi Josh,

I am finding out that 095P has some weird response to setting negative limits.  So be very careful with your settings and check those settings after you close ChangeConfig by opening ChangeConfig again.

When I set the West limit to -03:00:00, my East limit sets to -04:00:00 automatically (I can't change it).  With GEM Auto Flip Track unchecked, the mount will track to that -3 degree setting and stop.  This is what you want.

With GEM Auto Flip Go To checked, the mount will flip if you choose a target at less than 3 degrees EAST of the meridian.  I think you don't want that, so you just have to be careful.  You will control where the mount goes with GOTO's to avoid the ±3 degrees of the meridian.

I think this all will work for you, since you only track east to west (above the pole).

Good luck,
Don W

All of this is with the setting for Track Past Meridian Overlap set to zero.  If you don't have that = zero, then your mount will track past your -3 degrees.


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,
Many thanks for taking the time to test on my behalf, that's very kind of you. I imagine that as you have a conventional pier your meridian limits are pretty much default & I wonder what you'd find with the settings Don suggested to me earlier in this thread at #32847? If you do try this make sure you are in attendance just in case. Don't try it remotely.

I spent the whole weekend testing various scenarios with my settings, Dons recommended settings & the default settings. What I found was interesting but I have a few more checks to complete first before I post back.

Best wishes
Martin


Re: Meridian Limit and Unpark Question

Joshua Hufford
 

Thanks everyone. 

So if I understand it correctly, if I want the mount to stay 3 degrees away from the meridian on both sides all the way from north to south I would set the over the pole east and west limit to -03:00:00 and the under the pole to -177:00:00

Correct?

Was clear last night and able to do some testing for the first time under stars, pointing and tracking was pretty good. With no point model all objects across the sky were within at most 2/3 from center of a 910mm scope and 8300 chip. A rough measurement of the PE looks like about 12 arc seconds peak to peak. Seeing was not too good so I couldn't really nail down the guide settings but I was able to guide long enough to get good stars at 10 minutes of exposure. 

Next clear night I'm going to work on getting a point model created and hopefully refine the guider settings. 

Josh

On Sun, Apr 11, 2021 at 6:07 PM MartinC via groups.io <mncrane=virginmedia.com@groups.io> wrote:
No problem, it was good that there was a solution.

Best wishes
Martin


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

241 - 260 of 33141