OK, the similar issue here.
NanoPC T4 with FirendllyDesktop (64bit Lubuntu 18.04). ASI 294 MC Pro
USB2 cable - USB3 port on T4 == Download jam after 7~8 frames
USB2 cable - USB2 port on T4 == OK
USB3 cable - USB3 port on T4 == Download jam after 3~4 frames
USB2 cable - USB2 Hub - USB3 port on T4 == Download jam after 3~4 frames
USB2 cable - USB2 Hub - USB2 port on T4 == Download jam after 3~4 frames, BUT it was OK on once a night!
The USB2 Hub is that on the CEM60, not powered.

I guess the reason is because of power.
USB3 port needs more power and is not very stable with poor AC-IN power.
Multiple USB2 devices will have the same issue above.
Short cable needs less power.
USB2 needs less power.
Connect the guide camera to the USB port on ASI 294 MC Pro instead of the port on NanoPC T4, because the Hub on ASI 294 MC Pro is powered Hub.

I don't have the asi1600 but both mine are also usb3. When I had them plugged into an Odroid-xu4 I could run either one but not both...and the symptom was exactly the same as you are getting, shutter/time down/retry without download. After much t-shooting, I finally rigged them into an rpi3b with usb2 ports and they both worked.
It could still be something weird in the usb3 port hardware, but I also think this could be power related.
Usb3 ports limit current at 900ma, and that adds up, especially when your hot SBC is already drawing 3A(at times) of the 4A recommended. The supply can drop out of regulation and still operate the lower voltage sbc circuits, but peripherals may start acting very strange. It's like apollo 13 on the ground! After researching and testing in the shop, I now recommend more supply for any of the hotter sbc's or busy Observatory/remote setups. I also recommend running a powered hub for all accessories that don't demand a host port to keep current down in the sbc supply.

To fix my problem I just installed a 5A 12v-5v buck converter to run just the Odroid, and then only run the ASI178mm into the usb3 host port on that unit, while the rest is on a separate buck regulator and usb2 ports on an RPi3b/powered hub. I'd seen others going to 2 computers and realized this would give me more isolation as well as a remote desktop for high speed planetary work.

---this rig is currently not quite working, t-shooting right now to figure out why the asi178mm is not found on the network system.

Clear skies!

Ray

All these research are based on our assumption.
So first we should know the software cause that leads to the dead loop of exposing.
Which ASI APIs are called when the expose time goes to 0 of the dead loop.
Then we can figure out which part of the camera is wrong at the time.

We need the help from dev team.
@knro

The driver is hosted here for anyone who wants to take a look: github.com/indilib/indi/tree/master/3rdparty/indi-asi

Exposure timeout is usually related to USB bandwidth or communication issues. I've used two cameras (178 and 120) both exposing and downloading and I never had issues on x86-64 and armhf. Sure there might be a delay when an image is ready is download but the other camera is still uploading the data, but that never caused the exposure to timeout. The timeout is coming from the SDK itself, not the driver.

Hi all, i don't think it is an indi or driver issue.

I think there is something weird going on with Ubuntu and the way is handles USB3.0. Why are there no issues with USB2.0??

Yep. I agree it still could be software, especially when I later tried using a usb3 notebook with plenty of power available as the indiserver. :/ _ forgot i'd done that and it shoots the whole power thing in the foot.

I cut out most of my research steps for brevity, but I guess I should have left more. @knro duplicated the setup I had when I encountered this error, except with a pi instead of a usb3 Odroid and could not reproduce the problem in order to t-shoot it on his end. When I changed to a usb2 pi the problem also disappeared. -- this follows the current theme of usb2 okay usb3 not so much. That said, my asi178mm OR my asi120-s was working fine on usb3 when run standalone.

This thread journals that similar saga: asi-178mm asi120-s must stop one...

p.s. I was able to get an error to show in logs when it failed to download.

For what it's worth, I use an ASI1600MM-C Pro (i.e. USB3) camera together with an ASI120MC-S (i.e. also USB3) on a MinisForum N34 mini-pc running Ubuntu Mate 18.04 without any problems whatsoever. The ASI120MC-S is used as guide cam and it is connected to the USB hub of the ASI1600MM and, yes, that's an USB2 hub. But even when I connect the guide cam to the USB3 hub that is plugged into the N34 it works flawlessly. Ekos downloads the images from the ASI1600 within a second and continues guiding meanwhile. Honestly, I do not think this is a driver or INDI issue because I don't see it. Unfortunately I don't have a clue as to what the real issue may be.


Wouter

My theory is that this issue occurs on some combination of SOC (system-on-chip) hardware and kernel versions. I have experienced USB issues with ODroid before (even with USB 2.0) and it was due to kernel issues. It could be some hardware issue in the board itself, or kernel issue, or a combination of both. Power is usually the first culprit when such unstable operations are encountered but if power is ruled out, then in my opinion, it's SOC+Kernel issue.

Hi all yep I think wouter had hit it on the head. A few weeks ago I did an update to Ubuntu and all of a sudden usb3 worked.

Another update 4 days ago and usb3 is shot again. Usb2 still works.

Only problem is how does one update anything without breaking something.

what did you update, kernel or some packages?
The kernel of these ARM boxes are not updated often.
For packages, you can easily find out which one are related to usb like libusb

I'm running an Intel compute stick amd64 SOC running full Ubuntu 16.04lts desktop. So doing a
sudo apt-get update && sudo apt-get upgrade does everything.

My Asus tinker board in armh and as you say the kernel is not upgraded very often.

New update:

NanoPC T4
USB3 port -> USB2.0 cable -> CEM60 Hub -> USB2.0 Cable -> ASI290 mini
USB2 port1 -> PL2302 USB to COM -> CEM60 com
USB2 port2 -> USB3.0 cable -> ASI290MC Pro

Capture 200S X 12, -12C, with guiding on, works good.

So I can give the result that:
Only true USB 3.0 connection will cause problem.
The USB2.0 cable will not lead to USB3.0 driver working, even on the USB3.0 port.
The MC Pro camera with non-power USB hub will cause problem.
The problem is complexity, it may be some memory leak of the USB3.0 driver, and also the MC Pro camera is sensitive to the USB power.