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.