Debian – How to keep USB device (action cam) from going to sleep

debianusbusb device

I've got an action cam (iON Air Pro Lite WiFi). It uses an SD card and can be connected to the PC via USB cable. It comes with only Windows and Mac support. However, once connected via USB and turned on, the cam does show up as a 32 GB Volume (size of the SD) in Nautilus, which let's me edit the cam's config via a simple file and, most importantly, view, copy and delete the actual video files. That's all I need. It works the same on Windows, basically.

While connected and powered on, lsusb shows the cam as:

Bus 003 Device 013: ID 4255:1000 GoPro 9FF2 [Digital Photo Display]

The problem is: connected to my Linux (Debian 9) machine, the cam turns itself off again after only 1 to 10 seconds. If I manage to navigate to the video files folder and start copying a file, then the cam will stay on as long as the copy process is doing its work. Once the file is copied, the cam powers itself off after just a few moments. This does not happen when connected to a Windows machine.

My question is, what can I do to keep the device from turning itself off?
Seeing how this does not happen when connected to Windows and also not while keeping the device busy, I assume there should be a way. However, I really have no idea where to start. My line of thought currently is:

Could be a driver issue. As I have no knowledge about drivers, I wouldn't know how to go from here, unless someone would be holding my hand or could point me to amazing sources.
Maybe there is a way to poll/ping a USB device in some generic way and maybe that would be enough to keep it alive. If so, this sounds like something that could be solved with some code. My current research led me to the GET_STATUS Standard Device Request but that doesn't seem to do the trick (see below).
Worst case, a script that constantly copies dummy files from and/or to the device (or even just renames/moves files on the device) should probably do the trick. I would need to find a way to have it auto-run when this particular device is connected. This option seems feasible, but not very clean (after all, constant read/writes do shorten an SD card's lifetime, and given that a few moments of inactivity can lead to a power-off, these operations would need to run constantly).

EDIT 1: I found PyUSB and wrote a simple script that would send a GET_STATUS to the camera every 2 ms (via the ctrl_transfer function). This did not keep the cam from powering off at all.

EDIT 2: I still haven't found a solution. Also, in about one out of 5 cases, the cam turns off even while copying a file from it. Please share any ideas regarding possible causes and/or solutions.

Best Answer

It may be USB autosuspend.

Look at /sys/fs:

find /sys/devices/ -name autosuspend

And see if the relevant sysfs file contains "1"

Related Solutions

Linux – How to write raw data to a USB device

Usb devices are far more complex than simply pipes you read and write. You'll have to write code to manipulate them. You don't need to write a kernel driver. See http://libusb.info (née libusb.org) and http://libusb.sourceforge.net/api-1.0. This claims to work with Linux, OSX, Windows, Android, OpenBSD, etc. Under Mac OS X there are user-level functions in I/O Kit that will let you access USB. Under Windows, you may be able to use WinUSB, but it's complicated.

Here's a little diagram I drew once to help me understand the architecture of USB:

                 ╭────────────────────────────────────╮
    ┌──────┐     │   device     ┌─────┐  ┌─────────┐  │
    │ Port ├──┐  │            ┌─┤ EP0 ├──┤ control │  │
    └──────┘  │  │ ┌────────┐ │ └─────┘  ├─────────┤  │
              ├────┤addr = 2├─┤ ┌─────┐  │         │  │
              │  │ └────────┘ ├─┤ EP1 ├──┤interface│  │
              │  │            │ └─────┘  │   #0    │  │
              │  │            │ ┌─────┐  ├─────────┤  │
              │  │            ├─┤ EP2 ├──┤         │  │
              │  │            │ └─────┘  │interface│  │
              │  │            │ ┌─────┐  │   #1    │  │
              │  │            └─┤ EP3 ├──┤         │  │
              │  │              └─────┘  └─────────┘  │
              │  ╰────────────────────────────────────╯
              │
              │
              :

Executive summary: every device has an address (assigned by the O/S and subject to change), and up to (I think) 32 endpoints.

Within the device are one or more "interfaces". For example, a web cam might provide a "camera" interface and a "microphone" interface. A multi-function printer would provide several interfaces.

Endpoint 0 is used for control and configuration of the device, and the others are to access the various interfaces. Each interface has zero or more (usually more) endpoints.

Endpoints can be one of several transfer types:

Control Transfers are used to query and configure the device. Every device is required to support a minimum set of control statements. I believe that control transfers are only used with endpoint 0.
Bulk Transfers send or receive data at full bandwidth
Interrupt transfers (I'm not really sure how this is different from bulk transfers; USB doesn't have interrupts). Examples include keyboard and mouse
Isochronous transfers send or receive data at full bandwidth with realtime requirements but without reliability. Used for audio/video applications.

Also worth noting: a USB device can have multiple configurations, which control what interfaces are available and so forth. Changing a device configuration is almost like unplugging the device and plugging a different device in its place.

All of this information is laid out in device descriptors, config descriptors, interface descriptors, endpoint descriptors, etc., which can be queried via endpoint zero.

(Internally, data isn't a stream of bytes, it's packed into packets whose exact formats are part of the USB specification. For the most part, you don't need to worry about this as the controllers and drivers will manage this part for you.)

In practice, depending on your API library and operating system, you'll need to detect the device, read the various descriptors to find out what you're dealing with, optionally set its configuration (if the OS permits), open the interface, and open the endpoints.

For bulk endpoints, you can read and write raw data to them. For control transfers, the API library will provide function calls. I've never used interrupt or isochronous transfers; I'm sure your API library will have the relevant documentation.

More info: "Function" is a collection of interfaces that work together. It's not originally part of the USB spec, and it's up to the device driver to know which interfaces should be grouped together. The USB Working Group has defined device classes which support functions. This is done via the Interface Association Descriptor (IAD).

Best Answer

Related Solutions

Linux – How to write raw data to a USB device

Related Question