Date   

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


Re: Quite A Learning Curve

paul K
 

I would concur with others on this, one dual core 2GHz laptop with 4G RAM and WIn 7 will be absolutely fine. I ran all my systems from a Toshiba laptop with that spec up until three years ago. The only reason I changed was because the laptop was returned to its owner! I ran Sitech, Sequence Genarator Pro, PHD2, my SBIG Camera and guider, Pyxis rotator and Cartes Du Ciel simultaneously. Worked a treat.

best wishes
Paul


Re: Quite A Learning Curve

Don W
 

Hi Rusty,
That thinking doesn't apply now to ASCOM  guiding using PulseGuide, which SiTech uses.  Pulseguide measures the error and sends a required correction in terms of arc-sec to the controller (inside the PC), then SiTech controller moves the mount (quickly) to correct the error.  Guiding responses are now quicker than ever before.

Your old way required a timing correction pulse via the comm port to make the correction, and that was easily interfered with by other comm activity.  All that is ten year old technology that isn't a problem anymore.
Don W


Re: Quite A Learning Curve

Rusty Fletcher
 

Thank you for your help Don! The only reason for using two laptops is that when I used Mel Bartels software the tracking was always better (resulting in better images) when I used two laptops. The guide scope software was able to update the guiding corrections faster (because it was running on a dedicated laptop) and nothing interrupted the download of my primary imaging camera because that was also happening on a dedicated laptop. In practice everything seemed to just work better and faster when I set up two laptops. Also I am using two older laptops, both of them are: Core 2 Duo Processors @ 2.2 GHz and 4GB RAM running Windows 7.


Re: Quite A Learning Curve

Joshua Hufford
 

Hi Rusty, I'm thinking the same thing as Don. Why would you want to use two PCs for this? No reason you can't do it from one and make things much simpler. 

Josh

On Thu, Apr 22, 2021 at 9:21 PM Don W <westergren@...> wrote:
Hi Rusty,
Welcome to the SiTech world.  It is so easy to do all that from a single PC or laptpop.  I really doubt you can connect to two PC's with a comm splitter, but you are welcome to try.
Don W


Re: Quite A Learning Curve

Don W
 

Hi Rusty,
Welcome to the SiTech world.  It is so easy to do all that from a single PC or laptpop.  I really doubt you can connect to two PC's with a comm splitter, but you are welcome to try.
Don W


Quite A Learning Curve

Rusty Fletcher
 
Edited

I have used Mel Bartels stepper motor telescope control system for more than 20 years. I recently decided to upgrade to the SiTech servo motor system. I purchased the motors and electronics about a week ago and have not yet done the physical upgrade to my scope. I am studying the manuals, help files, and currently trying to familiarize myself with the software and everything I need to know to control my telescope with this new system. Do I understand correctly that I can connect two laptops to the same serial port, at the same time, on the SiTech Servo 1 controller using a straight through DB-9 Serial "Y" splitter? The reason I am asking is I would like to run SiTechExe connected to the Servo 1 controller, and control my primary imaging camera with my first laptop, while running my guide scope software (PHD) and sending ASCOM guide commands directly to the Servo 1 Controller from a second computer. Can this be done simultaneously? Thank you for any advice!

Rusty F.

621 - 640 of 33585