Control Board

(Mostly) Finished control board

I’m happy to say that the Control Board is complete, and tested.  In a strange twist of fate (including a nostalgic trip to the 80’s) one of the harder parts to source was a DB25 male-male parallel port cable.  I ended up finding an old iomega Zip drive with a male-female cable and a male-male gender changer.  Wow.  Retro.  Anyway, I’ve got that connection down.  Other than that, there was only one other complication.

Control board correction

As pictured above, there was a Engineering Change Order for this revision of the control board.  The outside pins of the voltage regulator weren’t connected to the decoupling capacitors and the protection diode.  I simply used some thin solder wick and bridge the pins.  Problem solved.

Low frequency noise component

Once all the components were installed, I powered the board up and began looking to quantify the power supply noise.  All power supplies contain noise, but it’s good to determine just how much is there.  In this case, the magnitude of the noise displayed is a little over 90 mV (20mV/div).  The time base is set to 10 mS/div in this photo.  We can derive the frequencies present.  The two big peaks are about 43 mS apart, 1/.043 = 23 Hz.  The smaller humps, including the larger ones, are about 20 mS apart and 1/.03 = 50 Hz.  I’ll just call it my own measurement inaccuracy, but that’s pretty close to 60 Hz.

High frequency component

These peaks are about 75 uS apart, so the frequency is about 1/.000075 = 13.3 kHz.  This is most likely the switching frequency of either the 20V supply leaking into the 10v source or my 12v bench supply (old computer power supply).  I’m going to defer any qualitative analysis until I observe any effects in the analyzer.  Similar to my analysis of the Master Oscillator, I’m simply documenting the system now, so if any problems crop up I know what to expect.

Connecting to the logic analyzer

In addition to analyzing the power supply, I want to know as much as possible about the qualities of the logic functions of the board.  The control board is responsible for capturing and buffering the data on the parallel port through a few CMOS latches.  I decided this was a perfect job for my shiny new logic analyzer.  I got this little guy about when Sparkfun electronics had their free day this year.  No, I didn’t get it for free, sparkfun’s stupid servers couldn’t keep up with demand so I got shafted.  I got it because Katie felt so bad for me she said I could buy it anyway.  Anyway, that tangent aside, I hooked it up to one of the logic ports and started working.

Logic test setup

The experimental setup for the logic test consisted of the crappy old laptop that’ll run the analyzer software (chosen because it has a parallel port) and my MacBook.  I’m using Sam Wetterlin’s control board testing app which toggles the logic pins as fast as it can.  The actual speed that it toggles is dependent on many factors, computer speed, load, etc.  Those factors are compounded by the fact that all this software is written in BASIC.  You can barely see on the computer on the right that there is significant variability in the toggle rate.  I somewhat haphazardly sampled what looked like the widest and narrowest pulses which ranged from 3mS to 75uS.  I can only assume that’s O.K., it’s mentioned in the documentation that variability is to be expected.  I would have liked to include a photo of an O’scope plot of the rise/fall times, but with this much variability, and an analog scope, it’s just too much of a pain.  I’ll have to assume it’s fine for now.

Logic analyzer screen capture

Update: I remembered that I took a screen shot from the logic analyzer program.  My assumption about the reason there is so much variability is that the twiddler program is being interrupted, so it’s not able to update the port.  I’m sure there’s a way to ensure better consistency, but probably not using such primitive hardware and a programming language that can’t hook more deeply into the operating system.  There are basic plans on the mailing list for a USB adapter.  My opinion is that using USB, it should be somewhat easier to ensure consistent timing.  Also, I tried taking a photo of the rise/fall times.  I couldn’t get a photo to come out, but I can tell you that with 50uS/div timing on the ‘scope the line is vertical, so it’s quite fast.

Oscilloscope settings (sorry for the poor photo)

Update 2: I was able to capture a few images of the rise and fall times of the logic signals, pictured above.  Taking this image tried both my photographic and oscilloscope skills.  The procedure I used was to turn out all the room lights.  Then, with the camera on a tripod set the exposure to 1 second.  On the oscilloscope, I set the ‘A’ trigger to “falling edge” and used the ‘B’ trigger as a time-offset from the ‘A’ trigger with a 5mS timebase.  Then, I set the display timebase to 50uS/div.  Next, I set the trigger mode to “single shot” (so it only draws the waveform once when the trigger fires).  With all that setup, I had to set the graticule and trace brightness so it was exposed mostly correct.  Finally, when I hit the shutter on the camera, I’d arm the trigger and hope for the best.  Eventually, I came up with an image I could use.  Let me just say that I understand the draw of digital oscilloscopes now.

Rise time image

With all that said, let’s analyze that image!  Like I said, the timebase is set to 50uS/div, so each one of those little dots represents 10uS.  It should be fairly easy to see that the logic ‘low’ portion of the waveform ends just before the 4th dot in that division, also that the logic ‘high’ portion picks up at almost that same spot.  I estimate that the difference in time is probably 1uS, and certainly much less than 5uS.  I’m satisfied with that result.  I don’t have an official answer for what the minimum specification is for the analyzer, but I’m sure this is more than within spec.  Also, qualitatively, the logic waveforms are clean and free of any undesirable artifacts.

Anyway, I’m still pretty happy with the build so far.  I get some more parts in on friday, so I hope to post again soon.

Update: 05/02/2010 8:04 PM

I’ve discovered that a bad latch on the control board is responsible for the problems I’ve been having with the Analog-digital converter.  When I was particularly frustrated with the ADC, I decided to attach the logic analyzer to it’s digital interface to see what was happening.  I noticed that often the convert line wasn’t being triggered.

Nasty ‘convert’ signal

I decided to investigate with the O’scope and found that the signal was looking rather ragged (see above).  It appears that the output transistor on the latch is having serious problems.  This image is the waveform with the ADC connected.

Latch output left open

With the ADC disconnected, the latch output is a little more normal, though it still isn’t good.  I’ve included an example of what they’re supposed to look like below.

Proper waveform

I’ve decided to remove the latch IC and throw it away.  I scrounged through my collection of 7400-series ICs, though I didn’t have any replacements.  The fourth latch on the control board is currently not used for anything, so I thought I’d substitute it for the damaged one.  It turned out to be rather simple to manage.  I unsoldered the latch enable (LE) pin on the 4th latch and soldered a short jumper to the LE signal for the 3th latch.

Hack-y fix to latch problem

This isn’t a particularly elegant fix to the problem, but it’ll do until I can order a replacement.  By the way, it appeared to fix the problems I’ve been having with the ADC.

  1. No comments yet.
(will not be published)

Please complete this capcha. I get almost 1000 spam comments a day! * Time limit is exhausted. Please reload CAPTCHA.