Issue - EKOS Scheduler that was working only days ago performing meridian flip has now stopped performing flip
Test case set up and in the logs at 11:26 am Aug 4 - - tracking location successfully, images (darks) capturing fine
Mount Tab show MF_Ready and Flip if HA> 1.95 degrees is triggered
Scheduler finishes a capture after about 163 seconds after MF_ready is triggered
Scheduler does NOT pause next capture and basically ignores the flip ready to go
I manually STOP the scheduler after the next capture -> the FLIP immediately starts and completes!!!!!!
so there is s break or block in transmission of the MF ready message pattern - or perhaps the acceptance
Please advise - since I have not rebuilt or updated code and I was successfully flipping within the past few weeks I am at a loss as to why this is happening
KSTARS 3.5.4Beta (modified by me many months ago in ekos/capture.cpp to correct placement of pre-capture script - this has been operational with flip since changed)
Serge - which builds did you test - I want to rebuild mine and do the same: indi main? 3rd party? - or are these private branches
HI Jasem et al.....
QHY just sent me back a new version of the 294 after fixing what was a USB problem - It appears there is NEW SDK from March but when I look in INDI control panel I see a February version - supposedly the NEW SDK allows for proper generation of the 47 meg MODE 1 image without a crazy double bayer pattern...I have downloaded the updated SDK from qhyccd.com but before I blow anything up is there and ADVISED way to update the qhyccd driver/sdk - not the INDI driver as I already build that from source, but the OEM driver. I am on astroberry......any advise would be great
Jasem, or anyone else - In qhy_ccd.cpp the following is being executed when neither are true - this makes me suspect that in streammanger there is a bug in isBusy() (a false positive) - I assume that the sdk layer is reporting correctly that HasStreaming is TRUE
if (HasStreaming() && Streamer->isBusy())
LOG_ERROR("Cannot take exposure while streaming/recording is active.");
Indi Control Panel consistently reports that streaming and recording is OFF and there is no streaming window open, so somehow Streamer->isBusy() must be returning TRUE randomly on system initialization (as above start the profile, when teh two cameras connect use indi control panel to execute the 1 second default exposure via the set button on main tab - result can be either both cameras hit this error, one or sometimes neither in whihc case all is OK to go for normal operation - I am currently getting on 1 out of 5 starts that are GOOD!!!!!)
Anyone able to help on this? - it is making things almost unusable - I went o github to see if I could debug the driver but where there used to be all the CCD drivers there is now only the simulator....am I missing something....This issue appear to happen more with my QHY294 than the QHY183 - after a random number of disconnect all devices then restart the profile I will get lucky and both cameras will take an image -
This is an odd one and a bit random (nothing to do with actually shooting through two cameras) - I have QHY183 and QHY294 - Both are recognized and operate but recently (INDI 1.8.9) on connection of all the devices, one or both of the cameras are being reported by INDI to be in streaming mode and you cannot take a regular test image due to an error in the INDI control panel:
1) both cameras connect - using the same driver - and both have normal configuration files properly populated
2) all settings in control panel indicated normal setup and NOT that the camera(s) is streaming
3) logs indicated no issue except the "cannot capture while the camera is currently streaming" error
4) if you try to capture a simple preview in the main camera window you see "aborted" and to see the INDI control panel
5) disconnect devices and restart in the EKOS window (play the profile) can correct the problem
Since it takes a restart of the INDI server I suspect this is some race condition and on the second or third try to load the driver the correct state of the camera(s) is obtained - once they can both take a preview all is good. It is also somewhat random...there have been many cases where both cameras are fine on initial run. I have also tried doing a manual connect for each device but still get the same issue.
If there any known issues with two cameras form same manufacturer perhaps?....
Thanks in advance
Hi Jasem and others...I have been trying to kludge a method for doing dual camera operation with a single instance of KSTARS/EKOS and INDI - I have succeed! By making use of the Script Manager in the camera window and using pre_capture to fire a script I have been able to successful use the indi_setprop call to trigger images on tee second camera that fire at the same time as the main camera captures. However note there is a small "feature" (read as possible bug) in the placement of the pre_capture scipt call - currently it lives ins a pre-job setup routine that only executes the script once (unlike its brother post_capture that triggers at the end of each frame capture). So I edited capture.cpp and moved the calls to where they would work on each frame start, commented out the original and removed a call to pre-capture processing in the script verification functions (you will see my changes in the attached) - for my purposes this works wonderfully: things like focus and filter changes,flip and most importantly dither all happen before the call to pre_capture - I have been testing all day with matching images in 2 cameras (both QHY) and getting no issues. I set the image name and target directory in the INDOC control panel for camera 2....I also use basic camera widow to set cooler on to desire temp, then load up a set of sequences for the main camera and point to my simple script with pre_capture:
echo "taking a picture"
indi_setprop "QHY CCD QHY294PROC-4e75.CCD_EXPOSURE.CCD_EXPOSURE_VALUE=300" <<<<<<<you set the camera to what you really have and whatever time you need
echo "command sent"
You set the value to whatever you want in the script but it should be LESS than the exposure of the main camera - for my last tests I have both at 300 seconds and a 2 sec delay in the main EKSO camera window (just in case) - BUT IT WORKS!!!!!
I did not want to push up to git as this is for my personal way of doing things but I think this could be very simple way to handle complex task of dual camera - there is no need for syncing threads as the main camera is performing the task of the intervalometer - fire and forget
I suspect you would want to see teh concept and verify if you need to keep the single-fire in the pre_job area...but maybe not...
Anyway I hope you can check it out and add to a real release that others can use downstream - BTW you can short circuit the original one-time firing of pre_capture by using the script but adding a sequence of 1 image so your JOB has lest say 50 single images - that is klunky but it also works
Enjoy and let me know if you have question - cheers J
was able to revert after rebuild - took a couple of tries and seems stuff was corrupt or locked - back at 3.5.2 + 1.89 indi - will update to latest when it appears in astroberry ppa
Add to that I can no longer build older versions and install them - I am stuck on 3.5.3....WTH....anyone got any good ideas?
Been trying to rebuild - was on a nice stable 3.5.2....latest master and a branched 3.5.2 are BOTH 3.5.3 and both no longer have EKOS - can't find or launch it - is there some weird dependency perhaps on INDI 1.9?...i am running 1.8.9.....this is very frustrating