I am trying to create an application with remote controlling a Fingerprint sensor (Guide included on link) for enrolling and identifying fingerprints on are Raspberry PI 3 Model. There is a SDK_DEMO for this particular functionality on Windows only, which you can find in the Guile I mentioned above.

  • SDK_DEMO is written in C++ on Visual studio so I can't manipulate the code to run it on Raspberry Pi 3.

From the SDK_DEMO source code I figured out which command I need to send to execute tasks.

The Commands

CMD_NONE                = 0x00,
CMD_OPEN                = 0x01,
CMD_CLOSE               = 0x02,
CMD_MODULE_INFO         = 0x06,

CMD_CMOS_LED            = 0x12,

CMD_ENROLL_COUNT        = 0x20,
CMD_ENROLL_START        = 0x22,
CMD_ENROLL              = 0x23,
CMD_ENROLL1             = 0x23,
CMD_ENROLL2             = 0x24,
CMD_ENROLL3             = 0x25,

CMD_DELETE              = 0x40,
CMD_DELETE_ALL          = 0x41,

CMD_VERIFY              = 0x50,
CMD_IDENTIFY            = 0x51,

CMD_CAPTURE             = 0x60,

CMD_GET_IMAGE           = 0x62,
CMD_GET_RAWIMAGE        = 0x63,

CMD_GET_TEMPLATE        = 0x70,
CMD_ADD_TEMPLATE        = 0x71,

CMD_FW_UPDATE           = 0x80,
CMD_ISO_UPDATE          = 0x81,
CMD_FAKE_DETECTOR       = 0x91,


ACK_OK                  = 0x30,
NACK_INFO               = 0x31,

SKD_DEMO recognised the FingerPrint sensor as Mass Storage and somehow was running the commands like that.

In Ubuntu though when I plug in the usb device I don't get any Mass storage mounting and on lsusb I get this:

enter image description here

I have be searching about this and tried to

echo "0x12" >> /dev/bus/usb/001/008

But I got a write error for invalid argument.

Here are the terminal commands for the echo attempt:

enter image description here

Is there a way I can send raw commands with this format and executing actions without needing to write a driver for this USB device on Linux?

3 Answers 3


I don't think it can work like that. For one thing echo "0x012... sent the literal string of ascii characters 0x12 which is only a base-16 representation of the actual binary data needed to communicate with the device.

Have a look into python perhaps (you could use a lot of other languages to do this as well, however Python is usually a good place to start) and communicating with USB devices. Maybe here: https://stackoverflow.com/questions/44290837/how-to-interact-with-usb-device-using-pyusb


You should write /dev/bus/usb/[vid:pid]. vid and pid are the numbers written near the ID. In your case you can try this command:

echo "0x12" >> /dev/bus/usb/001/2009:7638
  • Welcome to the site. Since your answer is in conflict to remarks in the previous answer, please indicate how your solution addresses this or in what way the other answer is in error. Also, usually the files under /dev/bus/usb are not named according to the VID:PID scheme but rather by bus number/consecutive device number (see e.g.here).
    – AdminBee
    Commented Jan 7, 2020 at 14:09
  • That "0x12" is most likely an ASCII representation of a byte value encoded as hexadecimal. Even if this were the right way to address the device the command is not correct.
    – symcbean
    Commented Oct 12, 2023 at 14:33

The SDK_DEMO seems to use a COM port for connecting to the fingerprint scanner in Windows, and the tutorial indicates that the use of a USB-to-serial converter is the expected way. Since the command set includes both CMD_GET_TEMPLATE and CMD_ADD_TEMPLATE, possibly for reading & writing fingerprint templates to the scanner respectively, it might be that the SDK_DEMO was actually implementing the mass storage emulation.

In your picture of your lsusb listing (BTW please don't attach pictures of text; just copy&paste the actual text if at all possible) the Bus 001 Device 008 device seems to have the USB vendor & product IDs of 2009:7638.

Unfortunately the USB vendor ID 2009 seems to refer to iStorage, and on that vendor, only a few flash drive IDs are known to exist.

On the other hand, the IDs of USB-to-serial converter chips are often configurable, as when such a chip is used as part of a larger product, the vendor of the larger product would wish it to have their own vendor & product codes. So first you must find out if the USB device with IDs 2009:7638 is indeed a USB serial converter with a custom ID, or is it something different.

To do that, please run the command lsusb -d 2009:7638 -v while the device is connected. If the output includes lines like this, it is definitely a USB-to-serial converter:

  bInterfaceClass       255 Vendor Specific Class
  bInterfaceSubClass    255 Vendor Specific Subclass
  bInterfaceProtocol    255 Vendor Specific Protocol
  iInterface              2 USB Serial Converter

But if the device actually provides a USB Mass Storage interface, then the output will include either a bDeviceClass or bInterfaceClass line with the value of 8 Mass Storage. If so, then the device should also appear in lsblk output.

If the USB-to-serial converter chip is a FTDI product (as suggested by the guide you linked), the correct driver module for it is probably ftdi_sio. To load the module and make it aware of the custom IDs:

modprobe ftdi_sio
echo 2009 7638 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

The same strategy can be used with other USB-to-serial driver modules, too; just replace the name of the module in both commands.

If you are unable to identify the correct driver module, please run lsusb -d 2009:7638 -v > /tmp/usbserial-info.txt and edit your question to add the contents of the resulting /tmp/usbserial-info.txt file into it.

If the USB-to-serial driver recognizes the device, a /dev/ttyUSB0 device node should now appear. This would be the device to use for communicating with the fingerprint scanner.

The /dev/bus/usb/xxx/yyy devices like the /dev/bus/usb/001/008 you tried to use are designed to be used with libusb, since they require the application using the device node to be aware of different USB endpoints and USB transfer modes. A single USB device will have at least one control endpoint and may have multiple interfaces, each with multiple endpoints.

The /dev/bus/usb/... device nodes allow the full feature set of USB to be used, but because of this, they are not really usable by scripts; basically these device nodes exist to be a target for specific system calls, not for simply piping data in and out of them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .