One of the good things about simulating circuits is that you can easily change component values trivially. In the real world, you might use a potentiometer or a pot to provide an adjustable value. However, as [Ralph] discovered, there’s no pot component in LTSpice. At first, he cobbled up a fake pot with two resistors, one representing the top terminal to the wiper, and the other one representing the wiper to the bottom terminal. Check it out in the video below.
At first, [Ralph] just set values for the two halves manually, making sure not to set either resistor to zero so as not to merge the nets. However, as you might guess, you can make the values parameters and then step them. Continue reading “Simulating Pots With LTSpice”→
If you follow electronics history, few names were as ubiquitous as RCA, the Radio Corporation of America. Yet in modern times, the company is virtually forgotten for making large computers. [Computer History Archive Project] has a rare film from the 1970s (embedded below) explaining how RCA planned to become the number two supplier of business computers, presumably behind behemoth IBM. They had produced other large computers in the 1950s and 1960s, like the BIZMAC, the RCA 510, and the Spectra. But these new machines were their bid to eat away at IBM’s dominance in the field.
RCA had innovative ideas and arguably one of the first demand paging, virtual memory operating systems for mainframes. You can hope they were better at designing computers than they were at making commercials.
There was a time when wise older people warned you to check your tire pressure regularly. We never did, and would eventually wind up with a flat or, worse, a blowout. These days, your car will probably warn you when your tires are low. That’s because of a class of devices known as tire pressure monitoring systems (TPMS).
If you are like us, you see some piece of tech like this, and you immediately guess how it probably works. In this case, the obvious guess is sometimes, but not always, correct. There are two different styles that are common, and only one works in the most obvious way.
Obvious Guess
We’d guess that the tire would have a little pressure sensor attached to it that would then wirelessly transmit data. In fact, some do work this way, and that’s known as dTPMS where the “d” stands for direct.
Of course, such a system needs power, and that’s usually in the form of batteries, although there are some that get power wirelessly using an RFID-like system. Anything wireless has to be able to penetrate the steel and rubber in the tire, of course.
Your new project really could use a block device for Linux. File systems are easy to do with FUSE, but that’s sometimes too high-level. But a block driver can be tough to write and debug, especially since bugs in the kernel’s space can be catastrophic. [Jiri Pospisil] suggestsUblk, a framework for writing block devices in user space. This works using the io_uring facility in recent kernels.
This opens the block device field up. You can use any language you want (we’ve seen FUSE used with some very strange languages). You can use libraries that would not work in the kernel. Debugging is simple, and crashing is a minor inconvenience.
Another advantage? Your driver won’t depend on the kernel code. There is a kernel driver, of course, named ublk_drv, but that’s not your code. That’s what your code talks to.
Space telescopes are all the rage, and rightfully so. The images they take are spectacular, and they’ve greatly increased what we know about the universe. Surely, any picture taken of, say, the Andromeda galaxy before space telescopes would be little more than a smudge compared to modern photos, right? Maybe not.
One of the most famous pictures of our galactic neighbor was taken in — no kidding — 1888. The astronomer/photographer was Isaac Roberts, a Welsh engineer with a keen interest in astrophotography. Around 1878, he began using a 180 mm refracting telescope for observations, and in 1883, he began taking photographs.
He was so pleased with the results that he ordered a reflecting telescope with a 510 mm first-surface mirror and built an observatory around it in 1885. Photography and optics back then weren’t what they are now, so adding more mirrors to the setup made it more challenging to take pictures. Roberts instead mounted the photographic plates directly at the prime focus of the mirror.
Andromeda
This image, captured with the NASA/ESA Hubble Space Telescope, is the largest and sharpest image ever taken of the Andromeda galaxy — otherwise known as M31. This is a cropped version of the full image and has 1.5 billion pixels. You would need more than 600 HD television screens to display the whole image. It is the biggest Hubble image ever released and shows over 100 million stars and thousands of star clusters embedded in a section of the galaxy’s pancake-shaped disc stretching across over 40 000 light-years. This image is too large to be easily displayed at full resolution.
Because it took hours to capture good images, he developed techniques to keep the camera moving in sync with the telescope to track objects in the night sky. On December 29th, 1888 he used his 510 mm scope to take a long exposure of Andromeda (or M31, if you prefer). His photos showed the galaxy had a spiral structure, which was news in 1888.
Of course, it’s not as good as the Hubble’s shots. In all fairness, though, the Hubble’s is hard to appreciate without the interactive zoom tool. And 100 years of technological progress separate the two.
Roberts also invented a machine that could engrave stellar positions on copper plates. The Science Museum in London has the telescope in its collection.
Your Turn
Roberts did a great job with very modest equipment. These days, at least half of astrophotography is in post-processing, which you can learn. Want time on a big telescope? Consider taking an online class. You might not match the James Webb or the Hubble, but neither did Roberts, yet we still look at his plates with admiration.
It is a movie staple to see an overworked air traffic controller sweating over a radar display. Depending on the movie, they might realize they’ve picked the wrong week to stop some bad habit. But how does the system really work? [J. B. Crawford] has a meticulously detailed post about the origins of the computerized air traffic control system (building on an earlier post which is also interesting).
Like many early computer systems, the FAA started out with the Air Force SAGE defense system. It makes sense. SAGE had to identify and track radar targets. The 1959 SATIN (SAGE Air Traffic Integration) program was the result. Meanwhile, different parts of the air traffic system were installing computers piecemeal.
SAGE and its successors had many parents: MIT, MITRE, RAND, and IBM. When it was time to put together a single national air traffic system the FAA went straight to IBM, who glued together a handful of System 360 computers to form the IBM 9020. The computers had a common memory bus and formed redundant sets of computer elements to process the tremendous amount of data fed to the system. The shared memory devices were practically computers in their own right. Each main computing element had a private area of memory but could also allocate in the large shared pool.
The 9200 ran the skies for quite a while until IBM replaced it with the IBM 3083. The software was mostly the same, as were the display units. But the computer hardware, unsurprisingly, received many updates.
If you’re thinking that there’s no need to read the original post now that you’ve got the highlights from us, we’d urge you to click the link anyway. The post has a tremendous amount of detail and research. We’ve only scratched the surface.
We are always amused that we can run emulations or virtual copies of yesterday’s computers on our modern computers. In fact, there is so much power at your command now that you can run, say, a DOS emulator on a Windows virtual machine under Linux, even though the resulting DOS prompt would probably still perform better than an old 4.77 MHz PC. Remember when you could get calculators that ran BASIC? Well, [Calculator Clique] shows off BASIC running on a decidedly modern HP Prime calculator. The trick? It’s running under Python. Check it out in the video below.
Think about it. The HP Prime has an ARM processor inside. In addition to its normal programming system, it has Micropython as an option. So that’s one interpreter. Then PyBasic has a nice classic Basic interpreter that runs on Python. We’ve even ported it to one or two of the Hackaday Superconference badges.
