Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

ASCOM drivers for a Meade LX600

  • Please log in to reply
8 replies to this topic

#1 Lindhard

Lindhard

    Explorer 1

  • -----
  • topic starter
  • Posts: 51
  • Joined: 24 Aug 2008
  • Loc: N 55° 30' -- E 8° 26'

Posted 06 November 2018 - 02:34 PM

Does anyone know where to find ASCOM drivers for a Meade LX600?

 

I would like to use Sequence Generator Pro but cannot find the drivers.



#2 SDTopensied

SDTopensied

    Viking 1

  • *****
  • Posts: 731
  • Joined: 25 Apr 2011
  • Loc: Atlanta

Posted 06 November 2018 - 03:00 PM

You'll find the Meade Universal Driver Project about halfway down the page...

 

https://www.ascom-st...copeDrivers.htm

 

-Steve



#3 AF7JQ

AF7JQ

    Explorer 1

  • -----
  • Posts: 51
  • Joined: 07 Mar 2018
  • Loc: Concho Valley, Arizona 6500Ft ASL

Posted 07 November 2018 - 10:50 PM

Hello,

The Universal driver won't work...it will connect but you won't be able to plate solve with it. Use the LX200GPS driver. It will complain about the firmware differences between the LX200's 4.?? and the LX600's 1.1.g firmware, find the error box and click ok. The LX600 firmware is nothing other than the LX200gps with the added code for the starlock, they just changed the numbering sequence. It still has the same bugs as the LX200.

The LX200gps driver will allow you to plate solve to "almost centered" but not quite...target will always be in the frame, but not perfectly centered in the frame you chose in the frame and mosaic wizard. It's easy to fine tune it though. Be happy to answer questions as they come up...

John



#4 OzAndrewJ

OzAndrewJ

    Vanguard

  • *****
  • Posts: 2229
  • Joined: 30 Nov 2010

Posted 07 November 2018 - 11:11 PM

Gday John

 

The LX600 firmware is nothing other than the LX200gps with the added code for the starlock, they just changed the numbering sequence. It still has the same bugs as the LX200.

For the purpose of the ASCOM driver recognising it, yes, it is only the ID code the LX600 returns that makes the ASCOM driver not want to connect. ( It is not the firmware version like 4.2g or 1.1g, it is the declared mount type that gets used )

That said, there are a lot of new errors built into the LX600s that the LX200s dont suffer from.

Whether or not they will affect you will depend on what you do ;-)

 

 

The LX200gps driver will allow you to plate solve to "almost centered" but not quite..

Yes and no. It depends on how the calling app uses the driver.

Several means are available to "centre" the mount on a target.

Some people use a "nudge" command, but under the hood, it really does a goto, and as such you cannot ever accurately get to a close position.

If someone wrote an app to do a nudge by using timed slews/guides, or the "move by X encoder ticks" command, then it could in theory get very close.

ie it all depends on who wrote the code and how they assumed a Meade mount works undfer the hood.

 

Andrew Johansen Melbourne Australia


Edited by OzAndrewJ, 07 November 2018 - 11:12 PM.


#5 AF7JQ

AF7JQ

    Explorer 1

  • -----
  • Posts: 51
  • Joined: 07 Mar 2018
  • Loc: Concho Valley, Arizona 6500Ft ASL

Posted 08 November 2018 - 12:17 PM

Hi Andrew,

The LX200gps driver will plate solve the LX600 a couple times getting close to center, as it tries to plate solve closer it reaches a point where it just slews back and forth overshooting each time and never getting closer. I can see in the scope log it is trying to use slew each time. The slew commands are too coarse to move in smaller amounts. The driver does not have nudge enabled (or what ever the mount uses for small movements) and with Sequence Generator Pro the telescope control panel leaves the software handset greyed out and not accessible. I've used all the available means to center SYNC, TARGET OFFSET, and SCOPE OFFSET, and "center here" that are options in the SGP telescope control panel and they all try to use SLEW, and they all get to the "almost centered" point before they start overshooting back and forth.  If I use the POTH Hub driver with the LX200GPS driver chosen inside I get software handset that allows small movements under software command. But SGP still uses the LX200gps driver so it can't access the soft handset from POTH. If the "under the hood" stuff is really just a GOTO then shouldn't the target offset, or the scope offset be able to get there? The scope has very small guide rates available, wouldn't it choose a rate more appropriate to move than to overshoot each time?  Then there is the goto in NATIVE form with the real handset and High Precision Pointing enabled. The scope slews to a star near the target, and centers the star very precisely with small movements, SYNCS the new coordinates and then moves to the target. The scope seems to be using much smaller movement control than slewing. I wish I could see the log stream in the scope to see how it handled that. Anyway, the LX200GPS driver is all we have for the LX600...it will plate solve to "almost there"  very well, but will always require intervention to fine tune it to the chosen frame. I have fine tuned things such that I can repeat plate solving to a total pixel error of about 350 pixels (4656 x 3521) and have it assume that's good, any tighter than that and it starts overshooting. My buddy programs in "c" for a living...if we could find source code he said he would take a look...it's all greek to me! Meade doesn't bother to provide drivers, and private folks aren't going to spend time writing a driver for free so it a dog chasing it's tail. I'm glad to be able to control things "sorta"  remote and get out of the cold, but it could be better if it centered itself and I didn't have to go out to the dome in the winter to fine tune it at all.

John



#6 OzAndrewJ

OzAndrewJ

    Vanguard

  • *****
  • Posts: 2229
  • Joined: 30 Nov 2010

Posted 08 November 2018 - 03:46 PM

Gday John

closer it reaches a point where it just slews back and forth overshooting each time and never getting closer. I can see in the scope log it is trying to use slew each time.

If the calling app is using timed slews ( ie pulse guides ), you may have a chance.

If it is using untimed slews and encoder feedback, then it is rafferties rules,

as the PIC on the mainboard simply lies to the the main CPU :-)

( This tripped me up for ages )

Basically, the main CPU uses relatively hi speed I2C comms to talk to the PIC.

It can ask for position reports at a very high rate, but the PIC simply returns the last valid read, until it decides to do another,

When tracking in Polar, it is not unusual for the PIC to only read RA position once every 3 seconds.

As such, when moving, you really dont know where you "are", just where you were at last read.

On top of that, when busy, it can take up to 300ms to do an axis read for position ( between PIC and MotorCard )

The clocking rates also vary based on whats happening.

This screws up all sorts of things that are time dependent, and is one of the reasons i suspect they do PEC the way they do.

( Something that also screwed with my head for ages )

The slew commands are too coarse to move in smaller amounts.

So use slower speeds ???? There is nothing stopping that ( other than any driver imposed limits )

But SGP still uses the LX200gps driver so it can't access the soft handset from POTH.

So connect POTH to the mount, then SGP to POTH

If the "under the hood" stuff is really just a GOTO

I dont know with SGP. I remember one of the other major apps provided a "Nudge" command, but it was done as a goto. This means you have no idea where you will end up :-)

ie from the normal handbox, when tracking, hold mode to get to the alternate menus.

Go to the RA/DEC screen and hit "goto", then "enter", "enter"  ie goto current.

The system doesn t know its already there so goes through the full goto process and drifts away then comes back.

Only prob is it has a 10 arcsec target radius so could be anywhere ( up to maybe 20 arcsec from where it started. )

I wish I could see the log stream in the scope to see how it handled that.

Its no different to a goto, just you use a MKI eyeball and guide speed to centre a target.

The mount uses a low speed to dothe same with a goto, but has a dodgy encoder read sequence and a large target radius.

 

Andrew Johansen Melbourne Australia

 

just looked at my notes for the LX600 "goto"

Basically, it selects a target that is 4 clock seconds behind required, then starts slewing.

It stops when within 60arcsec of that spot ( but you dont know how long till it reads the encoder :-)  )

It then selects an RA that is 8 clock seconds ahead of target and starts slewing. ( and sets an 8 second timer )

When within 10 arcsec of target, it stops and waits for the timer, then starts tracking

ie it should be on target and with preloaded gears so tracks away

Once more, there are timing and encoder variations in play, so you can get see sawing results

if you try to refine it using another goto. You really need to use pulseguides to tweak it in this scenario.


Edited by OzAndrewJ, 08 November 2018 - 04:33 PM.


#7 OzAndrewJ

OzAndrewJ

    Vanguard

  • *****
  • Posts: 2229
  • Joined: 30 Nov 2010

Posted 09 November 2018 - 12:44 AM

Gday John

I wish I could see the log stream in the scope to see how it handled that.

Just for info, i have attached 2 items i dug out of my archives.

1) Is a log of the commands sent to the AZ motor card when doing a slew from pole star to first align star during an align.

Note! This is PIC to Motorcard comms, it is not what the main firmware has "asked" for.

It shows the 2 stages of a goto, and roughly how often the encoders really get read.

Alt follows the same process, so i have left it out for clarity.

The data is for an LX600 1.1g firmware, but with no Starlock ( as i could never five finger discount one to test with ).

2) Shows a simple startup and track plot, and details how the tracking and encoder read rates change based on ???? and how the encoder reading clocking rates can be very different in time taken to complete.

It also highlights that in the main firmware, the CPU asks for a position read every 8ms but in reality, it only gets "new" data every 3 seconds at times :-)

All makes getting very precise position data "whilst moving" a problem.

 

Andrew Johansen Melbourne Australia

Polar1gEncoderRates.jpg

Attached File  Polar1AlignSlewToArcturus.txt   5KB   3 downloads

 

 

 

 

 

 

 

 



#8 AF7JQ

AF7JQ

    Explorer 1

  • -----
  • Posts: 51
  • Joined: 07 Mar 2018
  • Loc: Concho Valley, Arizona 6500Ft ASL

Posted 10 November 2018 - 01:27 PM

Wow, looking at the timing pulses I'm grateful to get as close as I do!!! Thanks for the additional info. Eventually I think the LX600 will be demoted to just visual work, and and a new EQ mount that centers mated to a RASA might be the ticket. Now, if I can only get the CFO (wife) to approve!

Thanks Andrew

John



#9 OzAndrewJ

OzAndrewJ

    Vanguard

  • *****
  • Posts: 2229
  • Joined: 30 Nov 2010

Posted 10 November 2018 - 03:32 PM

Gday John

As i mentioned earlier, if you can get an app that does a fine centre "nudge" using pulseguides, you can get very accurate, but if it relies on a "goto" to do a small tweak, you are going to struggle.

All depends on understanding how she works under the hood :-)

 

Andrew Johansen Melbourne Australia




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics