开云体育

On Sun, Mar 23, 2025 at 9:49?AM fenugrec via groups.io <fenugrec=
[email protected]> wrote:

Tek really messed up when they killed the old site. Maybe if more people
complained (I did, a bit) they would backtrack ?

I dumped all my notes and screenshots to my website,

It looks like archive.org captured at least some of the threads you
reference:





Maybe you could update the links on your page?

Adam,

Could the transistors be bad? The 2N5179 replaces ones on this board of the p/n, 151-0282-00. If you have component cooler, use that to briefly spray on the transistors to see if cooling them some makes a difference. If any transistors are bad, Mouser has the transistor in stock. The two 68mfd decoupling condensers for the B+ supplies on this board could be high in ESR.

Mark

Radu Bogdan Dicher <vondicher@...> added the photo album Tektronix TDS754D - acquisition board issues ( /g/TekScopes/album?id=301426 )

I added a couple of pictures here:
/g/TekScopes/album?id=301426. Please note:

1. CH 1 seems to be able to display the square wave from the
test/adjustment terminals.
2. CH2 and CH3 display a flatline, but no square wave (not quite sure
why).
3. CH4 - the one with the main issues, by all signs - doesn't display a
waveform at all.

Radu.

On Sun, Mar 23, 2025 at 9:37?AM Radu Bogdan Dicher via groups.io <vondicher=
[email protected]> wrote:

I'm reviving this thread, because I seem to have a very similar issue and
am not sure how to progress.

This is a 754D that had a plethora of errors, most of which got solved by
replacing SRAMs serving U200 (so, if the sequencing described by Jay
applies to this acquisition board, that'd be CH4, but it seems to impact
all channels apparently). The root cause was (possibly alongside other
types of failures of the SRAMs) a low-resistance condition between pins 2
and 3 of those SRAMs (corresponding to A16 and A14, all addresses being in
parallel across the eight ICs) of about 10 ohms. I had to remove seven of
the eight chips before this condition was eliminated (one original SRAM
left on that channel). Once I did that, all errors pointing to specific
U201 through U216 went away.

I've also reflowed all pins for U200 to eliminate cold joints being as a
possible cause.

I have on error left: "diagnostic test failure, digDataFormatDiag,
ERROR!!BYTE mode, in demux 200 ,i= 4 memBaseAdr 0x738000a= data =
fffffa00, expectedData[i] = aa00" This seems to generate some spurious
peaks, just like Jared seemed to experience (I'll enclose a picture
shortly).

Not sure what else to look for to narrow down the issue left.
Radu.

I'm reviving this thread, because I seem to have a very similar issue and am not sure how to progress.

This is a 754D that had a plethora of errors, most of which got solved by replacing SRAMs serving U200 (so, if the sequencing described by Jay applies to this acquisition board, that'd be CH4, but it seems to impact all channels apparently). The root cause was (possibly alongside other types of failures of the SRAMs) a low-resistance condition between pins 2 and 3 of those SRAMs (corresponding to A16 and A14, all addresses being in parallel across the eight ICs) of about 10 ohms. I had to remove seven of the eight chips before this condition was eliminated (one original SRAM left on that channel). Once I did that, all errors pointing to specific U201 through U216 went away.

I've also reflowed all pins for U200 to eliminate cold joints being as a possible cause.

I have on error left: "diagnostic test failure, digDataFormatDiag, ERROR!!BYTE mode, in demux 200 ,i= 4 memBaseAdr 0x738000a= data = fffffa00, expectedData[i] = aa00" This seems to generate some spurious peaks, just like Jared seemed to experience (I'll enclose a picture shortly).

Not sure what else to look for to narrow down the issue left.
Radu.

Continuing my diary of 492P woes in case it's helpful to some other poor schlub reading the archives in future.

On Mar 20, 2025, at 22:00 , Adam R. Maxwell via groups.io <amaxwell@...> wrote:

Another problem possibly found: it's been starting up deaf when cold (no zero spike, just baseline noise), and suddenly comes alive. Tonight I plugged the 100 MHz output into a 7104 when I started the 492 up, and the 100 MHz oscillator was dead. Also swapped that out, but the replacement doesn't quite make -20 dBm.

At least one version of the service manual says you can replace select resistor A34A1R1018 if output of the 100 MHz reference oscillator is low. Schematic shows it as 309, and this one had over twice that. Adjusted for correct amplitude by setting the 100 MHz peak to a -20 dBm peak from my 8640B (set using a power meter).

The original has an air variable cap in the middle fully meshed, which seems fishy.

"Tuning capacitor C3031 in the collector circuit serves to adjust for maximum output." It was adjusted for maximum output, so no problem there. Still takes ~5 minutes to start.

In spite of this progress of sorts, a -20 dBm signal is still 30 dB below the top of the display, so I'm still missing something.

I left it running for a couple hours yesterday while cleaning up the shop, and noticed that the 100 MHz reference had suddenly regained 30 dBm. Checking power input to VR module, it was -25 dBm. This morning, it was once again down 30 dBm on the display, and power to VR module was about -26 dBm, so I'm thinking all the RF plumbing on the bottom is fine.

At this point, I'm thinking it's probably temperature-related, but I'm stuck until I can fabricate extenders to poke at the VR while it's operating. Ideas welcome.

Adam
KK7ASV

Interleaved.

On 3/22/2025 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

Thank you, Harvey.

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

Nope.? The address switches on the instrument control the address (much like I2C does it).

HPIB has three functions, all of which can be separate: listener, talker, controller.? For listener and talker the address is set on the instrument.? For controller, there is one only if the instruments are not dedicated listener and controller.

For instance, a meter can be designated a talker, and put into talker only mode (interface talks only, ignores address).? The printer can be put into listener mode (interface listens only, ignores address).? Controller not needed.

The way the HPIB bus works is that nothing is assigned a role, every instrument/device has a hardware selected address.? The controller knows (because it's been programmed to) what instruments are where.? In the previous example, the controller (now present) would address the meter as a talker, the printer as a listener, and then allow the transfers to occur.? When the controller decides (by monitoring status lines) that the transfer is done, the controller then de-addresses the listener and talker both.

I got impatient after posting this and thought I'd play with it a little
more and I connected the GPIB interface to the TDS754D then booted it and
it just landed on #4 GPIB. Not sure why on #4 (whether it had to be
"elevated" at #4 and why there's three below that having nothing
connected).

Go to the manual or read the back panel.? In my TDS640A, like many other instruments with a display, the functions of the HPIB bus are hidden in a menu.? For older instruments, the settings are on the dip switch.

In your case, address #4 was set as a default.? IIRC, it can be any number from 1 to 32. (0 is reserved).

With switches, the other three are typically listen only mode, talk only mode, and I'm not sure about the third one.

Generally speaking, I'm seeing different instruments landing on
a pretty wild "#" GPIB port. I'm always doing a "list" to inquire which
GPIBs have something attached.

The HPIB system was designed for a well determined system.

What you'd have to do to enable some form of hot swap (I think the hardware would forgive it), is to poll instruments periodically, to ask them what they are.? You'd then need a table of active devices.? Any new device would show up at a different address (assuming you did that),? and you'd have to activate that in your software to deal with that instrument.? That makes it a dynamic system.

HPIB is not really designed for that, but you can make it play nice.

Now this assumes that you have a standard 488 bus controller, such as HP.? The microprocessor based USB to 488 bus controllers work a bit differently, since there's only listener and talker functions to activate,? the controller is a little less of a controller, since it doesn't manage conversations, just roles.

Hope that helps a bit.

Harvey

Radu.

On Sat, Mar 22, 2025 at 6:54?PM Harvey White via groups.io <madyn=
[email protected]> wrote:

The 488 bus is an addressed bus, which means recognizing an address on a
bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch
something, then an existing address doesn't respond, and a new address
doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect
sequence. You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all
of them), and when one doesn't respond, you need to forget it. You then
need to scan for a new device. (and 488 has, IIRC, none of that),
although the controller by polling each device.

So somewhat different there, and not like USB.

Harvey


On 3/22/2025 7:47 PM, Radu Bogdan Dicher via groups.io wrote:

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a

newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's

running and expect it to smoothly connect? Or is it typically better to
connect GPIB while the instrument is off, then turn it on, so it'd scan its
"peripherals" during the booting sequence and this would guarantee it's
connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all

instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up

to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking

for some input applicable to any instrument/brand.

Thank you,
Radu.

Perfect! Thanks a bunch for all that info!

I also am a bit miffed that Tek nerfed their forums, there was good info there, they could have at least archived it.....


Jared.

Steve and all,
Thank you for elaborating on the topic. It's really useful to put some good
detail and get a better understanding of the general rules and mechanisms
of the protocol. Steve - thank you very much for pointing me to your
excellent manual.

I am aware of setting a certain "GPIB address" (I've set it myself on a few
instruments, and that was in order to avoid conflicting same addresses on
multiple units in my environment). I decided as a matter of "intake" to set
a unique address to each instrument that lands at my bench and may stay.

For the connected TDS754D, here's what my list of devices looks like (see
below). Please note though, that the GPIB address set for the scope is
"14," and not "4" (which is the reason why I interpreted it as "landing" on
#4, as opposed to a deliberate process). I believe some GPIB addresses for
different instruments previously connected to the computer would be "07,"
"08," "29" below (I'm not sure why there's two GPIB_07...). The TDS754D
seems to not report its own GPIB #(?)... It does state its firmware version
though.

(visa) list
( 0) USB0::0x03EB::0x2065::GPIB_07_55137323934351C07071::0::INSTR
( 1) USB0::0x03EB::0x2065::GPIB_07_75935323239351A0F1F0::0::INSTR
( 2) USB0::0x03EB::0x2065::GPIB_08_55137323934351C07071::0::INSTR
( 3) USB0::0x03EB::0x2065::GPIB_29_55137323934351C07071::0::INSTR
( 4) USB0::0x03EB::0x2065::TEKTRONIX_TDS_754D_0_CF_91.1CT_FV_v6.3e::0::INSTR
(visa)

My initial question was meant to ask a slightly different thing though (I
did a bad job explaining). Is it customary to just plug GPIB into a running
instrument while making sure the address is different than any other
(previously) connected instrument, and then start to talk to the
instrument through it? Or doing it while the instrument is off is a safer,
"best practice" procedure?

I probably am overthinking this, but I typically try to learn a process
correctly, rather than trial and error, if I can. Also, hopefully my
question is better phrased this time around.
Radu.

<>
Virus-free.www.avg.com
<>
<#m_-1007817960827559090_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Mar 23, 2025 at 4:27?AM Steve Hendrix via groups.io <SteveHx=
[email protected]> wrote:

On 2025-03-22 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

GPIB doesn't have the concept of a "connection". Each device sets its
own address, sometimes via DIP switches, sometimes, via front panel
commands, etc., but that instrument "knows" its own address. It's up to
the user to ensure there are no collisions. There are 31 available
addresses - often set by 5 DIP switches. The 32nd address is reserved as
described below. The whole concept is quite different from either USB or
Ethernet addressing.

To start a data transfer (which may be a command, or some sort of data),
the Controller (usually a PC adapter of some sort these days; could be
an internal board with special drivers, or external like my KISS-488)
issues a command to one address (maybe even itself) to become the
Talker, and to one or more devices (instruments) to become a Listener.
The talker then proceeds to send bytes, ending with a specified
termination condition. The Controller usually then turns the bus around,
addressing e.g. the instrument to become Talker, and e.g. itself as
Listener, and data flows the other way. at the end, it issues Untalk and
Unlisten commands (that 32nd address).

I include a fairly detailed discussion of GPIB concepts in the beginning
of the manual for my KISS-488, which you can download freely at



Steve Hendrix

Tek really messed up when they killed the old site. Maybe if more people complained (I did, a bit) they would backtrack ?

I dumped all my notes and screenshots to my website,
and here's also a copy of the important bit:
****
Console port - Option 13 Board - (Signal Name)
A10 - 1 - (D24)
B10 - 3 - (D25)
A9 - 5 - (D26)
B9 - 7 - (D27)
B8 - 2 - (D28)
A7 - 4 - (D29)
B7 - 6 - (D30)
A6 - 8 - (D31)

B1 - 21 - (A1)
A1 - 23 - (A2)
B2 - 25 - (A3)
A2 - 22 - (A4)
+5V (B6) - 24 - (A5)
GND (A3/A8) - 26 - (A6)

B5 - 12 - (INT#)
B4 - 15 - (IOCS#)
A5 - 16 - (SYSRESET#)
A4 - 17 - (RNW)

A3, A8 - 9, 13, 19 - (GND)
B6 - 10, 20 - (+5V)

B3 - not connected

not connected - 11 - (DS#)
not connected - 14 - (DSACK0#)
not connected - 18 - (AS#)

Notes:
- As displayed in the "TDS520B Mod CM" service manual, On the console port "B" is the top side of the processor board.
- Signals A5 (Pin 24) and A6 (Pin 26) need to be set to +5V and Gnd to make sure the serial port of the option 13 board is selected.
- The 3 ground pins (9, 13, 19) should be connected on the option 13 board, so normally you only need to connect one of these to the console port connector.
Nevertheless I connected them all.
- The 2 +5V pins (10, 20) should be connected on the option 13 board, so normally you only need to connect one of these to the console port connector.
****

On 2025-03-22 10:11 PM, Radu Bogdan Dicher via groups.io wrote:

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

GPIB doesn't have the concept of a "connection". Each device sets its own address, sometimes via DIP switches, sometimes, via front panel commands, etc., but that instrument "knows" its own address. It's up to the user to ensure there are no collisions. There are 31 available addresses - often set by 5 DIP switches. The 32nd address is reserved as described below. The whole concept is quite different from either USB or Ethernet addressing.

To start a data transfer (which may be a command, or some sort of data), the Controller (usually a PC adapter of some sort these days; could be an internal board with special drivers, or external like my KISS-488) issues a command to one address (maybe even itself) to become the Talker, and to one or more devices (instruments) to become a Listener. The talker then proceeds to send bytes, ending with a specified termination condition. The Controller usually then turns the bus around, addressing e.g. the instrument to become Talker, and e.g. itself as Listener, and data flows the other way. at the end, it issues Untalk and Unlisten commands (that 32nd address).

I include a fairly detailed discussion of GPIB concepts in the beginning of the manual for my KISS-488, which you can download freely at

Steve Hendrix

On Sun, Mar 23, 2025 at 03:11 AM, Radu Bogdan Dicher wrote:

booted it and it just landed on #4 GPIB. Not sure why on #4

The address is selected in the scope (like most other instruments) and you don't have to reboot if you change it.
If you have National Instruments GPIB hardware you can try and play with this

/H?kan

Apologies for the gravedig, but does anyone have this pinout for the J40 Debug port to Option 13 adapter? Seems the Tek website links no longer work...

I'm currently designing a USB debug adapter and want to check the pinouts to make sure mine are correct.


Thanks!
Jared

Wolfgang the original Tektronix relays can often be reworked, eg exercise contacts or clean with Iso alcohol, contact cleaner and paper strip.

See threads years ago

Jon

Thank you, Harvey.

If I understand correctly, you're saying that the # GPIB connection may
"port" another, "hot swapped" instrument to the same # GPIB?

I got impatient after posting this and thought I'd play with it a little
more and I connected the GPIB interface to the TDS754D then booted it and
it just landed on #4 GPIB. Not sure why on #4 (whether it had to be
"elevated" at #4 and why there's three below that having nothing
connected). Generally speaking, I'm seeing different instruments landing on
a pretty wild "#" GPIB port. I'm always doing a "list" to inquire which
GPIBs have something attached.
Radu.

On Sat, Mar 22, 2025 at 6:54?PM Harvey White via groups.io <madyn=
[email protected]> wrote:

The 488 bus is an addressed bus, which means recognizing an address on a
bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch
something, then an existing address doesn't respond, and a new address
doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect
sequence. You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all
of them), and when one doesn't respond, you need to forget it. You then
need to scan for a new device. (and 488 has, IIRC, none of that),
although the controller by polling each device.

So somewhat different there, and not like USB.

Harvey


On 3/22/2025 7:47 PM, Radu Bogdan Dicher via groups.io wrote:

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a

newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's

running and expect it to smoothly connect? Or is it typically better to
connect GPIB while the instrument is off, then turn it on, so it'd scan its
"peripherals" during the booting sequence and this would guarantee it's
connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all

instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up

to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking

for some input applicable to any instrument/brand.

Thank you,
Radu.

The 488 bus is an addressed bus, which means recognizing an address on a bus and having something respond (think I2C for an example).

So when you hot swap instruments, assuming that you don't glitch something, then an existing address doesn't respond, and a new address doesn't yet get recognized.

The controller (and I think it doesn't , unlike USB) start a new connect sequence.? You'd have to program it.

That means, to autoconnect, you'd need to be polling the interfaces (all of them), and when one doesn't respond, you need to forget it.? You then need to scan for a new device.? (and 488 has, IIRC, none of that), although the controller? by polling each device.

So somewhat different there, and not like USB.

Harvey

I recently acquired a PG502 from Tek surplus (aka Country Store) and found several setting to be intermittent. Expecting that a good cleaning would be in order, I was astonished to find that cam switch drum appears to be decomposing. It looks dull, powdery and parched like mud flats after a dessert gully washer!
In fact, there was a lot of fine debris on the contact board. Cleaning the board and the contacts made no difference because the cam lobes are deteriorating. I have not touched the cam drum with any cleaner or other chemicals.
This unit was used in the production test area; perhaps its entire life. It was last cal’d June 2022. Perhaps it is the result of 45 years of continuous up time in a rack.

I have never seen a cam drum look like this.

Has anyone seen such a thing?
(See photo gallery for “Decomposing Cam Switch Drum.”)

Hi all,
As I'm exploring GPIB in my environment on multiple instruments, a newbee question - is GPIB essentially hot swappable?

Differently put, can I typically just hook it up to an instrument that's running and expect it to smoothly connect? Or is it typically better to connect GPIB while the instrument is off, then turn it on, so it'd scan its "peripherals" during the booting sequence and this would guarantee it's connecting with no issues?

I assume there's a rule of thumb, instead of a situation where maybe all instruments may be different and it's hard to tell what's the best approach.

I've connected it plenty before, but 95% of the time it's been hooked up to one instrument and so "hot swapping" wasn't a consideration.

This is for a TDS754D, reason I'm posting on this board, but I'm looking for some input applicable to any instrument/brand.

Thank you,
Radu.

Hello everyone,

its been a while since my last post. There were a lot of things which kept me from posting an update.
Nevertheless, I finally managed to do some measurements of my relay replacements. The VNA at work was blocked all the time. Therefore, I had to find a different way to measure the relays. In the Album there are now the measurement result of almost all possible combinations you can have in a DPDT relay. /g/TekScopes/album?id=299851

All in all the replacements perform quite a bit worse than the originals. This is not surprising as the original relays are close to perfect in terms of HF coupling (tiny cross sections with relatively large gaps between adjacent parts). The PCB in contrast provides 'long' traces in parallel.

As the VNA was not available I had to measure the relays with a automated setup composed of my 60MHz function generator as signal source and my digital oscilloscope as measurement device. Due to the noise floor of the oscilloscope and the low output level of the funtion generator dynamics of the measurement was not crazy high.
To get an impression how much coupling would be possible at the given distances between pins, I always measured one complete trace without any DUT at all (the traces called 'Fixture').
Nevertheless, the measurements always show that the replacement performs not as good as the original relay, but I think this is the price you will have to pay to get a relaibly switching relay.

Regarding leckage current I will try to perform a few measurements to see if the required 0.2nA is achivable or not. I hope the next update will not be delayed as much as this one.

Right now I have 4 unpopulated panels left over (each with 36x 148-0034-00 and 30x 148-0035-00 relays). Plus some additional ones of the first panel which were already populated with SMT components.
If you are interested, send me a message off list with your needs and we can discuss how I can help you.

Best regards,

Wolfgang