The A & B Channels

The A & B Channels Schematic

The A & B channels are identical. The A channel feeds digits to the Tape Time display, and the B channel feeds digits to the Locate Time display.

Unlike the three line S channel, these are four line channels, or four bits if you like, meaning they can generate 16 different combinations of ones and zeroes. The circuit has the same pull-up and spark protection as the S channel, as well as the same Hex Schmitt-Trigger Inverters. The four lines then enter IC2 on the A channel and IC6 on the B channel. These are SN74LS247N chips, which are BCD to Seven Segment Decoder/Driver chips. They take binary-coded decimal (BCD) inputs on four lines and drive a display. We are all familiar with a seven segment display, whether we know the name or not. It looks like this:

The seven segments start at the top, go around the display clock-wise, and end with the middle segment. They are given the designations a, b, c, d, e, f, and g. Let’s say you wanted to make the display show the number one. You would probably turn on the two segments on the right-hand side (b and c) and turn all of the other ones off, giving you this:

Based on our input, this particular chip provides the following outputs:

A or B Input Inverter Output Decoder/Driver Output
A3 A2 A1 A0 A3 A2 A1 A0 Display Value
1 1 1 1 0 0 0 0 0
1 1 1 0 0 0 0 1 1
1 1 0 1 0 0 1 0 2
1 1 0 0 0 0 1 1 3
1 0 1 1 0 1 0 0 4
1 0 1 0 0 1 0 1 5
1 0 0 1 0 1 1 0 6
1 0 0 0 0 1 1 1 7
0 1 1 1 1 0 0 0 8
0 1 1 0 1 0 0 1 9
0 1 0 1 1 0 1 0
0 1 0 0 1 0 1 1
0 0 1 1 1 1 0 0
0 0 1 0 1 1 0 1
0 0 0 1 1 1 1 0
0 0 0 0 1 1 1 1

Not much useful after the number 9, and I doubt the MTR-12 is using any of those.

Everything that happens in the circuit after this chip is actually irrelevant to us, so I am just going to ignore it all.

If I do what I did with the S channel, and remove all of the stuff in between the input and the useful information, I get this:

A or B Input Value
A3 A2 A1 A0
1 1 1 1 0
1 1 1 0 1
1 1 0 1 2
1 1 0 0 3
1 0 1 1 4
1 0 1 0 5
1 0 0 1 6
1 0 0 0 7
0 1 1 1 8
0 1 1 0 9
0 1 0 1
0 1 0 0
0 0 1 1
0 0 1 0
0 0 0 1
0 0 0 0


I did a little bit of analysis with my scope on the S Channel timing. The MTR-12 seems to be changing the state of the S Channel every 640 µsec or so. This means it is changing the state approximately 1575 times per second. That’s faster than I would have thought necessary, meaning every digit is getting updated almost 200 times per second. I guess that is useful when in fast rewind, or fast forward though, as the machine does move pretty fast in those modes. This also means that I have to keep my Arduino code lean enough so that it is long done any processing in a span of less than 640 µsec. I’m not sure if that will be challenging or not. I will have to do some measurements.

The first digit activated by the S Channel is the Sign Digit. On the MTR-12, this is just a minus sign that shows up if you rewind to a point earlier than the point you have marked as zero. I’m not entirely sure what the MTR-12 will be sending for this. It looks like it only has the middle segment (g) connected on that display, so maybe the machine will be sending it a regular digit that doesn’t have the g segment lit, like a 0, 1 or 7, for no sign, and any of the other ones for the – sign. I am going to make a guess that it is probably a 1 for no sign and a 2 for the – sign.

Time to do some experimentation, and some measurements for timing.  Stay tuned…



Being in the right place at the right time…

It turns out that I was close. The MTR-12 sends out a 1 for no sign, and an 8 for the minus sign. You win some, you lose some. Lol.

For testing, I wrote two new routines, Display() and decodeA(), and created four new variables currentA, lastA, currentB and lastB. The variables all have the value ”  -00000″ when the program starts. The first two characters are empty spaces, because the MTR-12 does not use an S value of 0 or 1 to activate any digits, and I am using the currentS variable to determine which position I am going to place a digit. The Display() routine reads the four A pins (A0, A1, A2, and A3) then calls decodeA() with the pin results. It then looks at the character returned and, if the currentS variable is 2 (the sign digit,) it changes an ‘8’ to a ‘-‘, and anything else to an empty space. Any other digit is stored in the currentSth place in the currentA variable. The routine then moves on to reading all of the B pins (B0, B1, B2, and B3) and repeats the above sequence for those, storing them into the currentB variable. currentA and currentB are then compared to lastA and lastB and, if either is different, it spits out the new time. I then started testing this setup…

So, a microsecond (µs) is 1/1,000,000th of a second. That’s 0.000001 of a second. It’s an incredibly short period of time, but it is the increment at which I apparently have to think when it comes to making the Arduino pretend to be an auto-locator.

When I was first trying the Display() routine, all I was getting at the A and B pins was binary 0000, which is all displays off. It took a bit of trial and error to realize that things were happening too quickly for the MTR-12. My decodeS() routine takes around 24 µs to respond to a change in the pin states, completely read all of the S pins, decode the result, and then store that result into the currentS variable. It was then calling the Display() routine, which immediately starts reading the A and B pins. It turns out that 24 µs after the S channel changes, the A and B pins are still not ready to be read. I inserted a 1 µs delay after the decodeS() routine, and before the call to Display(), and started to increase it until I saw the pins were ready with real data. At 20 µs, the pins started to show some changes, but it wasn’t until it reached 50 µs that I started to see real display times coming through. I will make the Arduino do some other tasks, like switches and keypad tasks, in this spot in the future, and see if I can get rid of the need to delay the processing. Leaving an “on purpose” processing delay in a final program makes me twitch a little bit…

To summarize the timing:

  • Interrupt call to decodeS() every 640 (ish) µs
  • Completion of decodeS() @ 24 µs
  • Processing delay of 50 µs
  • Call to Display() function @ 74 µs
  • Completion of Display() (and its calls to decodeA()) @ 124 µs
  • Sit and wait for another 516 µs for the next interrupt call

Like I said before, the Arduino can make some toast and have a little nap between these interrupt events.

After sorting all of this out, I was getting really good data from both the A and B channels, with only one small issue. It was driving me nuts. If you watch the testing video, it should become apparent to you.


The offest:

The MTR-12 has an inherent offset for a connected auto-locator. The point at which the time changes on the auto-locator outputs is actually later than it changes on the machine itself. I thought it was just slow in sending out the time update, but it is definitely doing it on purpose, possibly to allow itself to finish all of the internal processing before it starts to deal with an external device. You can actually rock the tape by hand back and forth over the spot where it changes the auto-locator time, and the time message will be sent each time you cross that line, but the time on the machine doesn’t change at all. At 15 IPS, the length of this offset is 10 inches of tape later than the machine’s time change point. That is almost a full second offset. Strange, but true, and the old auto-locators would have had the same offset. Not really of any consequence to me though. I think I can live with it. If I find it bothers me at all, I will write a routine to correct for it.

So, I have an almost fully working auto-locator. All of the Lamps, Switches and Displays are functioning well. The only thing left to do is fake a working keypad. This may be the trickiest of all, as you will see in the next post. Stay tuned.


Keypad – Part 1

Keypad Matrix

Sorry this took a few days, but I didn’t have a lot of free time to decipher the schematic. I had to go through the schematic and redraw the matrix for the keypad, as it was all very convoluted, spread over a couple of pages, and kind of hard to understand. The above image is actually what the keypad on the auto-locator schematic should look like. It is much clearer now. Since I am not going to have a physical keypad, I will figure out a way to fake having one with the Arduino, thereby (hopefully) getting the functionality of the keypad that can be triggered from MIDI.

The way the keypad seems to have worked is relatively simple. It used the lines decoded from the S Channel so that, when the S value was 0, 1, 3 or 4, those lines were sent to the keypad matrix (S0-S4 in the above image.) The MTR-12 has 8 inputs from the auto-locator (RL0-RL7,) which are the outputs from the keypad matrix. If a button on the matrix was pressed, it would pull whichever output it was connected to LOW during that currentS cycle. For example, let’s say I wanted to simulate the pressing of the ‘8’ key. In the above picture, you can see that I would need to pull RL0 LOW whenever the currentS was equal to 1. If I wanted to simulate a pressing of the Tape Time Reset button, I would pull the RL4 line LOW on every currentS cycle that is equal to 3. I’m not sure why they decided on 0, 1, 3 and 4. That seems odd to me.

Without going into too much detail about the electronic challenges of this circuit, these outputs may be a bit challenging for me. The original auto-locator circuit used SN7407N chips to buffer and drive these outputs to the MTR-12. These chips do several things, one of which is to convert logic levels between TTL and MOS. This isn’t an issue for me, as the Arduino is a CMOS chip. The SN7407N chips are also high sink-current drivers, and I am not sure if the Arduino has enough jam for this. The digital pins on the Arduino that have the best driving capabilities are 10, 11, 12, 13 and 50, 51, 52, 53, so I will be using those for testing this capability. I may end up having to put a couple of SN7407s in-between the Arduino and the MTR-12, which would be fine, as they are currently only $1.20 each at mouser. I have high hopes that I won’t need to do that though, as the Arduino is impressing me, and it has yet to disappoint me throughout this project.

I am going to treat the keypad like I did the switches. I will simulate a key press for the smallest amount of time required to activate the function. This will take a little experimentation, but I need these key presses to happen fast. That way, when the Arduino receives the message “go to 1 minute and 23 seconds,” it can enter the time into the locate in a way to make it seem like it is an almost instantaneous reaction to the command. That command probably requires five key presses, Locate Time Reset, 1, 2, 3 and Search, so the longer each key press takes, the slower the response will feel.

Before I do that, or even just test this rig out, I need to make a command interpreter that is capable of receiving a series of numbers, like the 123 in the above example, turn them into a series of key presses,  which it will then execute in sequence, each one executed after the previous one has finished. This will take a bit of thought. Stay tuned.


Keypad – Part 2

Well, that was a bit of an adventure…

I created a command queue, so that anything coming into the serial port would be added to it, and then executed one character at a time. The next command in the queue would then be decoded once the previous one had finished. I then created a routine to decode the commands and turn them into key strokes on the virtual keypad.

The virtual keypad is basically a two dimensional array. The first dimension is the currentS, and the second is whatever key on that line you want to press. Keypad[currentS] [Key]. For instance, if I wanted to press the ‘5’ key, I would set keypad[0][5] to true. If I wanted to reset the Tape Counter, I would set keypad[3][4] to true (see keypad diagram in previous post.) The routine keeps that key down for as short a time as possible, then automatically sets it back to false again.

Once I had that all worked out, in theory, I started to do some testing. That’s when things got a little weird…

The first thing I tried to do was reset the Tape Counter. The machine went into rewind. I then hit the Search Zero key. Nothing happened. I then entered ‘111,’ and the Locate Time changed to ‘00001.’ I tried ‘321’ and the Locate Time changed to ‘01321.’ That last command made me sit back and scratch my head. I had to really think about all of those commands, and their results. Why had that last one worked, but none of the previous? Then I twigged…

First of all, the damn schematic is wrong. It doesn’t use S values of 0, 1, 3, and 4. It uses, the way more normal, 0, 1, 2, and 3. That made my brain feel better anyway. Once I changed that, I tried the Tape Counter Reset, and it worked like a charm. I hit Search Zero, and off it went back to ‘00000.’

Second of all, I had neglected to add a little ‘off’ time between key strokes. When I had entered ‘111,’ the machine only saw it as one long keystroke. I added a couple of cycles of all keys off at the end of each command execution and, bam!, it all worked well. Silly me. Didn’t even think about that.

On my last attempt, the machine started to ignore a few keys. Specifically the ‘0, 8, Search Zero, and Store 2’ keys. That is all of the keys on the S0 line. After looking at everything, and double checking the logic of my code, I have come to the conclusion that there is an intermittent connection within the MTR-12 itself on that line. I don’t think this machine has ever had a remote control attached to this port, so it isn’t surprising that there is an unknown fault in that section. I will track that down and fix it.

With the known fault, I did the testing for the video without needing to hit any of the S0 keys. In the video, I use the ‘A’ for the Search key, and the ‘B’ for Locate Time Reset. When I enter ‘321A,’ I am really saying ‘321 Search.’ When I enter ‘342-A,’ I mean ‘342, change it to negative, Search,’ so the machine scoots off to -0.03.42. When I hit ‘BA,’ it is basically the same as Search Zero.

Check it out.

Stay tuned.

MIDI Hardware – Part 1

Proof of Concept Summary

I thought I would start this entry by summarising the results from all of the testing for the auto-locator functions being mimicked by an Arduino Mega.

    1. Power – Success
    2. Lamps – Success
    3. Switches – Success
    4. Displays – Success
    5. Keypad – Success

All functions of the old auto-locators can, indeed, be simulated with the Arduino. I am now moving on to the extra bits required to interface the Arduino with our studio control system.

Our system uses MIDI to control external devices, such as parts of our mastering console, and (very soon) our Crookwood Insert Router. The control software is part of our proprietary mastering software, and every controllable part of our setup can be stored into each project’s folder and archived with the project. I will be incorporating the functionality and user interface needed to control the MTR-12 into this software.

It is time to add the MIDI hardware, and see how slow the Arduino gets. I think it should be fine but, if it is too slow to be useful, I will switch from using MIDI for this to using a straight serial, or USB, interface. This would be an easy change in both hardware and software. I would very much prefer to keep it MIDI though. I envision incorporating MMC (MIDI Machine Control) into the final version, so that a change in state or position on the DAW (Sequoia,) causes an identical change in state on the MTR-12. Such as, if I hit play on the DAW, the MTR-12 goes into Play mode or, if I go back to the top in the DAW, the MTR-12 returns to zero.

Parts for the MIDI Input and Output

Parts for MIDI Interface

Conforming to the MIDI 1.0 Specification, and taking into account the way the UARTs are designed on the Arduino, I think that these are all of the parts that I should need to create a functioning MIDI input and MIDI output to interface to the Arduino. I have added these parts and their prices to the Parts List entry in this blog.


MIDI Input

MIDI Input Schematic

The MIDI input is the more complicated of the two interfaces, although it isn’t very complex. It requires a jack, three resistors, a diode and an optoisolator. The diode is there to protect the circuit from a cable that has been wired backward. The optoisolator eliminates the electrical connection between the two devices you are connecting together, but passes the data through. The spec says to use a 6N138, so I am. You can use other ones, but then you have to change/add other components as well, and I have all of these parts kicking around.

MIDI Output

MIDI Output Schematic

The MIDI output is very simple when connecting to an Arduino. All I should need is a resistor and a jack. To conform with the spec, you normally use a couple of logic gates on the line from the UART, but I don’t think these are needed with the Arduino. I should be able to just connect pin 5 on the jack to the TX line on the Arduino, set the baud rate to 31250, and everything should be fine.

I’m going to build the interface on a small breadboard in the next couple of days. It will swiftly become apparent if I have any wrong-thinking going on.

Stay tuned…

MIDI Hardware – Part 2

MIDI Control Board
MIDI Control Board Underside

The board construction didn’t take long, only about 15 minutes. Piece of cake…

The four wires coming off of the board are for +5V, GND, Rx and Tx. Here it is connected to the Arduino Mega.

MIDI Control Board Attached to the Arduino

The bonus for me is that, by attaching the +5V and GND to the bus strips on the breadboard, it gives me some extra connections for those, which I will probably need before the end of this project. I kept my soldering temperature in the medium range (400 degrees) so I wouldn’t fry the 6N138. I’m not sure how tough that chip is when it comes to high temperatures, so better safe than sorry. I only have one in stock…

I have chosen to use Rx1/Tx1 on the Arduino. This is only because, if I use the Rx0/Tx0 pair, it screws up the communication with the USB to computer connection. I think this is due to the baud rate for the MIDI protocol being a very odd rate, and the Arduino seems to want to use the same rate for both the Rx0/Tx0 and USB connections. Regardless, I need the USB connection to work so I can monitor what the Arduino is doing from the computer. The serial ports are all the same anyway, and there is no drawback to using Rx1/Tx1.


For testing the MIDI Control Board, I hooked up the board to the Arduino, connected the Arduino to the computer via USB, plugged a USB to MIDI cable into another port on the same computer and connected the MIDI input and outputs to the control board. I then opened up a little program that would let me generate some MIDI from the computer, and opened up the serial monitor in the Arduino IDE. I wrote a little code to make the Arduino react to anything coming into the MIDI input port on the Control Board. All it does is take anything coming into Rx1, and send it out of Tx0 (so I can see it in the serial monitor on the computer.)

The board worked great, right out of the gate. I rigorously tested both the send and receive ports, and there was not a single issue with either the transmitting or receiving of MIDI data.

The next thing I will be doing is writing the MIDI interpreter code for the Arduino. I’m sure there are some stock libraries out there, but I prefer to do the code myself, so I can tailor it to my needs. That way, I can remove any extraneous crap and make it small and sleek. Stay tuned.