20 replies to this topic

[Lord Beowulf]

Hi All,

 

So I'm finally to the point with my NexStarEquatorial direct-to-motor, NexRemote/hand controller replacement ASCOM driver that I'm ready to open it up to some initial beta testers.  Since we're moving into a full moon phase, now's a good time for experimentation.  For those who haven't heard me mention it before, my goal for some time has been to find a solution to the manual nature of having to wake up and hibernate NexRemote for automating my remote observatory.  While of course Celestron has now decided to develop a new Windows native replacement for NexRemote, at least for newer mounts, it didn't come in time to prevent me getting started on the driver I'd envisioned and I now have it operational.  Essentially I've implemented the important components of a NexStar hand controller directly into an ASCOM driver that communicates with the motor controllers directly through the PC or AUX port of the mount.  The driver automatically saves and restores the current position of the mount on exit so that even if the mount is powered down in between sessions, when the driver starts back up, everything's still where it was. 

 

This driver is targeted towards full system automation and imaging, so it only supports the NexStar mounts in equatorial mode (thus the name).  It also relies heavily on imaging software capable of plate solving and aligning automatically (i.e. something like Sequence Generator Pro).  With a good polar alignment and starting point, there's no need to do any sort of manual alignment at all, but it does support manual entry of coordinates from a plate solve to get the current reference if desired.  I actually don't use it because SGP handles that all for me.  Below are a couple of screen shots of the setup and hand control dialogs for the driver.  They're still in a state of flux and subject to change, but I thought I'd share the look so far.

 

 

 

I'm currently using this with my CGE Pro, and after finally figuring out a coordinate system oddity they had, it's working great (for the last couple of months of testing I couldn't image in the west because the range was limited to only 23 degrees above the horizon!  Thus the new Azimuth Offset value that screwed up the look of my setup dialog!   ).  I've also tested extensively with my 8SE mount, although not necessarily treating it as a fork mount for much of the time.  I still need to finish implementing the "reverse" checkboxes that you see in the setup as it turns out different mounts define positive in different directions.  

 

At any rate, at this phase, I'm looking for knowledgeable imagers and observatory operators using SGP or similar software with targeting, plate solving, and sync capabilities who'd like to try out the driver.  The assumption is that you know enough about your mount and how things work to be able to give good feedback (and ASCOM logs) from your experiences.  I'd like to cover the gambit of NexStar mounts including CPCs, CGEs, CGEMs, etc.  Currently the driver only supports direct communication through a PC or AUX port connection, although I expect I'll add the hand control command wrapper at some point in the not too distant future.  So if you're interested in giving it a shot, drop me a line and let me know the details of your setup and we'll go from there.  I also still need to spend some time on some documentation, but if there's enough interest, I'll attempt to get people going quickly.  Oh, and I need someone in the Southern Hemisphere, as I really have no way to test the coordinate transformation there!

 

Thanks,

 

Beo

[Michael_Swanson]

Hi Beo,

 

Excellent work!  I don't set up my scope in EQ mode so I may not follow this too closely, so...once you get to the point where you are ready for a general release, shoot me a message and I'll add ORO NexStarEquatorial ASCOM Driver to this page at my website:

https://www.nexstars.../PCPrograms.htm

 

Best regards,
Mike Swanson
Author of "The NexStar Users Guide II"
Author of "The NexStar Users Guide"
Author of "NexStar Observer List"
https://www.nexstarsite.com

[James Cunningham]

You mentioned a Windows replacement for Nexremote.  Where did you get that info?  Thanks.

Jim

[Lord Beowulf]

Hi Beo,

 

Excellent work!  I don't set up my scope in EQ mode so I may not follow this too closely, so...once you get to the point where you are ready for a general release, shoot me a message and I'll add ORO NexStarEquatorial ASCOM Driver to this page at my website:

https://www.nexstars.../PCPrograms.htm

 

Best regards,
Mike Swanson
Author of "The NexStar Users Guide II"
Author of "The NexStar Users Guide"
Author of "NexStar Observer List"
https://www.nexstarsite.com

Hi Michael, 

 

Great!  Thanks.

 

Beo

[Lord Beowulf]

You mentioned a Windows replacement for Nexremote.  Where did you get that info?  Thanks.

Jim

Hey!  No hijacking my thread!   

 

Years ago I was invited to join Celestron's beta testing website when I was looking for a solution to this issue (offering to re-write NexRemote for them if they'd be willing to give up the source code).  Part of the problem however is that since NexRemote is just an emulator and the functionality for the hand controller rests in the hand control firmware, there was no real way to add functions that weren't manually accessed through the hand control buttons, virtual or real.  More importantly, there just isn't room in the memory of the embedded microcontroller to add more code to the hand control firmware!  That's why some things just never get fixed/added.

 

At any rate, the new software is a collaboration with PlaneWave Instruments and is (not surprisingly) called Celestron PlaneWave Instrument (CPWI).  Initially, CPWI appears to be more of a planetarium software with scope calibration capability (similar to SkySafari but for a PC).  Unfortunately as you'll see in the link, the currently released version is only for their latest mounts and I was told there were no plans for backwards support.  However, about the time I had my driver breathing, they released a version for beta test that does go back and adds CGE Pro, CGEM series, and Advanced VX support (no CPCs/wedge mounted scopes yet), all accessed through the base of the hand controller (which I never use for remote control).  I haven't bothered testing it yet since I was already too far along to stop, but at least they're making progress.  However, I'm not sure if they have the ASCOM driver for it breathing yet either. 

 

At any rate, since my driver relies more on external planetarium/imaging software and is really just intended to give those a way to talk directly to the motors and sync the current RA/DEC without needing fancy calibration, it's not really targeted in the same direction as CPWI.

 

Thanks,

 

Beo

[freestar8n]

Hi-

 

I am in southern hemisphere with cge-pro.  This sounds interesting.  Does it do hardware pulseguides using the aux commands?

 

I currently use NexRemote and the normal ASCOM driver - in combination with TheSky and guiding software.

 

Would this work simply to replace the ASCOM driver and still use NexRemote - or are you saying to use the handcontrol and not use NexRemote with this?

 

Also - I didn't know CPWI might be available for my cge-pro and I will look into it.

 

Thanks,
Frank

[Lord Beowulf]

Hi Frank,

 

Cool.  I wasn't expecting to get someone in the southern hemisphere this quickly, so I still want to take a pass through and make sure that I think all the signs are toggled correctly.  

 

Yes, this does ASCOM pulse guiding using the standard MOVE commands (equivalent to pushing the arrow keys on the HC at the slow rate for the specified time).  I believe there may be a new pulse guiding command in the newer scopes, but since Celestron has yet to publish that, this works great for now.  The only thing I'd like to have is more control over the pulse guide speed setting.

 

And no, this completely eliminates NexRemote.  The dialogs you see are part of the server based ASCOM driver, which supports multiple clients connected simultaneously so that you can use SGP to align to the target and still pulse guide with PHD2.  That was about the last month or so of work converting my DLL based driver over to a shared server based driver.

 

Again, no more talk of CPWI on my thread!   

 

Beo

[nlsky]

Hi Beo,

This sounds great!

 

I would be interested to test if it will work on an AVX. Especially if it can bypass the handpaddle (although I suspect AVX does not support this).

 

DaveNL

[Lord Beowulf]

Hi Beo,

This sounds great!

 

I would be interested to test if it will work on an AVX. Especially if it can bypass the handpaddle (although I suspect AVX does not support this).

 

DaveNL

Hi Dave,

 

No reason to believe it won't work fine on an AVX assuming you have an AUX port interface.  I can't tell for sure from Celestron's pictures, but it doesn't look like they have a PC port there.  I do plan to eventually support communication through the base of the hand controller, but it's not my priority.  It's not like it will take that long to add, but I just don't need it myself!  

 

On the issue of AUX port interfaces, there were a couple of other posts where I promised to share what I'd done there.  I need to package this up some day, but this was an updated approach to Ken Hutchinson's serial-to-AUX port that uses USB and is quite a bit easier to put together.  I'm just using an Arduino style USB to TTL adapter like this one (note I just picked the cheapest US supplier on the list for the attached link and am not promoting any particular vendor.  You can buy cheaper elsewhere.), and added a 74HC125 buffer with a couple of pull-up resistors.  You should be able to see enough detail in the full sized photo, along with Ken's guide, to replicate this yourself.   

 

 

Thanks,

 

Beo

[Lord Beowulf]

So of course now that the moon's starting to get out of the way we're having cloudy evenings and I can't do any more imaging, but I've completed the validation of my driver in both fork and GEM mode for the Northern Hemisphere.  I had a pretty major modification required to address a coordinate system/travel limit issue with the CGE Pro.  The basic fix was relatively straightforward, but that led to reorganizing things to make the coordinate system adjustments easier.  

 

I still need to work on the Southern Hemisphere support since when I got into the updates it became apparent that it definitely wasn't going to work yet, so sorry Frank.  With the holiday coming up it'll probably be another week or two before I get it done.  At any rate, anyone wanting to test for the Northern Hemisphere, let me know.

 

And just to be sure everyone's on the same page, the main goal of this driver is to eliminate the human completely from the startup/shutdown and targeting process, so it's really only for fully automated imaging systems.  I have no plans to ever support alt/az (thus the name), and the equatorial mode alignment assumes a moderately well polar aligned system and then assumes plate solving can be used to get the RA/DEC of the current pointing direction.  Thus, it's not necessarily practical (or needed) for a manually setup system, but is ideal for an observatory.  People using it manually may still find it useful since they don't need to go through an alignment process in the hand control.  I just don't know how far off their polar alignment can be and still have things work reliably enough.  With SGP, I suspect it would work pretty well.

 

Thanks,

 

Beo 

[Lord Beowulf]

After working through some inconsistent command behavior, I have the driver working with the option to communicate through the base of the hand controller in addition to using the PC or AUX port.

 

Beo

[Lord Beowulf]

Ok, so I'm pretty much done at this point.  While I want to run back through and test everything again in all modes, I've successfully validated in both wedge and GEM mode in the Southern Hemisphere, so all the basic functions are in place and working correctly.  Here are the tweaked dialogs.

 

 

  

 

So, feel free to post or drop me a PM if you want to try it out.

 

Thanks,

 

Beo

[Lord Beowulf]

Hi All,

 

I've sent the beta version of the driver to a few interested parties so far, and have added a bit more detailed post about the driver and how it works to my website.

 

Thanks,

 

Beo

[Lord Beowulf]

Thought I'd bump this topic to be sure anyone else who might be interested would see it.  After using my driver for a few months (when weather permitted) I have a few changes to make, but for the most part it works great.  I need to tweak the targeting algorithms slightly as sometimes the default targeting functionality in the motor drives is so far off that my "creep to target" final slew motion can take a long time.  I also need to increase the robustness for communication problems (that I started having after futzing with other hardware on my system) to try to more gracefully recover and retry.  I hope to work on that in the next few days.

 

Also, for all my friends and acquaintances here on CN who may be Sci-Fi fans, I wanted to point you to this post in the vendor forum for a freebie on Amazon, today only.

 

Thanks,

 

Beo

[Todd1561]

Interesting work, and thanks for opening it up for public use. One question, it sounds like you’re using this with a permanently mounted scope. If that’s the case why don’t you just hibernate the scope after each use to retain it’s alignment? I was under the impression that’s how most people with observatories operated, thus negating the need for something like this. 

[Lord Beowulf]

Hi Todd:

 

You missed one of the main points behind why to do this.  Hibernation is not an automatic or programmable function.  You have to do it manually, and even worse yet, even though you're on a PC program with NexRemote, you still have to navigate through about twenty different settings in the virtual hand controller user interface to get through the utilities menu to the hibernate function and shut it down.  Absurdly complicated!  My driver hibernates automatically when the driver exits, so I don't have to do anything manually.  The only thing I have to do (that I hope SGP will fix) is manually tell it to connect all equipment (not just the telescope) prior to starting a sequence.

 

As an update, I've started having communication problems (one of the other big reasons to not like NexRemote!) since adding a second camera to my system and am working on making the driver more robust through communication errors.  After last night I'm starting to suspect a USB side problem that the port itself is temporarily going away, because retries don't work.  Thus I need to add a mechanism to detect a closed port as well.  That may be tricky since if the driver resets, the ASCOM wrapper may not know about it.  May be easiest to just do a close and open on any communication error.

 

Beo

[Todd1561]

OK, I wasn't thinking you were going for that level of automation.  I was thinking the goal was to just allow full interaction with a remote site to prevent physically having to go there.  Thanks for clarifying.

[Astronomia Oaxaca]

Hello, I am Filiberto from Oaxaca Mexico, I just found this topic and I think that it is exactly what I need. how can I get your driver? I have got   a CGE Pro That i need to be as autonomous as posible, at this time, i am using nexremote or cpwi but I have to do a calibration each time that i use my remote observatory.  This is not the way I think it should be, I have got also a Orion Atlas and with it, I only need to switch it on, send a goto, do a plate solve and sync and i am done

[Lord Beowulf]

Hi Filberto,

 

You already tracked me down on my website, but thought I'd respond here so that people didn't think I was ignoring you!  Thanks for testing the driver.

 

Beo

[Astronomia Oaxaca]

yes, Thanks you, I did a preliminary test and your driver works well with my telescope, I found certain troubles using it with Voyager capture software, you asked me to send you a log but I can not do any test because every night has been clouded, this weekend maybe

[Lord Beowulf]

No problem.  Let me know if you have any time to capture logs.  I'm pretty busy these days myself and have had to let astronomy go by the wayside for the moment.  Chances are that will be for the rest of the year!

 

Thanks,

 

Beo