Hacker News new | past | comments | ask | show | jobs | submit login
Cartoons in Tektronix Schematics (vintagetek.org)
120 points by segfaultbuserr 81 days ago | hide | past | web | favorite | 40 comments



The magnum opus of Jim Williams known as "App Note 47" has a cartoon at the end, and possibly a few more in the middle. As well as a copy of "Murphy's Law".

The cartoons in schematics are very much a product of their time - they were hand-drawn by skilled draftsmen who enjoyed drawing. I suspect most of them had a spare pad of doodles next to their work table.


They also attempted to make schematics logically cohesive, if possible. For example, in oscilloscopes signal paths are typically differential and DC coupled, but there are often sections where high and low bandwidth components are fed through different paths. In Tektronix schematics these symmetries and asymmetries, which paths are critical and which aren't, which things may look symmetric but are not, these are all very visible. This isn't always possible, though. For example, the Z blanking signalling in 7000 series scopes is distributed over approximately six or seven circuit boards just in the main frame, and the schematic drawers clearly came to their limits trying to pull this together into cohesiveness.

If you compare this to the schematics of more modern electronics, they are often madness. Even though it is far simpler to re-arrange schematics using EDA, it clearly isn't done a lot, because parts are sprinkled around randomly, everything is just on one enormous sheet or everything is randomly split up across sheets with numbered net names making connections etc.


As someone who's worked on (and drafted!) several schematics in the aerospace industry, I have to say: there's no reason it has to be that way!

The places I've worked have pretty rigorous style guides, and I personally try my best to make schematics readable and understandable. I suppose this is the same thing as code quality guidelines: you can set expectations and examples, but folks don't necessarily have to follow them.

My cooler projects are all stashed away somewhere in a company drawer, but here's one that I did early on: https://bitbucket.org/cyanoacry/ee91/raw/5d934fdc18e556938dc...


Some critique

- psu drawing: no left-to-right flow, connector names are numbered, output connector (CONN2) is just floating around on the left and connected via net names. Same pretty generic net name ("out") is used as in the main amp.

- amplifier drawing: the main feedback loop is obscured because it's only connected via net names, connectors are again just stashed of somewhere to the side and only connected by name and not labelled. I would also point out that each op-amp of the quad-op-amp U1 shares the same designator, so you can't talk about U1a, U1b etc., which you actually do in the text.

The left half of the schematic is arranged pretty neatly and logically, but the discrete output stage is pretty cramped over there (clearly limited by the fixed sheet size), though standard arrangements of the building blocks make it quite clear what everything is (U1c U/I conversion, current mirror to the top rail, mirrored back to the bottom rail with an x3 CM, resistive load to the top, emitter follower output stage, CCS as load, off to the output).


Nice little project. I wonder if the SiC MOSFETs that are becoming widely available would help with doing that kind of design?


Maybe! I've worked with some SiC FETs, but the issue I ran into with FETs in amplifiers is that they're typically made with switching in mind. If you run most FETs in linear mode, you get some pretty interesting failure modes[1].

But, Wolfspeed's SiCFETs /do/ have a published SOA (see fig 22[2]), so maybe I should revisit this...

[1] Figure II-3: "Visual Image of the IRF1405Z failure. This type of visual pattern is more attractive when observed on the surface of the moon, instead of on the surface of parts that are trying to land there." http://www.irf.com/technical-info/appnotes/an-1155.pdf

[2] https://www.wolfspeed.com/downloads/dl/file/id/145/product/1...


Even FETs that have a published SOA, it often ends up being roughly "don't spend more than about 10% duty cycle in the linear region" because FETs have been so strongly optimized for switching applications.


I got a good chuckle out of

1. We can ensure that they won’t explode when we use them.

(admittedly I understood very little after that ;P)


I wonder if it's easier or harder to do something like this in a modern corporate environment.

Wikipedia has a list of software easter eggs, let's see if we'll discover more of them as time goes on.


I used to like easter eggs in software but as the security landscape has changed, easter eggs now show a lack of oversight. If a programmer can slip in an easter egg, what else can they slip in?

Larry Osterman says it even better: https://blogs.msdn.microsoft.com/larryosterman/2005/10/21/wh...


>easter eggs now show a lack of oversight

no. Easter eggs show lack of "zero tolerance" corporate posturing. Which isnt to say that such posturing isnt important part of the security theater.

The cartoons, easter eggs, etc. is a "human touch", a sign that the product is done by people who love (or at least feeling something toward) their job, not by drones. Modern corporate environment is based on droning and has naturally extinguished that human culture.


If you don't have the source code, you can't "trust what's on your computer," as Osterman puts it. Easter eggs have no impact on that axiom one way or the other.

So, coming from Microsoft, it's easy to dismiss the entire article based on its initial premises.


Did he really unironically post a link to adequacy.org?

[edit]

For those less familiar, feel free to browse adequacy.org, or just read this gem:

http://www.adequacy.org/public/stories/2001.12.2.42056.2147....


I think the best solution is to add an "easter eggs" section to the manual. Few people read the manual, so they're still hidden enough.


If they are documented, as a user I would still think, "What else could they have been improving/fixing if they weren't working on easter eggs?" I wonder if in an alternate world, Excel minus the flight simulator easter egg could have been $1 cheaper or had 5 more bugs fixed.


As a dev, I can relate to working overtime for a small eater egg, or even if I were a manager I could understand those (security implications notwithstanding) if it would boost morale or team cohesion better than an akward social event.


That's an amazingly entitled viewpoint, in my opinion. There's also a rabbit hole there of saying that about any feature that one doesn't make use of.

I understand the concept that maybe certain classes of software (say, medical or military software) shouldn't have eggs, or perhaps that certified eggless versions of software should be available in situations involving contracted software. But would you say the same thing about game software? Hobbyist software? Easter eggs aren't always bad.


> I wonder if in an alternate world, Excel minus the flight simulator easter egg could have been $1 cheaper or had 5 more bugs fixed.

if anything, i think that Excel would have much more bugs, and would have much tougher time taking off :)


Evil can come from above.

Scratch that.

Evil usually comes from above.


So we shouldn't address evil from "below"?


No, but addressing "evil from below" by tightening the top-down control of "evil from above" doesn't minimize evil. Quite the opposite.


I can tell you firsthand that there are a number of software Easter eggs in the modern oscilloscopes made by a prominent competitor to Tek


Amusingly enough, one triggered by the string "TREK". ;)


I'm a fan of "CAKE" myself


What schematics?

That was an eons ago different era.


A picture of my old Tektronix 2225's warning tag:

https://i.imgur.com/jYNCC4d.jpg


I like a bit of whimsy in otherwise dry stuff. We try to enliven the D language spec with a D-Man cartoon here and there. I'd do more if I had any talent for drawing.

https://dlang.org/spec/iasm.html

Go's gopher cartoons are a nice touch, too.


I love finding easter eggs in die layouts. Even if it's not an easter egg but just someone's name, it's always nice to see how people have chosen to essentially scratch their name into history.


> scratch their name into history.

etch their name into history ;-)


To my surprise there is a museum right down the street from my house (Beaverton/Portland, OR USA). That I must have just been missing. Thanks for posting!


Glad to see my post brings a nice trip to you.

From the comment sections, it appears to me that Hacker News has no shortage of hobbyists and professional electronics engineers, but when I search relevant terms like "Tektronix", "oscilloscope", "spectrum analyzer", or "SPICE", there's no much information here, only two or three top articles. I guess it's unfamiliar to the Silicon Valley CS majority who doesn't have enough appreciate of hardware engineering. I'll try to post more of them in the future.


Absolutely go. I repair these scopes as a hobby and the people at the tek museum have been endlessly helpful. Repairing old tek designs and reading the schematics has made me a much better analog engineer.


Hey I'm in Cedar Mill and used to live practically across the street from Tektronix. My email is in my profile if you want to get coffee or check out the museum together. :-)


Somewhat distantly related - the Pro One synthesizer from the early 1980s had some "appropriate" graphics silkscreened on the PCB and the copper etch. A list and photos here:

https://jamebus.backpackit.com/pub/294552


Great cartoon overview of switching power supplies from TDK:

https://www.global.tdk.com/news_center/publications/power_el...


I wonder if cartoons like these (a distinct form of cartoons, unlike Tektronix) is a feature in Japanese media communication culture. I've seen similar comics of this style in Hakko's soldering 101 marketing materials [0], factsheets of Panasonic's solid aluminum capacitors, and user guides of Japanese laptops like Toshiba and Sony.

[0] https://www.hakko.com/english/hikaru/pages/

Hikaru's diary on learning to solder. A short story about soldering, from basic tools and safety precautions for getting started to solder things, good and bad solder joints, and the purpose of flux, it later goes on to explain how simple and thermal-regulated irons and how their heating elements work, point soldering and drag soldering techniques for SMD components, wave soldering and reflow soldering, and finally SnPb and lead-free alloy.


Back at the hi fi shop in the mid ‘70’s my older brother came over to my bench with a big smile to show me an amplifier schematic with a race car drawn on the arrow indicating an output.

We were simple people then finding amusement in the smallest things


It isn't such a small thing but rather emblematic of a culture killed off by Danaher.


Man thats just how things are now


I miss my old Tektronix Oscilloscope... I was learning electronics, a whole new world opened up. That was a great feeling, probably why I keep learning new software languages.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: