Oscilloscope refurbishment


#1

Hi VHS! Ages ago you guys donated a defunct oscilloscope to us here at FVMS. It was a mid-90’s Techtronic 500 MHz with 4 channels. It’s sat for quite a while, but one of our members (Mike) tore it down, cleaned and re-capped the whole thing.

It’s running really well now but now we’re looking at calibrating it. Would you happen to have a copy of the software that originally came with it ( I know this is probably highly unlikely, but I thought I’d check with you first). Also, do you have a GPIB cable compatible with an older Techtronic? I’ll post the model# on my next post as I don’t have the scope infront of me.

Thanks!


#2

Hey Jason!

I think I remember that scope, I’m stoked that you’re getting use out of it!

I don’t think we ever had any documentation or cables. Or at least, I never
saw any :frowning:


#3

So we’re making our own GPIB using an Arduino, and we’ve been able to make due without the original software, but we have one more request. Does anyone at VHS have access to a EPROM DIP package-compatible programmer? The only Eprom burner we’ve got is for Atmel 328 style chips, and we need something that can burn an DS1650Y NVSRAM chip.

Thanks!


#4

That sounds like something @SDY might have, or some of the ARC people


#5

I’ll pull a unit I have and send you the model Humber for you to verify that it would do the trick. Then, The software would have to be downloaded to your PC (the manuf still let legacy software to be downloaded for free!). And then I’ll drop it off and we can try it out and see if it works…
Back to you later this morning.


#6

PILOT-U44 Plus, Universal Programmer, manufactured by Advin Systems Inc., Sunnyvale, California, USA. No optional add-on modules, the socket for the device to be programmed is a zif40 pins. This programmer uses the parallel port (DB-25) for computer communications.

I remember downloading the software but not trying it out. See if you can find the software, because I vaguely remember that at the same location on the net it gave you the devices it was able to program (gazillions of 'em).

Let me know where we take it from there…?


#7

http://www.advinprogrammers.com/universal-EPROM-programmer-software-download.htm

http://www.advin.com/device-programmer/device-programmer-U44p.pdf

List of chips (MAY REQUIRE ADAPTER, WHICH I DO NOT HAVE!
http://advin.com/device-list/Device-List-U44p-programmer.pdf

Sadly, DS1650 is NOT Listed, but that does not mean it would not be possible to use this programmer to load it;

WARNING!!! Software is for Windows XP, NT, 2000, 98, and remember, you do need a parallel port!


#8

Thanks so much for helping out with this! We’ve got an old desktop at the space that’s still got XP, and we’re figuring what we could do to build an adapter if we needed to. I’m at work all day though so I won’t be able to confirm until this evening if we’ve got everything we need.

Again, thanks so much for the help and the offer to use your burner!


#9

Roger that.


#10

And if you need some parts/components for an adapter, make sure to give me a headsup, I have way too much s…tuff…


#11

I installed the latest Microsoft Windows 10 update and therefore cannot access the site anymore.
Thank you Microsoft, for another job well done.
Good luck to all.
SDY

Jarrett
December 11 |

That sounds like something @SDY might have, or some of the ARC people

Visit Topic or reply to this email to respond.

In Reply To

FVMakersJason
December 11 |

So we’re making our own GPIB using an Arduino, and we’ve been able to make due without the original software, but we have one more request. Does anyone at VHS have access to a EPROM DIP package-compatible programmer? The only Eprom burner we’ve got is for Atmel 328 style chips, and we need somethi…
Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.


#12

This is the latest update on the refurbishment. I originally tried to copy this directly from my e-mail. I’m not the one refurbishing this, it’s one of our members (Mike) who’s got it in process. I was hoping to attach the text with pictures in tact but I’ll have to upload them separately. The latest update is below:

You had asked about some pictures. Since I’m back into it up to my elbows, I thought I’d take a few. Photos without explanation isn’t as interesting so I’ll provide some extra background.

An early “victory-run” as it were after I fixed the vertical shift register & offset sample & hold: (didn’t bother to compensate the probes; it wasn’t important)

The attached photo ending in 4723 showed the waveform still with a massive offset due to a failed op amp. It prevented seeing the rest of the waveform at all. The waveform position was adjusted to the limit to be able to see anything at all…

I broke out the logic analyzer to try to see what the CPUs were saying to each other but they seem to speak in an extremely brief, proprietary code; not English communication. Had hoped to get error information but got nothing useful there.

In the photo 4243, you have the acquisition board. The signal comes into the 4 preamps at the top, through the ADCs below, and into the demux below that and the acquisition memory below that. The “CD stack” CPU is the triggering & control system. From what I have seen, the big chips all seem to either have “house numbers” on them or are fully custom chips.

From what I’ve seen, they’re over-clocking the 20ns RAM by a little bit and sharing the memory 8 ways so they can use their combined data handling rate to meet their requirements of 500 MSa/s.

They’re also sharing the demultiplexers probably for the same reason.

They have designed in much self-testing including “signal path compensation” automatic procedures.

The capacitor at the left leaked its electrolyte under R531 and its companion. Over time, it ate away the traces at the two red arrows. This particular problem caused a voltage divider to not work properly and be off by 42% when clearly it was intended to be especially accurate. Fixed.

The capacitor soldering isn’t pretty; it’s really hard to solder a tab that protrudes about 0.4 mm and is surrounded by plastic. And you need to do about 100 of them in a reasonable amount of time. And you don’t want to overheat things. And you don’t have a micro soldering iron or a microscope. My iron’s tip is the smallest that will fit the iron…it’s pretty good but maybe there’s something even better out there.

The board looks “grungy” but every cm2 has been thoroughly scrubbed with suitable cleaner several times and it still looks this way. This fact is quite unsatisfying but what matters most is that it works…and continues to work. The intention has been to scrub & wash away the electrolyte so it can’t continue to create new problems. Only time will tell us the successfulness of that cleaning effort. Typically people submerge the board in water with dish soap but I’m not prepared to do that since I don’t have a drying oven nor the courage/experience for that at the moment.

I found the above gem during a “tour” around all the circuits on the acquisition board during which time I reviewed the operation of each circuit:

· Power supplies present & healthy

· Voltage references working correctly

· Op amp inputs & outputs sensible?

· Test point values sensible & in stated ranges (if provided)

This brought out several interesting problems:

· An oscillating adjustable voltage reference in the trigger system (oops, no thank you…)

· A failed op amp intended to act as a constant current source; it was doing nothing of the sort

· A failed voltage divider (above)

· An incorrectly biased circuit in the triggering system (another dissolved trace)

The triggering system area of the board has been the most badly affected area of the instrument.

It’ll be quite interesting to see what happens with the remaining errors when these problems are fixed. I wouldn’t be surprised at all if the “ctl” errors go away. At least there’ll be fewer reasons for it to not work correctly. The things I found there would certainly be problematic.

With a GPIB interface in hand, the acquisition memory errors should be easier to solve since then I’ll know what the error actually is.

Maybe I can kill off the remaining errors by Saturday…that’d be nice but it’ll probably be a stretch since I’ll need to make & learn how to use a GPIB interface.

Again, it worked surprisingly well even with all those latent problems; there’s no concern for Saturday.

You can do with the photos or this text as you wish.

Ugh, in all the excitement, I forgot to check the compatibility of the memory with the programmer. Tomorrow probably…if I have time. Repairs of known problems will have higher priority.


#13


#14


#15


#16


#17


#18


#19


#20