Date   

Re: Meridian Flip Settings Explained

Russell R
 

Hi Don & Martin,

Don, in post #32972 you stated "Also you are using the WRONG terminology - you are NOT platesolving at all." and "There are so many problems with your procedure that I can't help you at all."  That's not exactly true.  Martin only initialized his mount, and used the platesolve in SGP after a slew to center on target.  I understood that you threw in the towel Don, I apologize for that.  I'm glad to see you are still trying to help Martin.  We need your expertise.

Martin, I understand your issue, because of the small dome and high shutter, you want to image past meridian, but flip at the meridian for gotos.

I suggested using a mount model because it does deal with flips, by pointing on the east side first, then flipping to the west, or visa versa.  It deals with objects below pole and it moves the mount to accommodate the rotation of a dome, all done automatically.   If it works for Martin with normal GEM settings, which keeps weights down, then I would like to see what happens when he would move the meridian limits for what he wants to do.   This is a test, without using SGP to command moves or platesolve, to stop the "mirror slew move" under pole, that's all.  I never said it would solve his problem. 

If it does work, the issue I have is that continually moving elevated shutter...........hmmm.  Maybe you should just get a bigger dome Martin......?

Good luck,
Russell R.










 


Re: A question for Don

Dan Hummel
 

Halfheimer's can be a bugger. Its a running joke with my partner that it's taking so long to finish this project that by the time we get done we will have forgotten how to use it. We installed a Renishaw on the RA axis long ago. As we remember we couldn't get servo config to accept the correct tick count. We thought we had used Tick Determination to get the values entered but that must have been faulty memory cells. I just tried to enter a new altitude value in the Servo Config Auto Tracking window and again couldn't get it to accept the values. For some reason it would accept up to 19,999,999 but not a tick more. I did discover that if I changed the value in a saved config file then load the controller with that file it would accept the new value. It even took the 134,217,728 count for twice the Renishaw resolution.

As for the Renishaw being an absolute encoder, there is a checkbox in the SiTechExe Mount Parms window to select Using Absolute Encoders. It was my impression that if this is unchecked we could use the higher ratio. Am I misunderstanding what that check box is for?

I'm going back to the drawing board and do my best to keep the ratio to 1: 1. It would be a shame not take advantage of two absolute encoders. Retro fitting this split ring has been a pain from the beginning. It always seems that I'm always trying to fit 5 pounds of crap in a 3 pound can.

Thanks again all for your help and patients.



Re: Meridian Flip Settings Explained

Don W
 

Hi Martin,
Your problems are NOT going to be solved with Russell's suggestions. It has nothing to do with a PXP model.  Your biggest problem (I can't solve) is that you are doing your testing "Under the pole".  The operation of SiTech Under the pole is very different from Over the pole.  The limits are defined differently and the motions of tracking are reversed.  I do not ever use Uner the pole, so I really don't know how it works.  I am located at 32° latitude, so I don't see any useful sky below the pole.
You are at 60° latitude, so there is a lot of sky below the pole for you to use.

My recommendation is for you to learn and use the mount only Over the pole until you are comfortable that way.  Over the pole I can help you.

Years ago Chuck made a pdf that describes the meridian limits.  I attached it here.  To me, the examples he used for Under the pole are not easy to understand.

Don W


Re: Meridian Flip Settings Explained

MartinC
 

Hi Russell,

Many thanks for your constructive reply. It's much appreciated. I've not got as far as looking at pointing models yet. Nor have I tried plate solving from within Sitech. But I take your point & it would be a valid test I agree.

In nutshell all I'm trying to achieve is to always begin imaging weights down, then allow the mount to track without flipping (or stopping) at any point. But, flip for goto's only at the genuine Meridian. GEM is the only configuration that can guarantee this by ticking the 'flip on goto' option.

That's the only reason I'm trying various Meridian settings - to try and achieve that mode of operation. 

I'm definitely interested in looking at a pointing model anyway as if I understand what I've read it can help to improve auto guiding? How applicable that is to a Mesu I'm not sure yet.

But as soon as an opertunity presents itself I'll run through your suggestions and get back to you.

Many thanks and regards
Martin



Sent from my Galaxy


Re: Meridian Flip Settings Explained

Russell R
 

Hi again Martin,

Like Don, I just looked at your video.  First, I don't do flips.... I use EQ mode and SGP, however I will ask you some dumb questions which you probably already answered.

Have you used the SiTech mount model? 

Let's try this:
Do you have another app like Astro Art?  If not just use SGP without sequence or platesolves, just the camera.
Tick the boxes for Platesolve in SiTech.exe
Using Sitech.exe make a horizon file if you don't have one and/or set altitude limits so that it's well under pole and above trees, shutters ect. Tick those boxes in SiTech.exe and restart.
Set your mount to normal GEM flip settings
Make 16 to 20 cal points script, it should automatically place some cal points under pole, (but I'm not sure about GEMs), press play.  How did it work?
Now, set your mount to the flip settings you want and clear the previous model script and restart SiTech.
Make another cal point script, again cal points should be under pole.  How did that work out?  

I just want to see if SiTech will navigate and solve on it's own, under your conditions.

SiTech & PXP is a hardy program.  Using my Alt Alt mode, I skewed PXP by 10 degrees from 0 before it blew up.

Non GEM user, :-)
Russell R.


Re: A question for Don

Russell R
 

Hi Dan,

I always understood the absolute encoder was a 360 degree devise.  You would be the first one I know to increase the ratio of an absolute encoder.  I don't know how the software would understand the absolute position at that point.  Maybe someone has done this and can explain it to us.

Best,
Russell R.


Re: Meridian Flip Settings Explained

Don W
 

Hi Martin,
OK, I looked at your latest video.  I see that you are misusing the settings, and doing all your "testing" Under the Pole.  Also you are using the WRONG terminology - you are NOT platesolving at all.  You are simply "SLEWING".

First, you are changing the settings for Over the Pole, then expecting the operation Under the Pole to be affected.  It doesn't work that way!

There are so many problems with your procedure that I can't help you at all.

Don W


Re: A question for Don

Dan Hummel
 

Thanks Russell, one of the great thing about the Sidereal system is the vast knowledge of its users group and there willingness to share with those of us with issues.

I misspoke when I talked about using tick management to determine ticks per scope revolution. What I meant to say was using Ticks Determination in servo config. After doing some research into the BISS interface and finding that the data is sent in packets, I had no worries about transition rates. My concerns is if the registers in the controller are large enough to handle the 130 plus million tick value and will it confuse the software trying to handle such a large number. At the moment I'm having a cabling issue with the controller, but I'm going to try to enter the value into the controller and then read it back. That will answer the first question. That still leaves the software issue unsettled. It would be nice to be sure this will work before I invest the time and material to build this mount. Any help out there would be greatly appreciated.



Re: A question for Don

Russell R
 

Dan & Don,

The limit for a Servo II is 8M to 10M ticks per second.  With absolute encoders, it's impossible to "miss" encoder tick. You read the encoder and that's where it is.  If it's ttl, and the encoder cables are adjacent to the motor cables you could miss ticks, also if the encoder cables are too long, so keep them short as possible.  You can use cascade mode and set backlash to zero.

Cheers,
Russell R.


Quite a learning Curve - 2

Rusty Fletcher
 
Edited

Hello All,

I still haven't installed the motors on my telescope yet, but today, for the first time, I connected all the wires to the SiTech Servo 1 Controller and then connected a 12 Volt, 4 Amp, power supply just to test everything. Since my scope is ALT/AZ I will refer to everything accordingly. Facing the AZ motor shaft and using the handpad, it moves clockwise when I push the right key and counter-clockwise when I push the left key. Facing the ALT motor shaft, it moves clockwise when I push the up key and counter-clockwise when I push the down key. The hand pad and motors seem to work great! The problem is I don't think my COM Port connection is working correctly. SiTechExe is giving me 4 scrolling messages.(1) Not Initialized (2) Below Horizon limit (3) Reading Servo Parms and (4) Bad Scope Commun. I have configured the COM port to the correct port (COM 1) in the "Config" settings. I am getting two solid red LED lights on the controller. Can someone please help me. What am I missing? Feel free to call me if you want to help out. I can talk anytime today until midnight (Friday 4/22/2021) 512-393-4460. Thanks!

Problem solved... To my own surprise my USB to Serial COM Port adapter was also a Null Modem adapter all rolled up in one. I had forgotten that years ago when I purchased it... it was designed as a package deal. Using Mell Bartels software that was what I needed. All I did was use a second home-made null modem cable I had made several years ago in sequence with the first null modem cable and wow... it works! One null modem cable cancels out the other null modem cable. I had a good laugh when I got it working! It's quite a contraption... but it works!

Rusty Fletcher


Re: A question for Don

Don W
 

Hi Dan,
I don't know.  The Servo II can read absolute encoders at 65 million tics/rev.  I doubt it can read twice that.
Tic Management won't work on Dec - it only works on RA while tracking.  TM has nothing to do with adjusting tic count.
Don W


A question for Don

Dan H
 

I saw your reply to Czar explaining the difference between a servo I and a servo II. You stated that the servo II can read a 65 million tics/rev encoder. We are trying to add a Renishaw encoder to the DEC axis to a split ring drive. It obviously can't be a direct drive so I'm working on an offset drive using 3/64 inch cables and pulleys. Not ideal, but better then we have now. Do to space constants it's going to be difficult to drive the encoder at a 1:1 ratio. It looks like it will be closer to a 2:1. We know we will have to use tic management to get the correct tic count. My question is will this increase in ticks per axis revolution of the scope be a problem for the Servo II even though the encoder is only 67 million tics per rev.


Re: Meridian Flip Settings Explained

MartinC
 

Hi Paul,

I believe it explains how the unwanted slew during plate solving takes place because if you noticed, I showed that there is a very small region around the target, where, if you (or your plate solver) issues a GOTO command, the mount, instead of just nudging that small distance, will shoot off the opposite side of the meridian.

That's why I picked that open cluster because it has 2 stars close enough to demonstrate. But a platesolver would do the same thing. Your plate solver may only issue a nudge of a few arc seconds or so. If that nudge is within the zone that I showed in the video then my mount will take off.

Yes it is a 'flipless' configuration & the Sitech config options do allow you to effectively 'move' the meridian but that in itself is not the problem.

The problem is that to avoid a flip (or stop) at your chosen meridian you have to move the Track-past.

In moving the Track-past you expose this area of plate solving 'vulnerabilty' for want of a better expression.

The further you move the Over Pole\Under Pole & Track past limits the greater the potential for plate solving problems. That is my finding anyway.

For now I've reverted back to meridian flips. They do actually work very, very well with SiTech but it's not what I upgraded my kit for. I tend to take 30min subs for NB so its easy to waste an image worth or more of time waiting for the mount to flip because there's 25min to go & you can't squeeze that last image in, then you have to probably re-foucus incase anything has moved, re-plate solve etc & before you know it you've wasted 45min. Imaging time in the UK is pure gold dust.

So all-in-all I can't just let this go. It needs to be resolved one way or another. A 360 deg track-past limit may be the answer. I don't know because I've also experieinced some other odd things. If I try placing limits on top of each other for example I can get the RA drive to gently oscillate. Or when you unpark, the mount flips etc. So some caution needs to be applied.

For me personally I tend to think that an option to just select track-past or not might be the answer but only Dan can say really. There are safety implications if you have a conventional pier so I guess a disclaimer would need to be applied?

As such I've reached out to Dan & Don.

Best wishes & have a good weekend.
Martin


Re: Meridian Flip Settings Explained

Jonk
 

Hi Paul, the plate solving experience was as follows:

  • The mount slewed to the target.
  • A plate solve image was taken.
  • As mostly expected, the goto was not 100% accurate, or at least within thepixel limit set in the solver.
  • The mount is nudged to suit, probably a few pixels depending on the initial accuracy.
  • The mount then does the 'mirror flip' and proceeds to take the next plate solve of the inside of the dome.
I expect that if the initial goto was way out in terms of accuracy, then the small nudge would be a fairly large nudge and the mount wouldn't 'mirror flip'.

This appears to be related to the settings as Martins shows, so having the option to remove or ignore the trackpast setting seems to be the best option for a flipless / bent knee GEM.

I suspect it's easy to implement in software, with a caveat to warn to user with a pop up message for confirmation that this is what they want else damage 'could' occur. I've seen this with other mount software.

Another way to do it is add another mount type, 'flipless GEM' perhaps, with the setting baked into that option.

I also guess, looking in from the outside, that the coordinates are being rounded prior to a calculation, or perhaps going negative in a calculation when a very small nudge or same goto is asked for, causing the mount to go to a mirror of the RA position.

We could I suppose, try different sized nudges in the simulation, until we repeatedly found the margin of error, maybe that particular number (is is RA only, or DEC related?) could give the developer a clue as to what's going on.

Incidentally, I've moved all my limits to 180 to try and 'hide' them all along the N meridian, but have not tested in reality, as my kit is not currently installed.


Re: Meridian Flip Settings Explained

paul K
 

Hi Martin, How does it explain the plate solving experience?

If It's a flipless configuration, but you need it to flip, isn't that use case accommodated by the Sitech meridian config options?

So you need track past Meridian overlap value to allow a value of 360? Would that do it?

Best wishes
Paul


Re: Meridian Flip Settings Explained

MartinC
 

Hi Don,

Hopefully you managed to view my video in the previous post?

I have a friend & fellow astro-imager who also has a Mesu e200 & SiTech controller. I realsised that I had only tried this & experieinced problems using SGP. I knew he was looking at Voyager as an SGP alternative so I asked him to view my video & try the same procedure with Voyager. We had a screen sharing session using Voyager and the behaviour was identical.

He was going to post the video but then got back to me with a very interesting discovery.

So I have produced another video to show our latest findings which I believe helps explain my plate solving experience as well as being extremely interesting in it's own right.

I know you said you had trouble viewing the previous video on your PC so I have produced it in 3 different formats & here are the links to each where they can be viewed or downloaded.

.MP4 version
https://1drv.ms/v/s!AneSiXQRo7prjBZ9PA-GSn9eOElR?e=OlmrxS

.AVI version
https://1drv.ms/v/s!AneSiXQRo7prjBWHuciLoHrbhrbL?e=jqbELC

.MOV version
https://1drv.ms/v/s!AneSiXQRo7prjBf7x4wmJez8FUnx?e=vT9mOz

Without doubt this demonstrates the problem is not related to any connected equipment, client software, plate solvers, cameras or PC etc but seems specific to SiTech.exe.

I realise I keep posting about this, but for me, and anyone else wishing to use the Mesu e200 in it's 'flipless' configuration as a GEM, this problem will present itself sooner or later.

Just to summarise the requirements for this configuration & mode of operation:

  • The mount needs to operate in GEM mode.
  • I need to begin imaging counterweights down - be this in the east or west.
  • Therefore the mount needs to flip on GOTO's as a conventional GEM when acquiring a new target on the oposite side of both north & south meridians.
  • For this, it needs to flip at the genuine north & south meridians - not at a meridian that has been artificially moved by adusting limits.
  • The mount needs to track past both north & south meridians until the sky runs out without auto-flipping or stopping.
  • If the target is circumpolar the mount just needs to continue tracking until daylight.
If you can view the videos you'll see exactly what I'm talking about but the conclusion I've arrived at is that my problem could possibly be fixed by an option to remove or ignore the "Track Past Meridian Overlap" limit. At the moment this is a mandatory threshold but for my application I think it needs to be optional.

Please let me know your thoughts & I look forward to hearing from you.

Best wishes & have a good weekend
Martin


Re: Servo controller 1 vs 2 #question

Don W
 

Hi Czar,
The difference is the processor speed and the power output.  They use exactly the same SiTechexe, but have different internal software.  The processor speed limits the size of optical encoders that can be used on mount axis for the Servo I to about 1 mega tic or slightly less.   The Servo I can handle servo motors up to about 2.5 amps.

The Servo II  processor is much faster, letting it read much greater tics/rev for mount encoders - over 65 million tics/rev for each axis.  The Servo II can regulate up to around 4 amps for larger servos.

Cost is another factor, the Servo II costs a lot more.  The Servo II faster processor lets the use of greater tic/rev encoders on mount axis, so it can use what is called "Cascade" control of tracking rates, giving it much more accurate tracking than the Servo I.

Don W


Re: Quite A Learning Curve

paul K
 

just to add that you probably will need a usb hub (or two) I used unpowered ones and provided separate power supplies to my gear, but I believe that USB 2.0 can supply up to 500mA through the USB cable if you have devices which can be powered in that way.
Paul


Servo controller 1 vs 2 #question

Czar <czar551@...>
 

Hello everyone,
i was wondering if i could have benefits from the second version of servo controller against the first version. I’d really appreciate it if you help me decide it.
 Clear Skies 


Re: Superstitious

paul K
 

Thanks Martin and Yann-Eric, Yes something is 'loose' somewhere causing the 'bag of nails noise'. There's no clutches on this one and when I rotate the dec axis it feels and sounds different in different places. Lucas Mesu has aksed to look by webcam.

Being an I.T. type of person, you might imagine I have several dozen backups of the Sitech config and Servo Config. (well, I might have :) )

Fingers crossed, I'll post back

Paul

821 - 840 of 33791