Similar issue here with my QHY174GPS (single camera): after the first recording of a stream the warning "Recording device is busy" appears and no further image or stream acquisitions are possible. The behaviour is fully consistent.
Note: in oder to get the camera alive again connect/disconnect of Ekos, or stop/start the driver from INDI web manager, with camera power off/on in between had no effects. Only rebooting the rasp Pi worked.
From the log window:
2021-12-09T08:27:02: [WARNING] Recording device is busy.
2021-12-09T08:26:43: [INFO] Starting video streaming with exposure 0 seconds (50 FPS), w=1920 h=1200
2021-12-09T08:26:37: [INFO] Recording stream has been disabled. Closing the stream...
2021-12-09T08:25:52: [WARNING] Recording device is busy.
2021-12-09T08:25:40: [INFO] Waiting for all buffered frames to be recorded
2021-12-09T08:25:36: [INFO] Starting video streaming with exposure 0 seconds (50 FPS), w=1920 h=1200
2021-12-09T08:25:36: [INFO] Record file is /home/pi/capture/indi_2021-12-09/indi_record_2021-12-09@08-25-36.ser
2021-12-09T08:25:36: [INFO] Starting video record (Duration): 1 secs.
Read More...
Sure, I am certainly on the option n. 3. And I will try n. 1 at the same time.
Who wrote the current QHY driver in INDI?
Read More...
?
I bring up this question again, as I have now this camera and I can offer help to test this feature, if somebody can make the necessary development.
I add that the features for the GPS are illustrated in the section for API programming here:
https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=30&id=190
This is an excellent camera for time-critical applications such as occultations, but the GPS feature is supported only by a windows program at present. INDI would become a great tool for that, if this option was added to the driver.
I really hope that a developer can help!
Best regards
Paolo
Read More...
Hi there
I would like to use the QSI174M-GPS to automate observations of stellar occultations (INDI + Ekos to start with).
Does the current driver support the information coming from the GPS in the camera to time-tag the frames (in imaging and/or stream mode) ? I suppose that the information should go into the FITS or SER file...
Best regards
Paolo
Read More...
I updated today to the last version on ppa and got a systhematic crash of kstars+ekos (segmentation fault).
This happens anytime I try to enter coordinates to slew or sync, in the control panel.
Restarting Ekos (but not the indi server) provides the warning window "sorry, the application indi_lx200generic has stopped unexpectedly".
I sent a report by the button appearing in this window... (who receives it? Jasem?)
Paolo
Read More...
Thank you Camiel and Jasem for having taken care of this driver! It is working much better now. I had cloudy nights recently so not able to test the last modifications. I'll let you know how it works in its last version.
Cheers
Paolo
Read More...
Camiel
I don't know what you modified, but the effect is now very positive!!!!! I made just a short test as it is totally cloudy, but the driver seems now to behave correctly, and communicate with the Pulsar with nearly no glitches.
Did you introduce delays?
I just found a small issue when slewing and at least once (over 3-4 attempts) the slew failed. I found in the log that nearly always the RES to the slew command is not valid at the first attempt. See below. Probably a small detail to tune.
Thank you so much for the good job and the support!
Paolo
SCOPE 177.343233 sec : CMD <#:GR#>
SCOPE 177.451890 sec : RES <00:00:00> (1 attempts)
SCOPE 177.451947 sec : VAL [0]
SCOPE 177.451954 sec : CMD <#:GD#>
SCOPE 177.562886 sec : RES <+00:29:59> (1 attempts)
SCOPE 177.562936 sec : VAL [0.499722]
SCOPE 177.562972 sec : CMD <#:Sr 00:00:00#>
SCOPE 177.673865 sec : RES <1> (attempt 0)
SCOPE 177.673926 sec : CMD <#:Sd -01:00:00#>
SCOPE 177.673952 sec : RES <#> (attempt 0)
SCOPE 177.784853 sec : RES <1> (attempt 1)
SCOPE 177.784913 sec : CMD <#:MS#>
SCOPE 178.456254 sec : RES <0> (2 attempts)
INFO 178.456317 sec : Slewing to RA: 0:00:00 - DEC: -1:00:00
SCOPE 178.563086 sec : CMD <#:YGi#>
SCOPE 178.895871 sec : RES <1> (1 attempts)
SCOPE 178.895933 sec : VAL [1]
SCOPE 178.895946 sec : CMD <#:GR#>
SCOPE 179.005681 sec : RES <23:59:59> (1 attempts)
SCOPE 179.005758 sec : VAL [23.9997]
SCOPE 179.005775 sec : CMD <#:GD#>
SCOPE 179.116608 sec : RES <+00:29:47> (1 attempts)
SCOPE 179.116666 sec : VAL [0.496389]
Read More...
Oh sorry there was it seems another modification? I did not check. Probably I missed it. I update by ppa and test tonight.
Thank you!
Paolo
Read More...
To say the truth, I did not use much filtering for my first driver version.
So the situation is:
- we had a Pulsar 2 driver which was working, but not implementing all options
- we now have a full Pulsar 1 driver (incorrectly called Pulsar 2), implementing most useful features, but not working with Pulsar 2
I see only two options:
- recover the previous driver for Pulsar 2 and keep the present one, renamed Pulsar 1 (but it seems not optimal to duplicate them)
- have a single driver, but recover somewhat the old behavior if the detected device is Pulsar 2
How to proceed? Camiel, can you explain why the driver should now communicate differently with respect to the original ?
Read More...
Hi Camiel
thank you, that's very helpful! I'm not at all a technical programmer (I program more for science work and numerical analysis) so I'm quickly lost with the drivers.
It might well be that some spurious characters are appearing in the answers, and the fact that we are on different versions of the hardware could explain the problem.
Paolo
Read More...