Meridian Flip Settings Explained


Don W
 

Hi All,
The settings in SiTech /ChangeConfig/MountParms concerning GoTo's and Tracking vs the Meridian are very straightforward (they do exactly what they say), but are still confusing to some users.  In particular, the use of a "bent pier" allows a GEM to rotated mostly without "hitting the pier".  This means the telescope can be pointed at the sky while the counterweight shaft is pointed UP (above the horizon).  This just means that SiTech can track (and image) a target starting well east of the meridian and continue all the way to the West horizon without a meridian flip.

OK, how do you setup to do this???
First lets define the terms and what they do.
1. These are only for a GEM, so GEM must be selected.
2. There are two check boxes, one for Auto Flip and another for Auto Track.  These boxes control whether the mount will Flip or Stop when the mount gets to the limit.  That is IT!, there is no other option.
3.The key to tracking without a flip is the setting for Track Past Meridian in the lower left of the window.
4. The limits are set in the wide boxes for 'Over Pole and Under Pole.  These limits are in degrees-minutes-seconds of arc, FROM THE ZENITH!  The angles are measured positive in the direction of the limit.  So +10° for the west limit is toward the west, and +10° for the east limit is toward the east.  Both of these limits can not exceed 90° (the horizon).  Now with 095M and later versions, these limits CAN be set to a negative angle, which allows the limit to be set BEFORE the meridian.

The same methodology applies to UNDER POLE, so the settings are angle from the meridian - directly Under the pole is 180°.  so if you set for 2 degrees after the meridian, set 178° or -178°.

I have said you should not use Under the Pole unless you are very far north latitude (or south latitude), like Canada or northern Europe.  Any DSO will be above the pole for at least 6 months of the year.  OK, if you are doing science measurements of double stars orbits or variable stars then you want to make measurements all year long - That is what Under the Pole is for - targets of opportunity.

I live and observe in southern California at latitude 32° so I don't ever use "Under the Pole" so I don't have any experience using it.

Meridian Flips are not caused by Platesolves!  Platesolves simply initialize the mount to the local sky, either Looking East or Looking West.  when SiTech is not initialized, and you do a platesolve, now it is initialized, and if SiTech is connected to any other ASCOM program, once initialized SiTech will report via ASCOM where it is pointed.

If SiTech is NOT initialized, then any motion via the handpad WILL NOT BE REPORTED to any ASCOM program like SGP.  Once SiTech is initialized SGP will have all mount motion reported.  If you don't understand this, then you WILL have unexpected results.

Don W


Russell R
 

Don W &  "bent pier" GEM users,

My question to you is.....why can't "bent pier" GEM users just put SiTech.exe in equatorial mode and forget about all the flip setting hoopla, that is providing one does not have to deal with dome walls, elevated shutters or piers.  With this you can go over/under pole and horizon to horizon.  The only issue...if you are pointing at an object say at the 4 o'clock position near NCP and perform a goto for an object at the 9 o'clock position, then SiTech will take the shortcut clockwise, and possibly twist some wires if your not set up for it.  Platesolves are no problem anywhere in the sky.

Cheers,
Russell R.


MartinC
 

Hi Russell,

You are correct, EQ mode is an option. But due to the 'shortest route' scenario, for a new target in the east it usually results in a weights up situation; which is what I'm trying to avoid.

Cable management on the e200 is very nice. The RA cables can route straight up the inside of the pier and be fixed at the top. With such a long length several rotations could be executed without any issue. 

What's really nice and very clever about Sitech is that it 'remembers' the rotation count. So when you park, the cables unwind by the requisite number of turns. This illiminates the risk of cable wind-up over time.

On the e200 there are 2 cables for the DEC motor that cross the route of the RA cables at 90 deg. These can become wrapped round the bundle of RA cables. That's almost happened to me a couple of times.

Best wishes
Martin

Sent from my Galaxy


paul K
 

Thanks for the explanation Don. For ordinary GEMs that need to flip, is there any advice on optimum settings for the meridian limits?

Are there any useful criteria to apply? I guess the settings will depend on Lattitude too?

Paul


Don W
 

Hi Paul,
For "ordinary GEMs" the meridian limits should be small, including the Track Past setting.   There are so many mount designs and telescope designs that there is no ONE recommendation.  Generally you want to avoid any possibility of  hitting the pier.  So you should know what that limit is and avoid ever exceeding it.

The  meridian limit is easy to change, so I tailor it to the local conditions.  For instance if I am imaging a target in the east, and I want to avoid a delay in the last image (waiting for a meridian flip) I may change the west limit, especially on a low Dec target where my long refactor won't come close to the pier. That simply allows a short time imaging with counter weight UP.

Recently Dan added the capability in 095M and later to use negative limits.  This allows the user to set the limit BEFORE the meridian.  Josh asked if he could set the limit to 3 degrees before meridian to avoid a cable problem.  Now you can.

So there are many reasons to change the settings, but keeping them near or ON the meridian is the safest procedure.

Don W


MartinC
 

Hi Don,

Thanks for your explanation.

I've just noticed that the settings in your screen shot have both Over Pole limits = 0. In post #32847 it was suggested "3. Set the Meridian Limit West to 90:00:00."  So I shall try 0 for each.

Can I just ask about your comment in point 4 above " These limits are in degrees-minutes-seconds of arc, FROM THE ZENITH! " Do you mean the Pole rather than zenith, as the pole is where the meridiean & track past lines intersect or have I misundestood something?

May I aslo ask your opinion on something:
I did not experience any meridian flips during plate solving. What happened was a slew, in RA only, to a point on the oposite side of the meridian. Preumably this was because Sitech thought my mount was out in RA by that amount. It then re-plate solved and returned to the correct place & continued imaging. I can only assume that the 2nd plate solve re-initialised the mount which corrected whatever had caused the RA error detected by first plate solve????

Given the above, if you ever make changes to any of the meridian & track past settings, would you recommend re-initialising and maybe even re-setting your park position before doing anything else?

I'm wondering if this may be where I'm introducing problems because I've not considered it before. Now I'm wondering if I should?

Many thanks
Martin


Don W
 

Hi Martin,
The zenith is straight UP.  West is 90° west from that point - NOT the pole!  This is NOT DEC or RA.

The settings for over the pole are exactly what they say.  If you want the mount to flip at the limit you set, then check that box.  If you want it to flip every time you slew (so the counter weight will always be down), then set the limits to zero and the check box to slew.

Early on I recommended setting the slew limit for West to 90°, this was for the understanding that the user wants to NEVER flip.  Leaving the East limit to zero means it will always be counter weight down looking east.

Don W


MartinC
 

Hi Don & others who may be interested,

I have adopted the settings shown above & thought it may be more useful to show a display video capture of my experience. There is more background to this in a previous thread https://groups.io/g/Sitechservo/topic/offset_init_flip_during_sgp/81890636?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,81890636

My video is about 13 min long & too large to upload here so it can be downloaded from my OneDrive
https://1drv.ms/v/s!AneSiXQRo7prjBJjqfM5hHoh0I1S?e=3yoPlr

I run through my setup and configuration and demonstrate how my mount behaves for the same target but with the adopted settings compared to the default settings.

Hopefully someone with more experience than me will spot something.

Many thanks
Martin


Don W
 

Sorry Martin,
Your video doesn't play on my PC.  So what is your verdict?  Does it work or are you having problems still?  Videos don't help for me.
Don W


MartinC
 

Hi Don, 
That's a shame about the video. I'll see what I can do about that.

Basically I'm still having the same problem. It doesn't matter where I place the limits, it just moves the problem to a different place in the sky.

Best regards
Martin



Sent from my Galaxy


paul K
 

Hi Martin, When I click your link I am presented with a onedrive dialog which looks like it's asking to sign in or create an account, but on looking more closely there is a download button and the downloaded file works fine on my WIN 10 PC.

Regards the problem, I am no expert, but intuitively, if you have limits of some kind, there will be an operational limit/ problem. So I feel you may be back to asking Dan to program in a solution for flipless GEMs

Dan obviously knows the code and how difficult or easy it might be to do this.

best wishes
Paul


paul K
 
Edited

Hi Martin , at point 3.45 ish in the vid I noticed you have GEM autoflip goto checked. Would it be useful to uncheck this as essentially you don't want flips at all. Just a thought....

I think the ASCOM v2 camera simulator is brill, especially for indoor modelling of situations which were previously taking up precious night time. I have used it for modelling different cameras in SGP with the framing and mosaic wizard to check out FOVs, but what you've shown re loading an image means it's a true simulator, a very clever piece of software, thanks for sharing that.

best
Paul


MartinC
 

Hi Paul, 
Many thanks for your comments. I feel you are probably right and I have reached out to Dan.

Regarding the tick box it certainly isn't intentionally ticked, although I have tried both options just for kicks. I'll check the video again. It may be where my mouse was hovering? 

I'll see if can convert the video format so Don can hopefully view it.

Best regards
Martin



MartinC
 

Hi paul, yes it's very useful. I used it a lot when I was writing my dome driver as you can test during the day as if it were imaging for real.

By the way I've checked my video & that check box is meant to be selected as I need my mount to flip on Goto's.

Best regards
Martin


paul K
 

Hi Martin, just to show my lack of understanding of this subject, if it's a flipless mount, why do you need it to flip on Goto? What would be the criteria for that? I thought the idea of flipless was you could point at an object rising on the eastern horizon (scope would be pointing east) and you'd just track that right through to the west? I guess your observatory building might be a constraint for that as counterweights go up as you track. I've obviously missed something.

best,
Paul


MartinC
 

Hi Paul, 
Yes that's it exactly. My observatory is small compared the the scope size. The dew shield is always very close to the dome walls & the shutter threshold is quite high. The difference in dew shield height between starting imaging with weights up/down is approx 1.6m. So if I begin imaging weights up either in the east or the west my scope can't always 'see' over the shutter threshold. That's why I need it to flip on goto's so that I can begin imaging a new target weights down. I'm happy for it to track past the Meridian until I run out of useful sky.

So my criteria are:
I need it to flip on goto's 
I need it to track past both Meridian
I need it to operate with the Meridian in the correct place; not st a Meridian that's been artificially moved to a different place in the sky.

Best wishes 
Martin



Sent from my Galaxy


MartinC
 

Hi Don,

As promised I have converted the video to a different format. From the following link you should be able to play it using Windows media player or the Films & TV app in W10. VLC media player is a free app that will play just about any format & is available for MAC or PC.

https://1drv.ms/v/s!AneSiXQRo7prjBRzU_e0UVaJ8I3Z?e=ymEZsK

Alternatively if know which format you prefer I'll try my best to provide it for you.

Best regards
Martin


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


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


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.