I also had an ASR-33 and when I tried to give it away the response came back "What's that?" Before the days of politically correct garbage disposal, I just set it out on the curb next to the garbage can and it was taken away to the dump.
Thos ole shaker suystems packed a real punch if you weren't careful. I remember one test on a rack frame for a microwave system - the test went up in frequency until there was an ear-splitting screech and the frame came apart all over the lab. The operator's comment to the mechanical designer was, "Well, now you know."
And if your nostalgia instinct is strong enough, I have an ASR-33 in my garage - they're remarkably difficult to give away! But my daughter learned to write on it, so it had a second life.
My uncle worked for the company, I remember going to one of those open houses when I was 10-12 years old, unfortunately I missed the one with the incident in this story but remembered playing with the equipment and having what I typed pop up across the room, great stuff at that age (the incident would have been more fun). Thank you for the memory.
The lesson also holds for more modern devices as well. Take a microcontroller-driven motor control. If you're designing the firmware on the driver board, you can assume that it will always be powered up properly, with enough gradation to prevent giant power spikes. Then when someone drives it and accidentally sends control signals from zero to 100% in one processor machine cycle, it will spike and blow or just lurch off at full power risking mechanical damage.
Alternately, you can build in protection schemes that will assume that someone might just "forget to turn the gain down" when powering on.
The lesson here should stike a chord with amp designers/builders. The "click" of switching to a different signal source with potentially different DC offset can potentially destroy a speaker (or speakers) on a high power rig. This could be rather expensive when restoring vintage audio gear.
I remember those teletypes; we had one for our "computer class" in junior high-school (BASIC). It was connected to the "mainframe" in Boston, MA. We had to write our program out on paper (!), verify it by hand, then enter it (type it in) line by line. You had to wait in between lines for an acknowledgement before entering the next line. Once it was entered it was saved to punch tape. The next day you could go pick up the results of the run. And people complain about Windows...
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.