I recently acquired a couple Hawking Technologies HNC230G web cameras. They sound good on paper, but they don’t really deliver the way you’d like. Here’s a list of shortcomings and problems, with a few workarounds. Most importantly, I provide a perl script that will simply download a JPEG image, which is what most of us want to do anyways.
Some Dubious Claims
Not all of their claims about the camera really stand up to scrutiny.
Claim 1: WiFi access. Hawking Tech claims that these guys will do 802.11b and g wireless networking. As far as I can tell, that comes with a few caveats:
- Your wireless network must broadcast its SSID. Many security conscious networks do not broadcast their SSIDs. If that’s your network, you’ll have trouble getting these things onto your wireless network.
- They only support WEP 64 and 128 bits. If you’re using WPA or WPA2, you’re out of luck.
- I had difficulty entering a network name manually (ours doesn’t broadcast) and having it saved right. The installation program lists ‘autodefault’ as the SSID for a manually-entered network. If I enter, for instance, “X” as my network name, then I see “Xutodefault” as the name of the network it plans to join. Well done.
Claim 2: Access control. They claim that you can assign user IDs and passwords so that only certain people can look at your web camera. That’s not really true. Anyone can connect to port 4321 and pull JPEG images off the camera. If you want to do the dumb web interface with it’s Java Applet, then you’ll have to login. If you just want images off the camera, you can bypass that login altogether.
Claim3: View images in a browser. That’s sorta true. You’re actually running a Java Applet in your web browser. This makes me say WTF? Why go to this level of trouble and make it this difficult to use. Why can’t the camera, which already serves up JPEG images on demand, just do it via HTTP? Why this goofy home-brew protocol on port 4321? (not ice that they ignore IANA’s officially assigned port numbers, too).
Claim 4: Movies. Hah! If your idea of a “movie” is clicking reload as fast as you can on a web page, then go get some popcorn and settle in for a show. Although you don’t have to click reload, that’s what’s going on behind the scenes. The Java Applet simply requests JPEG images as fast as it can, and renders them on your screen as fast as it gets them. It’s the illusion of motion. You get 2-3 pictures per second this way. Actual movie technologies (e.g., QuickTime, MP4, etc.) use techniques to deliver less than a full frame every time. They send just the differences between frames most of the time. The HCN230G just sends you full frames of JPEG pictures over and over as fast as it can. Given that it’s inefficient Java, running in a web browser, it can’t pull and render that fast.
Gripe 1: Configuration by lame Windows program. The Windows setup program they give you is really poor. It was obviously shoved out the door as fast as they could write it. How fast? So fast that when you’re picking your wireless network, the installation program says “choose the network to connect your printer server to.” Ooops. We’re not dealing with a printer server here, folks. Furthermore, the Quick Start program and the Administration program are completely redundant. Why write it twice? Do it once correctly, rather than twice half assed. Or for that matter, do it once on Windows and once in Java to run everywhere (MacOS, Linux, etc). The idea that something as primitive as that initialization tool should be written in C or C++ in 2006 is absurd.
Gripe 2: You get 1 IP address that will be used on either the wired or wireless networks. I realize this works fine in most home situations, where your wireless and your wired networks draw from the same pool of IP addresses (typically managed by the same device). But in corporate worlds it is more common that the IP addresses issued on a wireless network will be completely different from the IPs issued on a wired segment. If you set it one way using the wired interface, it will be wrong for the wireless interface, and vice versa.
Gripe 3: I find these things to be really cantankerous and difficult to initialize. I pretty much had to isolate my laptop and the camera at the office, plugging just the 2 of them into a switch all by themselves. After I got it mostly configured, then I connected their switch into the rest of the corporate network. Once I got it configured, I tried hard not to go in and change any settings. They just weren’t reliable enough.
The mystical protocol
The protocol for getting images out of the camera seems pretty straightforward, and dumb. Click this link to download my perl script that pulls images from the camera. It works like this:
- Make a TCP connection to port 4321 (unless you changed it during configuration)
- Send the ASCII characters ‘0110\n’ to the camera.
- Read the data that comes back. The first 2 bytes are the size of the image file. The next 2 bytes can be safely ignored, and everything else is a standard JPEG image.
I think what bothers me most is that there was some programmer with more hubris than wisdom and he (it’s always a guy who thinks like this) thought it would be better in some way to build a goofball proprietary protocol. Nobody in product management cared, noticed, or understood what a collosal waste of time his dumb idea was. Nobody benefits. It’s just totally lame. In fact, as a result of this stupid protocol, the whole access control mechanism goes out the window. If they were pulling images through the miniature web server in the camera, then the images would be access controlled. It’s no wonder that tech companies struggle with products. If this is typical of what your product team has to offer, you’re going to be lucky to sell any at all.