(29SEP2000 at 15:33 - getting slashdotted, so the page will probably load slowly.  I'll try killing off any unnecessary apps on the server to try and spped things up)
 

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 (which he calls the 'tattooable version'):

#!/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!

Jack Andrews contributed the following scans of his CueCat innards (06A00):

Charles Sullivan sent in these of his 06A00:

Note that it's similar to Sean Kauffmann's 07A00, but Sean's has the designation (FM+H Rev 0.3) screened on the board while the above shows (TM+H Rev 0.3).

Minion has been doing a little work on creating a Win32 decoder - his site is at http://www.jaggedsoft.com/cuedog/

Several people have also confirmed that a declawed CueCat will still work fine with the CRQ software.

Glenn Powers is giving DC hell over the fact that they are sending out unsolicited CueCats via the USPS yet their EULA still claims that the item is on loan...

Wayne Buckhanan passed on his findings on the pinouts of the CueCat mini-DIN connectors:
I have one of the ones you identified as 68-1965, two screws, etc..  I yanked the cord off of mine and checked the wires and I thought at first there were two of the six pins that weren't connected like you reported, then I had a flash of thoughtfulness and ran back and checked the female connector that is the pass through, it has those two lines hooked up as CLK and DATA on the female connector, along with the power and ground.  My guess was that the cue cat inhibits the keyboard from sending data by just twiddling those two lines as appropriate (I've been
reading about keyboard interfacing lately, but it hasn't sunk in far enough yet to tell you for sure that the computer takes the data line high and the keyboard waits for it to stop doing that to start clocking).

Phill K dropped me a line regarding CueCat versions and electronics production:
    You mention that the model A with the toshiba cpu comes after the one with the hyundai cpu. I respectfully disagree.
    I have worked in a large surface mount factory (SMT) that builds many different assemblies for different customers who outsource their production. I worked as a test/QC/production technician and offered suggestions on how designs might be simplified and improved.
    The model A is just that - a model A. The first give away is the cpu choice. The toshiba CPU is more complicated and offers more power, where as the hyundai cpu is a simpler 8051 variant that is going to be cheaper and easier to get. Also, look at how many screws are used to put the back on - 2 versus 4. That makes it quicker to put together (important when you do a large quantity, like millions). The single led and single plastic photodiode with light pipe is going to be less expensive than 2 leds and metal housing photodiode. It is more cost effective to have the strain relief part of the housing than part of the cable. I haven't seen a machine that "inserts metal shields", and am pretty confident that it is done by hand. It would be quicker to tape something on. It is more cost effective/easier to have a single board rather than a separate board for the leds and have to
connect that with wires to the main board.
    But the clincher to the argument has to be the scanning orifice. Take a look at the photos on the web page side by side. The scanning orifice for the "model A" is larger and the housing looks like it was designed for that originally. Looking at the smaller orifice you see that it is half the size but yet the housing is still the same size as for the larger one. Why isn't the housing smaller if it came first?
    The only problem I have with my own argument is the RAM. Because the ram is a pricey part. But chip supplies have been increasingly tight this last year, and it may be that it was more cost effective to have an 8051 plus ram rather than just the toshiba cpu. adding the ram is why there is the 74HC373.
    The Toshiba CPU could cost three bucks. But the 8051 could be $.75, the 74HC373 $.25, and the ram $1.00 (guesstimates), thus you would save $1.00. Take away a led and use cheaper photodiode you save another $.75. Even though the board is a little bigger, the fact that it is a single piece is a big plus.
    It's true that the blob-tronics are a cheaper design. My guess is that this is the "middle version".
    I saw an add in the newspaper for these. On the ad they said they have "10 million ready to ship". That is allot. It is entirely within the realm of
possibility that the have two plants making these simultaneously. The hyundai cpu version made, and another making the blobtronic version. Even if one was more expensive than the other, it might be more important to achieve quantity rather than savings. Another factor is that there are allot of part shortages going around, so if they had two designs, they wouldn't be hung up on production if they couldn't get a part.
    Also, it is clear that they wanted the cuecat to scan _any_ barcode. So while the model As are a simpler design, the addition of a lens in front of the photodiode in the hyundai version probably makes it perform better. And adding the ram gives you a chance to do more work on the scanned data, again increasing performance.
    I could be wrong, but the hyundai version seems like a more refined design. It would be interesting to compare the two to see which one was better at scanning in different conditions with different barcodes, and see which one is more accurate. Like with a bright light shining on the cuecat, as I think this is why there is the black cardboard in the hyundai version. Some mice will stop working with bright sunlight shining on them because light "leaks into" them. I only have the hyundai cuecat, and can't spend too much time on this. But it would be interesting to get other people's thought on this.
 

Sherrod Munday wrote in with some very interesting info on the small 5-pin serial ID chip that is showing up on some CueCat revisions.  Note that U5 is the normal 8-pin 93LC46 and U6 is the smaller 5-pin device that fits in the same spot on the board.

Physical Description and Layout
==============
On the 07A00, U6 is a small, 5-legged device with three leads coming out of one side, and two on the opposing side.  Markings on the image submitted by Sean Kaufmann show L00F, while my unit showed L071.  There are no other identifiers present on the chip.

With the board oriented so that the silkscreened "U6" is right-side-up, the three-legged side is on top, and the two-legged side is toward the bottom of the circuit board. Immediately adjacent to the chip are eight unused pads on the circuit board: they are spaced out to accept a chip the same size as the ATC93LC46 (used on the original model 68-1965).  There are four pads on the right of the chip, and four pads to the left.

Pinout:  I'll use letters, since I can't tell which is pin one on the chip (I know, this isn't very good, but I can't tell anything about the chip).  This layout is given with the PCB in the same orientation as described above -so that you can read "U6" right side up.

A B C
D   E

Pin     Connection
A       To pin 4 of the orientation of U6 on the 68-1965A (Upper right pad, closest to uC)
B       Ground.  It's connected to a Thru-hole that goes through board to ground plane
C       To pin 2 of unused pads beside chip, using pad pinout as described on pin A above
D       (Not connected)
E       To pin 8 and 6 of unused pads. (Lower-left corner, farthest away from uC).  Also connects to +5 VDC source.

So it's apparently a 4-connection device, with 2 for power and 2 for data.

Observations:
==============
I don't see a serial number data pattern on my scope upon power-up.  I do find a clock-type pattern (quite regular) on pin C each time I run a bar code.  The pattern is only present immediately prior to the output generation of the serial data to the computer.  Pin A seems to be used for the serial number output of U6.   I couldn't get a good enough read on my scope to determine its format, though.  Since everything else is so similar to the original 68-1965, I'd be willing to wager it's stored on the chip in the same way.  Both Pin A and C are normally high (+5Vdc), and are pulled low during pulses.  Based on observations, I'd guess Pin A is Data Out and Pin C is Clock.

Therefore, the pinout would be:
DO GND CLK
N/C     Vcc

My only lingering thought is that the chips may have come already pre-serialized prior to installation, and that "N/C" pin really would be Data In.  Of course, if this device allows writing on the Data Out pin based on the voltage present, who knows...

Surgery time......
==============
Since I'm not one to go cutting traces unless it's necessary, I used desoldering braid to simply remove the chip from the PCB.

Results
==============
Cuecat version 07A00 is now declawed.  Fairly simple, yes?

Pre-snip scan
.C3nZC3nZC3nXENv6E3T1CxnX.fHmc.C3r2ENv0ENnXE3DY.

Post-snip scan
.BM5UBM5UBM5UBM5UBM5UBM5U.fHmc.C3r2ENv0ENnXE3DY.

Note that declawed version 07A00 outputs the same S/N as the first 68-1965A that you reviewed.  So apparently, even though they seem to have gone to a custom microcontroller and changed the serial data chip, the functionality is the same.

Out of curiosity, I tried placing the ATC93LC46 chip from my original model 68-1965 into the correct orientation on the 07A00, hoping it would pick up the identity of the older unit.  No luck.

My next project, if I'm daring enough: To Dremel-tool off the epoxy from the uC and find out what it is.  Hopefully I could do this without destroying it...
 

Jack Hintry noted that his CueCat has the same 5-pin chip, but with the inscription 'M00P'.  I'm wondering if the lettering on this device (so far we have M00P, L00F and L071) is shorthand for the serial number contained inside.  Could this be something like Dallas Semiconductor's silicon serial number?

Finally, here's a very simple mod that's perfect for laptop/portable users:

The button is just a small pushbutton I picked up from Radio Shack (while snagging another CueCat, of course).  Snip the power line (red on the 'A') and run wires up to the switch.  Press the button, whisk it past a barcode, release button.  Minimal power draw!  Only problem I've had with it is on bootup - if you don't hold the button down (to power on the CueCat), the BIOS spits out a keyboard error.  This is on a desktop, though - on a portable it would probably be fine.

Michael Rothwell has gotten a reply to the letter he sent to DC's lawyers, but it's just as vague as the first one.  Not too surprising, I suppose.

Checked up on Michael Rothwell's page, and Stephen Satchell has some interesting thoughts on DC's rationale for who to send nasty letters to - it seems that DC may primarily be trying to crack down on software that is used to "establish links between barcodes and Web content".  That is, if your software takes a bar code and fetches a particular web page based on that input, DC gets mad.  Stephen is also guessing that the firmware revision number is embedded in the CueCat serial number - read more here.

But enough about that, back to hardware.  Al Davis (who apparently has some really fun toys at work) was kind enough to bombard his CueCat 07A00 board with radiation in an attempt to see what's hidden under those blobs of epoxy.  Although the resolution isn't quite enough to give much information (you can just barely make out the circular epoxy blobs), it still makes for a very cool picture!

Jack Hintry supplied the following pictures of his board with the mysterious 5-pin serial number device:

Note that Jack has successfully declawed this one by slicing through one of the traces (this is presumably the DO line for this device).  Can anyone identify this mystery chip?

Anyhow, this would seem to invaildate Stephen Satchell's theory that DC's beef is with software, as I've been careful to focus only on hardware.  Look, guys, you don't control the hardware - you're giving it away.  Please grow a clue.

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