开云体育

Haha. Yes Jimbert He is still my friend I asked him first... He didn't really care too much about his scope! Not sure he even wants it back! Says it takes up too much space.

John W.

I removed the defective U500 and cleaned it with Deoxit put it back in the scope and got the same error message. Then with great fear I removed the good U500 and put the U500 I suspected was bad into the good scope and got the Test 05 Fail 42 message. I then put the good U500 in the bad scope and there was no error message.

So I figured I had my answer. I then looked for a replacement U500 and ordered one.

John w.

On Fri, Dec 20, 2024 at 12:04 PM, Wevie wrote:

I will do the raw copy of the disk in the upcoming days, will update this
topic for sure.

I was under the impression that calibration coefficients are in nvram too on
8000 series. That explains at least the issue with lost calibration parameters
due to drained battery's..

It was 4+ years last time I looked at it so take the following comments with a grain of salt. Some calibration data is stored in a directory "CalConst". I think those are the ones scope can figure out itself and save. File names are "1" to "16" but "4" is missing. Bank 4 has the EEPROM data for things scope can't figure out itself such as the reference voltage. During boot of my scope bank 4 is loaded from EEPROM:

0x16987e0 (tShell): Reading 280 bytes of service cal data from EEPROM[0] into 0x2d1a240
0x16987e0 (tShell): nvMem_read succeeded
0x16987e0 (tShell): Reading 66 bytes of service cal data from EEPROM[280] into 0x2d1a300
0x16987e0 (tShell): nvMem_read succeeded

It is possible that after scope boots these values are in NVRAM and by saving NVRAM you are also saving the factory data. However, it has to be somehow mapped to EEPROM if EEPROM is lost. My scope came "broken" (Tek cal reject, input relays were bad) so I don't know if some of the boot scripts were modified and EEPROM is not usually loaded. If someone with a TDS7xxx can also paste their log file we can tell. In any case it looks like EEPROM is storing some useful information. Lost NVRAM data will erase some calibration coefficients but here are hooks in vxWorks to read and write calibration constants from the disk "calConst" directory so even if they are lost they may be recovered (assuming they were written properly in the first place) but not bank 4 which is on EEPROM.

Solution may already be there in many pages of eevblog discussions.
Ozan

"... a friend loaned me his spare 2465A ... so I swapped PSUs ..."

Is he still your friend? ;-)

I will do the raw copy of the disk in the upcoming days, will update this topic for sure.

I was under the impression that calibration coefficients are in nvram too on 8000 series. That explains at least the issue with lost calibration parameters due to drained battery's..

Thanks, Mark! I’ll give that a try. Might actually have time over the holidays to do so. Jim

Congrats on the diagnosis and upcoming fix :).

On Fri, Dec 20, 2024 at 12:35?PM N7ZMG via groups.io <jwaldburger5377=
[email protected]> wrote:

Further reading in the forums lead me to believe that the failure could be
related to the Hybrid U500 (which is the trigger hybrid). Well it just so
happens that I have a working U500 the other scope. So I swapped them
out. Problem solved. No error code on start up. I have found a
replacement U500 and have ordered one.

Have you tried swapping the bad U500 to the good scope or putting it back
in the bad one?
It is possible that the problem was only due to contact corrosion between
the hybrid and the socket, in which case reseating the hybrid will usually
clear it up. On my 2467 I had all kinds of glitching and weirdness until I
treated the hybrid contacts with DeOxit.

My only questions now are:

1. Should I put the original PSU back in their respective scopes to
preserve some calibration parameters?

My $0.02 is that the scope was originally calibrated against a calibrated
DAC, and any component drift from then will push the scope further away
from calibration. So, by doing the DAC calibration you've probably improved
things.
This is however not to say that the scope(s) won't benefit from
re-calibration, especially after you replace the trigger hybrid.

Note that you can assess the horizontal calibration using only the scope's
own calibrator, as for most sweep speeds, the calibrator will generate a
signal that crosses all major graticule lines.
The calibrator signal is also specified to be 0.4V peak-to-peak, accurate
enough to allow you to roughly assess the accuracy of vertical deflection
for at least one vertical setting.

The calibration process is mostly about setting up accurate sweep times and
vertical deflection, but there's also an automated step where the trigger
levels are calibrated against a known signal, so changing a trigger hybrid
may throw that off.

2. Did I screw up some calibration parameters by adjusting the DAC
reference?
3. What should the voltage on pin 13 of J119 be? That seems to be the
only difference between the two now working scopes (should I even worry
about that) I don't find that (pin 13) voltage spelled out anywhere in the
manual except when adjusting the DAC.

On my 2467 schematics, the DLY_REF_0 and DLY_REF_1 references are routed to
J119, pins 13 and 14. Those are double-filtered from the DAC, then straight
up buffered by the S&H op-amp. What this means is that the voltage on pin
13 will be a function of what your DLY_REF_0 signal is set to, which is a
function of a bunch of scope settings.

Hi Egge,
Thanks for the link, now looks like script is updated for TDS7000 too.

Just note that factory calibration coefficients are on not the NVRAM but on an EEPROM which should be dumped separately as I wrote earlier.
Ozan

My answers are inline.
Ozan

On Fri, Dec 20, 2024 at 12:15 AM, Wevie wrote:

...
I assume that there is some server running on the Windows parts listening from
request made by the Vxworks bootloader? Or how is filesystem knowledge
implemented otherwise?

TDS7000 service manual 071-0711-03 page 225 shows the general diagram. Windows motherboard and PPC motherboard talk through PCI bus. Video driver is not the one on the Windows MB but on PPC, shared by both motherboards. Windows provides the decorations and PPC provides the waveforms. This way waveforms are displayed with a high refresh rate while Windows takes care of the cosmetics.

If I'm able to stop the Vxworks autoboot I can get this vi-like shell, to run
the commands you provided?

There is a console port inside the box on the PPC board. It is so useful that I punched a hole for a DB9 connector and took it out to back. I can send you pictures of where it is on TDS7104. With the console you can interact with the scope real time.

Other option is to modify the topScript.hw and put your commands. It is not as convenient as you need to reboot for every change. I prefer console port approach.

Just be careful with cc_init() function if you play with it. I believe one of the options overwrites calibration coefficients. If you end up analyzing the code on your scope, and it has the same cc_init function, perhaps you could report back what each option (parameter passed) does.

I will first do the HDD dump, create a normal Vxworks boot trace, and load
some binaries in Ghidra to see what I can already dump without heating up a
soldering iron.

I believe it is possible to dump Dallas RAM and EEPROM from vxWorks. I remember Dallas RAM address was coded as an external variable, vxWorks could display it.
Ozan

Jim,

Your focus control could be dirty. See if it has the tabs on the back that can be bent back enough to put in some contact cleaner. The 1meg resistors and resistor parallel to the focus preset (2meg in this case) in these strings are stressed by the voltage across them. Even the 453/4/A types have this problem even though they are a higher value of resistance. Replace with 1W types. I got 1W 1% types from China on epay. I would get at least 40, if not more, for stock. The 150V zener could be bad. Also replace the two 22meg 1/4W carbons, R1659 and R1684, with Vishay VR37 series.

Mark

Hi Ozan,

" - NVRAM is not on a socket. On TDS7104 you can dump its contents to a file using vxWorks. I think the code is somewhere on EEVblog for a different family of TDS scopes but works on TDS7000 "

The Script/Code you mentioned is from flyte on eevblog. Used it recently to make dumps from my TDS7404B.



Egge Siert

Keith,

The NTV should be NTC.

If you have the memoury backup battery in a brick shape, 667-TL5903P is what I put in mine. It is axial leaded. I mounted the battery a bit off the board while bending the leads to fit in the holes. This current capacity is higher than original and costs less than one in the original shape.

Mark

Thanks, it is fun to watch. One of my favorite components is the dual directly heated gas filled commode diode. It passes all input to ground and must be operated with a septic tank coil in each plate lead. The plates show no color at maximum CCS rating, but increasing load to ICAS ratings will cause it to flush.

??? Bruce Gentry, KA2IVY

Thank you John for sharing the Youtube URL to the original US color version of the Turbo Encabulator



This version was done sometime in 1977 performed by Bud Haggart. Additional information may be found on the wiki pages.
The original concept was apparently from England on the 40's, and in 1962 GE created a published specification sheet.

/g/TekScopes/album?id=299609

I have finally had time to get back to working on my 2465A. First let me review the problem. All of a sudden the scope started displaying an error code "Fail Test 05 Fail 24". Which would clear when I pressed the A/B Trigger. However, the scope would not trigger very well and behaved rather erratically.

Life got in the way and I did not have much time to work on the scope but a friend loaned me his spare 2465A that he does not use. I finally have had time to work on mine. First this forum is a wealth of information... if one has time to comb through all of the years and years worth of posts. Some of the same contributors keep popping up time after time with helpful information (Siggi seems to be one of them) .

My version of the 2465A has a "through hole" A5 board so no spilled guts of the SMD capacitors. So that ruled that problem out. I thought that the power supply my be suspect and need recapping -- even though the voltages all checked out on J119 on the A1 board (Main Board). But learning from posts on the forum that there my be "ripple on the rails" causing the problems I decided that the PSU still might be the issue. So I pulled the PSU. Upon inspection it appeared that it had been recapped at some point in time as many of the capacitors appeared to be newish (not original).

Then it dawned on me that I had a working 2465A at my disposal so I swapped PSUs putting the PSU from my non-working scope into the working scope. It worked just fine. So that ruled out that the PSU was the problem.

From reading the forum postings I got the idea that the problem was somehow related to the DAC ref. Since that is what is effected when the SMD capacitors leak. I probably did not read enough forum posts because many of them say that you should not adjust the DAC reference as it effects the calibration parameters. (BTW I still have the two PSU swapped in the scopes and I wonder if that somehow effects the calibration parameters)

At any rate I followed the DAC ref adjustments and to the best of my knowledge the DAC is spot on in its adjustment.

Some where in the process the failure message went from Test 05 Fail 24 to Test 05 Fail 42 . Then for a brief period the message was gone all together. But that was short lived.

Further reading in the forums lead me to believe that the failure could be related to the Hybrid U500 (which is the trigger hybrid). Well it just so happens that I have a working U500 the other scope. So I swapped them out. Problem solved. No error code on start up. I have found a replacement U500 and have ordered one.

My only questions now are:

1. Should I put the original PSU back in their respective scopes to preserve some calibration parameters?
2. Did I screw up some calibration parameters by adjusting the DAC reference?
3. What should the voltage on pin 13 of J119 be? That seems to be the only difference between the two now working scopes (should I even worry about that) I don't find that (pin 13) voltage spelled out anywhere in the manual except when adjusting the DAC.

Thanks in advance for your thoughts and the thoughts of all of the previous forum gurus who helped me greatly.

John w.

thank you
animal

John Addis discusses this at


Key paragraph:

The 7000 series projection contains four atavistic holes which were once going to hold SMB connectors for the signal and trigger paths. They were designed into the interface at an early date. Roy Hayes (3A3, 3A8 and 7A12 designer) then suggested that an edge connector could be made with adequate HF response and that the connectors and cables would be an unnecessary expense. The SMB connectors were never used.

-George

Watching this topic with interest because I have a 7904 with a focus issue as well. Some resistor(s) has (have) drifted, most likely. Symptom is that I have to turn the focus knob fully CCW to get the trace just barely in focus. Even touching the focus knob at that point will blur the trace into oblivion. Someday I will get around to fixing it…..

Jim Ford
Laguna Hills, California, USA

On Dec 1, 2024, at 21:53 , Adam R. Maxwell <amaxwell@...> wrote:

HI all,

I have an older 7904 (SN < B260000) that I've been happily using, but decided to check Z-axis calibration. Step 4k is where I've hit a wall, so basically right out of the gate. Voltage on TP 1778 to chassis ground is supposed to be 123 ± 3 VDC, and it's 128 V. Unfortunately, R1757 does not change the reading at all.

I kept trying to figure this one out.

Checking DC voltages and annotating the schematic, I had a moment of panic when the 15V test point on the Z-axis board read 14.7, and started looking for a dying tantalum. It turns out the +15 and -15 TPs come after a 4.7 ohm resistor (which had drifted out of tolerance, so I replaced them).

I'm not sure what the autofocus signal should look like, but there's no waveform after Q1775, and replacing Q1775 and Q1777 did not change anything. It's just DC on collector of Q1775, which didn't seem right. At this point, I suspected Q1765 or Q1769, but do not have replacements, and each produced a family of curves on the 7CT1N.

I finally noticed TP1778 voltage read low (<120 VDC) for a few moments as I was starting the scope up, and for that brief time, R1757 could vary that voltage. This inspired me to hit Q1765 and Q1769 with freeze spray, and sure enough, freezing Q1769 temporarily fixes the problem. I'm waiting on an AT5058 that will hopefully be an actual fix for this.

thanks,
Adam

Hi Ozan,

Thank you!! Great information.

I know Vxworks a bit from different embedded systems, this Windows / Vxworks hybrid is something completely new to me.

I assume that there is some server running on the Windows parts listening from request made by the Vxworks bootloader? Or how is filesystem knowledge implemented otherwise?

If I'm able to stop the Vxworks autoboot I can get this vi-like shell, to run the commands you provided?

I will first do the HDD dump, create a normal Vxworks boot trace, and load some binaries in Ghidra to see what I can already dump without heating up a soldering iron.

Thanks again, much appreciated!