34970A data logger loss of serial port com

If there really is a non-volatile memory error, maybe it is reverting to its lowest, highest, or default bit rate on the serial port? Have you tried different bit rates in the connected equipment? If the HP puts something out on the serial port when turned on (banner, "I am here" info), maybe scope that while turning the HP on to see what the timing looks like?

Arguing against this is that it seems weird to keep the bit rate - a parameter for the logger itself - in the NVM on an input module.

What happens to the voltages if you put a 1K or so resistor from each of the "output" signals (TXD, RTS, DTR) to ground at the external RS-232 connector?

The 16550 has its own crystal; is that operating at close to the right frequency? There appear to be handy test points on the XIN and BAUDOUT pins.

This is probably not related, but: a few years ago I tried to roll my own program to talk to an Agilent RF power meter over its RS-232 port. I found the protocol documentation to be extremely lacking, and I also found that incorrect commands on the RS-232 port would cause the meter to just lock up, requiring an AC power cycle to correct. I gave up on it after wasting half a day or so. My point is, don't totally discount the possibility that the firmware is doing something weird.

Matt Roberds

Nothing from the tx at power on.

The Tx terminal is static high, loaded down to below 3V by 2K. Carrier detect is also high and load similarly. The rest are the lines that are visibly functional - these are inputs floating around ground.

I'll check oscillators and clocks the next time it's open near a scope.

What bothers me is that the serial port section is completely isolated from the logging input hardware, where any kind of fault would be expected. A lot of other hardware isn't though. If the problem is in the logging input live section (includes the 'main' controller), then I could be looking at corrupted memory that isn't on a module.

I can accept weird, so long as its repairable.

RL

1K was from memory; Googling the spec indicates a range of 3K to 7K is popular. If 3K or more also loads it down below 3 V, I'd start to suspect the MC145407 or the charge pump caps connected to it.

The schematic shows that there isn't a "carrier detect". In addition to TXD, there is RTS and DTR. It is possible that one of these doesn't raise until the logger thinks it is "ready", or maybe it is affected by the flow control options in the Interface menu.

Looking at it again, the I/O controller (U305A) runs on a 12 MHz ceramic resonator (U301). Was the unit banged around, dropped, etc?

The schematic says it "uses backplane supply", but if that was gone, then a lot of other things would be dead. Maybe the supply is noisy?

Matt Roberds

There is no flow control on all of the default RS232 settings used.

All oscillators are banging away at their labeled frequencies.

An awful lot of stuff is common to the ADC and it's floating hot measuremen t terminals, including the main controller, memory and even the front panel display.......

The backplane carries grounded digital com RST/SRQ and data lines as well a s the signals of floating analog circuitry.

The multifunction module used at the time of the fault employed the grounde d digital bus only. There were no connections to the floating DAC outputs c ommon to the ADC and main controller. I think this means that I can rule ou t damage in the floating circuitry....which would be nice.

The I/O controller (U307 - PC16550) isn't socketed, but the microcontroller running the show (U305)is.

RL

One of the Agilent guys suggested that I try to recalibrate the 34907 module. After some curious, repeated rejections, the 34970 finally accepted a calibration change on the previously un-used and unconnected DAC output, channel 4. This was outputing 10.6 when asked for 10.0. (Wouldn't accept a zero offset change though, no matter what was done.)

This change retired the turn-on error associated with the card and suggests that it doesn't matter WHAT was connected at the time of the failure - ANYTHING is fair game.

I'm going to dust off an old usb-gpib adapter (if I can find the damn thing) to see if the logger still speaks gpibish. If twiddling registers can regain distantly-associated functionality, it would be a cheap fix, but I'm clutching at straws here.

Repair and/or replace is two weeks.....(I'm not completely dense - a replacement/back-up is already en route)

RL

The 34901A module present in slot one during the 'event' has owned up to the flashing front panel and beeping. It's a constant power- on-reset.

This module was responsible solely for monitoring LV ground-referenced signals ported by a 3ph wattmeter.

Will repeat the symptom any time, by itself. Without visible damage, it's shelved till...

RL

Does removing that module also fix the serial port?

Maybe it got a little more AC than it wanted. I once discovered that your average circa-1995 PC parallel port doesn't really like having

6.3 V AC fed into it. By experiment. :)

Put a note on it. I've been bitten more than once by finding an item that will solve my problem in the back of a cabinet, only to later discover that it was back there because it was broken...

Matt Roberds

No. Serial port is unresponsive regardless of interface modules present.

This module is a relay switch matrix that directs two contacts to inputs of a 6.5digit multimeter, isolated from ground and the serial port to some hu ndreds of volts (CAT1-300V spec). The measurement(s) it was making involved reading the monitoring pins of an other instrument - LV outputs of current/voltage transformers and RMS-DC co nverters. There is NO issue with the cheap commodity serial port interface on the con necting PC; just the interface sitting in the high-tech, application-specif ic marvel of modern automated measurement and instrumentation.

Cabinets? Luxury! The reference to shelves here was only speaking figurativ ely. You wear these things around your 'interneck' till they rot off, to teach y ou some kind of a lesson. I have a strong immunity to bad smells, so it's n o real hardship.

There are no discrete parts damaged or misbehaving. No basic digital parts outputting what they shouldn't. Power application shows no abnormal supply loading as various sections are enabled/disabled manually. Compares to know n working good units favorably in most respects. There's only that great u n-socketed 40 pin PIC left. All it's supposed to do is count, remember it's name and do what it's told.

But it's the serial port in the main unit that needs reviving. When the rep lacement shows up, I guess this will go off to whatever sub-contracted back room they send these things, to get their PICS de-scrambled.

RL