upekux/README/datasheet

	=================================================================================
	================================   ATTENTION!   =================================
	=================================================================================
	=                                                                               =
	=             0483:2016 STMicroelectronics Biometric Coprocessor                =
	=             This driver was written to work on Sony VGN-UX1XRN.               =
	=          Testing and debugging was carried out only on this model.            =
	=                                                                               =
	=================================================================================

	This is a kind of datasheet. I tried to fill in all the necessary information here
	to work with the fingerprint scanner. Please note that the information was obtained
	mainly from the Wireshark program by intercepting and analyzing packets over the 
	USB bus, which are transmitted by the original driver from under Windows. 
	Therefore, the information may not be accurate. Some of the information was taken
	from the source code of the libfprint and thinkfinger projects.
	
	Apparently, even though the VID:PID matches of the fingerprint scanner, they have
	a different fingerprint coprocessor and scanner, so the driver may not work with
	all models.
	
	Also see: 
		file> lsusb_output
		file> pgm.html
		site> http://netpbm.sourceforge.net/doc/pgm.html
	
	=================================================================================
	=============================   PROTOCOL OVERVIEW   =============================
	=================================================================================
	
	The general model of communication between the host and the scanner resembles the 
	usual OSI model:
	
		Commands and data are transmitted over the messages.
		Messages are transmitted over the packets.
		Packets are transmitted over the USB bulk transfers.
	
	Packets and messages have auxiliary fields, such as length, flags, etc. Big message
	may be spit into several packet and big packet may be split into several USB bulk
	transfers. I noticed that in the packet header the data is in big-endian byte order, 
	while in the message headers and message body the data is in little-endian byte 
	order. This is another similarity with a regular network.
	
	Communication between the host and the scanner takes place using USB bulk endpoints.
	Here is a description of USB endpoints:
	
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
	
	Note that these endpoints has wMaxPacketSize is 64 bytes. Therefore, large packets
	must be received and transmitted in parts of 64 bytes.
	
	=================================================================================
	===============================   PACKET FORMAT   ===============================
	=================================================================================
	
        <PREFIX>             <HEADER>
   0x43 0x69 0x61 0x6f    0xAB 0xCD 0xEF    <MESSAGE>    <CRC>
   -------------------    --------------    ---------    -----
           |              |                  |             \
    =================     |     =======================     ======================
    = "Ciao" prefix =     |     = Body of the message =     = UDF-CRC16 checksum =
    =  ( 4 bytes )  =     |     = ( <LENGTH> bytes )  =     =     ( 2 bytes )    =
    =================     |     =======================     ======================
                          |               
             ===============================
             = 0xAB - <TYPE>   ( 1 byte )  =
             = С   - <COUNTER> ( 4 bits )  =
             = DEF - <LENGTH>  ( 12 bits ) =
             ===============================

<PREFIX>
	It is string "Ciao". All packages start with this prefix. 
	Note that the prefix is not null-terminated.

<TYPE>
	Indicates the type of packet. See "SERVICE MESSAGES" chapter.

<COUNTER>
	When the host sends a command to the device, this field is used as a counter. 
	It starts at 0 and increases by 1 with each new command. After reaching the 
	value F, the counter is reset to zero and starts from 0. When the device responds 
	to a host request, the value of this counter remains the same as in the request.
	
	An interesting fact: during the experiments, I tried to increase the counter 
	value by more than 1. The sensor did not perceive this as an error. When I 
	tried to send requests without changing the counter value, it led to an error. 
	From my experiments, I conclude that with each request, the value of this field 
	must be changed, the value of the field itself does not matter.
	
	Also see "SERVICE MESSAGES" chapter.

<LENGTH>
	The length of the <MESSAGE> in bytes. Big-endian: D - MSB, F - LSB.
	It looks like the maximum packet length is 2043 bytes (this is not a typo).

<MESSAGE>
	Message body <LENGTH> bytes long. The message format is described below.

<CRC>
	UDF-CRC16 checksum. Calculated for the entire packet, excluding the prefix and CRC.


	After sending a command from the host, the device responds with another message 
	indicating the completion of the command, including any requested data.

	=================================================================================
	=============================    MESSAGE FORMAT   ===============================
	=================================================================================
	
	This section describes the format of messages when the <TYPE> field of the 
	package = 0. When the driver is sending commands as above, and when the device 
	is responding, the <MESSAGE> seems to follow this structure:

      <FLAG>    L1 L2     <STATUS>     <SUBCMD>       <MSGDATA>
      ------    -----     --------     --------       ---------
    ( 1 byte )    |      ( 2 bytes )  ( 1 byte )        data
                  |
              <MSGLEN>
             ( 2 bytes )


<FLAG>
	If the entire message fits into 1 packet, then this field will have the value 0x28.
	If the message is too large to fit into one packet, then it is split into several 
	packets. In the first packet, this field will have the value 0x2c. If the packet 
	is not the first and not the last, then this field will have the value 0x24. In 
	the last packet, the value of this field will be 0x20. If the message is split 
	into several packets, then to receive the next packet, the receiving side must 
	send 1 byte with the value 0x30 as a response to the command.
	Note that the <MSGLEN>, <STATUS> and <SUBCMD> fields are only present in the 
	first packet of the message. If the message is divided into several packets, then
	the remaining packets contain only <FLAG> and <MSGDATA>. 
	

<MSGLEN>
	Length of <STATUS> + <SUBCMD> + <MSGDATA> in bytes. 
	Little-endian: L1 - LSB, L2 - MSB.

<STATUS>
	If the request is executed without errors, then this field has the value 0x00 0x00.
	If an error occurs, then there will be a nonzero value.

<SUBCMD>
	Subcommand. In the device's response to a command, the subcommand code will be 
	unchanged. The description of most of the subcommands, the purpose of which I was 
	able to understand, is given later in this document. Subcommand list:
	
		0x01, 0x02   FLASH MEMORY ACCESS
		0x0b, 0x0c   RAM ACCESS
		0x0e         IMAGE CAPTURE
		0x10         UNKNOWN ACTION 1
		0x12         TOUCHPAD MODE
		0x15         IMAGE QUALITY
		0x16         IDLE MODE
	
<First byte of MSGDATA>
	I noticed in this field a certain pattern that fits in most cases. When the 
	host sends a request to the scanner, it usually sets the value here so that 
	MSB = 0 and LSB != 0, for example 0x02. When the scanner responds to a request, 
	it increments this field by 0x10. For example, for a 0x02 request, the scanner
	will return a 0x12 response.

	=================================================================================
	==============================   CONTROL REGISTER  ==============================
	=================================================================================
	
	The control register is accessed via the USB control endpoint.

Read control ( 8 bytes )
	bmRequestType 0xc0
	bRequest      4
	wValue        0
	wIndex        0
	wLength       8


The control register is 8 bytes in size:
	<ZEROS> <STATE>

<ZEROS>
	The first 4 bytes are always 0x00.
	At least, in my experiments, I did not see any other values here.

<STATE>
	The last 4 bytes indicate the state the finger scanner is in. Here are some of 
	the values that I was able to see and roughly understand their meaning:
	
	on power on:
		{ 0x40 0xb0 0x00 0x30 }
	
	after init cmd 0x0400:
		{ 0x40 0xa8 0x00 0x30 }
	
	in idle state:
		{ 0x00 0x80 0x03 0x30 }
	
	on swiped in idle mode
		{ 0x40 0xa8 0x02 0x30 }
	
	There are some other possible values, but I'm not 100% sure what they mean, so 
	I'm not listing them here. Full list in the protocol.h.

Write control ( 2 bytes )
	bmRequestType 0x40
	bRequest      12
	wValue        0x0100
	wIndex        <CMD>
	wLength       1
	data          { 0x00 }


<CMD>
	0x0400 reset and init
	0x0601 wake up
	0x0602 go to idle

	=================================================================================
	=================================   INTERRUPT   =================================
	=================================================================================
	
	The fingerprint scanner has an interrupt IN endpoint, here is its description:
	
		bLength                 7
		bDescriptorType         5
		bEndpointAddress     0x83  EP 3 IN
		bmAttributes            3
		wMaxPacketSize     0x0004  1x 4 bytes
		bInterval              20
	
	Thanks to this, host do not need to constantly poll the scanner, instead, host can
	send an interrupt request and wait for a response. I noticed that when an interrupt
	occurs, it returns the 4 low bytes from the control register. In some cases, this
	can eliminate the need to request data from the control register. 
	
	When the scanner is in standby mode, it can detect touch. When this happens, the
	scanner will return an interrupt with the following data
	
		{ 0x40 0xa8 0x02 0x30 }
	
	The scanner then automatically tries to scan the fingerprint. This interrupt must
	be handled. If this is not done, then after a few seconds the scanner will reset.
	
	=================================================================================
	============================   SERVICE MESSAGES   ===============================
	=================================================================================
	
	If packet has <TYPE> = 0, then it common packet, and <COUNTER> used as packet 
	sequence counter. If packet has <TYPE> != 0, then it service packet, and <COUNTER>
	must be = 0.
	Types 0x03, 0x04 and 0x05 descibed int the "FINGERPRINT SCANNER INIT" chapter.
	Type 0x0b described in the "TOUCHPAD MODE" chapter.
	
	This chapter describes 0x08 and 0x09 types.
	Sometimes on read data from scanner he will answer with packet like this:
	
		<TYPE> - 0x08, <LENGTH> - 0
	
	Host must be answer this:
	
		<TYPE> - 0x09, <LENGTH> - 0
	
	In most cases, this happens before the scanner actually starts transmitting the
	finger image. I guess one should always be ready to handle packet type 0x08.
	
	In the course of my experiments, I had cases when the scanner hung up and 
	constantly sent a packet with type 0x08. The host must take this into account and
	be prepared to act if the scanner freezes. For example, the host may initialize
	the scanner again.
	
	=================================================================================
	========================   FINGERPRINT SCANNER INIT   ===========================
	=================================================================================
	
	After power on or if something going wrong scanner need to be init.
	
	1) Write 0x0400 to the control register. After that scanner will reset and control 
		register have the value is { 0x40 0xa8 0x00 0x30 }.
	
	2) Read packet from scanner. Packet has be like this:
		type - 0x03, data - { 0x01 0x62 0x30 0x2e 0x32 }
	
	3) Send packet to scanner:
		type - 0x04, data - { 0x01 0x00 0xbc 0x02 0x00 0x00 0x00 0x00 } 
	
	4) Read packet from scanner:
		type - 0x05, data - { 0x01 }
	
	5) After that basic init must be done. Then there are several packages, the purpose
	of which is not completely clear. I'm assuming it has something to do with data 
	encryption, because the contents of these packages change each time. I haven't been 
	able to figure this out, so I just send the packets that I was able to capture with 
	Wireshark and it doesn't seem to throw any errors. This step cannot be skipped as 
	without it, the scanner does not work correctly.
	See protocol.h "3-way challenge-response authentication" comment.
	
	6) See RAM chapter.
	
	=================================================================================
	============================   FLASH MEMORY ACCESS   ============================
	=============================   subcmd 0x01, 0x02   =============================
	=================================================================================
	
	The fingerprint scanner has its own non-volatile memory that can be accessed for
	reading and writing. I have read several different datasheets for different Upek
	products. They mention memory of several hundred bytes and support for external
	memory chips up to 64 kilobytes. In our particular case, the scanner seems to have
	at least 349 bytes of internal memory and 8 kilobytes of external memory.
	In what follows, I will call the built-in memory FB-region, and the external - 
	FC-region. I decided to call them that because it corresponds to the byte value 
	in the command that accesses the memory. Here are the commands themselves:
	
	
	Flash write:
		
		request:   0x01     0x04 <RE> 0x58 0xc4 0x63  L1   L2  0x00 0x00 <DATA>
		answer:    0x01     0x14
		           ----     ---------------------------------------------------
		         <SUBCMD>                       <MSGDATA>
	
	Flash read:
		
		request:   0x02     0x04 <RE> 0x58 0xc4 0x63
		answer:    0x02     0x14  L1   L2  0x00 0x00 <DATA>
		           ----     --------------------------------
		         <SUBCMD>              <MSGDATA>
	
<RE>
	Region. 0xfb (small built-in) or 0xfc (big external 8kb).

L1 L2
	Data length. Little-endian: L1 is LSB, L2 is MSB. I suspect that the next 2 zeros
	are L3 and L4, but I haven’t come across such large values in practice, so I 
	don’t claim.


Details
	Apparently, there is no way to specify a specific address in memory to perform 
	read or write operations. A read operation returns all data in the specified region.
	The write operation overwrites the entire region. After a successful write, the 
	region will contain only the data that was written by the write command. The region 
	can be cleared by writing 0 bytes to it. Also way to clear the memory, which is 
	given to me, is to go into the BIOS and clear the memory from there (yes, there 
	is a corresponding menu item there). At least the original Windows driver writes 
	in large blocks. For example, it overwrites the entire 0xFB region, even though 
	it actually only changes two bytes there.

0xFB-region
	So far I have not figured out what is stored in this area. The intercepted packets
	show the word "TBXLITE". I didn’t go deep into the study of this format. I think 
	I'll deal with it later. I can mention a few here. First: after clearing memory 
	from BIOS, this region is not empty and contains data. Second: at the first boot 
	into Windows, the driver reads this region and overwrites it, changing two bytes.
	Third, this memory always stores 349 bytes of data. I don’t know the exact size 
	of this memory and didn’t check it. I am afraid of disrupting the operation of 
	the scanner. I can also note that the data in this area does not change depending
	on the number of added fingerprints in Windows.

0xFC-region
	This region is about 8 kilobytes in size. This region is clean after clearing
	memory from the BIOS menu. Windows can store fingerprints here. Each fingerprint
	uses 372 bytes. Windows says it can store up to 21 prints. It is not yet clear if
	the scanner can use these fingerprints on its own. I think that any data can be 
	stored in this area without fear of damaging the fingerprint scanner.
	
	=================================================================================
	====================================   RAM   ====================================
	==============================   subcmd 0x0b, 0x0c   ============================
	=================================================================================
	
	I have every reason to believe that this memory is operational, so I decided to 
	call it that. This memory always contains 96 bytes of data. The true meaning of 
	all this data can only be guessed at. The only thing I managed to find out is the 
	assignment of the penultimate byte in this data.
	
	Ram write
	
		request:    0x0b     0x04 0x03 0x00 0x00 0x00 0x60 0x00 0x00 0x00 <DATA>
		answer:     0x0b     0x14
		            ----     ---------------------------------------------------
		          <SUBCMD>                       <MSGDATA>
		
	Ram read
	
		request:    0x0c     0x04 0x03 0x00 0x00 0x00
		answer:     0x0c     0x14 0x60 0x00 0x00 0x00 <DATA>
		            ----     -------------------------------
		          <SUBCMD>                <MSGDATA>
		
	
<0x03 0x00 0x00 0x00>
	It is logical to assume that this is a region of memory, but this is not accurate.
	
<0x60 0x00 0x00 0x00>
	Length of data - 96 bytes.
	
<penultimate byte of DATA>
	This byte somehow affects the operation of the scanner when scanning a finger. If 
	this byte has a value of 0x00, then during a finger scan (subcmd 0x0e), the 
	scanner will report the full set of flags (see IMAGE CAPTURE chapter). The 
	original Windows driver sets this byte to 0x00 only during the registration of a 
	new finger. For the rest of the time this byte is set to 0x01.
	
	
	In general, the algorithm of actions is something like this:
	
		1) During initialization, read all memory and save to buffer.
		2) Change the penultimate byte to 0x01 and write the contents of the buffer to 
			memory.
		3) Before scanning a finger, if you need a full set of flags, set the 
			penultimate byte to 0x00 and write it to memory.
		4) After scanning, set the penultimate byte to 0x01 and write to memory.
	
	=================================================================================
	===============================   IMAGE CAPTURE   ===============================
	================================   subcmd 0x0e   ================================
	=================================================================================
	
	The scanner can transmit fingerprints as a PGM image. Image size is 144x270, 
	38880 bytes, 1 byte per pixel. PGM format is described here:
	http://netpbm.sourceforge.net/doc/pgm.html
	Just in case, I saved that page as an HTML file. There are two ways to get an 
	image from the scanner: wait for an interrupt or explicitly request a scan. Getting
	an image by interruption is described in the section idle mode. This section describes
	polling image acquisition.
	
	Switching the scanner to scanning mode is performed by the following command:
	
		 0x0e    0x02 0xc0 0xd4 0x01 0x00 0x02 <DETECT> 0x00
		 ----    -------------------------------------------
		subcmd                  msgdata
		
	<DETECT>
		The scanner can handle situations where the user is not swiping the finger 
		correctly over the scanner. This flag indicates the mode of operation. If the
		flag is set to 0x00, then this function is disabled. If the flag is set to 
		0x01, then this feature is enabled. Windows uses this when registering a new 
		fingerprint.
	
	After switching to scan mode, the scanner will wait while the user swipes over 
	the scanner. The response from the scanner will indicate the current status:
	
		 0x00     0x20 0x01 0x00 0x00 0x00 <FLAG> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
		 ----     -----------------------------------------------------------------------
		subcmd                                 msgdata
	
	<FLAG>
		The value of this byte allows host to assess the situation and take appropriate
		action. For example, tell the user that he is doing something wrong. Note that
		the set of states returned will differ depending on which value of the <DETECT>
		byte was set when the scanner was put into scan mode. Also see RAM chapter.
		Known values:
			0x00 - Get ready, next response will be with picture
			0x07 - User slid their finger too far to the left
			0x08 - User slid their finger too far to the right
			0x0c - User has not swiped the scanner yet
			0x0b - The quality of the fingerprint is poor
			0x0f - User swiped the scanner incorrectly
			0x1c - User swiped the scanner too quickly
			0x1d - The finger slid strongly horizontally
			0x1e - User swiped the scanner too short
	
	To continue polling the scanner, the host must send the command:
	
		 0x00    0x30 <CONTINUE>
		 ----    ---------------
		subcmd       msgdata
	
	<CONTINUE>
		This field indicates the intent of the host. If the host wants to continue 
		polling, then the value in this field must be set to 0x01. If the host wants to 
		stop polling and exit the scan mode, then this field must be set to 0x00.
	
	
	When something happens, the scanner will send a corresponding response to the request.
	
	When the user swiped the scanner correctly:
		 0x0e      0x12 0xe0 0x97 0x00 0x00 <picture>
		 ----      ----------------------------------
		subcmd                  msgdata
	
	<0xe0 0x97>
		Length of picture in bytes. 0x97e0 = 38880 bytes.
	
	When the scan was canceled during polling:
		 0xe4 0xfb    0x0e     0x12
		 ---------    ----     ----
		   status    subcmd   msgdata   
	
	If the user does not swipe the finger correctly for 2 minutes (timeout):
		 0xe6 0xfb    0x0e     0x12
		 ---------    ----     ----
		   status    subcmd   msgdata
	
	After receiving any of these three responses, the scanner is in normal mode and 
	can process other commands as usual.
	
	=================================================================================
	==============================   UNKNOWN ACTION 1   =============================
	================================   subcmd 0x10   ================================
	=================================================================================
	
	In some cases, after receiving the fingerprint image from the scanner, the 
	original Windows driver fulfills this request. It is not clear what this does, but
	the scanner works fine without it.
	
		request:    0x10      0x02 0x64 0x00 0x00 0x00 0x00 0x00 0x00 0x00
		            ----      --------------------------------------------
		          <SUBCMD>                        <MSGDATA>
	
		answer: 0x00 0x00      0x10      0x12
		        ---------      ----      ----
		        <STATUS>     <SUBCMD>  <MSGDATA>
	
	If success, then <STATUS> will be 0x00 0x00.
	On failed, <STATUS> will be 0xe6, 0xfb.
	Perhaps there are other values of failure, but I have not met.
	
	=================================================================================
	===============================   TOUCHPAD MODE   ===============================
	================================   subcmd 0x12   ================================
	=================================================================================

	The fingerprint scanner can work in touchpad mode. To activate the touchpad mode, 
	send the subcmd 0x12 to the scanner.
	
	request: 0x12      0x02 0xff 0xff 0xff 0xff
	         ----      ------------------------
	       <SUBCMD>            <MSGDATA>
	
	If everything went well, the scanner will go into touchpad mode and the next 
	response from the scanner will correspond to the touchpad protocol ( protocol 
	description below ), otherwise, something went wrong. 

Errors.
	In the course of my experiments, I had unsuccessful attempts to start the operation 
	in touchpad mode. In those cases, I received the following response from the scanner:
		0xea 0xfb     0x12      0x12
		---------     ----      ----
		 <STATUS>   <SUBCMD>  <MSGDATA>
	
Touchpad protocol:
	The response header is always the same:
		<TYPE>   =  0x0b
		<COUNTER> = 0
		<LENGTH> =  6

	<MESSAGE> format is

        0xAA       0x00      0xCC 0xDD     0xEE 0xFF
        ----       ----      ---------     ---------
       <STATE>     <??>      <X AXIS>      <Y AXIS>
       1 byte     1 byte      2 bytes       2 bytes


<STATE>
	This field is a finger detector. Possible values:
	
		No finger            0x00
		Finger is present    0x01
		Tap (as on touchpad) 0x02
	
	In some cases, the value 0x03 appears. I do not fully understand 
	when this happens. Perhaps there may be other meanings here.


<??>
	Unknown field. During my experimentation, I have always seen the value 0x00 here.


<X AXIS> and <Y AXIS>
	Litle-endian signed short ( 0xCC and 0xEE is LSB, 0xDD and 0xFF is MSB ).
	
	Examples of values:
	
		 <X AXIS>    0xCC 0xDD
		swipe left   0х23 0x00  (+)
		swipe right  0xf7 0xff  (-)
		
		 <Y AXIS>    0xEE 0xFF
		swipe up     0x0a 0x00  (+)
		swipe down   0xfa 0xff  (-)
	
	
Touchpad protocol: request
	
	The request header is always the same too:
		<TYPE>   =  0x0b
		<COUNTER> = 0
		<LENGTH> =  1
	
	<MESSAGE> format is:
		<CONTINUE> 
		  1 byte

<CONTINUE>
	A flag that tells the scanner the intent of the host. If the host wishes to continue 
	working in touchpad mode, then it sets the value of this flag to 0x01. In this case, 
	the next response from the fingerprint reader will follow the format described above.
	
	If the host wishes to stop working in touchpad mode, then the value of this flag is 
	set to 0x00. In this case, the fingerprint scanner will return a response to 0x12 
	subcmd:
	
	answer:  0x12      0x12
	         ----      ----
	       <SUBCMD>  <MSGDATA>
	
	=================================================================================
	===============================   IMAGE QUALITY   ===============================
	================================   subcmd 0x15   ================================
	=================================================================================
	
	After receiving fingerprint image from the fingerprint scanner, host can request
	quality of received image. Actually, I'm just assuming that the value indicate the
	quality of the picture.
	
	request:  0x15       0x02
	answer:   0x15       0x12 <QUALITY> 0x00 0x00 0x00
	          ----       -----------------------------
	        <SUBCMD>                <MSGDATA>
	
<QUALITY>
	1 byte. values 0x00-0x64 (0-100).
	Seems little-endian int (4 bytes), but this is only an assumption. In practice, the 
	remaining bytes are always zeros.
	
	=================================================================================
	=================================   IDLE MODE   =================================
	================================   subcmd 0x16   ================================
	=================================================================================
	
	If at the moment host do not need to work with the scanner, then host can send it
	to standby mode. In this mode, it does not need to be polled. It probably also 
	consumes less power in this mode. In standby mode, the scanner can signal a touch
	with a USB interrupt. If such an interrupt occurs, then it must be processed,
	otherwise the scanner will reboot in a few seconds and go into an uninitialized 
	state. The sequence of actions to put the scanner into standby mode:
	
		1) Send the command:
		 0x16        0x02 0xf4 0x01 0x00 0x00 0x02 0x00 0x00
		 ----        ---------------------------------------
		subcmd                       msgdata
		
		2) Write command 0x0602 to control register.
		
		3) Send USB interrupt transfer. Note that a response to an interrupt transfer 
		may return immediately with the following data:
		
			{ 0x00 0x80 0x03 0x30 }
		
		This is fine. In response to this, another interrupt transfer must be sent.
		
	The scanner should now be in standby mode. The scanner can exit the standby mode 
	in two cases: the user touched the scanner, or a command to wake up was sent to 
	the scanner. Here is the sequence of commands to wake up from standby:
		
		1) Write 0x0601 to control register
		2) Read standby command response:
		
			 0x16       0x12 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00
			 ----       --------------------------------------------
			subcmd                     msgdata
		
		In the process of waking up interrupt transfer will return one of the 
		following states:
		
			{ 0x40 0xa8 0x00 0x30 }
			{ 0x40 0xb0 0x00 0x30 }
		
		There is no need to send the next interrupt transfer in response to this 
		interrupt. The scanner can then receive and process other commands as usual.
	
	
	In the event that an interruption occurs, the sequence of actions is weaving:
	
		1) Wait for interruption
		2) If the interrupt returned data not { 0x40 0xa8 0x02 0x30 }, ignore it and 
		send the new interrupt transfer and go to step 1.
		
		3) If the interrupt returned data { 0x40 0xa8 0x02 0x30 }, this means that the
		user has swiped his finger over the scanner and he has data. In this case, the
		procedure is as follows:
		
			> Write 0x0601 to control register.
			> Read standby command response.
		
		If there was an error while scanning, then the answer may be like this:
		
			 0xef 0xfb    0x16     0x12
			 0xe6 0xfb    0x16     0x12 
			 ---------    ----     ----
			  status     subcmd   msgdata
		
		I have noticed that this happens if I touch the bezel without touching the
		scanner itself. If need to go to standby mode again, then follow the procedure 
		that was indicated at the very beginning.
		
		If everything went well, then the answer will be:
		
			 0x16    0x12 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0e 0x97 0x00 0x00 <picture>
			 ----    --------------------------------------------------------------------------
			subcmd                                   msgdata
		
		
		<0x0e 0x97>
			Length of picture. Little-endian. 0x97e0 = 38880 bytes length. 
		
		The image format and commands will be described in the corresponding section.
		Also see "IMAGE QUALITY" chapter. After receiving the image, the scanner is 
		in working mode and can continue to execute commands as usual. If need to go 
		to standby mode again, then follow the procedure that was indicated at the 
		very beginning.