Ohhhhh... ok. I had the same problem with DSLRs and RPi. The USB Bus on is shared (network for example) and is not capable
to cope with the large size of the files. That's my opinion but others using it can confirm. This also happens with dedicated OSC cameras.
Normally there are some options that have to be disabled so you can use it, even on an RPi4 because they are very demanding (Auto-debayer, 3D Cube).
You also have to enable "Limited Resources mode". I have opted with the same decision as you at the time, use the guider.
All this options are on the Fits options configuration, have you tried them?
In that case that's not normal, when I connect the D5500 to the PC it's almost instant. Even my Mac takes about 3 seconds to download.
Are you using USB3 on the PC or USB2?
I have a D5500 and that's normal download time for a 10/100mb/s network speccially using NEF(raw) format. Using Native format is a bit faster but maybe inconvenient
My Canon 550D also did take about the same amount of time.
Now that I have a 1Gbit network it takes about 5 seconds to download my images from my atik to my room.
You must be having the same problems we reported here:
But it seems no solution available. Those problems are persisting for more than 3 years now.
Before loosing my mind I have in the last hours making some other testing and found out some important details on one of the problems, so here's what I found;
First, there are two distinct problems
1 - Frame dimensions - this one has to be solved on the driver / sdk our using ekos / indi panel workaround . So this one stands the same situation as before.
2 - Frame loop hanging:
Now for this one I tried to isolate the problem, without using KStars/Ekos. So I tried using CCDCiel and PHD2 connecting to the latest drivers/sdk and.... voila!!!!
No problems at all stopping the frame loop. I even change binning during capture and still no problems. No matter what I do the camera stays rock solid without hanging.
And there is one important detail I found.
In both applications when I manually stop the loop, the last frame is always downloaded after the stop. That is not happening in Ekos. As soon as you stop the loop, the camera
immediattly hangs, so it seems that the QHY6 does like interrupting the frame download. I remember this also happened to my Atik 420m some time ago and it was corrected
after an update.
Soooooo...... it seems this only happens in ekos. I hope this helps troubleshoot at least one problem.
That would really be the best solution in fact.
Hi! Sorry about that, I sent you a PM.
Hi again and thanks for the assistance. If you wish you can send them my email, it's public you can see it on my profile picture in this thread under my Avatar (Envelope Icon).
Yes I tried several older versions unsuccessful. But the problem is very old, it has 3 years since the first report on the forum! So I think I could go even further in time.
Well I have just made the test with the latest SDK and it seems that qhy6 does not support live frame, here are my results:
nmac@nnnnn-Linux:/usr/local/lib$ ls -al libqhyccd.*
-rw-r--r-- 1 nmac nmac 11648696 nov 19 18:40 libqhyccd.a
lrwxrwxrwx 1 nmac nmac 15 set 16 07:33 libqhyccd.so -> libqhyccd.so.20
lrwxrwxrwx 1 root root 24 nov 19 18:43 libqhyccd.so.20 -> libqhyccd.so.220.127.116.11 -rw-r--r-- 1 root root 3816536 nov 19 18:40 libqhyccd.so.18.104.22.168
nmac@nnnnnLinux:/usr/local/lib$ ldd /usr/bin/indi_qhy_ccd | grep qhy
libqhyccd.so.21 => /lib/x86_64-linux-gnu/libqhyccd.so.21 (0x00007f86e9f60000)
QHYCCD|QHYCCD.CPP|GetQHYCCDSDKVersion|21 10 12 16
QHYCCD SDK Version: V20211012_16
-- qhyccd.cpp param
QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside|numdev set to 0
************************** config file path 22.214.171.124 svn: 11499 ************************************
QHYCCD|QHYCCD.CPP|InitQHYCCDResource|Load ini filePath = /usr/local/lib fileName = qhyccd.ini
Init SDK success!
Yes!Found QHYCCD,the num is 1
connected to the first camera from the list,id is QHY6-M-010aXXXXXXXXXXXX
Open QHYCCD success!
The detected camera is not support live frame.
SDK resources released.
INDI is pointing to a different place: libqhyccd.so.21 => /lib/x86_64-linux-gnu/libqhyccd.so.21
I have already replaced this symlink to the SDK one and the results are exactly the same.
Yes I have already tested the live and still frame samples and they both work without any problems at all.
But INDI problems persist anyway.
I did that test when I installed the sdk manually from QHY also following that PDF file.
Anyway tonight I will test again and post results as asked.
Yes it does. It's the latest. Thanks!
Yes it does try to get the dimensions from the SDK but its getting 0 x 0 filled on INDI Panel.
In my case I am using the latest provided by INDI (21.10.26) but I have also tested 21.9.10 and QHY own version 21.10.12.
They all have both problems.
That's what I was afraid... no response.
In the case of frame dimensions, in spite not being the ideal, the frame size could be set directly and automatically by code on the INDI Control panel UI Fields (the read only ones) as a workaround
or assuming a fixed dimension on the driver code when this dimension returns 0 for this camera model. Or even asking the sensor dimensions like the DSLR Driver.
The hanging after stop problem however is way difficult to debug.