Mesu Mount problems- jumping in RA

[RayD]

51 minutes ago, Zakalwe said:

The vast majority of users seem genuinely happy with their kit.

Finger crossed.

8 minutes ago, Mesu said:

Off course I'm interested.

 

I just checked my mail box.

 

They are all answered.

 

Most of them within a few hours.

 

Lucas Mesu

Thank you Lucas that's very comforting to know.  Hopefully there is a reasonably simple resolution as mine is on order so worrying to see issues which appear to hard to track.

[swag72]

1 hour ago, Mesu said:

Off course I'm interested.

 

I just checked my mail box.

 

They are all answered.

 

Most of them within a few hours.

 

Lucas Mesu

 

Hi Lucas - I sent you an email on the 25th December that I received no acknowledgement of at all. No matter about that one but if you can look at the latest I have sent you that would be great. It would appear that the software issue is fixed..... which is excellent news.  

[tomato]

I guess this is a question for Lucas:

is there any way the mechanical arrangement of the drive (roller/disk interaction) could result in the RA jumps that are being observed?

Just for background, I have owned a Mesu 200 for nearly 3 years which has seen inermittant use throughout that time  with lots of manual handling setting up and taking down, and it is yet to miss a beat so I am an extremely satisfied customer.

However, like  all existing and prospective new customers, I am very interested to understand the cause of this problem and how it can be resolved.

Steve

[Dan Gray]

2 hours ago, Mesu said:

Off course I'm interested.

 

I just checked my mail box.

 

They are all answered. Most of them within a few hours.

 

Hi All, This is Dan Gray from Sidereal Technology.

First and foremost, I've been working with Lucas Mesu now, for Several years.  A couple of years ago,  My wife (Samantha) and I even had the privilege of meeting him and his wonderful family.  I know for a fact that Lucas does respond to issues.  Here's a case I remember well.

The motor manufacturer that Lucas was using came out with the same motor, but a magnetic encoder instead of an optical encoder.  It cost less, but had the same specifications (as far as I know).  But what Mesu mount users found out very soon, these motors had periodic error in the magnetic motor encoder.  I remember Lucas telling me of driving long distances where he could, and providing other means to replace every single RA motor with these encoders.  In other words, he bent over backwards to fix all of the issues.  It turns out that even this problem wasn't the fault of Mesu mounts, but the motor manufacturer encoder issue! 

Now, about us at Sidereal Technology, we also work hard to fix any issues.  We did have some issues with the software and firmware while controlling Mesu mounts over the years, and you can ask Lucas, we always respond in kind.

This leaves me with NO doubt whatsoever, that when we get this problem nailed down, if it's mechanical, Lucas WILL fix it.  If it turns out to be software or firmware we'll fix it.

So, for Lucas not responding, my bet is a lost email or something, I'm not sure, my experience is he's better at communication than I am!

Over the last few weeks, I've been in contact with everyone that I know has had the RA jumps with a Mesu mount.  We weren't sure if it was software or hardware, and we had to analyze a lot of data to make a determination, which is just now coming out.

Here's what we've learned so far....

In version 0.91T (or any version of SiTechExe.exe before 0.91Z), there was an issue, that if the computer clock and the Servo clock didn't agree by 50 seconds, then SiTechExe WOULD create a jump in RA!

Once one of the users figured this out (I think it might have been Steve or Gordon), then I was able to go right to the issue, and come out with a version that fixed this.

So, SiTechExe version 0.91Zb clock control is now different.  There is an offset correction that happens.  If you change the computer clock, then this offset will keep the mount from jumping because of this reason.  It only changes the offset slowly (about 1 mSec per second of time) until the Servo Clock and the Windows clock agree again.  You can see the offset grow over time by clicking on SiTechExe/Features/Offset Rates.

The other addition I made to SiTechExe is an option to create a log file that can help me figure out why there are jumps.

I've only been getting data from Sara, and she's been extremely helpful in providing me with the log files, both PHDGuiding logs, and SiTechExe logs, every single night that she's able to image.

Here's what we've found  so far, all from Sara's data (thanks Sara for diligently sending me the log files).

Jumps in late 2016 (using versions before 0.91Z) could definitely have been because of the SiTechExe software, and the Servo clock and the PC clock having a large difference.

Once I've fixed this in 0.91Z  I've only received logs from Sara, no other folks have had permissable weather :-(

After looking very hard at the log files, it seems to me that SiTechExe, along with our ServoII controller is doing exactly what it's told.  In looking at the logs around the jumps, I can see that before the jumps, the motor is running smoothly, and the only reason that the system finds a jump, is because PHDGuider see's that the star has moved.  But the data shows that the motors have been steady until they're asked to make the correction (which they do).  I see this in each instance of a jump.  So, it appears that the sky has moved for no reason :-) .  But, since that's unlikely, and since all of the jumps are to the East, (there are large guide West commands) Lucas and I are thinking that it may be roller slippage on Sara's mount.

But, we really need more data from other folks.  

If you're a Mesu mount user, and you're having jumps in RA, then WE NEED YOUR DATA....

Here's instructions:

1. Download and install the 0.91Zb software:

http://siderealtechnology.com/SiTechSetup091Zb.exe

2. Go to the Config tab, Change Config, Ascom and Logging, and turn on "Log Debug Stuff", and "Log Tracking Info"

3. Image for the night, and in the morning, find your SiTech Data folder, zip up and email me the following files:

a. SiTechDebug.txt

b. SerialIOTrap.txt

c. \LogActionFiles\LogTrackingInfo__2017_01_08.csv (your date will vary)

d. SiTech.cfg

My email is grayarea    ....  the.AT.symbol  .....  siderealtechnology.com

Your data folder is located here (your's may vary according to your windows country settings)

C:\ProgramData\SiTech\SiTechExe\

If you can't find your data folder, you can click on SiTechExe/Config/ChangeConfig/ and you'll see a button labeled "Open Data Folder"

Once we have this *&&*^%% issue fixed, don't forget to turn all of the logging  off.

Sara, special thanks to you for all of the log files, and thanks everyone else that has been helpful in making progress to figure this out.

Cheers, Dan Gray

http://siderealtechnology.com

P.S.  Unrelated topic: my best image with our 12.5 inch F/8  Planewave CDK, ST11000 camera, and our Alt/Alt mount at Shepherds Lair Observatory

http://www.siderealtechnology.com/M33-2.jpg

I took all images 5 minutes with no guider (open loop).  There's about 12 hours of LRGB data.  The Alt/Alt mount has a field De-Rotator.  This is needed for Alt/Alt mounts, just like Alt/Az mounts.

Here's a link to our observatory in the Portland Oregon suburbs:

http://siderealtechnology.com/SLO/index.html

 

 

 

 

 

 

 

 

[ollypenrice]

^^ Posts do not get any better than that. Hats off to Dan Gray for a comprehensive and honest reply. I have (and love) the earlier and more primitive ArgoNavis on my Mesu but Dan's post is a masterpiece of communication and customer care. I'm very impressed.

Olly

[gnomus]

I have been following this thread for a bit and thought I should chip in to reassure anyone who has ordered or may be about to order this piece of kit.  

I have also had great service from Dan and Lucas.  Dan supplied us with different '.exe' files when I was trying to track down a meridian flip issue.  Sometimes we'd get a couple of new files a night to test.  It was fixed quickly and has been fine ever since.  

And Lucas was superb when I broke our Mesu (entirely down to my own stupidity).  He even supplied us with cake and coffee when we picked it up!  (And no charge for his time.)

I would have no hesitation recommending the Mesu and the chaps who support it.  

[swag72]

A very informative post Dan and I hope that soon you can gather some data from other users that experienced the RA jump problem so that you can be sure that it's fixed. From your analysis of my data it would appear that the software side is no longer an issue.... which will be great news for others out there with the Mesu and those who are considering it.

Meanwhile I am liaising with Lucas regarding the issues that I may have with my mount. I'm currently on a run (exactly the same targets as last night) and so far all is well.... so it looks potentially like some sort of intermittent 'thing'.

[RayD]

Thank you Dan for an excellent explanation of your efforts thus far to resolve this issue, which certainly for me, who has just ordered the Mesu200 is extremely welcomed and encouraging.

I know as an engineer myself how hard intermittent issues can be to resolve, and knowing that both you and Lucas are dealing directly with this certainly helps to allay and fears I had.

I'm sure everyone appreciates yours and Lucas' input and are confident this will be resolved.

[Zakalwe]

1 hour ago, Dan Gray said:

Here's what we've found  so far, all from Sara's data (thanks Sara for diligently sending me the log files).

Hi Dan

You should also have received a log file from me (Stephen Jennette). I sent it to you on 01/01/17 at 10:14PM (UK time). Let me know if you haven't received it and I'll send it again.

 

For the record, Sidereal have been exceptional in diagnosing and trying to fix this issue. I think that the mount is mechanically fine (if it was a problem with the roller/drive train then I'd expect the anomaly to be periodic). 

I recently contacted Sideral about a handset failure on my mount.  The handset had been a bit dodgy from when I bought it in September 2015. I don't use it that much, so it wasn't a big inconvenience. I was speaking to Bernard at Modern Astronomy and he mentioned that there had been a bad batch of these and to contact Sidereal Technology in the US.
So I dropped them an email on 30th November. Within 5 hours (bear in mind the time difference) I get a response which was "No problem, send me your address and we'll ship one to you". I asked about cost (these are $100 new) and the answer was "No cost- we had a bad batch. It's our responsibility to fix this". I enquire if they want the old one returned or how they want payment for postage and get the same response- no cost to me, they will bear the cost of replacement and postage.
The same afternoon I get an email from Taj Wurl-Koth giving me the USPS tracking number. I was not asked to prove that I had bought the mount. I wasn't told to contact my dealer. It wasn't mentioned about the age of the unit even though it was outside the 12 month warranty. Just a very straightforward "its our mistake, we're taking responsibility for fixing it". I received the new handset 6 working days later.

I cannot praise Dan, Taj and the team at Sidereal enough. These guys know how to do customer care.

 

Again, the vast majority of peeps are getting sterling service from their Mesu mounts. I and a very, very small group of people are the only ones to get this problem. I'm confident that it will get fixed. I've been offered the option of returning my mount for a full refund, both from Lucas Mesu and from Bernard at Modern Astronomy. At this stage I have decided not to take that option as I want this fixing and I hate giving up on a problem. I'd also lose out on quite a bit of money due to the Sterling devaluation, but in reality, that's secondary to getting a solution.

 

[tomato]

I too recall the extraordinary lengths Lucas went to in order to replace the encoders where he personally visited owners affected by this in the UK. It was one of the many reasons along with Olly's ringing endorsement that persuaded me to invest in this mount.

Also I must agree 100% with the comments made about Dan's latest post, such a precise, factual summary of the findings to date, and clear instructions on how we can all assist in sorting this.

Awesome

[pietervdv]

Hi,

I have been happily using the Mesu200 mount for 3.5 years now. When I just received the mount I had the issue Dan described earlier with the bad magnetic encoders on the RA axis motor. Lucas was great about this and replaced the faulty RA motor with a version with an optical encoder. I even got treated to a tasty cake and coffee when I stopped by, and got charged nothing for the fix. After this, the mount ran like a gem for 3.5 years without any glitches whatsover.

But (yes afraid so...):

When reviewing the sub exposures from my last imaging session I found a frame with a very large error in RA. I found this striking as the mount NEVER, EVER loses sub frames. I have not updated my pc for the last 3 years and changed nothing in my imaging setup. I am fairly certain there is no roller slippage causing this as evertyhing is balanced out perfectly. I am sure nothing bumped into the mount also, otherwise I would have seen an error in DEC for sure. After reading this thread I had a look at the PHD guide logs, and there it is, a huge spike in RA.

Attached is the guide log screen.

The bizarre thing is the same night my hand controller also broke down completly. I got poor reactions from pushing the direction buttons the last couple of weeks. This is not such a big deal as I use platesolving and GoTo's to move across the sky, but I find it striking that both issues (tracking error and handpad controller failure) occured at exacly the same time. I read above there was an issue with poor hand controllers (bad batch)? This is probably a long shot, but perhaps there is a short circuit inside the handcontroller to blame (causing a slew operation for a fraction of a second?). Perhaps an issue to check with all the users experiencing the issues, if the handpad is plugged into the controller.

 

Regards,

Pieter

[tomato]

Hello Pieter,

Sorry to see you have experienced an RA jump.

Just a thought, do all users who have had RA jumps, have you had your hand controllers plugged in at the same time?

[Zakalwe]

45 minutes ago, tomato said:

Hello Pieter,

Sorry to see you have experienced an RA jump.

Just a thought, do all users who have had RA jumps, have you had your hand controllers plugged in at the same time?

I wish it was that simple.

• I have had jumps with the bad handset connected.
• I have had jumps with no handset connected.
• I have had jumps with a new functioning handset connected.

Ergo, it's not the handset.

[ollypenrice]

Pieter isn't the kind of guy to say this but, at the risk of embarrassing him, I know him personally and he is a very, very good engineer. 

Olly

[tomato]

Fair enough.

Of course there could be multiple causes but we can't be that unlucky surely?

[andrew s]

I have not used PHD so I can't tell but are the jumps always in the same direction? If so does the mount speed up or slow down? I have not seen this discussed but it may have some diagnostic value?

Also does it jump if you are not guiding and can PHD just monitor this?

I hope it is solved soon for you all.

Regards Andrew

[Dan Gray]

Hi  Pieter ,

I was wondering what version of SiTechExe you're using?  Have you upgraded the flash rom of the ServoII to 9.5?

If this continues, then I'll really want to see your tracking logs from SiTech, but you'd have to upgrade to the latest to have the tracking logs available.

Here's the latest version:

http://siderealtechnology.com/SiTechSetup091Zb.exe

 

[ollypenrice]

19 hours ago, tomato said:

Fair enough.

Of course there could be multiple causes but we can't be that unlucky surely?

Hmmm... In other lives, troubleshooting engines, for instance, I have fallen foul of the multple cause problem before now and it is the ultimate nightmare. I've also had problems that defied logical analysis. (You have identical parallel components B and C which are downstream in the system from component A. Component B does not work, component A does work, so the cause could not be component A. But it was...) However, this is something that will surely only ever apply to one unit, not to more than one.

I've no doubt whatever that you'll sort this out. The product is excellent.

Olly

[Zakalwe]

21 hours ago, tomato said:

Of course there could be multiple causes but we can't be that unlucky surely?

Possibly, but at this stage let's stick to eliminating one thing at a time. The current thinking is that the Sitech internal clock and the PC clock accrue a difference and when this difference hits a certain value the mount "jumps". Dan's new firmware looks to have addressed the handling of this difference. Certainly on mine, the time difference ran out of control whereas now it's hovering at a couple of milliseconds.

The weather is driving me nuts. it's blowing a hooley here (again) and there's flurries of snow.  Non-stop crummy weather all December and Jaunary so far. Someone please remind me again why I took this hobby up in Lancashire!

 

2 hours ago, andrew s said:

Also does it jump if you are not guiding and can PHD just monitor this?

I hope it is solved soon for you all.

Regards Andrew

Thanks Andrew,

Yes to both questions.  I have seen the mount jumping when the only software running is the SiTech control software.
PHD can run a Guiding Assistant which monitors the apparent movement of a guidestar without sending any guide commands to the mount. This will display a number of things: Polar alignment error, tracking rate errors and backlash errors. I used the PHD Guiding Assistant to correct my Mesu's poor RA tracking. Here's one of the reports that shows the information that it reports on- you can see the RA drift rate of 3.09 arc-seconds per minute, virtually no DEC drift (indicates good polar alignment), how long the Guiding Assistant has monitored the mount for (430 seconds).

All-in-all, its a very useful tool

[Singlin]

Other mounts similar to ours such as the Gemini state that for every change in temperature of 15 degrees Celcius the roller bearing metal will either contract or dilate causing a change of guide speed and a calibration has to be done. Andreas of Gemini has an automatic option to do this in his softwre that can be done during the day to.

I use the below method to do mine.

 

I previously had problems with my RA guide speed being too slow and as a result PHD was correcting RA always in the same direction and could not guide efficiently.

I decided to use Artemis (my ccd capture software) to track a star for 10 minutes and determine how many pixels it moved .

I made sure that my RA axis corresponded with the up and down lines of my cross-hair in Artemis and then slewed a star to the middle of the cross-hair.

I then placed my mouse pointer on the middle of the star and read the pixel number shown at the bottom right of the Artemis software window (for RA the pixel number is the second one)

After 10 minutes I placed the mouse pointer on the middle of the star again and jotted down the new pixel number.

I subtracted the first number from the second.

In my case the star moved up and moved 91 pixels.

I then multiplied 91 x 1.11 (the pixel scale of Atik 383 and Quattro 10")

This gave me 102 Arc-seconds of movement in 10 minutes.

Lucas Mesu Kindly helped me out with the next bit and I eventually managed to understand the Maths.

I launched Servo Config and  clicked " Edit Parameters" to get the data from my controller.

My number of ticks per scope revolution in the Ra Motor was 7949474.

In 10 minutes the Ra makes 9000 Arc seconds.

This is the Maths as explained by Lucas:

In 10 minutes the Ra makes 9000 Arc seconds.

Divide the error (102) by 9000=0.0113333333333333

0.0113333333333333 x 7949474=90094

7949474 - 90094 = 7859380

7859380 is the new number to put in the Ra Ticks per scope Rev window in servo config.

In my case this made it worse so instead of subtracting 90094 from my original ticks per revolution of 7949474, I added it to obtain my corrected number of 8039568.

Now my mount is tracking efficiently in Ra too and my guiding problems have been sorted too.

[Zakalwe]

Or use Guiding Assistant to do the calculation.

[Singlin]

Good tip Stephen.

[tomato]

Has anybody heard if other Sitech users (but not connected to a Mesu 200) have experienced jumps in RA? 

I think the PlaneWave EQ mount uses the Sitech but I suppose there might be fewer of these in circulation?

[pietervdv]

On 11-1-2017 at 19:48, Dan Gray said:

Hi  Pieter ,

I was wondering what version of SiTechExe you're using?  Have you upgraded the flash rom of the ServoII to 9.5?

If this continues, then I'll really want to see your tracking logs from SiTech, but you'd have to upgrade to the latest to have the tracking logs available.

Here's the latest version:

http://siderealtechnology.com/SiTechSetup091Zb.exe

 

Hi Dan,

 

I have been using SiTech V0.90P. I'll upgrade to the latest version and start logging. Not sure how to update the flash rom, do I need the handcontroller for that?

Cause its broken... Lucas was going to order a new one from you to ship with a next batch of controllers.

I'll report back if the skies ever clear around here.

 

Thanks,

Pieter

[Dan Gray]

No, you shouldn't need the handpad to upgrade the firmware, just the controller.

Use ServoConfig.

Here's the 9.5 firmware:

http://siderealtechnology.com/V95.BIN

Dan

Hi  Pieter ,

I was wondering what version of SiTechExe you're using?  Have you upgraded the flash rom of the ServoII to 9.5?

If this continues, then I'll really want to see your tracking logs from SiTech, but you'd have to upgrade to the latest to have the tracking logs available.

Here's the latest version:

http://siderealtechnology.com/SiTechSetup091Zb.exe