Actually it just failed on the second job after I restarted it. I managed to get the console log this time.

2020-02-17T00:19:07 Parking mount in progress...
2020-02-17T00:19:06 No jobs left in the scheduler queue.
2020-02-17T00:19:06 Job 'M 81' is terminated due to errors.
2020-02-17T00:19:06 Warning: job 'M 81' slew failed, marking terminated due to errors.
2020-02-17T00:18:54 Job 'M 81' is slewing to target.
2020-02-17T00:18:54 Warning: job 'M 81' found not slewing, restarting.
2020-02-17T00:18:54 Job 'M 81' is slewing to target.
2020-02-17T00:18:54 Warning: job 'M 81' found not slewing, restarting.
2020-02-17T00:18:51 Job 'M 81' is slewing to target.
2020-02-17T00:18:50 Mount unparked.
2020-02-17T00:18:49 Mount parked.


Read More...

Running a recent pull from git (maybe a week old) and pretty current indiserver and drivers from git as well on Mint 19. This mount is a Software Bisque Paramount MX+.

I'm having a problem with Ekos where it will fail a job while the mount is still slewing to the target. This *seems* to be more frequent when the job is started with the mount parked but I can't say for certain. Less frequently Ekos will think the slew is done and start the focusing routine. I usually solve the failure by stopping the schedule, resetting the state of the failed job, then starting it again. If there is no subsequent job in the schedule the system will go into shutdown.

Near as I can tell the driver polls the mount asking if the slew is complete and it gets an appropriate response but the driver tries to restart the slew which throws an error. Could be the driver is at fault but I'm not sure. The console logs in Ekos indicate an attempted restart of the slew, which could causing the driver to restart and get the error. Unfortunately I didn't save those logs.

Here's a snippet that I think covers what's going on:

[2020-02-16T22:52:19.063 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] CMD: /* Java Script */var Out;Out = sky6RASCOMTele.IsSlewComplete; "
[2020-02-16T22:52:19.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2020-02-16T22:52:19.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Slewing stage...
...
[2020-02-16T22:52:22.065 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] RES: 0|No error. Error = 0. "
[2020-02-16T22:52:22.066 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] CMD: /* Java Script */var Out;sky6RASCOMTele.GetRaDec();Out = String(sky6RASCOMTele.dRa) + ',' + String(sky6RASCOMTele.dDec); "
[2020-02-16T22:52:22.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2020-02-16T22:52:22.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Slewing stage...
...
[2020-02-16T22:52:25.066 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] RES: 3.9802719370492765,20.99556246770557|No error. Error = 0. "
[2020-02-16T22:52:25.067 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[SCOPE] Current RA:  3:58:49 Current DEC: 20:59:44 "
[2020-02-16T22:52:25.067 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] CMD: /* Java Script */var Out;try {sky6RASCOMTele.Asynchronous = true;sky6RASCOMTele.SlewToRaDec(7.32398, -13.2668,'');Out  = 'OK'; }catch (err) {Out = err; } "
[2020-02-16T22:52:25.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2020-02-16T22:52:25.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Slewing stage...
...
[2020-02-16T22:52:28.070 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] RES: TypeError: A Mount command is already in progress. Error = 121.|No error. Error = 0. "
[2020-02-16T22:52:28.071 MST DEBG ][           org.kde.kstars.indi] - Paramount : "[DEBUG] CMD: /* Java Script */var Out;try {sky6RASCOMTele.Asynchronous = true;sky6RASCOMTele.SlewToRaDec(7.32398, -13.2668,'');Out  = 'OK'; }catch (err) {Out = err; } "
[2020-02-16T22:52:28.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2020-02-16T22:52:28.919 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Slewing stage...
[2020-02-16T22:52:28.920 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 6
[2020-02-16T22:52:28.920 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Slewing stage...
[2020-02-16T22:52:28.921 MST DEBG ][ org.kde.kstars.ekos.scheduler] - Find next job...
...

Full log attached.

- Greg

File Attachment:

File Name: job_fail.log
File Size: 66 KB


Read More...

Greg replied to the topic 'Live stacking methods?' in the forum. 3 months ago

han.k wrote:
Unfortunately, that is not possible. If you stack bayered images , the red pixel will fell over blue ones and green ones etc. Debayer is only possible before stacking. It will increase the load but it's to only possible way. so to get colour images, you have to checkmark the option "convert OSC images to colour. The Debayer option F8 only works for a single image.


Hah! I should've thought about that - Calibrate & Debayer, *then* Align & Stack. It's been a long times since I've done OSC so I'll give myself a pass for goofing that one up. The result is certainly interesting though.

Read More...

Greg replied to the topic 'Live stacking methods?' in the forum. 3 months ago

Han,

In the case of the images I attached above, they are the same stack. The first is the non-debayered result. I had automatic "Covert OSC to color" disabled. To get the color image I waited until the stack was complete then I simply debayered it (F8). These shapes appear in most and possibly all of the stacks I ran last night.

- Greg

Read More...

Greg replied to the topic 'ASTAP astrometry integration' in the forum. 3 months ago

Testing out on OSX, Kstars 3.3.7.

I am able to get ASTAP to run, however I have not been able to get a solution reliably. Sometimes trying a second or third time immediately will result in success. Saving the images from the alignment tab that failed and loading them in to ASTAP by hand proves that it can get a solution with the images as they are. I'm not sure but I think maybe the failure appears to be related to the Field Height Image setting in the alignment tab of ASTAP, which I notice is sometimes erroneously set at a number less than 2x the actual. I haven't figured out how this value is getting in the config. I tried forcing this setting in Ekos (presumably with the -fov parameter) but it is overwritten each time and doesn't seem to take. I also noticed that the command line parameters for the astrometry.net solver pop into the options field if you click on the pencil icon to open settings then select OK. This is reproducible.

Read More...

Greg replied to the topic 'Live stacking methods?' in the forum. 3 months ago

han.k wrote:
Greg,

Just released a new macOS version (0.9.298). It would be nice if you could test it. My testing of the macOS version is very limited. I compile it using virtual machine running 640x480 resolution only on a old laptop. :)

Han


Han,

Thank you!

I have it running presently. I'm working with OSC tonight. Some feedback while running live stacking:

- The UI becomes quite slow to respond when live stacking is enabled.
- Dragging the image around is glitchy, especially when live stacking is enabled.
- When adding flats they don't appear in the list until after you press "analyse". Added flats do not have a checkbox next to them.
- I get odd patterns in the images from time to time. For example:



- The noise reduction appears to work quite well as evidenced by the smoothing of the background.

Overall very promising results. Keep up the good work!

- Greg

Read More...

Greg replied to the topic 'Live stacking methods?' in the forum. 3 months ago

Hi Han,

I'm testing live stacking on OSX. I see the OSX build is listed as being a version or two behind the others. Is it possible to get an OSX build? I'd like to provide feedback on the latest and greatest so I'm not reporting things that are already resolved.

- Greg

Read More...

Greg replied to the topic 'ASTAP astrometry integration' in the forum. 4 months ago

Tested it out a couple of nights this week. I admit I forgot I had it configured. It "just worked".

And wow - very fast solutions. Love it. Nice work Jasem & Hans.

Read More...

Greg replied to the topic 'kstars build from git error /usr/bin/ld: cannot find -lsecret-1' in the forum. 6 months ago

I tried to build on my new laptop running Mint 19.1 using the details in this post:
https://indilib.org/forum/general/210-howto-building-latest-libindi-ekos.html

Results were the same as alacant:

[ 96%] Linking CXX executable kstars
/usr/bin/ld: cannot find -lsecret-1
collect2: error: ld returned 1 exit status
kstars/CMakeFiles/kstars.dir/build.make:224: recipe for target 'kstars/kstars' failed
make[2]: *** [kstars/kstars] Error 1
CMakeFiles/Makefile2:393: recipe for target 'kstars/CMakeFiles/kstars.dir/all' failed
make[1]: *** [kstars/CMakeFiles/kstars.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2



Confirmed this *did* solve the problem for me:

knro wrote: <code>
sudo apt-get -y install qt5keychain-dev libsecret-1-dev
</code>



Read More...

Greg replied to the topic 'What is the right way to control meridian flips?' in the forum. 9 months ago

sterne-jaeger wrote:

It would be frustrating to wake up to a dialog asking if I want to flip and find that the system sat waiting for input and stopped imaging.

Seems like nobody needs such a dialog - myself included.

Please accept my humble apologies. I did not intend criticism or disrespect with the statement.

... However, it may make it unclear from a planning point if or when the flip may occur if it is no longer associated with one (or both) of these tabs. It will also make it easy to forget to consider it as part of the imaging sequence if it becomes otherwise "hidden" by relocating it away from these tabs.


The design idea is slightly different. The meridian flip behaviour is simply an attribute of the mount and not of a capture or schedule sequence. As long as you do not change the meridian flip behaviour, it remains the same for all your captures and schedules. I do not see a reason turning this behaviour on and off for specific sequences.


I think the flip *during imaging* should be well coordinated with the imaging sequence, and highly visible within the sequence, and predictable.

Yepp, this remains unchanged. The Mount module requests a meridian flip permission from the Capture module. As soon as a frame capture is completed, the Capture module grants the permission and waits, until the flip is completed. As soon as it is completed, it re-aligns and restarts guiding. By the way, this behaviour remains untouched.


Got it. Thank you for the clarification.

Read More...

Greg replied to the topic 'What is the right way to control meridian flips?' in the forum. 9 months ago

If the mount tracking can be disabled that would be ideal.

I wonder if it would be best to handle these details in the driver's though as a set of limits that fall within the mount's capability. These would be exclusive of any flip function requested by Ekos.

Read More...

Greg replied to the topic 'What is the right way to control meridian flips?' in the forum. 9 months ago

ChrisRowland wrote: I woud be wary of adding more complexity to something that is already causing support problems becuse of it's complexity.

Doing the pier flip early will probably need further information from the mount and also a bool SetSideOfPier(PierSide ps); function. The driver would need to implement this, including reporting an error if it can't be done. Many mounts can't flip early so some way of notifying the user that it's possible would be needed. Some indication of an allowable hour angle range would be one way.


A fair point. I admit I am unfamiliar with out Ekos presently initiates a flip. I suspect it may just be a normal slew command?

In the case of my equipment (paramount), TSX mostly controls when the early (or late) flip is available I. Generally, I keep the flip point as far east of the meridian as possible. As long as the mount has passed that line, issuing a slew is enough to get the job done. In a case like this it could be as simple as re-issuing a slew command and trusting that the mount knows what to do.

I guess a complexity in this is ensuring that Ekos knows to reset guiding and the model due to the flip. In that case it would need to know the change in the side of the pier.

Read More...

Greg replied to the topic 'What is the right way to control meridian flips?' in the forum. 9 months ago

I agree with Jasem and Wouter. An unattended meridian flip that is coordinated with my imaging strategy is a required feature for me. A merdian flip is a "major" action in an imaging sequence, much as guiding, focusing, capturing are. It would be frustrating to wake up to a dialog asking if I want to flip and find that the system sat waiting for input and stopped imaging.

As an imager, I primarily interact with the capture and scheduler tabs. I can agree that maybe the flip feature might be better located elsewhere (like in the scheduler). However, it may make it unclear from a planning point if or when the flip may occur if it is no longer associated with one (or both) of these tabs. It will also make it easy to forget to consider it as part of the imaging sequence if it becomes otherwise "hidden" by relocating it away from these tabs. I think the flip *during imaging* should be well coordinated with the imaging sequence, and highly visible within the sequence, and predictable.

Read More...