×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Capture & Solve -> Slew to Target...

  • Posts: 333
  • Thank you received: 24
Good news is that RPI3 is doing good with the imaging capture. I hope someone can help me some more. I have a couple of other posts related to this align/slew-to-target, and I am trying again to see if someone can help me understand how to improve the Slew to target.

The symptom is the Slew to target cannot work without some sort of manual intervention for me: nudging to get close enough framing for multiple night imaging sessions.

Slew to target can get my CGEM within 2'. If it works 3-4 more times it can get near 1'. After this, the accuracy is never to 30" save 2 three times in past six months.

It is not clear if I am expecting too much of the CGEM DX, if there is something I can do to improve the CGEM DX, or if there is something to do in process that can make this work better.

GOAL: use scheduler to pick target and let the RPI3 control the equipment for session on 1 or 2 targets, and also reslew close enough to the target after meridian flip. Then repeat on another night to collect more images

QUESTION: when at the sub minute level is there a way to have ekos nudge the mount instead of slewing again? It is this nudging I end up doing manually. If Ekos could nudge the mount, plate solve, and determine how much more to nudge, then this could be perfect.

Background:
- I am imaging with my C11 at f/10, so 2800mm focal length (perhaps slew to target is asking too much of CGEM?)
- The good: image capture is beautifully easy, focuser just works, control via skysafari great.
- The okay: does plate solve okay, it is not as fast as a more powerful PC.
- I need help: slew to target and time/date sync (for another day)
6 years 7 months ago #18588

Please Log in or Create an account to join the conversation.

  • Posts: 456
  • Thank you received: 76
AS a C11 user I think you may be asking too much of the CGEM.
I have a CPC1100 (fork mount) and I know what you mean about nudging the mount. I wrote a complete mount control system for my CPC1100 using the AUX protocol and an indi driver to communicate with this system. I implemented a 'nudge' goto when the target is less than a few arc min away. I dont think this feature can be easily added to the standard indi celestron driver unless the entire thing is re-written to use the AUX protocol.
Derek
6 years 7 months ago #18592

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
If I can get things setup I am interested in creating an AUX driver for CGEM.

I started looking at the indi_celestron_gps code to see about adding PEC and backlash settings, and perhaps one or two more things. Basically, some of the function in the Nexstar AUX is what I was hoping to bring over to INDI: www.paquettefamily.ca/nexstar/NexStar_AUX_Commands_10.pdf

Coding is not new to me. This environment and setup is though, as well as available time.

Is the nudging code available to build upon?

I will gladly share and offer whatever I can get going. I know I am going to have a bunch of question.
6 years 7 months ago #18593

Please Log in or Create an account to join the conversation.

How about using INDI NexstarEVO driver which is based on the AUX commands?
6 years 7 months ago #18594

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24

Thank you. I will check it out.


Sent from my iPhone using Tapatalk Pro
6 years 7 months ago #18596

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
Can I have a look at your code @dokeeffe please? I have implemented the whole AUX driver for indi: nexstarevo driver. The missing piece is the wired interface - right now it only works over wifi, and testing with german mount. So far I have tested it only on fork AltAz mounts but in principle it should work for equatorial orientation. Maybe We can use some of your code to improve the indi driver?
And you are right - standard celestron driver is a totally different beast.
Last edit: 6 years 7 months ago by Paweł. Reason: Add user name
6 years 7 months ago #18600

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57
The NexstarEvo driver is almost what you need - unfortunately it needs wifi connection to the telescope. I intend to implement wired link support in the future but have no hardware to test it on. It was never tested on the german mount as well.
But you should be able to use timed movement commands of the celestron driver to nudge the mount to the correct place.
The following user(s) said Thank You: Stephen
6 years 7 months ago #18601

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
I was just looking at the NexstarEvo driver and noticed the wifi, and no serial, connection. Thank you for confirming the serial and gem would be the missing parts. Looking at the new_open.c it seems that a serial connection could be added.

I was initial thinking was to extend one of the existing drivers in the fashion of the SkySafari Auxiliary driver. I started looking to extend the current indi_celestron_gps. Now that I see the NexstarEvo I am trying to determine direction.

The initial idea was using one of the current drivers to nudge it along monitoring the RA/DEC, and then plate solve again to confirm (perhaps it would be easier to start with turning PEC on and off first.). In the celestron driver, looking at the Park function and the tty_write PEC could be turned on and off, ideally sharing the same port. The nudge would then use the current get RA/DEC to read to confirm the nudge in the right direction and then correct/stop as needed. This did seem possible at the time... The other question was how to integrate into the plate-solve module so that after some accuracy was obtained with the slew to target and nudge to target would be used to complete, and so it would all be done within the scheduler.

I am still wrapping my head around the client/server design... nearly there. Seems my iOS program and made me forget more than I knew.

Please let me know if it would be adding to a current driver, or if the auxiliary driver concept may work. Perhaps, if abstracted out properly, for nudging at least, it could be used for other mounts as well.
6 years 7 months ago #18602

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
I was just looking at the NexstarEvo driver and noticed the wifi, and no serial, connection. Thank you for confirming the serial and gem would be the missing parts. Looking at the new_open.c it seems that a serial connection could be added.

I was initial thinking was to extend one of the existing drivers in the fashion of the SkySafari Auxiliary driver. I started looking to extend the current indi_celestron_gps. Now that I see the NexstarEvo I am trying to determine direction.

The initial idea was using one of the current drivers to nudge it along monitoring the RA/DEC, and then plate solve again to confirm (perhaps it would be easier to start with turning PEC on and off first.). In the celestron driver, looking at the Park function and the tty_write PEC could be turned on and off, ideally sharing the same port. The nudge would then use the current get RA/DEC to read to confirm the nudge in the right direction and then correct/stop as needed. This did seem possible at the time... The other question was how to integrate into the plate-solve module so that after some accuracy was obtained with the slew to target and nudge to target would be used to complete, and so it would all be done within the scheduler.

I am still wrapping my head around the client/server design... nearly there. Seems my iOS program and made me forget more than I knew.

Please let me know if it would be adding to a current driver, or if the auxiliary driver concept may work. Perhaps, if abstracted out properly, for nudging at least, it could be used for other mounts as well.
6 years 7 months ago #18603

Please Log in or Create an account to join the conversation.

  • Posts: 456
  • Thank you received: 76
Maudy / Jochym, yes of course, I hope the code is some use..... Its here on github github.com/dokeeffe/auxremote

Probably needs a bit of explanation as to why I did things the way I did. Normally an indi driver talks directly to the hardware, however I have a java application sitting in the middle that talks to the mount over serial (AUX commands) and then provides a high level HTTP API. The INDI driver is just a bare-bones shell that talks to the java application using HTTP. I also have an angular javascript client in the works but thats low priority....
I did this because I have more experience with java (my full time job) and I wanted something ultra reliable and well tested. I think I have about 90% test coverage. The entire thing is working really well for me with the CPC1100 on a wedge. I can align the mount from a cold start (power on) park/unpark is much more reliable for me than the standard driver. I also exposed PEC functions.

Most of the core logic is in the MountService.java
github.com/dokeeffe/auxremote/blob/maste...nt/MountService.java
The bit that nudges the mount if the target is <1deg is the slew method line 120.

One really important thing I learned is make sure you enable cord wrap AFTER unparking the mount (setting tracking and doing a sync) Otherwise it looks like the cord wrap does not get enabled. I learned this when testing once and almost crashed the scope into the wedge!!

Derek
The following user(s) said Thank You: Stephen
6 years 7 months ago #18615

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
I hope to work through some of this this week. Not sure what I am fully getting into yet.

I can say that last nights RPI3 imaging session worked amazingly well. The only thing pending is the nudging the mount to centre the RA/DEC:
- The celestron GPS driver controlled things well
- pulse guide calibrated a lot better then the ST-4
- PHD2 guided well consider how low NGC 7293 was
- the scheduler worked great.

The meridian flip needed my intervention to re-center which I am not good at yet - sigh, took about 30. Once done things continued on until twighlight.

If this nudging can be added... oh my! I may post back with questions as I work though things.
6 years 7 months ago #18644

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 24
Jochym, have you looked at this library? github.com/rumengb/libnexstar

I am considering making an INDI wrapper for it, and before I get too far, I am wondering if you discarded this library for a specific reason.
6 years 7 months ago #18660

Please Log in or Create an account to join the conversation.

Time to create page: 1.553 seconds