...but never dared to ask. Disclaimer: The following information came to me via divine inspiration (not entirely any more). Therefore, it can easily be wrong or a product of my imagination and will be highly unorganized. In particular, neither HP nor Konica have anything to do with this page.
This thing started out in February 98 as a hack for the old PhotoSmart camera (with model number C5340A) and the respective Konica model. In the meantime, Jeff Schaller has fixed it up for the C30, and thus it should work for these newer cameras as well. Of course, Jeff Miller's recommendation to get a compact flash to PCMCIA adapter that allows mounting the C30's flash card is still valid. More details (described as "anecdotal" by Jeff) can be found in a mail he kindly sent me. Uh, and of course there's always gphoto if you prefer a GUI. I've been told that one of the drivers knows how to talk with HP's cameras.
Still with me? Great. If you just came here to look for the downloading software for Linux: Here is a
distribution (now in version 1.1)
I've put together. It doesn't have a configure script (for lack of stuff to check for), but thanks to Brian Goines it has man pages since version 1.1. I'd really like to hear from you if you use this program. Please do read the README.
There's also a DOS port of this program done by Dietmar Segbert. His page on the C200 is here.
To give you an idea of what the limits (and merits) of the camera are, here are a few unscaled (but in part cropped) pictures: me in front of a file cabinet, a forest lane, a few toads, and a cute Orang Utan photographed through a window.
Now and then people ask me about the serial cable that connects the C5340A to a PC (DB-9). Carson Gray had success with the following minimal connection:
DB-9 Mini-8Pin DIN ===== =========== 2 Rx 3 3 Tx 5 5 Grd 4If this doesn't work for you, contact me (because I find it hard to believe you can do without DTR).
This section needs an overhaul badly, but I doubt I'll ever do that.
Every communication with the camera begins with an enquiry. Raise DTR and send the camera an ASCII ENQ (5). If all is well, the camera will answer ACK (6). Afterwards, you can issue commands, still keeping DTR low. Commands are wrapped into data packets.
Data packets, regardless wheter sent from computer to camera or vice versa, have the following format:
| 02 | Payload length low/high | Payload bytes | 03 | Checksum |
Neither header nor tail count into the payload length. The checksum is a sum over all bytes that precede the checksum byte, including length and 03, but excluding the intial 02. Don't ask me what the 03 is supposed to mean. It appears to be 0x17 in the real long data blocks the camera puts the image information into, so it might be some sort of high byte of some weird length, or possibly it's some hint on the contents of the block. For the blocks you're likely to construct it is three.
Within a payload, you have to escape some bytes, namely 2, 0x11, 0x13, 0x1b (obviously), and 0x1d. Escaping is done by prefixing the byte with 0x1b (ESC) and bitwise inverting it. In this way, 0x02 becomes 0x1b 0xfb. Note that this is at the "link layer", i.e., the escaped sequence counts as one byte for the computation of the length bytes and enter the checksum un-escaped.
After you have made sure the camera is there, you may start to issue commands. It usually does not hurt to first go through an ENQ/ACK cycle before starting with commands. After that simply send a data block containing a command and its parameters. If almost all is well, the camera ACKs this (i.e., it sends a 0x06), otherwise you'll see a 0x15. It may well be that the camera later complains about something else, but at least you've got the checksums and stuff right if the camera responds with a 0x06. If you're done sending the command, send an EOT (0x04).
If you reqested data from the camera, it will now send an ENQ (0x05), and if you ACK, the data will come rushing in. It seems the camera will never send more than 0x800 bytes, so usually you'll have to receive more than one packet, and you'll know the camera is done sending data when it answers with an EOT (0x04).
This is one point where I've lazy so far. Expect more to come. Right now I know the following commands:
| Code | Effect | Parameters | Remarks |
|---|---|---|---|
| 8830 | Get picture | 00 00 02 00 <picture number> 80 | |
| 9080 | Set bitrate | 00 00 <code low> <code high> 00 00 | 19200D: 40 38400D: 80 57600D: 100 115200D: 200 |
| 9020 | Inquire status | 00 00 00 00 | The number of pictures the camera has in memory is in Byte 12 of the response. |
| 9000 | Take picture | 00 00 02 00 | Some kind of control block is supposed to be the next command. (see below). |
| 8000 | Delete picture | 00 00 02 00 <picture number> 80 |
A control block for taking pictures I've had luck with is
c0,90,00,00,02,c0,ec,00. I did not do much
research into the meaning of these parameters. All in all, taking
pictures is a muddy business right now (as a matter of fact, the
psmsho routine in psmget is very rough and shouldn't be supposed to
work).
Andreas Hintermüller has done a bit of research into the status block that comes as a response to the 9020 command. Here is what he found:
| Byte | 6 | 09/10 | 11/12 | 13/14 | 16/17/18 | 19/20/21 |
|---|---|---|---|---|---|---|
| Contents | Power Status (2=full) | Capacity of memory card | Number of pictures taken so far | Capacity left in med res pictures | Year, Month, Date | Hour, Minute, Second |
All the words have intel byte order (not because I like it but because the camera seems to use it), i.e. to issue a get picture command, send 0x30 0x88. And of course, everything is radix 16 (that's PC for hex). It's probably safe to expect that the picture indices might as well be 16-bit. However, I don't get 256 pictures onto my memory card, so there's no way to check that.
