Mesu Mount problems- jumping in RA

[swag72]

Do you know what Olly - I can actually pinpoint the start of this issue to a Windows update I did on the 10th December ...... I hadn't updated for about 18 months and so thought it was about time........ So it could have been any old 18 month update that caused the issue..... but I don't understand why it's only affecting a small handful of us. Presumably if it was a Microsoft update then as long as everyone had their system up to date they would have the same issue.

[tomato]

Ok thanks Sara.

lt is strange how some units have been affected from new and others are only now exhibiting the problem after a years of trouble free operation.

My rig is coming up to 3 years old and is set up and taken down after each session but I cannot see how this would make it immune.

[Davey-T]

Just reading about the plan to add another second to this year and that this appears to happen quite frequently, maybe twice a year, no idea if / how this would affect the mount clock.

Dave

[steppenwolf]

Quote

but I don't understand why it's only affecting a small handful of us.

Hmmm, this issue could be dependent on the operating system - I am still running Windows XP which doesn't update any more (YIPPEE!). Could this be significant?

[swag72]

I've set the mount running now so that it has maximum time to develop it's ' nightly fault' and hopefully Dan will be able to get to the bottom of it  

[steppenwolf]

I have just started a POLL, if you are a Mesu owner, please take part as it may help to resolve the cause of this particular problem.

[steppenwolf]

In addition to the poll, please also post your Operating System in the thread ONLY IF YOU HAVE THE RA JUMP FAULT.

[msh1]

1 hour ago, ollypenrice said:

I wonder if some specific update from Windows or other may lie behind this. There are so many knock-on consequences from changes in IT. I remember having a 'sudden onset' problem with both my cameras. Finally some inspired soul at Atik said, 'You haven't recently changed the PC to run two screens have you?' Yes I had, and that was it. Why the 'two screens' would affect the camera control I have no idea.

Olly

olly what were the problems you had with running two screens because im having a problem with my atiks i wonder if its the same problem ?? as i have just started to use two screens 

 

[andrew s]

On 12/27/2016 at 17:57, Dr_Ju_ju said:

 

If the absolute time is that important, I'd use a time server that syncs with the MSF Rugby (Radio) time source (this is slaved to the UK Labs master).

 

I use a MSF clock as a NTP stratum 0 reference to discipline the time on the main observatory computer and NTP to serve it over my network. However, all Windows versions are not real time operating systems and the timing of events and processes can't be relied on. I am not sure if this is relevant to the issues here but almost any Windows update could change its timing behavior.

Regards Andrew

[Xplode]

Kinda off topic, but might be a help for people wanting to sync their clocks easily and reliably.

I use a Globalsat BU353-S4 GPS unit together with NMEATime2 to keep my clock synced.

It's pretty cheap and a solution that everyone can easily setup 

I've used it on 2 computers for 1+ years and it just works.

[Zakalwe]

I sincerely doubt that this is a Windows issue. It's been happening to me since I got the mount in August 2015, over two different PCs and a million different Windows updates.

If it does prove to be a Wndows issue then surely it's not too much to expect the equipment to work with the most popular desktop OS in the blooming world??? I have no intention of using a 15 year old OS such as XP- apart from the hideos security issues it wouldn't work with modern USB3 devices.

[tomato]

Again, please excuse my ignorance, but is the Sitech controller unique in requiring this clock function to operate?

Does EQ MOD do something similar? I've never run it so have no idea. I guess sidereal rate tracking under software control can be achieved without requiring a real time clock function?

[derrickf]

On 30/12/2016 at 20:34, Zakalwe said:

I sincerely doubt that this is a Windows issue. It's been happening to me since I got the mount in August 2015, over two different PCs and a million different Windows updates.

If it does prove to be a Wndows issue then surely it's not too much to expect the equipment to work with the most popular desktop OS in the blooming world??? I have no intention of using a 15 year old OS such as XP- apart from the hideos security issues it wouldn't work with modern USB3 devices.

I agree, it is unlikely to be an OS related issue per se (it could though conceivably be related to some combination of OS settings).

ISTR from another thread that you are using win 10 pro as am I. I have not had any issues with jumps in RA, indeed imaging at around 0.5 arcseconds / pixel RA jumps of the magnitude others have observed would be a huge issue for me.

 

[ollypenrice]

On 30/12/2016 at 18:23, msh1 said:

olly what were the problems you had with running two screens because im having a problem with my atiks i wonder if its the same problem ?? as i have just started to use two screens 

 

Oh blimey, it was years ago. I had one issue in Vista to do with having to delete an initialization file but I can't remember the ins and outs of the two screens business. Atik might be able to help. I'm sorry, it was just too long ago for me to remember the details, I just remember it happening.

Olly

[swag72]

8 hours ago, derrickf said:

........ I have not had any issues with jumps in RA, indeed imaging at around 0.5 arcseconds / pixel RA jumps of the magnitude others have observed would be a huge issue for me.

 

Trust me, it's a huge issue for me as well  

[derrickf]

Has anybody considered whether the guiding software used has any bearing on this - I use MaximDL and I recall Steve indicating that he also does - neither of us has (yet) been afflicted by jumps in RA. It seems that some others who use PHD do experience the RA jumps.

[swag72]

As far as I am aware, Dan from SiTech believes that it is a clock differential thing..... The clock from the PC and the SiTech software eventually get out of sync and when the difference hits 50,000ms the RA jumps and then this difference goes back to zero........ So the guiding software is irrelevant as I understand it as the PC clock and the SiTech will run in the background doing the same thing regardless of whether PHD or Maxim is used.......

That's my very untechie understanding anyway!!!

[derrickf]

I have great respect for Dan and he may well be right - however he appears in this case to have based his solution on reviewing logs from only 1 or possibly 2 systems that exhibit this issue.

Anyhow it looks like those users who are suffering with this are content that a fix is on the way so there's little point in further conjecture; I'll keep quiet

[swag72]

I'm not trying to stifle your voice Derrick - I am only passing on the information that I have from Dan  His software update also includes massive amounts of logging so that if the problem either reoccurs or is something different then he should have a starting point to sort it at least.

 

[Zakalwe]

5 hours ago, derrickf said:

Has anybody considered whether the guiding software used has any bearing on this - I use MaximDL and I recall Steve indicating that he also does - neither of us has (yet) been afflicted by jumps in RA. It seems that some others who use PHD do experience the RA jumps.

My Mesu jumps whether the guiding software is running or not. .For example, leave the damn thing unattended when doing solar animations as the mount jumps and I lose the sun.

Ditto when doing Lunar or planetary. This is obviously with no guiding running, just the mount just the mount tracking.  Theres virtually no other software running other than Sitech and Firecapture. This confirms, to me at least, that the behaviour is in the mount.

[derrickf]

7 minutes ago, Zakalwe said:

My Mesu jumps whether the guiding software is running or not. .For example, leave the damn thing unattended when doing solar animations as the mount jumps and I lose the sun.

Ditto when doing Lunar or planetary. This is obviously with no guiding running, just the mount just the mount tracking.  Theres virtually no other software running other than Sitech and Firecapture. This confirms, to me at least, that the behaviour is in the mount.

I almost agree with your conclusion: if I understand your setup correctly, the problem, based on your observation,  would seem to be in either the mount (including the Sitech controller) or in Sitech.exe.

Have you tried doing an animation run using just the handset (a PITA I know - the handset is the weakest part of the whole mount hardware IMHO and I dislike it intensely). Clearly if the behaviour persists then it is the mount at fault; if it doesn't then that would be pretty incontrovertible proof that the issue lies with Sitech.exe.

FWIW when I first got my mount, I had some seemingly random RA jumps but I chased that down to a PXP model gone bad after making some (what I thought were) minor changes to the mechanical configuration. I built a new PXP model and the jumps went away - probably un-related to the current problems people are seeing but I thought I would mention it.

 

[RayD]

I'm glad it is a 2 month wait for mine as I'm watching this thread intently hoping for the fix.

There is a video on YouTube of this mount randomly jumping when manually slewing with the handset.  I suspect that's totally unrelated, but I guess shows they aren't without their faults.

[Zakalwe]

Just now, derrickf said:

I almost agree with your conclusion: if I understand your setup correctly, the problem, based on your observation,  would seem to be in either the mount (including the Sitech controller) or in Sitech.exe.

Have you tried doing an animation run using just the handset (a PITA I know - the handset is the weakest part of the whole mount hardware IMHO and I dislike it intensely). Clearly if the behaviour persists then it is the mount at fault; if it doesn't then that would be pretty incontrovertible proof that the issue lies with Sitech.exe.

FWIW when I first got my mount, I had some seemingly random RA jumps but I chased that down to a PXP model gone bad after making some (what I thought were) minor changes to the mechanical configuration. I built a new PXP model and the jumps went away - probably un-related to the current problems people are seeing but I thought I would mention it.

 

Running the mount without any PC connected is just about the only thing that I haven't tried, to be honest. Having said that, I didn't buy the mount to run in this mode. I bought it with the express point of running it as an integrated AP setup.

 

These are the tests and actions that I have taken so far:
Hardware:

•     Replaced the obsy PC (new power supply, motherboard, CPU-the lot)
•     Replaced all cables connecting the mount (USB and Power)
•     Removed the USB hub connecting the mount to the PC. The mount is now directly connected to a USB port on the PC.
•     Changed the mount power supply unit.
•     Ran the mount from a 12v battery.
•     Replaced the imaging scope focuser.
•     Changed the USB cables going to the guidecamera amd imaging camera.
•     Removed the side-by-side bar and mounted the OTA with piggy-backed guidescope directly in the Mesu saddle.
•     Checked the tightness of all bolts (saddle, alt/z adjusters, main mounting bolt. All tube rings and guidescope mountings are tight.)
•     Disconnected the faulty hand controller.
•     Connected a new hand controller.

 

Firmware and Software:

•     Upgraded to 0.91T
•     Upgraded to 0.91Xd
•     Reinstalled SiTech.
•     Reinstalled Sequence Generator Pro
•     Reinstalled ASCOM

 

RA Tracking Issue:

•     Corrected the poor RA tracking. The fact that this has drifted over time might be related? Dodgy encoder? When I first got the mount the tracking was correct (apart from the jumps that I first observed in September 2015 see the screenshot below.) The tracking drifted quite badly in the following 8 months. The RA encoders ticks have had to be changed from the factory setting of 7979352 to 8131810

    Tests:

•     Multiple runs of PHD2 Guiding Assistant. The mount has been observed to jump in RA when no guiding commands are being sent.
•     Ran the mount from Sequence Generator Pro. The mount continually causes SGP to fail a sequence as the guidestar is lost.
•     Disconnected SGP from PHD2. Ran PHD2 as a standalone guider. The mount still jumps.
•     Changed the PHD2 parameters as per the results of Guiding Assistant.
•     Changed the RA Encoder setting to Ignore to take the shaft encoder out of the loop. The mount was observed to jump in RA when this was done.
•     Checked all the lat/long settings in SGP, Cartes du Ciel, SiTech. All are the same.
•     Disabled the Horizon file.
•     Rebuilt the sky model (PointXP)
•     Ran the mount without any sky model.
•     I've re-ran all the cables and used a nylon sleeving to bundle them. The cables are fastened to the rear and front of the saddle. They then loop to the north of the mount and are tied off to the counterweight bar clamping bolt. I am confident that there are no cables snagging.
•     Polar alignment has been verified using a QHY Polemaster.

 

 

[Zakalwe]

1 minute ago, RayD said:

I'm glad it is a 2 month wait for mine as I'm watching this thread intently hoping for the fix.

There is a video on YouTube of this mount randomly jumping when manually slewing with the handset.  I suspect that's totally unrelated, but I guess shows they aren't without their faults.

If it's the one that I'm thinking off then that was one of the guys on here. The problem was traced to a loose connection on the Sitech controller.

[RayD]

1 minute ago, Zakalwe said:

If it's the one that I'm thinking off then that was one of the guys on here. The problem was traced to a loose connection on the Sitech controller.

Ah ok.  Yes it did seem a bit extreme to be software issues.

I'm still happy with the decision to order it as I'm sure this will get resolved, but of course intermittent problems can sometimes be so hard to track down, even though the actual fix is often pretty simple.