Setting up a cat cam with a SN9C102 webcam on Linux

December 15th, 2005

The idea/design goals

The initial (admittedly silly) idea was to be able to keep an eye on newly-resident kittens remotely, while not at home. Ideally on a mobile phone.

Despite the fact I run the niche-but-surprisingly-popular Webcams In Norway, I had never felt the need to operate a webcam myself before. So, I started doing a bit of research into what webcams would do the job. Main criteria were:

  • Works on Linux
  • Can be mounted on a ceiling fairly easily and without doing much damage
  • Physically small and visually inconspicuous (so that it doesn’t look stupid attached to my ceiling)
  • Not too expensive – this is a silly idea, after all
  • Easy to get hold of

After a bit of looking around, it turned out that a common cam is one that comes under a variety of names including “(Microdia) Sweex Mini Webcam” and “Dynamode M6323”. It’s available online here in the UK for as little as GBP7 (about €10), although for convenience I picked one up from a local Maplin Electronics shop for about GBP15. These are tiny cams (about 3cm square) that have a cream case and are on a flexible metal pole (so you can plug it in and then adjust the position) with a USB connector on the end.

Drivers

The first thing to do was to get it working under Linux. Although lots of people seem to have had a bash at writing drivers, there appear to be two open source drivers that are reasonably complete:

  • sn9c102 (included in recent kernels)
  • spca5xx (separate kernel module)

Being built into the kernel and therefore already available, the sn9c102 was the obvious choice. However, I struggled to get it working initially: although plugging the cam in resulted in it being detected correctly (from syslog messages), I couldn’t find any app (xawtv, webcam, gnomeeting, motion…) that could get an image from it; they all failed mysteriously. (I later got to the bottom of this; read on). So I had a bash with the spca5xx driver which seemed OK (all the apps could get an image from it) but a bit dark (I later found this was due to the drivers reading from the cam in “compressed” mode which has a higher frame rate but darker pictures)

Coming back to the snc9c102 driver, it turns out that although the driver is a standard Video4Linux 2 driver, the cam has some kind of weird “colour system” (I’m not an expert here so I don’t really understand the deep technical details) and hardly any apps support it. However, there is a patch (provided by the author of the sn9c10x driver) in the contrib/ directory of xawtv which adds the necessary support to xawtv. (I don’t really understand why it’s not been applied to the main xawtv distribution). With this patch in place, the xawtv “webcam” application then works fine. (The main xawtv app still doesn’t seem to work, and I don’t know why, but I didn’t really care)

Physical mounting

With the software side of things working, it was time to think about mounting the cam. Now, I wanted to install this thing as tidily as possible and with the least material damage to my house, so I didn’t really want to make a hole in my ceiling large enough for a USB connector to pass through. So, as an engineer the natural first thing to do was to dismantle the cam to see what was inside (engineers like dismantling things); the plastic case just clips apart easily revealing the PCB and actual camera inside:
Picture showing interior of the webcam. The front of a small PCB has some surface mount components and the actual camera mounted on it.
Picture showing interior of the webcam. The rear of the small PCB has a crystal, some surface mount resistors and a Sonix sensor chip mounted on it.

The flexible metal post is attached pretty firmly to the rear of the case; you would have to cut the plastic case (probably slightly tricky to do without completely trashing it) to separate the two.

In order to keep damage to the house to a minimum, I wanted to just drill a tiny 2-3mm hole in the ceiling. So, I decided my best course of action was to de-solder the incoming wires from the cam PCB, attach a fresh (long) set with loose tails, feed these through the ceiling into the loft, and reconnect them in the loft to the back of the cam and hence the USB connector. (Actually, it would be nice to completely get rid of the metal stalk and rear of the cam case, but I don’t know of anywhere that sell USB connectors you can easily solder/crimp to loose tails, so I needed to keep the original stalk just for the USB connector attached to it).

It didn’t take very long to de-solder the wires and attach a new set of long (approx. 30cm) loose tails (I just used some telephone wire I had handy):
Image showing the cam PCB with a new set of wires attached to it
The main cam PCB with the fresh set of loose tails

The next thing was to attach some terminal blocks to the loose tails now coming from the rear of the cam housing, so that the cam can be easily connected/disconnected above the ceiling.

Image showing the rear of the cam housing, with the loose wires coming out of the flexible stalk connected to terminal blocks
Rear of the cam housing, with the loose wires coming out of the flexible stalk connected to terminal blocks

Now is probably a good time to get an overview of what we have achieved – below you can see the cam PCB and the rear of the cam casing, connected by a long set of loose tails and a terminal block:

Image showing the cam PCB and the rear of the cam casing, connected by a long set of loose tails and a terminal block

Now all that remained was to:

  • attach the front plastic plate of the webcam to the PCB, with sticky tack
  • push the loose tails through the ceiling
  • attach the cam to the ceiling, with sticky tack again
  • connect the loose tails from the cam (above the ceiling) to the terminal blocks that are connected to the rear of the cam and the USB connector
  • run an active USB extension from above the ceiling, connected to the cam’s USB connector, back down the centre of a convenient wall (stud walls are great)
  • cut a hole in the wall (stud walls are great, again) and install a wall-mounted USB socket
  • connect it all up

Here’s the finished look:

Image showing the cam attached to the ceiling

Configuring the xawtv ‘webcam’ app

With the hardware in place, final configuration of the software was easy. Here’s what I used for my .webcamrc:

[grab]
# I already have a video device on my machine, so the cam becomes /dev/video1
device = /dev/video1

# input was "USB" on older driver versions
input = Camera

# This is the cam's only supported capture size
width = 352
height = 288

# some text for the image
text = CatCam 1 %Y-%m-%d %H:%M:%S

# Capture image every 0.5 second
delay = 0.5
wait = 0

# JPEG quality for saved images
quality = 75

# Rotate the image to make it "portrait" (this suits the position of the cam)
rotate = 3

# Put the image in /path/to/webdir/webcam/webcam.jpeg
[ftp]
local = 1
dir = /path/to/webdir/webcam
file = webcam.jpeg
tmp = uploading.jpeg

End result was a regularly-updated JPEG image of cat cuteness accessible over the web (I already had a local web server set up and running using Apache HTTPD):

Image showing the view from my ceiling over the hall, with cats apparent

Adjusting the gain

The above worked great – when the light was at the right level. However, the cam doesn’t seem to have a built-in automatic gain control (AGC) so as soon as the light gets brighter or darker, the picture gets either dark or washed out. The ‘webcam’ app doesn’t seem to let you adjust the cam’s gain, especially once it’s running, so I needed to find another way. Turns out the sn9c102 driver sets up a sysfs interface that gives you low-level access to the cam’s internal registers, one of which controls the gain. Thus, the following shell commands (with appropriate permissions) let you set the gain from the command line:

# tell the driver that we want to write to register 0x20 (which is the gain register)
echo 0x20 >/sys/class/video4linux/video1/i2c_reg

# write gain value ZZ to the register
echo 0xZZ >/sys/class/video4linux/video1/i2c_val

ZZ is a hex number containing the desired gain.

A simple web interface in PHP allows the gain to be adjusted remotely via a web page.

Recent driver versions

Note that with recent versions of the driver,

  • sysfs support is not enabled by default – you have to compile the driver/kernel with CONFIG_VIDEO_ADV_DEBUG. I’ve written a patch that allows the sysfs interface for the sn9c102 driver to be turned on and off at module-load time via a module parameter called ‘sysfs’.
  • I found it necessary to pass the parameter “frame_timeout=1” to make the ‘webcam’ app work (otherwise it fails and you get syslog messages saying “Video frame timeout elapsed”

Conclusion

That’s about it. All the initial goals were achieved and remote cat monitoring is possible from anywhere in the world, using either a desktop PC or a mobile phone with GPRS and a basic web browser. Although I used this for cats, I suppose it could be a good general security device.

Response to the 2004 European Commission consultation on DRM

September 14th, 2004

This is a response to the 2004 European Commission consultation on DRM, as submitted to the Commission.

Dear Sir/Madam,

In response to the consultation announced on http://europa.eu.int/information_society/eeurope/2005/all_about/digital_rights_man/text_en.htm, I would like to make a number of observations and comments related to the Final Report of the High Level Group on Digital Rights Management.

First of all, I welcome the fact that the Commission is taking an interest in DRM and engaging in discussion of related issues, but would reflect that the Report appears to be based on a number of questionable assumptions about DRM, and fails to take into account the broad spectrum of views about it, including some of those expressed in earlier Workshops. In particular, the Report appears to focus on what the content industry believes to be the problems with DRM, rather than what consumers (who are after all the ultimate enabling force) perceive as the problems. In this response, I hope to clarify my concerns and offer a consumer perspective on these issues.

On the assumption that DRM is required to develop a digital marketplace:

The Report repeatedly discusses the supposed “enabling” functions of DRM. There is a limited observational truth in calling DRM an “enabling” technology, but only so far as noting that large content providers in particular appear to have been reluctant to engage in digital distribution without the perceived “protection” of DRM. However, this evidence alone is not sufficient to merit the implicit assumption that DRM is required in order to enable broader establishment of consumer services. The reality is that many large content providers have not even tried digital distribution without DRM. DRM is not called for, required or desired by consumers; rather, it is something largely being imposed on them by content providers. Thus to start from an assumption that DRM is required to enable growth in consumer services is incorrect. Statements that DRM enables a variety of trading models such as rental and sale are disingenuous; such models have thrived without DRM for a long time even in markets where unauthorised copying and distribution are easy and economically viable. Without substantial supporting evidence, it is just as reasonable to assume that it is reluctance on the part of content providers to engage with their customers in the digital marketplace which is hampering the growth of that marketplace, not the limitations of (or lack of) DRM. To the contrary, the mere presence of DRM can itself hamper the growth of those very markets, due to the inherent consumer-hostile nature of such technology, a point I shall return to later.

On the implicit assumption that the word “Rights” in Digital Rights Management refers only to the “rights” of licensors:

The Report fails to discuss or even acknowledge the long-term consequences of a heavily DRM-based content marketplace. In particular, it places heavy emphasis on the “rights” of content producers, but fails to acknowledge the effect of the balancing rights of consumers and society in general, either in the development of digital marketplaces based on DRM or in the desirability of encouraging DRM at a national or European level. What is necessary is to recognise and take into account the historical context of copyright, which is not an absolute property right but rather an artificial, limited-time monopoly granted by society which is limited in scope and grants certain rights to society as well as to the producers.

Modern DRM systems often rely, to a significant extent, on essentially ephemeral media such as computer storage for license/key management and so on. Indeed, some DRM systems work based on the assumption of the continued existence of and ability to communicate with the content provider. Whilst in the embryonic market, these issues have not risen to the surface, in time there will be an impact when businesses providing DRM-restricted content on such a basis disappear or otherwise cease providing services on the same basis that they did originally. Placing rights management outside the hands of consumers in this way seriously damages confidence when purchasing content.

For example, I am a willing and keen adopter of new online services. I have every desire to participate as a consumer in a marketplace for digital content. However, at the present time the presence of DRM makes that marketplace considerably less attractive than traditional “physical” sales. Consider a compact disc containing music for example: if I purchase a legitimate disc from a retailer, I know that my rights and freedom to use that disc are entirely under my control, constrained only by my obligations under law: once the disc is in my possession, there is no way that the content owner can physically restrict my ability to use it. Similarly, I can use it with any device, from any manufacturer of my choosing, which is capable of playing CDs. However, with digital content hampered by DRM, the content producer may arbitrarily restrict my rights in any number of ways: I may only be able to use specific software or devices (perhaps from a specific manufacturer) which may not even be available to me, I may be prevented from exercising normal rights that I have under copyright laws (for example, related to use of copyright material for the purposes of review or research) and, worst of all, it’s possible (dependent on the DRM system employed) that the content owner might in future be able to prevent my use of the content either by action or omission. (An example of action would be remotely updating a DRM license key to revoke my rights to use the content; an example of omission would be if the content provider went bankrupt and the DRM software was no longer able to verify the validity of my license and consequently prevented me accessing the content). Predictability and interoperability, as identified in the Report, are important factors to consider, but they do not alter the underlying nature of DRM.

What I hope is now apparent is that there is a fundamental contradiction lying at the heart of the Report: that DRM (at least as used and envisaged in the context of mass-produced consumer content) is fundamentally an anti-consumer technology, and yet the Report tries to examine how a marketplace can be developed which is acceptable to consumers, and provide an upbeat assessment of the future. The weak conclusions of the Report serve to illustrate a number of key fallacies that lie at the heart of DRM, which are:

  1. that it is possible to unambiguously define and enforce, technologically, a set of licensing rules for a given work. This is logically impossible within the constraints of what is “reasonable”, primarily because the delicate balance of copyright law requires subjective judgements on human behaviour such as “intent” to be made. A computer or other DRM device cannot do this; it cannot, for example, determine whether the distribution of part of a copyright work falls under a permitted use allowed by copyright law, or whether it is infringing, because the technological steps involved in doing either might be identical.
  2. that it is possible to employ DRM without restricting the freedom of the marketplace or of consumers. For DRM to work, it unequivocally requires consumers to give up certain freedoms, in particular their freedom of choice and control over the playback devices which they possess as well as the content media which they purchase. Even “open” DRM standards ultimately rely on “closed” technology to be effective. This is aggressively anti-consumer, and is a concept irreconcilably opposed to the genuinely enabling tide of technological innovation, openness and freedom which has come about in recent years with the proliferation of digital technology.
  3. that it is possible to solve societal problems (for example, a lack of respect for copyright) with technology. Again, DRM serves to aggravate the situation here rather than alleviating it. Alienating consumers with DRM can only lead to an adversarial relationship between producer and consumer. In a monopoly marketplace (as the marketplace for content mostly is, particularly in the area of films and music) where consumers cannot choose between suppliers, giving consumers a choice between “not purchasing” and “purchasing with unacceptable restrictions” serves only to alienate, annoy and potentially criminalise law-abiding consumers who only wish to purchase content and make reasonable use of it, whilst those who happily deal in infringing materials will continue to do so; the fact that they have to circumvent technological “protection” measures is unlikely to be much of a deterrent.

You will, no doubt, recognise that many of the issues are quite general in nature. Nevertheless, I feel that they are highly relevant in the context of the Report: until these fundamental issues are openly acknowledged and discussed, the lesser issues that the Report identifies such as interoperability, privacy and security, are mostly red herrings; addressing them will only mildly improve the palatability of DRM to consumers, whilst the core problems of the relationship between producers and consumers in a digital marketplace remain unaddressed.

The truth is that DRM is a hugely expensive, intrusive and problematic solution to a largely illusory problem. Contrary to the apocalyptic visions put forward by certain stakeholders, digital media technology, with or without DRM, will not destroy the content industry. Rather than giving legitimacy to DRM, the Commission’s time could be spent more constructively by researching and reporting on business models which harness the power of digital media without requiring such restrictive and adversarial technology, and undoing the damage done by the grossly reactive, imbalanced and ill-conceived European Copyright Directive.

Thank you for considering these views as part of your consultation.

Yours,

Tim Jackson