Thanks Andrew, very useful to know that your ASI works ok along with other devices, all connected directly to the USB ports of the RPi (begin the combined max current 1.2A). So I think I shouldn't have any power problems with my ASI, in my case.

As Christian has pointed, the 0.6/1.2A option switch of config.txt is for RPi2 and RPi B+: www.raspberrypi.org/help/faqs/#powerReqs

I'm performing a test with a fresh install of Ubuntu MATE 16.04.2 LTS (Jasem, is this is the version you have?). It comes with kernel 4.4.38-v7+ (which is also the one originally packaged in Raspbian Jessie, and was also giving the same problems, that's why I upgraded to 4.9.13-v7+). I compiled everything from source as I did on Jessie and began a Focus->Framing capture almost an hour and a half, for now it seems to work ok (even with the flooding of usb reset messages I'm getting in dmesg). I'll report back later.

Thanks to everyone.

Well, yesterday it kept running until I stopped it, after more than 8 hours without issues. I'm waiting for clear skies to test again along with the other devices (main imager, focuser, mount). Meanwhile, I'll run a test again to see if this result is repeatable.
dmesg is flooded with usb reset messages, but according to Yang from ZWO ( zwoug.org/viewtopic.php?f=17&t=6901 ), they are "normal", as a reset is requested by the SDK on each exposure (but it seems to me some rough workaround).
I'm not sure about the differences between Raspbian Jessie and Ubuntu MATE regarding USB management... maybe different kernel compile options.
All in all, this is not reassuring at all, any update (kernel, sdk, etc) could break it.

A last update, as I've repeated the test (Focus -> Framing) several times. results summarize as follows:

* exposure < 1 second: get frequent ASIGetExposureStatus failed (0) (every other exposure if I set 0.5 seconds) , first retry seems to work. I guess any momentary load on the system could lead to reach max retries and then failure. I guess this is not surprising as long as the SDK is resseting the USB communication on each exposure.
* exposure >= 1 second: no fails whatsoever for 8-9 hours on a freshly booted RPI. But in one test I did without rebooting before starting the Focus->Framing sequence, it "freezed" (no response to StartExposure, as described in the opening post) after 9 hours.

So these results may be considered just enough for guiding, provided that the RPi is booted before each night session. But also may be considered as enough reason to return the camera to the provider.

Unfortunately I didn't have yet the opportunity to perform an actual test guiding and imaging due to bad weather.

FYI: my two Rpi 3 both default at 600mA so i had to reset the max_current value to 1 to enable 1.2a. Always worth checking.

It seems that max_usb_current=1 has no effect on RPi3, it is hard-wired to provide 1.2A max.
www.raspberrypi.org/forums/viewtopic.php?p=930695#p930695
www.raspberrypi.org/help/faqs/#powerReqs
Anyway I also ran a test with max_usb_current=1 before finding that information and got the same results as I reported on the opening post.

I replaced the SDK manually to the most recent version 6.0110. See if that helps.
zwoasi.com/software/

I compiled the driver from git, which already has SDK v0.6.0110 as Jasem commented in his commit (also checked by binary comparison).
Thanks.

Hi all,

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?

Thank you.
Piero

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

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

Hi 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).

Not very helpful, I guess, just to let you know.

Best Regards.
Sergio

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