Inside Air Traffic Control

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.

There were earlier control systems, some with groovy light pens. These days, the control tower might be in the cloud.

BASIC On A Calculator Again

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.

Continue reading “BASIC On A Calculator Again”

Robot Sees Light With No CPU

If you ever built a line following robot, you’ll be nostalgic about [Jeremy’s] light-seeking robot. It is a very simple build since there is no CPU and, therefore, also no software.

The trick, of course, is a pair of photo-sensitive resistors. A pair of motors turns the robot until one of the sensors detects light, then moves it forward.

Continue reading “Robot Sees Light With No CPU”

Tolerating Delay With DTN

The Internet has spoiled us. You assume network packets either show up pretty quickly or they are never going to show up. Even if you are using WiFi in a crowded sports stadium or LTE on the side of a deserted highway, you probably either have no connection or a fairly robust, although perhaps intermittent, network. But it hasn’t always been that way. Radio networks, especially, used to be very hit or miss and, in some cases, still are.

Perhaps the least reliable network today is one connecting things in deep space. That’s why NASA has a keen interest in Delay Tolerant Networking (DTN). Note that this is the name of a protocol, not just a wish for a certain quality in your network. DTN has been around a while, seen real use, and is available for you to use, too.

Think about it. On Earth, a long ping time might be 400 ms, and most of that is in equipment, not physical distance. Add a geostationary orbital relay, and you get 600 ms to 800 ms. The moon? The delay is 1.3 sec. Mars? Somewhere between 3 min and 22 min, depending on how far away it is at the moment. Voyager 1? Nearly a two-day round trip. That’s latency!

Continue reading “Tolerating Delay With DTN”

The Random Laser

When we first heard the term “random laser,” we did a double-take. After all, most ordinary sources of light are random. One defining characteristic of a traditional laser is that it emits coherent light. By coherent, in this context, that usually includes temporal coherence and spatial coherence. It is anything but random. It turns out, though, that random laser is a bit of a misnomer. The random part of the name refers to how the device generates the laser emission. It is true that random lasers may produce output that is not coherent over long time scales or between different emission points, but individually, the outputs are coherent. In other words, locally coherent, but not always globally so.

That is to say that a random laser might emit light from four different areas for a few brief moments. A particular emission will be coherent. But not all the areas may be coherent with respect to each other. The same thing happens over time. The output now may not be coherent with the output in a few seconds.

Baseline

A conventional laser works by forming a mirrored cavity, including a mirror that is only partially reflective. Pumping energy into the gain medium — the gas, semiconductor, or whatever — produces more photons that further stimulate emission. Only cavity modes that satisfy the design resonance conditions and experience gain persist, allowing them to escape through the partially reflecting mirror.

The laser generates many photons, but the cavity and gain medium favor only a narrow set of modes. This results in a beam that is of a very narrow band of frequencies, and the photons are highly collimated. Sure, they can spread over a long distance, but they don’t spread out in all directions like an ordinary light source. Continue reading “The Random Laser”

Windows? Linux? Browser? Same Executable

We’ve been aware of projects like Cosmopolitan that allow you to crank out a single executable that will run on different operating systems. [Kamila] noticed that the idea was sound, but that the executables were large and there were some limitations. So she produced a 13K file that will run under Windows, Linux, or even in a Web browser. The program itself is a simple snake game.

There seems to be little sharing between the three versions. Instead, each version is compressed and stitched together so that each platform sees what it wants to see. To accommodate Windows, the file has to start with a PE header. However, there is enough flexibility in the header that part of the stub forms a valid shell script that skips over the Windows code when running under Linux.

So, essentially, Windows skips the “garbage” in the header, which is the part that makes Linux skip the “garbage” in the front of the file.

That leaves the browser. Browsers will throw away everything before an <HTML> tag, so that’s the easy part.

Should you do this? Probably not. But if you needed to make this happen, this is a clear template for how to do it. If you want to go back to [Kamila’s] inspiration, we’ve covered Cosmopolitan and its APE format before.

Philips Kid’s Kit Revisited

[Anthony Francis-Jones], like us, has a soft spot for the educational electronic kits from days gone by. In a recent video you can see below, he shows the insides of a Philips EE08 two-transistor radio kit. This is the same kit he built a few months ago (see the second video, below).

Electronics sure look different these days. No surface mount here or even printed circuit boards. The kit had paper cards to guide the construction since the kit could be made into different circuits.

Continue reading “Philips Kid’s Kit Revisited”