Picked up a CueCat barcode scanner at RatShack ("You've got questions.  We've got blank stares.") yesterday along with a few other odds 'n' ends.  If the store actually carried the stuff in their commercial sales catalog, I'd be a happy camper - I don't need an animated Elvis Presley phone, I need a local source of microcontrollers and specialized ICs.  But I digress...

One of the things that has a few people worried is that the clerk at Radio Shack takes down your name and address in their system before giving you your CueCat.  However, there doesn't appear to be a way of tying a particular CueCat to a person at the time of purchase (although Digital Convergence most likely can trace a CueCat back to a particular Radio Shack).  Although each CueCat has a unique serial identifier, each CueCat package has the exact same barcode on the front (which is what the clerk scans in).  My goal was to find where that serial identifier lurks inside the CueCat....
 

Opened up the package (threw away the software, natch - looks like it's available here, anyway) and immediately began to open up the scanner.

Scan of bottom side of PCB (click for full-size image)

Scan of top side of PCB (click for full-size image)

And here are two pics of the board with the shield carefully removed (and the serial EEPROM forcefully removed  :-)

(click on either for full-size image)
 

semiconductor devices:
U1: ATC 93LC46 (serial EEPROM)
U2: Hyundai 90C54-GB189 (OTP/mask microcontroller) - running at 14.7456 MHz
U3: Phillips 74HC373D (octal D-type transparent latch; 3-state)
U4: Utron UT6164JC-15 (15ns asynchronous SRAM, 8K x 8)
U5: Motorola HC4066 (quad analog switch multiplexer)
    or a Phillips 74HC4066D (quad bilateral switch)
U6: TI 271C 04T DH10 ? (under foil wrap - ???)
U7: TI LM358 (dual general purpose operational amplifier)

The component that caught my eye was this small 8-pin device (U1) on the top side of the board:

The scan doesn't really show the markings at all, but it's an ATC 93LC46, which is a 1kbit serial EEPROM.  Unfortunately, ATC doesn't have datasheets for the device available on their page.  Not to worry, as other manufacturers have 93LC46s available, such as Microchip and Holtek.  The datasheet for Holtek's HT93LC46 is located here, and it's a closer match than the Microchip unit, as it implements an ORG pin to control how the memory is accessed (in the above picture, the ORG pin is tied to VSS - this would make the unit addressable by 128 8-bit words if it was actually a Holtek 93LC46, but the ATC unit appears to be setup the opposite way - more on this later...).

A sharp-eyed irrelevant@dm-mm.com commented "Looking at the board pads near the EEPROM it appears they are used during the final test to program in the serial number.  In cuecat2b.jpg the pads to the right show small indentations as though probes had been used to power-up the board and program it during final test."

The first thing I tried was removing the 93LC46 from the board.  However, I'm really not equipped to desolder SMT devices, so this was rather futile.  So I simply soldered some wirewrap wire onto the pins to see what's going on.  I hooked my trusty scope up to them and found that the data is read out of the 93LC46 only on powerup of the CueCat (about 100ms after powerup, to be exact).

After this, I tried hooking up the 93LC46 to a PIC microcontroller (with a little bit of code that I whipped up) to see what lurks inside the serial EEPROM.  Unfortunately, I managed to wipe the contents of the EEPROM (looks like it reads back all locations as 0xFF now).  Oh well, at least I don't have that pesky serial number in there anymore.  :-)

Unfortunately, hooking up a microcontroller to erase the EEPROM is a little out of range for your average privacy-concerned individual.  I'm guessing it should be possible to disable the serial number by cutting the CLK line to the EEPROM, which should be easy for anyone with a keen eye and a sharp X-acto knife.

I'll have to wait until I get another CueCat before investigating what's inside the EEPROM.  In the meantime, I've been looking to find exactly what EEPROM data areas are being scanned.  WIth my trusty Tek TDS 210, I took a closer look at the CS (chip select), SK (clock) and DI (data input) lines.  For those interested, the 93LC46 is an SPI (Serial Peripheral Interface) device - it uses a synchronous serial line to transfer data (your computer's serial port is asynchronous and doesn't use a separate clock line).  The CS line is used to tell that particular chip that it's being talked to, otherwise it will ignore data being sent to it.

Anyhow, the 93LC46 is sent a total of 9 commands (they are all read commands, but more on this later).  The CS line goes high a total of 9 times (the first CS 'pulse' is extremely long, as the CS line goes high as soon as the CueCat is powerd on), and I used this as a baseline to see what was happening on the SK clock line (since my scope has only 2 channels, I can't look at every pin at once).  I noted that there were 27 clock pulses during each CS 'pulse', and I could see a gap between clock pulses where the CS line went high-low-high.  So I hooked up the SK and DI lines to the scope and took a look at exactly what bits were being sent:
 

CS 'pulse'	data clocked in
1	0110000001111111...
2	0110000010111111...
3	0110000011111111...
4	0110000100111111...
5	0110000101111111...
6	0110000110111111...
7	0110000111111111...
8	0110001000111111...
9	0110001001111111...

OK, now the first thing to note is that the leading 0 is basically garbage, as the first 1 is really a start bit (and not yet the beginning of a command).  Also, the trailing 1s aren't really bits sent to the EEPROM - these are clock pulses provided for the EEPROM to write out its data on the DO line.  So what we really have is a command like this:
10000110
...followed by a high DI line.  The first two bits are the command, followed by the address.  In the 93LC46, '10' is the read command.  But what's this?  We only have 6 bits to define the address and a lot more than 8 clock pulses after the command is sent - the EEPROM must be organized as 64 16-bit words!

So, the microcontroller reads in a total of 9 16-bit words from addresses 0x01 through 0x09 (I have no idea why they didn't start at 0x00).  Note that in this sample scan

.C3nZC3nZC3nYCNr2C3fWCNnY.fHmc.C3DZCxPWCNzWDNnX.
        000000001175023101      UPA     040293153502

that the serial ID field is 18 characters long (or 9 16-bit words).  I wonder if they're hiding anything nifty in the other 55 words?  And why did they use a serial EEPROM?  I would think that something like Dallas Semiconductor's silicon serial number would be a smaller, cheaper, totally non-volatile alternative, but maybe this gives DC better control over assigning IDs (perhaps there's a 'special' bar code that can be scanned in to rewrite the EEPROM?).  I'm glad they used a 93LC46, though - you can desolder them and use them for other stuff...

Anyhow, I'm now itching to try disabling the serial ID by cutting one of the traces to the 93LC46 - I don't have a virgin CueCat to try it on, but if anyone wants to give it a shot, cutting any of the traces as shown by the yellow 'cuts' in this photo should disable the serial number (or give floating voltages to really whack out what the microcontroller is reading back - you may even be able to get some 'random' serial numbers generated in this way).

Cuts from top to bottom disable the DI (data in), SK (clock), and CS (chip select).

Or, you can slice this line by the microcontroller to sever the DO (data out) line (I'd be inclined to try this one myself - the floating voltages could be fun here).  Remember - you should only need to cut only one line to disable the serial ID - take your pick.

Thanks to cyberbill@xhub.com for verifying this technique:

" I just de-soldered the DO line(pin 4) of the 98LC46 (left it floating) on my 68-1965 CueCat and it worked great. Instead of getting the serial number, It returns garbage:

.VlY8VlY8VlY8VlY8VlY8VlY8.fHmc.C3DWCNnZDhzXCNf0.

Seems to be constant. They probably have the line pulled either high or low inside the Hyundai chip."

But I'll let the pictures do the talking:

Undersides of CueCats - 68-1965-A on top, 68-1965 on bottom

Scanning 'orifice' - 68-1965 on left, 68-1965-A on right

Innards - 68-1965 on left, 68-1965-A on right

And now for the fun stuff...

Bottom of model A with lower plastic lid removed

Top of model A

Bottom of model A with metal shield removed

Top of model A with metal shield removed

Removing the metal shield from the board is easy - you simply need to desolder 4 different tabs on the plates (desoldering braid works very well for this).

You'll note that the components on the model A have been simplified significantly - there is no more clear plastic lightpipe, the receptor appears to be a much more robust unit, the shielding is much more suited to large production runs (machine-insertable and solderable), there are fewer chips, and the board size has been reduced - certainly a more economical unit to produce.

So, what makes the model A tick?

U1: Toshiba TMP87PH47U (OTP microcontroller)
U2: TI HC4066 (Quad bilateral analog switch)
U3: Intersil CA3140 (BiMOS operational amplifier with MOSFET input/bipolar output)
U4: TI LM324 (Quad general purpose operational amplifier)
U5: ??? S93C4 (serial EEPROM)

Strangely, there are no manufacturer markings on chip U5, and I can find no references to a '93C4' semiconductor anywhere.

The mystery chip

Despite the lack of clues based on the chip markings, I have a feeling that this is a serial EEPROM like the 93LC46 used in the earlier model CueCat, given that

• the package and pin count is the same
• they both have the '93' designator
• pins 1 through 4 (top left to lower left) connect to the microcontroller
• pins 5 and 8 (lower right and upper right, respectively) appear to run to power busses
• pin 6 (next pin up from the lower right) is tied to one of the power bus pins (in this case Vcc), strongly suggesting that it is an ORG pin as on the 93LC46

Also, p_mancuso@hotmail.com pointed me to a very nice site to find chip data:  http://www.hitex.com/chipdir/

Well, let's see if we can in fact disable the serial ID by slicing an appropriate line.  I took a virgin model A (thanks Bill) and first scanned in a barcode to see what the normal output would be:

.C3nZC3nZC3nZCNbZDhf7C3nX.fHmc.C3DZCxPWCNzWDNnX.
        000000000130728002      UPA     040293153502

After this, I cracked it open and decided to chop the DO line as such:

Swiping the unit over the same barcode now yielded:

.BM5UBM5UBM5UBM5UBM5UBM5U.fHmc.C3DZCxPWCNzWDNnX.
decode: Bad data

Aw, poop.  It seems this works a little too well.  Or does it?  I then ran the output through the great Larry Wall's frighteningly compact perl decoder:

#!/usr/bin/perl -n
printf "Serial: %s  Type: %s  Code: %s\n",
    map {
        tr/a-zA-Z0-9+-/ -_/;
        $_ = unpack 'u', chr(32 + length()*3/4) . $_;
        s/\0+$//;
        $_ ^= "C" x length;
    } /\.([^.]+)/g;

and got this:

.BM5UBM5UBM5UBM5UBM5UBM5U.fHmc.C3DZCxPWCNzWDNnX.
Serial: ------------------  Type: UPA  Code: 040293153502

Success!  Apparently the 'validity' of the serial number is entirely dependent on how the particular decoder program processes the encoded string.  (As a note, Michael Rothwell's latest decoder, FooCat v0.1.2 now processes a 'declawed' CueCat string without error)

So, what's next?  Well, I'll be working on adding a button to turn on the unit (thus conserving power for laptop/portable users), I'll add in an enable/disable switch for the serial ID, and I'll be checking the total power draw of the unit (to see if it will work with this little gizmo: Happy Hacking Cradle)  So stay tuned!

"There's another cuecat model amongst the world as well as the two you have on the dissection page.  Though the part number is still 68-1965-A, the sticker on the bottom reads '06A000' in purple ink.  It bears a great similarity to the 05A00, though there are some notable differences.

The top of the unit has two more capacitors: one to the right of the potentiometer (which I recently discovered from a barcode mailing list controls scanning speed), and one to the write of the crystal. The circuit board says (HM+H Rev 1.1) with 016-000370-10208 beneath that, and the crystal says 'S24.000' (which I assume is 4mhz prefixed by a part #).  Etched on the board on the bottom (below the shielding) is "MB-BR338HM R1.1"

The backside is also quite similar, though the CPU appears to be custom now and is encased in a blob of epoxy.  The rest of the back and front appear to be the same (same chips as well), though I don't have my soldering iron handy so I can't check beneath the shield.  The only other difference I noticed with that the circuit board that provides power to the LEDs has "2300" instead of "1700" on it.  Everything else appears to be the same."

Ben followed up with a claification on the potentiometer: "By the by, the current conclusion on the potentiometer is that it controls the gain (which affects the scanning speed in some cases...)"

Stephen Satchell pointed me to his excellent site where he actually dissects the CueCat barcode 'Cue' itself.  If you're wondering how the information is actually encoded in a bar code, check it out: http://www.fluent-access.com/wtpapers/cuecat/index.html

joeynick@one.net sends this rather ironic discovery:
"Here's a slightly amusing lil' tidbitty for ya from Netcraft:
www.digitalconvergence.com is running Apache/1.3.12 on Linux"
...although he notes that radioshack.com is running IIS.  Not terribly surprising, I suppose.

reedstrm@rice.edu pointed out a page showing how to (re)program a 93c[456]6 serial EEPROM using only your parallel port: http://www.unix.cslab.tuwien.ac.at/~ackerman/faz_eep.htm   Now you can change your CueCat serial ID to whatever you want!

And David Forbes notes that DC's EULA (http://www.digitalconvergence.com/ula.html) not only states that the CueCat is only 'on loan' to the user, but also that "you may not reverse engineer, disassemble, modify, rent, lease, loan, sublicense, or distribute the :CueCat reader".  Oops.  In addition, I'm supposed to notify DC "of any information derived from reverse engineering or such other activities, and the results thereof will constitute the confidential information of Digital:Convergence that may be used only in connection with the Software and :CueCat reader".  Well, here's your notification, I guess.  "Your rights under this License will terminate automatically without notice from Digital :Convergence if you fail to comply with any term(s) of this License".  I had rights?  Really?  How very nice of them!  Since my rights are now terminated, I guess they'll be knocking on my door any day now to get their stuff back...

Finally, I've had several inquiries as to how much it actually costs DC to produce a CueCat.  I honestly don't know enough about large-scale electronics production to hazard a guess (though I've heard guesses of around $5 ea.).  If anyone has some actual cost data or thoughtful estimates, I'd be interested to hear it!
 

And now for some more hardware info:
 

Pin	Function	Wire Color ('A' model)
1	data	orange
2	no connection
3	ground	green and black
4	power (+5 volts)	red
5	clock	brown
6	no connection
shell	shield	black and green

Note that the blue and yellow wires don't connect to anything on the mini-DIN connector (though there are traces on the circuit board that go to these pins).

I chopped the red power line on my model 'A' and hooked up my multimeter inline with the unit and found that it draws only 22.5 mA - looks like the Happy Hacking Cradle will work quite nicely after all!  Anybody out there have one for their Palm?  I figure this is a solution just waiting to find the right niche...  (Inventory?  Grocery shopping?)

I managed to get a copy of the datasheet for the Hyundai microcontroller used in the 68-1965 model (the link waaay up at the top of the page for the micro has been updated as well).

Several people have asked how I've gotten such clear high-res pictures of the circuit boards.  Well, I have a prototype Minolta with a custom ground Carl Zeiss lens, a digital camera back and...  Oh, I'm a rotten liar - I tossed the boards onto an HP ScanJet and scanned them in at 600 dpi.  For the regular shots I used an Olympus C-2000 Z (quite a nice camera - only thing I don't like is that it uses these 'SmartMedia' cards instead of the CompactFlash cartridges that normal people use - takes forever to get images off of the floppy adapter...).

Yet more software has been poppoing up lately - Azalea Software has released AzaleaQTools, which is a nice little bundle of software (for both Linux and Windows! with source!) that can be used to create barcodes compatible with the CueCat (which Azalea craftily refers to only as a "recently released free or low-cost scanner").  Nab it at http://www.azalea.com/QTools/

Stephen Wooding has put together some Java classes to handle the data generated by the CueCat (as well as a sample program that utilizes them).  Snag it from http://popbeads.org/Software/CCScan/

I wonder if DC has gotten the idea that they've lost the battle?

Mega thanks go to Sean Kauffman, who supplied these pics of the 07A00:

Note that this version is one of the 'epoxy-blob' CueCats, and it's simply a cost-reduction technique as DC appears to be continually refining and further simplifying the design - it's certainly a cheaper unit to produce in quantity than the original 68-1965!  I'll take a closer look at the pics later and see what can be done to 'declaw' this version...  (anybody got access to an X-ray?)

Several people have noted that DC's EULA seems to be changing as they see fit...  Note that the EULA that is posted at http://www.wizkid.org/cuecat/index.htm and the current EULA at http://www.digitalconvergence.com/ula.html don't quite match up...  Specifically, they added bits pertaining to the CueCat hardware itself, which was originally not even mentioned in the EULA.  Dunno about anyone else, but switching around the EULA as such seems like a really slimy trick.  As Michael Ducy stated, "What license am I bound to?  The one that was up one digital's site when i got my cuecat or the "revised" one?"  Have a look at Michael's site here: http://s1066194.umsl.edu/cuecrap/index.html and the Slashdot story here: http://slashdot.org/article.pl?sid=00/09/18/1129226&mode=thread

Also, I had to grin when I saw the "What's New" heading on DC's main page: "On Sept. 15, 2000, Digital:Convergence Corporation experienced a security breach that may have exposed certain members' names and email addresses.  The company was alerted of breach efforts by Peter Thomas at Securitywatch.com. The company has secured the site and is conducting a thorough security examination."  Although their press release made it sound like they were actively cracked, it was really just a case of being sloppy - they really should know better than to keep user information in a plaintext file easily accessed from their website...

Michael Rothwell was interviewed on Internet News Radio - check his site for the MP3...

David Bilodeau noted that "the code on the bottom is very similar to Radio Shack's own method of date coding the manufacture of its items - 05A00 is May, 2000.  07A00 is July, 2000, etc.  Can't remember what the "A" is but it might just be the May "A" run, and then if they ran more in May it would be 05B00, etc."

Tim Kerby, who hails from Scotland, shares his insights on the actual workings of the CueCat:
"I'm going to try and reverse engineer their microcode and write my own on the PIC microcontrollers.  With a serial eeprom (put to better use) you could make the unit standalone like the expensive symbol readers for home shopping and store barcode scans. Looking at your page my first thoughts were that the cat read into the ram on the early versions at a very high clock rate and decoded from there with the microcontroller but the newer cats don't have the ram.  My other thought is that the analogue switch could be used to gate the input after reading the timing the start character but there is not a constant swipe speed.  Instead it must multiplex the keyboard and cuecat so the keyboard is effectively switched off while the cat enters data.  After closer inspection here is how I think the thing operates (newer model):

• The barcode is read by the optosensor which is very nicely shielded with the metal connector.
• It then passes through a high but variable gain amp and probably a bandpass filter to remove any dc offset and mains hum and also clean any bad printing of the barcode.
• This is then passed to the uC running at a high clock rate and read in to memory.
• The uC decodes from memory and checks the device serial number.
• The keyboard is switched and the data output over the keyboard lines.

And if anyone hasn't seen this goodie yet, here's Pierre-Philippe Coupard's instructions on making a CueCat RS-232 pod.  I was a bit confused from seeing that Pierre hadn't used the clock line in any way, and when I asked him about it he replied: "John Rigby, the author of the original hack, clocked several CueCats at around 8000 bauds quite reliably, so I assume the speed is preset."  Neat hack!  Pierre also cautions that it may not work with all machines: "I can tell you right now that more than one computer will not work with it : the signal that the 7404 spits out is TTL, and so the pod relies on the PC to be able swallow TTL on the RS232 line."

Finally, although I've heard from many happy people that have successfully 'declawed' their CueCat, I have yeat to hear whether or not a 'declawed' unit will still work with DC's software - if anyone has info, please let me know!

Thanks for all the info, additions, and your kind words - this page has been a lot of fun and the enthusiastic feedback makes it all worthwhile!

My, my...  Look who's been showing up in the logs: log capture (207.158.100.67 is dallas.digitalconvergence.com)

Hi guys!  Hope you like the page!

CueCat Mirror List
CueCat Verified Mirroring Sites
CueCat Resources
FooCat BarCode (currently down due to Digital Convergence being idiots)
CueCat Software Spies on You (also mirroring this page)
CueCat Links