开云体育

Please explain more.

On Tue, Mar 4, 2025 at 04:37 PM, Dave Brown wrote:

The museum is open to the public with no admission charge. We participate in
external STEM events for free. The museum relies 100% on volunteers,
donations, and eBay sales for its operation. These sales help keep the museum
open.

Hi Dave,
If you feel that this discussion is harmful to the Museum's revenue stream, then I will certainly "cease and desist". I'm just a hobbyist, and I don't want my interests and curiosities to harm a small business. The museum I work at ( ) struggles with funds of course also. We do charge admission, and have several paid staff in addition to a number of volunteers like me; but we also have over 50 acres of property and 8 or 9 buildings to maintain (one of which is on the CO Historic Register). We host multiple school group tours every week, host STEaM camps, etc. We think we are one of the very best museums of its kind anywhere.

Pete

Nothing shorted nor open on the A9 board

Thank you Craig. The museum is open to the public with no admission charge. We participate in external STEM events for free. The museum relies 100% on volunteers, donations, and eBay sales for its operation. These sales help keep the museum open. If you haven't noticed lately, a lot of museums have folded.

On Tue, Mar 4, 2025 at 03:23 PM, Brian Cockburn wrote:

Open sourcing would be nice, but I would guess that the museum see this as a
(small) revenue generator. Although, an open source set of instructions could
include a request for a donation.

My understanding is that the fellow that wrote the code for the VintageTEK design passed away (per a note from Tom Fang). And I inferred (but could be wrong!) that the source code is lost/missing, so making changes would require a re-write.
Please correct me if these things are not true.

Meanwhile, I want to re-iterate that I won't be selling anything, and I have no interest in "reverse-engineering" someone else's design. If my project (basically just FW/SW) seems useful to someone, I will share it. If a non-profit (such as VintageTEK) feels that sharing my code is a bad thing for them, then we can talk about that... I volunteer at a local Museum every week, so I fully understand the issues.

Pete

Open sourcing would be nice, but I would guess that the museum see this as a (small) revenue generator. Although, an open source set of instructions could include a request for a donation.

As to volume, 25 at a time seems about right to me. Go for 250 and you'll be left with a lot of stock I'd reckon. Demand has been pent up, but is limited.

On Tue, Mar 4, 2025 at 3:09?PM saipan59 (Pete) via groups.io <saipan1959=
[email protected]> wrote:

Correct, AFAIK. The distinction (I think) would be: To draw a line, you
have an X-Y START point, and also an X-Y END point. You could have analog
circuitry that causes the X and Y voltages to move linearly from the start
point to the end point, thus drawing a perfect line.

The 2430 and its ilk have a relatively simple vector generator circuit for
X and Y that recreates absolutely beautiful traces on the CRT. The slope is
generated by subtracting the current and the desired X/Y, which is then
sampled at the appropriate time. I guess to generate arbitrary vectors
you'd want to be able to set a starting point ... or just control the Z
axis as well?

No clear about the role of DC502 here...
T

On Tue, Mar 4, 2025 at 12:49 PM, Craig Cramb wrote:

Leave the design and building to the Tek Museum. They use it to keep the
museum in operation. Soon as they allow everyone to get the design or
reverse engineer the board then it’s for others to run with and take money
away from the original developer.

The same thing has been done many times, for years. Consider all of the "oscilloscope clock" designs out there. Anyone who wishes to support VintageTEK.org should absolutely buy from them (do they actually make a profit on those sales??). As for me, it's an intellectual exercise, which I think some folks on this forum are interested in.

Jimbert wrote:

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.

Correct, AFAIK. The distinction (I think) would be: To draw a line, you have an X-Y START point, and also an X-Y END point. You could have analog circuitry that causes the X and Y voltages to move linearly from the start point to the end point, thus drawing a perfect line.
When an MCU with a DAC is involved, the difference is that there are discrete steps. In my case, there are 4095 steps between 0 volts and 3.3 volts. The DAC output could be LP filtered to give a very close approximation to a true line.
For drawing a picture, it could be made up of a collection of "lines", each with a different position, direction, and length. This is what a vector display does. My simplification is to replace a line with a series of dots.

Pete

Leave the design and building to the Tek Museum. They use it to keep the
museum in operation. Soon as they allow everyone to get the design or
reverse engineer the board then it’s for others to run with and take money
away from the original developer.




On Sun, Mar 2, 2025 at 1:03?PM Dave Brown via groups.io <davebr=
[email protected]> wrote:

We have inventory for another set of 25 and will begin building. Watch the
store. We didn't expect this amount of demand and have a lot of shipping to
tend to this week.

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

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