Log All the Fails!

A project log for DCC Hacking

Reverse-engineering Digital Compact Cassette recorders

Jac GoudsmitJac Goudsmit 07/20/2018 at 06:010 Comments

I finally started to do something that I've been wanting to do for over 20 years: use a logic analyzer to figure out how the DCC-175 communicates with the PC. It didn't go so well but I fixed my mistakes. If you want, you can skip this log to go to the next log which will have some juicy interesting stuff (arguably?). If you want to find out how I made a stupid wrong assumption that threw me off for a few days, keep reading. 

---------- more ----------

I had attached the pins of the DCC-link cable to the logic analyzer based on the schematic in the DCC-175 service manual. But instead of the signals I was expecting to see, I got the mess that you can see above. Obviously, that picture makes no sense at all. Lots of spikes, and none of the wave forms look anything like I would expect. It looked like there was a lot of interference, possibly a problem with grounding.

So I back-tracked what I did:

First of all, I had tried to connect the grabbers of the logic analyzer to the right-angle connector that's in the DCC-link plug and connects it to the cable to/from the recorder. Right angle connectors usually have plenty of blank copper and space to clamp the grabbers of the logic analyzer, right?

Well... No. My HP 16500C logic analyzer from eBay is at least 20 years old and most of the grabbers have had their best days. The header on the DCC-link circuit board uses 2mm spacing (not 2.54mm) and the grabbers are just a little too thick, and they don't grab that well anymore either. And though it looks okay in the picture below, doing my project this way was going to be pretty frustrating with grabbers flying off in all directions all the time.

So I had decided I needed something that would be a lot more sturdy. Maybe I could just make something that I could plug straight into the pod of the logic analyzer?

 I soldered some wires to a straight male header from my modest parts bin. I kept the wires short to minimize the chance of interference and/or skewed timing readings.

But the pins kept coming out of the header and then they were a pain to put back.

Let's try again, this time with a right-angle header so the force on the pins is mostly sideways and they hopefully won't come out of the pod. That seemed to solve the mechanical issue, but I still got a lot of that interference and even if I ignored the interference, the signals made no sense. I gave up and didn't have time for the project for a few days.

When I came back, I decided to go back to the drawing board.

The picture above is the part of the schematic of the DCC-175 that shows the computer connector. But I knew the cable is shielded so the shielding is not in the schematic drawing. Maybe I needed to use that as reference ground? But that didn't make sense, since the DCC-link works fine without the shielding attached to anything.

I started doing some measuring with a multimeter, and the first reading was immediately way off: instead of 5V between pin 1 and 10 on the DCC-link circuit board I measured something that wasn't even close. But that didn't make sense: The LED lit up while the circuit wasn't even connected to anything except the recorder. So it was getting 5V just fine, nothing was broken.

I opened the plug on the recorder side of the cable to see if something was loose (and for giggles). Was the ground pin connected to the shield of the cable but not to pin 10, or something? Nope. All the pins of the connector were connected to the cable. The cable is nicely color-coded by the way, and the conductors in the cable was attached in an order that made total sense (if you know the values of the color codes on resistors): black=1, brown=2, red=3, orange=4, yellow=5, green=6, blue=7, violet=8, grey=9 and white=10. 

Wait a minute. 

Once I saw how orderly the plug on the DCC-175 side was connected, I remembered that I hadn't noticed that kind of order and regularity on the other end.

I had completely overlooked the possibility that the connector on the PC end of the cable might not be connected the same way as the other end. I guess I've spent too much time in a world where connectors are mostly connected by ribbon cables where a twist in the wire is always obvious. The engineers who designed the DCC-link plug weren't bound to the order in which the signals were connected to the plug, because it was easy to switch conductors of the multi-conductor wire at assembly time.

That explained a lot: Not only was I using one of the signals as ground reference, I also had pretty much all my wires crossed.

pin number
Wire ColorDCC-link
Pin Number
Signal Name

After I corrected my mistake, the logic analyzer was still showing crappy signals but they made a lot more sense now. 

When I read through the manual of the analyzer, I found out there's a small RC filter in the leads between the pod header and the grabbers. Alright, fine. So I can't plug my jig straight into the pod. But I could detach the grabbers and plug my header straight into the leads that would normally have the grabbers plugged into them. This turned out to be a mechanically secure way to attach everything.

Note, nothing is connected to pin 1 (the 5V power supply of the DCC-link from the DCC-175). I don't need to analyze that. So the black ground lead is now correctly on pin 2, and I made sure the rest of signals were correctly configured in the logic analyzer.

Now all signals started showing up rock-solid on the analyzer, and they started making sense too!

All of the signals are now very clear; there's a glitch on the WAKEUP trace in this picture but I think that's a matter of adjusting the voltage threshold levels on the logic analyzer. It's not very important anyway; it just signals to the recorder that a PC is attached and wants to control it.

I had the analyzer set up so that it triggered on the L3REF signal which is a short pulse to indicate that the start of a PASC data block is coming out of the recorder (or is expected on the input during recording). The data that's coming out of the I2S bus (SBDAO and SBWS)  is what's expected, and the format of the serial data was somewhat of a pleasant surprise; more about this in the next log.

Now that the setup is in a working state, I can get serious with the reverse-engineering project. In the next log, I'll show what I discovered so far and how I'm going to proceed.