I just have received a UVC AR0130 Mono camera. I wan't to use it as a guiding camera.

The max exposure is 500ms. I have tried several settings, but it does not perform well with Kstars 3.5.0 and latest indilib.

I have tried different settings, but the results are the same.

Current settings are
YUYV:4:2:2 @ 1280x960

Video Stream reaches 1.5fps with 500ms exposures but a single exposure with 500ms takes about 3s:

2021-01-13T14:34:57: [INFO] Started 0.500-second manual exposure.
2021-01-13T14:34:57: [INFO] Capture of one frame (0 stacked frames) took 3.030569 seconds.
2021-01-13T14:34:53: [INFO] Started 0.500-second manual exposure.
2021-01-13T14:34:53: [INFO] Capture of one frame (0 stacked frames) took 2.973841 seconds.
2021-01-13T14:34:49: [INFO] Started 0.500-second manual exposure.
2021-01-13T14:34:49: [INFO] Capture of one frame (0 stacked frames) took 2.801923 seconds.
2021-01-13T14:34:46: [INFO] Started 0.500-second manual exposure.

200ms takes about 1-1.6s:
2021-01-13T14:38:12: [WARNING] No exposure or streaming in progress
2021-01-13T14:38:12: [INFO] Capture of one frame (0 stacked frames) took 1.081661 seconds.
2021-01-13T14:38:11: [INFO] Started 0.200-second manual exposure.
2021-01-13T14:38:10: [INFO] Capture of one frame (0 stacked frames) took 1.097628 seconds.
2021-01-13T14:38:09: [INFO] Started 0.200-second manual exposure.
2021-01-13T14:38:09: [INFO] Capture of one frame (0 stacked frames) took 1.241811 seconds.
2021-01-13T14:38:07: [INFO] Started 0.200-second manual exposure.
2021-01-13T14:38:07: [INFO] Capture of one frame (0 stacked frames) took 1.163899 seconds.
2021-01-13T14:38:06: [INFO] Started 0.200-second manual exposure.
2021-01-13T14:38:05: [INFO] Capture of one frame (0 stacked frames) took 1.097333 seconds.
2021-01-13T14:38:04: [INFO] Started 0.200-second manual exposure.
2021-01-13T14:38:04: [INFO] Capture of one frame (0 stacked frames) took 1.646151 seconds.
2021-01-13T14:38:02: [INFO] Started 0.200-second manual exposure.


When trying to use stacking f.e. additive, the driver sets the exposure to maximum and this results in only one stacked frame:

2021-01-13T14:39:55: [INFO] Capture of one frame (1 stacked frames) took 3.497064 seconds.
2021-01-13T14:39:51: [INFO] Started 1.000-second manual exposure.
2021-01-13T14:39:51: [WARNING] Requested manual exposure is out of device bounds [0.000,0.500], stacking up to 1.000 seconds using Additive.
2021-01-13T14:39:51: [INFO] Capture of one frame (1 stacked frames) took 3.523913 seconds.
2021-01-13T14:39:47: [INFO] Started 1.000-second manual exposure.
2021-01-13T14:39:47: [WARNING] Requested manual exposure is out of device bounds [0.000,0.500], stacking up to 1.000 seconds using Additive.
2021-01-13T14:39:47: [INFO] Capture of one frame (1 stacked frames) took 3.535223 seconds.
2021-01-13T14:39:43: [INFO] Started 1.000-second manual exposure.
2021-01-13T14:39:43: [WARNING] Requested manual exposure is out of device bounds [0.000,0.500], stacking up to 1.000 seconds using Additive.
2021-01-13T14:39:43: [INFO] Capture of one frame (1 stacked frames) took 3.304365 seconds.
2021-01-13T14:39:40: [INFO] Started 1.000-second manual exposure.
2021-01-13T14:39:40: [WARNING] Requested manual exposure is out of device bounds [0.000,0.500], stacking up to 1.000 seconds using Additive.


I also tried the "indi-webcam" driver, but with this ekos is crashing after indi connect ....

I also tried Motion JPEG ... with the same result :(

So any suggestions here?

Read More...

You need at least one capture sequence with 2 Frames in a row to get the boolean isTemperatureDeltaCheckActive become true.

In my case the Capture group was 1 Frame Ha, 1 Frame Oiii, 1 Frame Sii, 1 Frame Ha, and so on.

Because of this, the isTemperatureDeltaCheckActive will never be set to true and the focus delta is not checked. Maybe it is enought to start with two short captures, f.e. L-L-S-H-O-S-H-O-S-H-O becuase the isTemperatureDeltaCheckActive will be only resetted when you uncheck the checkbox.

The only "driver" issue that may be changed is that the driver debounces the temp updates by 0.5° of temp change, but this is also done by myfocuserpro2 ...

CS

Read More...

Hey, no it is _not_ a driver issue. It is a bug with single frame captures. I have fixed this localy and created a pull request in github: github.com/KDE/kstars/pull/24

CS
pmneo

Read More...

So, i think i have found the issue ;)

The capture module does not check the focus temp when having single filter sequences (S H O S H O) ...

I have fixed this localy in capture.cpp:

<pre>
IPState Capture::resumeSequence()
{
// If no job is active, we have to find if there are more pending jobs in the queue
if (!activeJob)
{
SequenceJob * next_job = nullptr;

foreach (SequenceJob * job, jobs)
{
if (job->getStatus() == SequenceJob::JOB_IDLE || job->getStatus() == SequenceJob::JOB_ABORTED)
{
next_job = job;
break;
}
}

if (next_job)
{
//check delta also when starting a new job!
isTemperatureDeltaCheckActive = (m_AutoFocusReady && limitFocusDeltaTS->isChecked());

prepareJob(next_job);

//Resume guiding if it was suspended before
//if (isAutoGuiding && currentCCD->getChip(ISD::CCDChip::GUIDE_CCD) == guideChip)
if (guideState == GUIDE_SUSPENDED && suspendGuideOnDownload)
{
qCDebug(KSTARS_EKOS_CAPTURE) << "Resuming guiding...";
emit resumeGuiding();
}

return IPS_OK;
}
else
{
qCDebug(KSTARS_EKOS_CAPTURE) << "All capture jobs complete.";
return IPS_BUSY;
}
}
// Otherwise, let's prepare for next exposure.
else
{
isTemperatureDeltaCheckActive = (m_AutoFocusReady && limitFocusDeltaTS->isChecked());

// If we suspended guiding due to primary chip download, resume guide chip guiding now
if (guideState == GUIDE_SUSPENDED && suspendGuideOnDownload)
{
qCInfo(KSTARS_EKOS_CAPTURE) << "Resuming guiding...";
emit resumeGuiding();
}

// If looping, we just increment the file system image count
if (currentCCD->isLooping())
{
if (currentCCD->getUploadMode() != ISD::CCD::UPLOAD_LOCAL)
{
checkSeqBoundary(activeJob->getSignature());
currentCCD->setNextSequenceID(nextSequenceID);
}
}
// otherwise we loop starting the next exposure until all pending
// jobs are completed
else
checkNextExposure();
}

return IPS_OK;
}
</pre>

And now i can see in the log:
<pre>
[2020-09-30T21:46:55.844 CEST DEBG ][ org.kde.kstars.ekos.capture] - Focus temperature delta (°C): 0 . Requested maximum delta (°C): 1
</pre>

But in the scheduler seems to be broken in the current nightly :P

Read More...

Yes i think so. I have just done some recent changes to the driver and build it localy, now let's see if this works.

CS
pmneo

Read More...

So i have switched over from KStars running under Windows to run KStars under the Raspberry PI 4.

The Temperature based Focus is still not working, but now i can see following logs:

<pre>
, QVariant(qlonglong, 5196))))
[2020-09-30T12:36:20.491 CEST INFO ][ org.kde.kstars.ekos.focus] - "Idle."
[2020-09-30T12:36:20.494 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.494 CEST INFO ][ org.kde.kstars.ekos] - "DeepSkyDad AF3 focuser is online."
[2020-09-30T12:36:20.496 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.519 CEST DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Capture" )
[2020-09-30T12:36:20.528 CEST DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Focus" )
[2020-09-30T12:36:20.636 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.641 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.646 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.650 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.652 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.656 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.659 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.661 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.678 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.687 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.691 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.696 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Focuser temperature is not available"
[2020-09-30T12:36:20.700 CEST DEBG ][ org.kde.kstars.ekos.focus] - "Setting current focuser temperature: 0.00"
</pre>

This is really strange, because the INDI Tab shows the Temp correctly and it is updated correctly, when taking the sensor into my hand:



Any Suggestions?

Read More...

DerPit wrote:
I also noticed that in debug it's even more verbose and reports the check after each frame, like
<code>
[2020-08-18T06:37:15.478 WEST DEBG ][ org.kde.kstars.ekos.capture] - Focus temperature delta (°C): 0.21 . Requested maximum delta (°C): 1
</code>
So enable debug for the capture module and check the output...

Edit: Sorry, just see that your log was with debug, and without the entries. Definitely try again with 1,00


I tried with 1 but i can't find such log entry in my logs :(

El Corazon wrote: "2020-09-16T22:29:09.259 Mitteleuropäische Sommerzeit INFO ][ org.kde.kstars.ekos.capture] - "Ekos will refocus in 3.600 seconds.""

Also, you are set to refocus after 1 hour anyway. Most likely, temperature drop will not exeed the [delta] T before the next refocus will be triggered anyway.

So if you want to test refocus on delta[T], disable the refocus after 60 min check box.


I had this disabled this option, but no focus was done. The thing is, that it seems that Ekos is not checking the current focuser temp. The only step where i can find the focuser temp is while the autofocus procedure:
[2020-09-17T02:39:56.796 Mitteleuropäische Sommerzeit DEBG ][     org.kde.kstars.ekos.focus] - "Setting current focuser temperature: 13.00"

But in this case it seems only to resolve in half steps, the UI of the driver has more sensible steps:



So do you think this may be a driver issue?

CS
pmneo

Read More...

I tried it, Ekos prints 1,000 after inserting only a 1.

Can anyone post a log with a working temp autofocus?

Here is a verbose snip of focus and capture ... the temp from focuser is readed correctly, but i can't find any hint that ekos is listening for the temp change ....

[2020-09-16T22:29:09.068 Mitteleuropäische Sommerzeit INFO ][     org.kde.kstars.ekos.focus] - "Autofocus complete after 18 iterations."
[2020-09-16T22:29:09.069 Mitteleuropäische Sommerzeit DEBG ][     org.kde.kstars.ekos.focus] - Stopping Focus
[2020-09-16T22:29:09.070 Mitteleuropäische Sommerzeit DEBG ][     org.kde.kstars.ekos.focus] - AutoFocus result: true
[2020-09-16T22:29:09.070 Mitteleuropäische Sommerzeit DEBG ][     org.kde.kstars.ekos.focus] - "Setting current focuser temperature: 16.50"
[2020-09-16T22:29:09.070 Mitteleuropäische Sommerzeit INFO ][     org.kde.kstars.ekos.focus] - Autofocus values: position,  6403 , temperature,  16.5 , filter,  "G" , HFR,  1.20918
[2020-09-16T22:29:09.247 Mitteleuropäische Sommerzeit DEBG ][     org.kde.kstars.ekos.focus] - State: "Complete"
[2020-09-16T22:29:09.259 Mitteleuropäische Sommerzeit DEBG ][   org.kde.kstars.ekos.capture] - setFocusStatus:  1
[2020-09-16T22:29:09.259 Mitteleuropäische Sommerzeit INFO ][   org.kde.kstars.ekos.capture] - "Ekos will refocus in 3.600 seconds."
[2020-09-16T22:29:09.260 Mitteleuropäische Sommerzeit INFO ][   org.kde.kstars.ekos.capture] - "Focus complete."
[2020-09-16T22:29:10.217 Mitteleuropäische Sommerzeit DEBG ][   org.kde.kstars.ekos.capture] - Focus elapsed time (secs):  0 . Requested Interval (secs):  3600
[2020-09-16T22:29:10.317 Mitteleuropäische Sommerzeit INFO ][           org.kde.kstars.indi] - ASI EFW :  "[INFO] Setting current filter to slot 4 "
[2020-09-16T22:29:13.280 Mitteleuropäische Sommerzeit INFO ][   org.kde.kstars.ekos.capture] - "Capturing 180,000-second B image..."

CS

Read More...

Hmm, i will give it a try, but i can not insert a dot here.

Kstars is running under Windows, while Indiserver is on PI4 ...

Thanks
pmneo

Read More...

Don't think so, the hfr field works fine for example.

Any other suggestions, or has anybody else tested this feature??

Read More...

I'm trying the new Autofocus on Temperature change, but it seems not working:

[2020-09-12T21:29:59.907 Mitteleuropäische Sommerzeit INFO ][ org.kde.kstars.ekos.focus] - "Autofocus complete after 15 iterations."
[2020-09-12T21:29:59.908 Mitteleuropäische Sommerzeit INFO ][ org.kde.kstars.ekos.focus] - Autofocus values: position, 6799 , temperature, 15.5 , filter, "L" , HFR, 1.2956


Focus has finished on 15.5° and in Capture tab the refocus delate is set to 0.5°:

The current temp is 14.0° and NO focus has been done yet ...




The full log is attatched ... i am using 3.4.3 Stable

CS
Philip

Read More...

Philip Mair created a new topic ' Autofocus and Cloud issues ...' in the forum. 6 months ago

This night i had an issue with some partial clouds.

The Autofocus process failed to focus and moved the Focus from initial 6200 up to 11300 and was not able to find a focus for the complete night.

The clouds where present from 23:27 till 23:53.

At 23:35 the Guding process lost his star:
[2020-09-09T23:35:41.310 Mitteleuropäische Sommerzeit INFO ][ org.kde.kstars.ekos.guide] - "Lost track of the guide star. Searching for guide stars..."

At 23:38 the Capture module restartet the Sequence and started Autofocus:
[2020-09-09T23:38:44.038 Mitteleuropäische Sommerzeit INFO ][ org.kde.kstars.ekos.focus] - "Autofocus in progress..."

And this was tried until daylight ... because it lost it moved too far away from the focus position and never moved back .... < i would treat this as a bug ...

Focus Settings are:
- Full Field with Annulus 25% / 75%
- Detection: SEP
- Algorithm: Linear
- Tolerance: 5%
- Initial Step Size: 15
- Max Travel: 200
- Out Step Multipe: 5.00

Any Suggestions how to fix that?

CS
Philip

Read More...

Hello knro

I just wanted to let you know that the Windows build is failing since 10 days: binary-factory.kde.org/job/KStars_Nightly_win64/

CS
Philip

Read More...