开云体育

Pete said: "... Each vector can have a default length of "one". That is, each is actually a pixel, which only needs an X and Y position. It's not necessary to "draw proper lines". .... In the MCU, the code simply goes to each pixel position and "lingers" for a short time. ..."

I've never worked with vector displays, but isn't what you describe how it has to be done? You can't just tell a 'scope to draw a line from point A to point B. I guess the only difference would be how the image is stored. In your description, I think the image would be stored as pixels. The alternative would be to specify the vectors in the image file and have the MCU calculate each pixel and then "draw" them as you describe. The latter would make the image file smaller but would place more burden on the MCU. It would boil down to a tradeoff between memory size and speed of redraw (flicker).

Sorry, one more thought:
Making vectors programmatically doesn't have to be difficult: Each vector can have a default length of "one". That is, each is actually a pixel, which only needs an X and Y position. It's not necessary to "draw proper lines". I should be able to handle up to about 5K pixels (much more than is really needed I think). In the MCU, the code simply goes to each pixel position and "lingers" for a short time.
So, the PC program simply looks at each pixel (or group of pixels) in a BMP file, decides if it is 'on' or 'off', and if it's 'on' then output the X and Y values. An optimization would be to send the pixels in a "nearest first" order, to avoid traversing the display more than necessary.

Pete

Meanwhile, in my experiments this morning:
A raster display WITHOUT a Z-axis is looking "impractical". Two issues so far:

1) A 256 X 256 bitmap only updates 4 or 5 times per second. The issue is (primarily) that the pixels are 'compressed' as 8 pixels per byte, so there is code required to 'unpack' individual bits from each of the 8K bytes.

2) To avoid using a Z-axis, my idea was that the dot would move off-screen to the left for any 'blank' pixels. This allows each pixel to be "equal time", which is good. But the limited BW of the MCU's output causes some 'smear'. And, with my test scope (Tek T935), when in X-Y mode the horizontal position control doesn't allow the 'blank' trace to go off-screen. Because it has a high duty-cycle relative to the 'image', it is VERY bright. AND, the T935 is 35 Mhz BW, so on an older, slower scope the smearing and such would be even worse.

So, I think I'll switch to working on a vector-based solution. The only downside I can think of at the moment is that it adds a lot of complexity to the code on the PC that must generate the vectors (I would like to feed it a BMP file, and have it produce a set of vectors). Of course, creating image vectors by hand would be easy (just tedious).

Pete

On Tue, Mar 4, 2025 at 10:34 AM, Nick wrote:

Throwing a raster image on an analog scope misses the point in my opinion. ... Send your bitmap through digital DisplayPort to a digital LCD, it'd look better.

I understand your point, but (to me) the main point is "display something **on an old analog scope**". That is, displaying a GOOD image is NOT the point of the exercise - of course there are much better ways to do that.
As for raster vs vector: a raster is a collection of vectors, perhaps with a Z-vector added.

Pete

Throwing a raster image on an analog scope misses the point in my opinion. One of the biggest advantages of an analog XY display is its ability to draw vectors with infinite resolution, something that no modern digital system can achieve. If you're not going to showcase that capability, then why use XY at all? Send your bitmap through digital DisplayPort to a digital LCD, it'd look better.

On Tue, Mar 4, 2025 at 06:45 AM, Jimbert wrote:

If you used a raster display, would you have parameters in your code for the
number of steps per X and Y lines? It seems like that would be necessary or at
least nice, to handle the BW of different 'scopes. I suppose other parameters
would be required to enable and setup the Z axis and maybe output voltage
ranges on all the axes.

Right. All the important params could be specified by the Windows app that provides the image data.
One real limitation is the memory space of the MSP430FR2355. With an arbitrary monochrome bitmap, the most it will handle is about 300 X 300 pixels. That *might* be plenty to do interesting things with, but I don't know until I try it on a real scope.
Adding the Z-axis, with multiple levels of brightness, increases the memory usage dramatically. But it should work to do 4 brightness levels on 150 X 150 pixels.
Anyway, first I'll focus on monochrome only, and see how it goes.

Pete

The failed component is a 3.3 uF 160V capacitor on the F&I board. C2031.

Sounds good, Pete!

If you used a raster display, would you have parameters in your code for the number of steps per X and Y lines? It seems like that would be necessary or at least nice, to handle the BW of different 'scopes. I suppose other parameters would be required to enable and setup the Z axis and maybe output voltage ranges on all the axes. Lots to think about here.

Came across someone with the same problem which he located to the HV board.

That could well be the case, as the 245B this A9 board came out of has no display either. It's only a small board so if the fault is there it shouldn't take long to identify.

Just a quick update..

After walking away from this 2465 and working on other scopes, following a hunch, I checked the HV board and discovered that the 120-1418-00 high voltage transformer had failed short, hence the lack of display.
Fortunately I have a 2445B waiting to be repaired, with an almost identical HV board, so I popped that into the 2465 and the unit came to life, although the screen is incredibly out of focus.

/g/TekScopes/album?id=301087&p=Taken,,,50,1,0,0

I'll have a read-up of the manual when I get a moment and check out the focus circuit.


James

Hi John,

On Mar 2, 2025, at 16:12 , John Miles via groups.io <john@...> wrote:

Check the CPU's reset line. It's driven by an optocoupler on the power
supply board, as I recall, and the resistor that drives the LED side of the
optocoupler can open up.

I couldn't find an optocoupler in the power supply schematic, and RESET on the processor board schematic led me to GPIB board. Likely that's me being clueless and looking at the wrong thing, but I found an old post of yours that mentioned a 495 using the line-trigger:

/g/TekScopes/message/1938

This motivated me to pull the power supply apart. I found one leg of a RIFA with integrated 22 ohm resistor had a broken solder joint, so I resoldered that and replaced the ugly line trigger RIFA C3085, since I had a reasonable replacement on hand. Put it back together, and it started right up! I'll replace the rest of the ugly RIFAs in the supply when I get parts.

Now back to the service manual and your notes document to try and figure out why I can only see the cal signal and harmonics with a ref level of -70 dBm (and no signals at all on higher bands).

thanks,
Adam KK7ASV

Hi, Thank you for your message and suggestions. As I mentioned, the acquisition board is shorted, and I have isolated the op-amps and, if I am not mistaken, some CMOS components connected to the +5V and +15V lines, along with some resistors and capacitors that are causing the short.
I just need to locate the input pins for these voltages to apply a small, limited voltage and see which of them generates heat. I know I can apply the voltage to a capacitor, but I’m not sure if it would be the same.
Do you have any suggestions? Thanks in advance.
P.S.: The CRT board is disconnected.

FWIW, I'm starting to work on a version that uses an off-the-shelf MCU board, so no assembly is required other than connecting to the vertical and horizontal of a scope, and powering the board (via a USB connector).
And my intent is to make a Windows console app that processes an arbitrary BMP image, and talks to the MCU board via USB to load the 'image' into the board for display. So the image can be changed at any time.

This morning I did a "proof of concept" to verify that I can control multiple analog outputs from the MCU board. The output voltage is 0 to 3.3. The 'bandwidth' of the output has limits - basically a slew rate limit. So small changes in the output are fast, but large step-function changes show some 'rounding'. But it seems to be plenty fast for a CRT display.
The "catch" is (of course) that the rest of the firmware/software still needs to be written... ;-)

The board I'm using is this:

It's only $13 from T.I. I've used this board, and many similar T.I. boards, on various projects (and in my "real job" at HP before I retired). It supports four analog DAC outputs, so I'm thinking that I can support X, Y, and Z axes on a scope.
It implements a USB "console" port, which is easily discovered by Windows as a COM: port. I assume that other OS platforms would do it also. The 5V on the USB port also powers the entire board.

In the SW, my first thought is that a raster display would be easiest (given that a BMP file is the input). And with Z-axis intensity control, it would probably make nice displays of detailed images(?).
But a vector display would also have advantages (more like what the VintageTek board does). Needs more thought...

For a case that does NOT include the Z-axis, I'm thinking that a 'hybrid' of raster and vector would be an easy thing to try: that is, with a monochrome image, the dot moves very quickly over the 'black' parts of a scan line, but 'lingers' on the 'white' parts.

Anyway, if/when I come up with anything that works, I'll be glad to share it.

Pete

Open sourcing the design would be awesome. :)

Regards
Jared

Another vote for a kit version.

Leo: More than that, the very wideband CTs us distributed wdgs and terms and low perm GHz material.

see the excellent Tektronic Circuits Concepts



Oscilloscope Probe circuits



Probe Measuremens



Jon

Ed, David, thank you for the CM choke reminder.
I needed this for 10MHz sinewave but it's a good idea to keep things tidy at the higher end.
Leo

I have successfully made a CT-6 replacement by taking apart an ethernet transformer (Bourns SM51108), cutting off the old windings and winding 10 turns of thin wire on the toroid.
This transformer model is not moulded, coils are just glued to the inside of the empty tub shell.

After testing it with 50mV source in series with 50R load (1mA primary current) I got exactly 5mV/mA response on the secondary into a 50R load (SA or RF voltmeter.) BW is from 70kHz (-3dB) to 2GHz+.

Still, if there is anyone in the UK who has original Tek CT-6 I'd like to borrow it for a few days to X-ray it.

Leo

I have not read all the other responses so apologies if this is a repeat.
I owned a 744 once with the same hiccup behavior. The CRT driver circuit was bad. You report that you have (had) good VGA from the back panel, and that's what I had.
I was able to temporarily remove the connector to the CRT circuit (I believe it was a small four-pin connector) and then the scope powered up and I was able to use it with the VGA output.
After that I was able, some how, to troubleshoot and repair the CRT board, but I see someone has offered to help with replacement boards so that would be the way to go.
Good luck and of course keep us posted.
dan

I was thinking the same thing, make a kit out of it?