INTRODUCTION:

This camera library is for USB cameras with chip from S&Q Technologies,
which report themselves in /proc/bus/usb/devices as Vendor:Product
0x2770:0x9120, belonging to Class:Subclass:Protocol ff:ff:ff
(proprietary:proprietary:proprietary). 

It could reasonably be suspected that all of these cameras have the same
chip in them, or similar chips from SQ. Several such cameras are listed in
sq905/library.c, and it seems that there are probably more. The two cameras
which I have actually used to develop this driver are an Argus DC-1510, and
a "Gear to Go."

These cameras are very cheap and basic, with maximum resolution 352x288.
Within the class of cheap cameras they have some interesting features
nevertheless. For example, these cameras are able to download 16,232 bytes
in one operation, repeating in order to download a larger image. Thus,
downloading even a large number of pictures is done very quickly. Some
cameras are much slower. On maximum resolution setting, these cameras will
hold 19 or 20 pictures (depending on the particular model and its features).

WHAT CHIP IS ACTUALLY IN THESE CAMERAS? 

The brief answer is that I do not know. There may be more than one chip
involved here. 

The website of SQ Technologies <www.sq.com.tw> lists an SQ905 chip and also
an SQ913 chip, and an SQ915, but no SQ912 at all. The INF file for both of
the camers which I own is called sq9120.inf, and that file lists the
supported devices as 0x2770:0x9120 and 0x2770:0x9130. This information might
lead one to suspect that the chip inside these cameras is actually the
SQ913. However, the byte sequence 09 05 00 26 is used several times in the
initialization sequence, apparently as an address reference point equivalent
to sector zero on a harddrive. This might possibly imply that the chip
inside is the SQ905.  Another possibility, since the "Gear to Go" offers a
feature ("compression") which the Argus DC-1510 does not have, is that the
"Gear to Go" contains a later chip, perhaps the SQ913 or SQ915, which is
backwards compatible with the SQ905, while the Argus DC-1510 contains the
SQ905.

There is also the reasonable suspicion that the 0x2770:0x9130 device could
easily be supported by this driver, too. I do not have access to one of
those cameras. 

An inquiry to SQ Technologies about information and the data sheet on the
chip in the 0x2770:0x9120, for the purpose of developing a Linux driver for
the camera, has not been answered. All development of a driver, therefore,
is based on observation of the traffic between the camera and the computer,
conbined with observation of what the camera is actually doing while the
traffic was going on.

WHAT FEATURES DO THESE CAMERAS HAVE, AND WHAT DOES THIS DRIVER SUPPORT?

	FEATURE LIST					SUPPORTED (Y/N/Part)
-- USB connection to computer
-- High resolution 352x288 						
	-- 20 pictures on Argus DC-1510					Y
	-- 19 pictures on "Gear to Go"					Y
	-- 38 pictures on "Gear to Go" if using compression		P
	-- Low resolution 176x144		
	-- 80 pictures on Argus						Y
	-- 76 pictures on "Gear to Go"					Y
	--152 pictures on "Gear to Go" if using compression		P
	-- Both cameras can be used for video capture 			N
	-- Ability to "switch" resolution between pictures 		Y
	-- Ability to download all pictures on camera			Y
	-- Ability to download the first k pictures, where 
		k is less than the number on the camera 		Y
	-- Frequency filter for use in artificial light. Can be set 
	to cancel 60hz or 50hz interference. Done with button-pushes 
	on the camera, not with software.

Notes: 

"P" means that it is currently possible to get raw pictures from the
compressed data, or ppm pictures which do not make much sense of the
original. 

The pictures obtained on the uncompressed settings can quite often
be superior to those obtained using the support for Windows which came with
the camera. 

Video capture is not yet implemented. Perhaps soon?

WHAT FEATURES DO THESE CAMERAS ABSOLUTELY NOT SUPPORT?

1. 	The downloading of "thumbnails" as special files is totally 
unsupported by the hardware. What, then, does the manufacturer's supplied 
driver program do? 

What that supplied software does is only to give the option to download any
consecutive sequence of photos which are on the camera, starting from the
first one. As the download completes, "thumbnails" are created (obviously in
software, on the computer) and displayed. The user may then choose from the
displayed photos which ones he/she wishes to save to a permanent location.

2.	Considering the way the communication protocols of these cameras
seem to work, it would seem quite impossible to copy any data to the camera
for storage and transport. The camera clearly does not have files on it,
only data addresses. And the camera does not keep time. for the same
reasons, it would also seem impossible to delete a photo from the camera by
action of software on the computer. The camera supports two choices for
deletion: delete the last photo taken, or delete all. Each action is
performed by an appropriate sequence of button pushes on the camera.

To find a way around these constraints would indeed be most interesting. Who
knows? Maybe these things can be done. Could be that these chips have
undocumented capabilities.


WHAT FEATURES OF GPHOTO2 AND LIBGPHOTO2 DOES MY DRIVER SUPPORT?

	A short answer to this is, the relevant options of gphoto2 now
appear to function as intended, given the constraints of the camera.  A big
exception is capture, which is not yet supported.


NOTES FOR DEVELOPERS 

1.	The program is set up to put out pictures in PPM format. If you want
raw format, that can easily be put back in. 

2.	 The gamma setting (actually seems to be one over gamma) used for
the construction of PPM image files has been obtained by trial and error. It
seems to work very well for outdoor pictures, but the setting is a
compromise between what happens with outdoor photos and what happens with
indoor photos. Conceivably, the program could support a choice between two
or more gamma settings, optimizing for different conditions.

3. 	To unscramble the "High Compression" setting on the "Gear to Go" or
similar cameras is obviously the biggie right now. 

4. 	Landscape-oriented pictures will come out right-side-up. This is
done by reversing the order of the data, because the picture comes out of
the camera upside-down. Reversing the order of the data also causes the
color mappings to reverse from RGGB to BGGR. If you wish to comment out the
byte-reversal in order to experiment, then please be aware that
you have reversed blue and red, too. 

5. Please get back to me with reports about other SQ cameras, with their
specifications (what it says in the manual about resolution and number of
pictures, as well as make and model would be enough), and with log files. 

6. At this point, I suspect that there are cameras out there which use the
same or very similar controller chips which may use the same initialization
routines but support different resolution settings, such as 640x480 or
higher. Let's be on the lookout for such cameras. 


ACKNOWLEDGMENTS:

	-- to several members of East Alabama Linux Users group, for help
and encouragement:

		Bruce Gray, 
		Darrel Hankerson, 
		Thomas Kilgore (my son, the Perl hacker)
		Kelley Price, 
	for some basic help with C.
		Wade "Bear" Tinney, 
	for help in discovering how to subscribe to the gphoto-devel mailing
	list
	-- to Prof. Stan Reeves, Department of Electrical Engineering,
	Auburn University, for a very informative discussion of how a Bayer
	array is constructed.
	-- to my colleagues 
		Darrel Hankerson, who knows clever ways to pass a character
	string from one function to another
		Steve Stuckwisch, who could explain to me Darrel's
	explanation
	-- to Christophe Barbe, for encouragement
	-- to Lutz Miller, for making me do it right.


WARRANTY? 

	Absolutely not. No warranty. Never. Not responsible for any actual
	or potential damage or consequences to anyone or to the equipment of
	anyone for using this program, whether the alleged damage or alleged
	consequences are claimed to be real, imaginary, direct, collateral,
	for pain and suffering, or are claimed to be inflicted upon any
	"third party" who is not the user or installer of the program. The
	program has been written for my pleasure and to broaden and deepen
	my knowledge of computer hardware and software. The program has not
	been written with the immediate expectation of financial gain or
	profit on my part, nor has it been commissioned for pay. It is
	presumed that any end-user of this program will have access to the
	source code of the program and can judge for himself or herself
	whether he/she wishes to use it or not, or can consult someone with
	appropriate expertise to make such a judgment. 


Theodore Kilgore
07/07/03
