EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: bench_knob on February 20, 2015, 10:25:29 am
-
Hi All,
Short story version, I fixed it.
Long screwy story version:
Some time back I bought an old HP-8568B Spectrum Analyzer. For a long time I've desired to own a spectrum analyzer instrument but it always seemed that I either didn't have the money or when I did, I didn't remember the want, hah! In any case I bought the 8568B in two pieces on eBay, (altogether about $600 sans shipping and a new, wrong version CRT, that I didn't need in any case as the HP85662 IF & Display Section CRT is bright and sharp). I'm not exactly certain what option version it is, as the documentation doesn't match the numbers inside the unit. My hunch is that it was repaired by a previous owner using parts from a different version instrument. Its supposedly an H96 option version (sn prefix: 2517A) which a prior associate of mine (now owner of) 'DKD Instruments' identifies as being a less expensive down-build version...downgrades such as "RF INPUT #2" connector was changed from an 'N' connector to a BNC connector, type down-grading. And something about a card based oscillator, but that mod isn't in my box. The H96 version supposedly has an 85680-60202 A15 Controller board, but the unit actually has an 85680-60182 Controller. Just as well as the 60182 board is likely a better board.
I've been developing a lecture for an upcoming UFO Conference where I'm featured speaker. I'm giving a talk about my interaction experiments and instrumentation efforts involving luminous-orbs. Luminous-Orbs, or 'orbs' as these things are loosely named, is a phenomenon often seen in an area of suspected alien mecha activity. These volley-ball size self-luminous glowing objects radiate multi-spectral energy in addition to light. I have instrumented these objects using various gadgets, including my recently acquired HP-8568b spectrum-analyzer as well as with other instruments, numerous of which I home-brewed specifically for the task. Some folks may jump to the conclusion that I must be instrumenting Venus or an airplane. I don't think so. I have seen these objects with my eyes and instruments in different ways and various time periods. Frequently at night as they are easier to visually detect as they glow and move around typically at low altitudes. It seems to me, that these things seem curious about Humans, or perhaps just me? As I have frequently seen these spheres from just a couple dozen meters distance, at about 3~5 meter altitude, generally below the tree limbs. Too big to be lightening-bugs. I've also seen and instrumented them in daylight, but they are more difficult to see. It’s useful for co-verification, visual + instrument. They can appear anywhere, while some investigators seem to believe that they only visit rural areas, that has not been my experience. For instance, in the residential area where I reside I saw one in daylight, while I was on my long driveway in front of my home. I saw it from a distance of about one foot. It happened during an unusual conversation. I was talking on a cordless 72 MHz Uniden residential phone (1997) with a friend who was at work at JPL (Jet Propulsion Laboratory). At that time he was an RF engineer and a direct member of the FUR (Flight Unit Rover) Mars Pathfinder robotics team; he converted COTS Motorola radio-modems for flight. His modems are sitting on Mars. <how kewl is that?> We were discussing my idea of designing a wide-field CCD galvo-mirror directed tunable LASER to track, illuminate and capture reflected LASER light from an ablating meteor while transiting. (as meteors behave a bit like flying-saucers, I was hoping to get JPL interested to make it and then maybe I could talk them out of the plans. Turned out JPL already had already engineered something similar, but it was for the military...no access.) While pacing up and down my long driveway, I noticed a bluish sheen around my feet on the driveway concrete, the light was from a luminous-orb which was one foot forward of my face, and one foot above my head. At that time I was actively pursuing information and executing instrumentation strategies regarding ET objects and luminous-orbs. That's what I call a "close-encounter", something in the radio conversation attracted their interest, or so it could be conjectured? There were additional things that transpired but I'm already pushing the scope-envelope here. :o (In my defense, while its a screwy story, with screwy twists, how often does one hear a true story like this?)
So I've been developing a GPIB program which I'm writing in Borland Delphi-7 (I loathe dotNet/C#), running on WinXP Pro & a ProLogix USB/GPIB controller) to operate my HP8568b for a conference demonstration in March. A week ago, I went into my lab to turn things on for the evening development tasks, and the Check I & II LEDs did not turn off and there was no signal on the analyzer. Normally, the Power-On-Pretest (POP) cycles through a sequence of internal tests whose status are indicated via the two front panel CHECK LEDs, I and II indicating various pass/fail states. They normally illuminate for a couple of seconds and then both extinguish. But this time, they both remained illuminated. Also, the operator front panel indicators did not all illuminate momentarily, while a few LEDs on the IF & Display Section were illuminated here and there. All the controls were unresponsive. Pushing a button associated with a status LED caused no visible response, while on the CRT display, the grid was being painted along with some digital information such as '10dB ATTEN', etc. But there was no noise or other signals being painted.
I tracked down my Artek HP8568b (85680 & 85662) TRM manuals (schematics sections are not scanned full size, and are presented in interrupted sections over several pages, beyond that the manuals are well done, and are text searchable too. It was worth the money, but I wish the schematics were a bit better.) I reviewed the instrument verification and test procedure section. Intuitively, it seemed to me that the failure might be in the digital section, as the RF/analog section seemed to be functional as exhibited on the CRT display.
The verification chapter described the two Check LEDs operation...both remaining on after POP indicates a malfunctioning (A15) Controller, i.e. the CPU card in the (85680) RF Section module. The RF section normally sits on the bottom of the two module stack. So I disconnected the two module interconnect cables (rear panel), swapped the modules top to bottom and flipped the RF Section up-side-down (boards are located in the bottom of the box), setting it on top of the IF & Display Section module, normally situated on the bottom. Reconnected the module interconnect cables, removed the bottom cover of the RF section, and removed the A15 & A12 board cover. The A15 Controller also has 14 diagnostic LEDs on the top edge of the left side of the board. Unfortunately a 50 signal SpectraStrip ribbon cable was routed over the top of the board. As I was ejecting the board out of the card cage one of the card-ejector levers (manufactured in 1984, 31 years old) broke off and I was being careful with it. It was really difficult extracting it without the card-ejector lever. However from one of my jobs in my youth, when I was a CMC mainframe customer-engineer, I happened to have the foresight (a.k.a. packrat-itis syndrome), to save a few card-ejector levers; I replaced it.
With the card out of the cage, I rerouted the two ribbon cables by twisting and 'rolling' them, down under the right side card edge notch, so that they did not pass up over and block the diagnostic LEDs. At this juncture it seemed obvious to me that the previous owner did work in this area as those cables, although difficult to do so, were improperly routed.
With A15 re-inserted, and the system powered on, the Power-On-Pretest (POP) LEDs DS0 ~ DS14 indicated one of the UV ROMs to be failing checksum. The A15 Controller, lower right corner was marked 85680-60182, and I pulled up the schematics for the board, along with parts-locator mechanical drawing (which PCB guys refer to as the top silk-screen layer). The 60182 board has four UV ROMs, each marked uniquely.
ROM Label IC Nr
============ ============
85680-80069 U38
85680-80070 U40
85680-80071 U37
85680-80072 U39
The HP service manual only gave an HP internal part number, but as I've been acquiring other HP gear, I also have been collecting information, and one of those documents is a very large robust HP internal part number to manufacturer part number cross reference database, which revealed that the UV ROMs were manufactured by AMD, being AM27256 or 32k x 8 ROMs.
I pulled out my old dusty Needham EMP-30 ROM burner/reader. But I couldn't get it work with WinXP. I then rummaged through a pile of PCs that I've had for years. Hah! One of'em when turned on, exclaimed with a loud bang accompanied by copious cloud of stinky white capacitor fart-gas!! (1000uF @16V) Another PC wouldn't even beep. I tried everything, changing cables, PCs, OS's...nothing worked with the two old Needham DOS driver floppy disks I had. The last time I used the burner only DOS was in use and all those fast 27MHz PCs had parallel ports!! In desperation I actually started using my brain, as it occurred to me that if I can't get that ROM burner working I could end up with 125 LB spectrum-analyzer door-stop in my lab!! I needed modern drivers. So I hopped up on the 'Net, visited the Needham site...they are OOB! On a hunch, I vectored over to the 'Wayback Web Archive' website and sure enough, Needham's business website is archived, along with their software download page. So I downloaded the EMP-30 EMPwin (WinXP) driver; installed onto one of my older HP laptops that has a parallel port. Plugged it all in and voila!! The burner is running. <sigh>
So, two days later I read and saved the four ROM images as .bin files and documented all the checksums. I should have done that from the get-go when I first received the spectrum analyzer and all the other HP gear I've acquired. I have two HP8116A function generators, HP6632A, and a HP3438 DMM programmable power-supply (sweet) and other obsolete gadgets. I've learned my lesson, I'm gonna archive all those chips later this week. But I needed a set of verified good HP ROM images.
I hopped up on eBay and looked around for an A15 Controller card, a concern being to at least acquire the SW version my analyzer build was manufactured to. I infer from the HP service literature that HP only released five SW versions (A ~ E, keyed to instrument serial numbers) and I luckily located a card with the same version (Rev C, as also denoted by the ROM label 80xxx number range series. Date Code & Rev Info from pg A15-6, table 1-2, 'TRM Vol 1 RF 085680-90137 v1' manual). I paid $60 for a card and it arrived yesterday via UPS.
I extracted the four 'new' ROMs, plugged them into the ROM burner and saved the binary images as .bin files along with documenting their checksum values. I then compared the checksums between failing ROM set to the newly acquired ROM set, and sure enough, the U40 checksums did not match as predicted by the POP self-test diagnostics, while the other three ROM's checksums did!! With my confidence building and getting excited, I plugged the four 'new' ROMs into my analyzer's A15 Controller card, inserted it into the analyzer, and sh.it-howdy boys! It works!! So, then I yanked out the ROMs and put them into the 'new' card and swapped it into the analyzer and it also works, so I have a good spare Controller card. I dug out (a really old dusty) UV eraser, but I couldn't find the power-wart for it. So I fired up my old trusty HP6291A linear power-supply, checked the voltage using my HP3438 DMM, found the correct DC barrel lead-set and erased the bad-checksum UV ROM chip. I tanned it for 15 minutes. Experience shows that longer than that, sometimes it kills them prematurely. Stuck the erased ROM into the burner and it failed the FF blank check at location 0x2003 with a '0x7F'. I wrote all 00s to it, and then erased it again. One more burn cycle and it failed at loc 0x2003 again. It’s just a bad chip. I rummaged around and found an old Intel D27256-20, which is in the same speed range as the AMD AM27256 ROM in analyzer, programmed it, stuck into the Controller and now I have two good running A15 Controllers.
<whew!>
All this to edify an audience of clueless UFOologists next month, hah!
Outsiders of engineering ask why it takes us so long to do stuff!?
I've included the Rev C ROM images as a zip attachment along with an info document having the checksums, and other trivia.
The file has been PeaZipped (very good open-source, free zipper). The filename includes a time-stamp:
HP-85680-60182_A15_RevC_ROM_SET.20150219-233430.zip
The file contains for .bin ROM image files and a info plain text file.
bench_knob
-
Wow. That's one heck of a story. Thanks.