Date   

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


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

 

Yes that’s exactly what I’m saying J

 

So just out of interest you always initiate in the West? And park in the West too?

If so then you are initiating, parking & plate solving all on the same side of the pier?

I’m just trying to get a handle on how others are working & if this could be relevant?

 

Many thanks for your support.

 

Best regards

Martin


Re: Offset Init & flip during SGP sequencing

paul K
 

I respect your position on this Don, but I can just hear folks saying - why am I getting involved with instructions for driving a car when I drive a motorbike.... :)
Perhaps a minor mod to help those folks who don't need to get involved with the not inconsiderable detail of meridain limits and flips, might be to provide a tick box in Sitech config which auto populates the boxes with the setttings needed for flipless working. Just trying to help....
best wishes
Paul


Re: Offset Init & flip during SGP sequencing

paul K
 

Hi Martin, so if I have it right, what you're saying is if you decide to image a target anywhere in the east and the mount platesolves in order to centre on the target, your mount will flip. Is that right?

I don't image in the east due to trees, so never tried a platesolve looking east.

Paul


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Don,

 

I’ve not had an opportunity to image yet but in preparation I have the settings configured as you suggested. I am initiated in the East and parked in East as I always do.

 

I can perform GOTO’s via Skyview, SGP, Cartes Du Ciel or Stellarium and the mount behaves as I would expect a GEM to behave. I.E. it flips if select a target on the opposite side of the meridian; either going from East to West or West to East. It goes through the pole if my target is in the opposite sky quadrant. And it re-parks correctly from anywhere in the sky.

 

It does not auto-flip or stop tracking when the scope tracks past the 90 deg track-past setting you suggested or if the scope tracks past either pole.

 

This is great but all of the above was also true of my previous settings.

 

The problem occurs during plate solving in the East, when the ‘InitPoint’ window appears during the adjustment (East radio button active). That’s when my mount would flip – but as I said to Paul – not a ‘genuine’ Meridian flip. It wouldn’t be pointing back at the target. It flips to the same declination but mirrors the RA position on the opposite side of the Meridian. I.E. If the target was 3hrs East of the Meridian, the mount would ‘flip’ to the same declination but 3hrs West of the Meridian.

 

If my scope was in the open air & not in a dome then it would actually work out because having performed this strange flip SGP re-plate solves, with the InitPoint window showing the West radio button active this time (I assume because the scope is now looking West). The plate solve error is obviously massive but the mount then returns to the correct position, plate solves again (East radio button active again when the InitPoint windows appears) and this time my imaging sequence continues as if nothing has happened.

 

If my target was in the West the plate solve takes place (West radio button active when the InitPoint windows appears), the mount remains where it should, it takes one or two small plate solve adjustments as you might expect and my imaging sequence continues as it should.

 

So Don, although I’m really hopeful that your suggested settings resolve this behaviour I’m struggling to understand how the Meridian & track-past limits can influence the plate solving\InitPoint routines in this way?

 

If you have any further thoughts please let me know. If not then I’ll get back to you once I’ve had a chance to actually image.

 

Many thanks & regards

Martin


Re: Mesu 200 Mk2 Tracking stops close to equator

Jose Ignacio Sanchez Rodriguez
 

Hello Paul,

Thanks for your post. The MKII has clutches. What I mean with not engaged is that, with the motors unclutched, I start tracking on SiTech.exe. In such a way I can perform a day test an establish a baseline for what I should expect during a night test or even during a day test under load. I just cannot setup indoors right now. Some building stuff going on at home.

If the current variation I observe in the above conditions is normal, then I can perform further tests with conditions closer to the ones last weekend. If it is not normal, then I have saved a lot of time.

As the DEC motor is idle during tracking I just checked what happens to its current when I slew the scope in DEC with the handpad. I see a similar variation in current as I observe on the RA motor while tracking in the above mentioned conditions. If I slew in RA while tracking the current does not go up much higher than while tracking. That sounds a little off, but I declare myself a total ignorant in this respect. That´s why I want to know if what I observe in this controlled conditions is normal or not.

I already sent the PHD2 and SiTech logs to Lucas. I´ll report back with his conclusions.

Best Regards,

Jose


Re: Mesu 200 Mk2 Tracking stops close to equator

paul K
 

Hi Jose, when you say tracking but not engaged, I'm not quite sure what you mean by that. It is useful to test the motors under no load (I guess that's what you mean by not engaged?), but what I'd say is the 'acid test' is to monitor the motor current under a normal load i.e. clutches engaged, mount position set to roughly where it failed and the system tracking. It will probably take a lot of time to check it, but if it's possible to log motor volts and amps you could just check the log. Don will know.

best wishes
Paul


On Thu, 8 Apr 2021 at 10:27, Jose Ignacio Sanchez Rodriguez <jsanchez.es@...> wrote:
Hello Don,

Today I checked the amperage and voltage of the motors on the SiTech Controller Stuff. This was with the motors tracking but not engaged, so as to be able to control for the balance variable. What I saw is that, on what I assume is the DEC motor (the one on the right) the amperage was pretty constant at 0.05. I think this is because, as I am not guiding, the DEC motor is idle. When I hover over the RA motor (the one on the left) the current moves from as los as 0.04 to as high as 0.1.  The voltage (I think there is a common indicator for the two motors) is steady at 13.5, which is my PSU voltage.

I am attaching a link to a short video of this test (the voltage does not show in the video, only the currents).

https://www.dropbox.com/s/764w5rhmvc934jo/Controller%20Stuff%20Motors%20Amperage.mov?dl=0

Is such variation of the RA current something normal? 

Best Regards,

Jose


Re: Mesu 200 Mk2 Tracking stops close to equator

Jose Ignacio Sanchez Rodriguez
 

Hello Don,

Today I checked the amperage and voltage of the motors on the SiTech Controller Stuff. This was with the motors tracking but not engaged, so as to be able to control for the balance variable. What I saw is that, on what I assume is the DEC motor (the one on the right) the amperage was pretty constant at 0.05. I think this is because, as I am not guiding, the DEC motor is idle. When I hover over the RA motor (the one on the left) the current moves from as los as 0.04 to as high as 0.1.  The voltage (I think there is a common indicator for the two motors) is steady at 13.5, which is my PSU voltage.

I am attaching a link to a short video of this test (the voltage does not show in the video, only the currents).

https://www.dropbox.com/s/764w5rhmvc934jo/Controller%20Stuff%20Motors%20Amperage.mov?dl=0

Is such variation of the RA current something normal? 

Best Regards,

Jose


Re: Offset Init & flip during SGP sequencing

Don W
 

Hi Russell,
The colors are the limits set  for the meridian limits, and they reflect the colors of the limit lines in SkyView.
Don W


Re: Offset Init & flip during SGP sequencing

Russell R
 

Don W.,

I don't ever deal with meridian flip limits, but curiosity got the best of me. What are the colors blue, green and yellow referring to in that diagram? 
Ol Chuck is quite the artistic engineer!

Russell R.


Re: Long term alignment (new user)

Mark Copper
 

Sorry for not being clear. The Nexus is connected to the SiTech Servo Controller serial port to serial port. (https://www.astrodevices.com/resources/NexusDSCdocuments/Using-Nexus-DSC-with-SiTech-Servo-controller.pdf)

No, I'm not just staring at hardware. Worse. The hardware is a thousand miles away this week and I'm just *thinking* (and reading) about it. And to make matters worse I'm not familiar with any planetarium software -- unless you count Kstars. While thinking (in the shower, of course) it dawned on me that having just built an observatory, maybe I shouldn't need to align the telescope after every power cycle.

However, I have learned a couple things over the last day. Serge at Astro Devices kindly called and both informed me that he is working on a parking routine for the Nexus and assured me that 6-8 Mpoint objects would suffice to build an alignment model that would serve my scope (a Spica Eyes) and current purposes. Don W kindly pointed out if I can get SiTechEXE going, then SiTech also provides a parking facility and Taj at Sidereal Technologies has told me that Dan G had developed a Linux wrapper for SiTechEXE as well so I may not need to resuscitate a Windows box. Finally, there is an interesting thread this week at Cloudy Nights that mentions maintaining alignment across multiple sessions with the Nexus as well.

So I am very appreciative of the information everyone has generously provided, and am looking forward to getting hands on next week.

Mark


Re: Offset Init & flip during SGP sequencing

Don W
 

Hi All,
Your comments wanting special settings for flipless GEMs are un-necessary.  The settings I suggested for Martin do exactly what you want.  Nothing more is needed regarding modifying SiTech.
Don W


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Don,

 

Once again much appreciated many thanks for the guide too. I’ve setup your suggested limits for over the pole & track past so just waiting for clear skies now J

 

Best regards

Martin

 

From: Sitechservo@groups.io [mailto:Sitechservo@groups.io] On Behalf Of Don W
Sent: 07 April 2021 18:58
To: Sitechservo@groups.io
Subject: Re: [Sitechservo] Offset Init & flip during SGP sequencing

 

Hi Martin,
On the subject of Under the Pole, I don't do it, so I have not studied it.  However Chuck Shaw created a guide to meridian limits some years ago.  I attached it here for you.Image removed by sender.


Re: Long term alignment (new user)

jmgoldba
 

On Wed, Apr 7, 2021 at 05:47 AM, Mark Copper wrote:
Since my scope came pre-configured... channeled through a Nexus DSC.
Not sure what "channeled" means in this context or what kind of pre-configuration was done. Are you just staring at hardware with no software or instructions on how to set it up or use it? Per Nexus:
You can use the Nexus DSC with planetarium software such as SkySafari Plus/Pro, Starry Night, Cartes du Ciel, TheSky just to name a few.
If you're using a program such as TheSkyX (which runs under Linux) then you'll have an option to Setup/Clear and (Un)Park the scope. -Jesse

Jesse


Re: Offset Init & flip during SGP sequencing

paul K
 

yes I think it would be a nice evolution for Sitech to accommodate the new flipless GEMS. Dan has written some brilliant stuff to get us where we are, so hopefully it's not too much work. Only Dan will know. I've recently purchased a 2.2m Pulsar and just setting it all up in a field with unobstructed sky views (!) but no electricity - so that's my latest challenge trying to keep power consumption down and solar energy available :) I might try to make a wind powered generator - we seem to get plenty of that !

Re dome driver, yes it's a steep learning curve. I used the ASCOM templates and was really fortunate to have some initial pointers from Tom How (ASCOM developer videos) and Rick and Tim at the ASCOM Developers forum. They're a great bunch.

I hope things work out for you and fingers crossed Dan might be able to provide that feature to opt out of flips. There are about 5 folks on the forum who use the eMESU and I think in years to come that will only grow.
best wishes
Paul


Re: Offset Init & flip during SGP sequencing

Don W
 

Hi Martin,
On the subject of Under the Pole, I don't do it, so I have not studied it.  However Chuck Shaw created a guide to meridian limits some years ago.  I attached it here for you.


Re: Offset Init & flip during SGP sequencing

MartinC
 

Hi Paul,

Many thanks for your reply & yes you get my point(s) exactly. I agree with your comments. I've checked through the SGP & ASCOM logs including the one for my dome. The only explanation for SGP capturing a plate solve image is because SGP did not initiated the scope slew\flip & therefore is 'unaware' of what's taking place at that moment in time.

After further study I'm pretty sure the settings for my Meridian limits are the cause of the unexpected mount behaviour and that's down to my failure to undestand them properly. I thought I had it nailed but I'll try Don's suggestion next time there's a clear night. Perhaps then it will make sense to me.

I agree MFlips are painful and a 'flipless' GEM is a fairly new innovation. It is a GEM by nature of it's construction but you want it to track past the Meridian(s) as if it were a fork mount. I have asked Dan previously about having the track-past & limits as an option so as you comment hopefully in a future release?

By the way congratulations on writing your dome driver. I hadn't written any ASCOM device specific code before either. A few ASCOM client apps but not a driver so hats off to you as there's a learning curve for sure.

Best regards
Martin

1101 - 1120 of 33967