I just bought an ASI120MM-S which I'd like to use on my Raspi3 running Raspbian stretch for guiding.
The camera seems to work rather well, even though I haven't tested it for a long continuous time.
What puzzles me is the slow download time of each image, even if I use very short exposure times (like 0.01s) I cannot get more than one image every 3-4 seconds.
Also, as sergiod already said, at every frame completion I see the "reset high-speed USB device" message in dmesg and, like sergiod, it's hard for me to consider it as normal.
What puzzles me even more is that if I use lin_guider, which doesn't use Indi but has its own ASI driver, the same camera on the same hardware is lightning fast! I can get up to 3-4 frames per second and no "reset high-speed USB device" message at all. And lin_guider uses the same libASI contained in SDK v0.6.
Is there anything I can do to improve the camera performance with Indi?
What actually is the "reset high-speed USB" doing? Is it resetting the USB Traffic parameter to ASI default as a consequence of you setting something different in Ekos? Maybe choose Auto USB Traffic in the Indi Control Panel settings
Skywatcher 190MN - EQ6 Pro (with Belt Mod) - ASI1600MM-Cooled - ASI EFW7 - ASI120MM - WO f4 Guide Scope - Rigel nStep - KStars/Ekos - KDE - PixInsight
Actually I'm not using Ekos as Indi client, but even with ccdciel and phd2 things are the same.
I've also tried Auto USB Traffic but nothing changed, unfortunately.
Thank you
Piero
I may be wrong, but looking at the source code of lin_guider it seems that it uses the SDK "ASIStartVideoCapture" function instead of "ASIStartExposure" , which is the one used in the INDI driver. See asi_core::start_exposure() in lin_guider/src/video_dev/asi_core.cpp and ASICCD::StartExposure in indi/3rdparty/indi-adi/asi_ccd.cpp.
The SDK manual, describing ASIStartExposure says: "Usage: start a single snap shot. Note that there is a setup time for each snap shot, thus you cannot get two snapshots in succession with a shorter time span that these values."
Also, Yang from ZWO confirmed to me that the SDK calls to libusb for a device reset on each exposure ( zwoug.org/viewtopic.php?f=17&t=6901&sid=...7cb64f649d24e#p12521 ); that seems to explain the message we see on dmesg and the "setup time" mentioned on the SDK manual (and hence, the relatively slow performance).
Hi Sergio,
thank you for your thorough analysis, it looks really interesting!
I strongly suspect that what you pointed out (the two different functions used) could explain the huge difference in performance between lg and phd2, what do you think?
Best regards,
Piero