Tag Archives: geek-life/hands-on

This Classic Calculator Was Literally Reverse Engineered From the Bare Metal

Post Syndicated from Stephen Cass original https://spectrum.ieee.org/geek-life/hands-on/this-classic-calculator-was-literally-reverse-engineered-from-the-bare-metal

Was the Sinclair Scientific calculator elegant? It certainly was a hit, gracing the cover of publications like Popular Mechanics after its release in 1974. Cleverly written firmware dragooned its limited processor, intended only for basic arithmetic, into performing way beyond specifications. This allowed Sinclair to sell a scientific calculator to countless folks who otherwise could not have afforded one. But it was also slow and sometimes inaccurate, provided barely enough mathematical functions to qualify as a scientific calculator, and was difficult for the uninitiated to use.

I’d vaguely known of this calculator because of its place as a milestone toward the birth of the British microcomputer industry and such beloved machines as the Sinclair ZX Spectrum. So I clicked when I came across Chris Chung’s replica kit of the calculator on the Tindie marketplace. Then I read the description of how the original calculator worked—scientific notion only? no “equals” button?—and how the replica reproduced its behavior, by using an emulator running firmware that had been reverse engineered by visually examining the metal of an original processor. This I had to try.

Let’s first get to the hardware. The kit is one of a number of Sinclair calculator replicas, but it wins points for simplicity: One chip and a credit-card-size printed circuit board are combined with a small handful of discrete components. Chung actually offers two kits: his original, developed in 2014 but put on Tindie in late 2019, displays numbers using two small QDSP-6064 bubble LED modules [PDF], which have the classic look of 1970s calculators but are long discontinued and hard to get. His 2020 update of the kit uses modern seven-segment LED displays. The difference in rarity is reflected in the price: The 2020 version costs US $39, while the original version costs $79. However, in a nice touch, the original version lets you have your cake and eat it with regard to the bubble LEDs: The through holes in the PCB are sized to create a friction fit. This means you don’t have to solder in the modules, preserving them for some future project.

Both versions are functionally identical, based around a MSP430 microcontroller. The MSP430 eliminates the need for most of the other components found in the Sinclair Scientific, and runs an emulator of the TMS080x family of chips. The TMS080x family was built by Texas Instruments (TI), and specific versions, like the TMS0805 used in the Sinclair Scientific, were differentiated by the contents of the chip’s 3,520-bit ROM.

For many years, how Sinclair coaxed this chip into performing magic remained locked away in TMS0805 chip ROMs. That began to change in 2013, when Ken Shirriff got wind of the Sinclair Scientific after getting involved with the Visual 6502 team. This group likes to reverse engineer classic chips, for which the original design drawings are often lost. Sometimes this involves etching chip packages away with acid and carefully photographing the exposed silicon dies with a microscope to see the individual transistors. Shirriff was able to create a generic simulator of a TMS080x chip in JavaScript just by studying Texas Instruments’ patent filings, but the specific code used in the Sinclair’s TMS0805’s ROM still eluded him, until Visual 6502 team member John McMaster took photographs of an exposed die in 2014.

Shirriff is no stranger to IEEE Spectrum due to his extensive work in the history of computing, so I emailed him to ask how he’d gone from a micrograph to working code. By looking at how the metal oxide gates were laid down in the ROM section of the chip, “I was able to extract the raw bits the same day,” Shirriff wrote back. “Phil Mainwaring, Ed Spittles, and I spent another day figuring out how the raw bits corresponded to the code….The code was 320 words of 11 bits, but the ROM was physically 55 rows and 64 columns.…Through a combination of examining the circuitry, analyzing patterns in the bits, and brute-force trying a bunch of combinations, we figured out the arrangement and could extract the code.”

Once he had the code loaded into his simulator, Shirriff could tease out its workings. The algorithms used throughout “were essentially the simplest brute-force algorithms that could get an answer. But there were some interesting mathematical tricks they used to get more accuracy, not to mention programming tricks to get the code to fit,” he explained. (If you want detailed explanations, Shirriff maintains an online version of his simulator that lets you step through the code, line by line.)

The Sinclair Scientific was able to reduce complexity by using reverse Polish notation, in which mathematical operators come after the numbers they are operating on—for instance, “5 + 4 =” becomes “5 4 +.” The trigonometric functions used an iterated approximation technique that could take several seconds to produce results and were often accurate only to the first three significant figures. The calculator also used fixed scientific notation for everything—there was no way to enter a decimal point. So rather than entering “521.4,” you’d enter “5214,” which is displayed as “5.214”; then you’d press “E” and enter “2,” making the number “5.214 x 102.” Only one number could be entered at a time.

On paper this looks terrible, something you’d have used only if you couldn’t afford, say, the HP-35, whose designers prided themselves on accuracy and functionality (although the HP-35 also used reverse Polish notation, it did so in a more sophisticated way).

But Sinclair wasn’t trying to compete against other calculators; he was competing against slide rules. I’d read that point in histories before, but I didn’t really understand its meaning until I held this kit in my hand. By chance, I’d also recently purchased a vintage Pickett slide rule and learned how to do basic operations with it, thanks to the lessons available on the International Slide Rule Museum website. As I used the Sinclair Scientific, I was struck by how conceptually similar it was to using my slide rule. There, two- to three-figure accuracy is the norm, the rule’s sliding “cursor” means you’re passing just one number between scales, and you typically don’t bother about magnitudes—you work with the most significant figures and make a mental estimate to insert the decimal point at the end, so that 52 x 2 and 5,200 x 20 are calculated in exactly the same way.

This realization is why I feel replica kits are so important—they are an easy way to provide the understanding that only comes from operating a device with your own hands. It was a great reminder that, as folks like Henry Petroski have pointed out, good design is not really something that exists as an abstract ideal but as something that exists only within a specific context. So, was the Sinclair Scientific elegant? For me, the answer is a resounding yes.

This article appears in the June 2020 print issue as “The Sinclair Scientific, Remade.”

9 New Suggestions For Bored Engineers

Post Syndicated from Stephen Cass original https://spectrum.ieee.org/tech-talk/geek-life/hands-on/9-new-suggestions-for-bored-engineers

IEEE COVID-19 coverage logo, link to landing page

Like many of you, IEEE Spectrum’s staff is still working from home. As the weeks have turned into months, we’ve had to find ways to occupy our minds and hands. A few weeks ago, we looked through Spectrum’s archives to find 19 things you can do with minimal space and resources. Now here’s a new selection of ideas to keep cabin fever at bay:

Build A Sophisticated Microscope Using Lego, 3D Printing, Arduinos, and a Raspberry Pi

Post Syndicated from Yuksel Temiz original https://spectrum.ieee.org/geek-life/hands-on/build-a-sophisticated-microscope-using-lego-3d-printing-arduinos-and-a-raspberry-pi

I am a member of a team at IBM Research–Europe, in Zurich, developing microfluidic technologies for medical applications. Two years ago, I was asked to provide high-quality photos and videos of our microfluidic chips for a big tech event. I borrowed a 4K camcorder from a colleague, attached a macro lens to it, built a custom light diffuser using an LED matrix and polyester film, and positioned everything using a high-end tripod and a few micromanipulators. I was able to take eye-catching videos as liquids filled microfluidic channels. It was clear to me that this should be the new level of quality and style for our publications and presentations. However, my photo setup occupied half a bench in our lab and it required hours of fine adjustments to record one shot.

We have a tradition of inventing microscopes at IBM in Zurich. In 1981, Gerd Binnig and Heinrich Rohrer created the scanning tunneling microscope here. As a DIY enthusiast, I quickly found myself in my own quest to build a better setup. The result was a US $300 modular and motorized microscope that combines my three favorite adulthood hobbies: Arduino, Raspberry Pi, and Lego.

Taking a photo of a microfluidic chip is not easy. The chips are typically too big to fit into the field of view of a standard microscope, but they have fine features that cannot be resolved using a regular camera. Uniform illumination is also critical because the chips are often made of highly reflective or transparent materials. Looking at publications from other research groups, it’s obvious that this is a common challenge. With this motivation, I devoted some of my free time to designing a multipurpose and compact lab instrument that can take macro photos from almost any angle.

My first prototype was a Raspberry Pi camera module mounted on a stage that could be moved in three dimensions using the mechanisms of linear stepper motors from old CD-ROM drives. The Raspberry Pi camera was an ideal choice because it allows the manual adjustment of critical parameters like ISO settings and exposure time. I carefully removed the plastic casing holding the lens, revealing the CMOS image sensor, and engineered a delicate mechanism to move the lens back and forth in fine steps so I could take high-magnification macro photos. The setup worked well for a while, but it was fragile. I broke the lens mechanism and damaged the image sensor several times by accidentally forcing the moving parts beyond their limits.

I decided to take a different approach. I removed the lens entirely from the Pi camera. Then I took the objective lens from a low-cost USB microscope and mounted it on another CD-ROM linear actuator so that the objective lens could move back and forth along the optical axis of the Pi camera. I built a housing from Lego bricks to shield the camera’s exposed sensor.

However, this attempt resulted in nothing but an appreciation of the high price tag of the linear stages used in microscopes: The travel distance of the CD-ROM actuator was too short to achieve a wide magnification range.

I switched to a lead-screw mechanism used in 3D printers. Instead of commonly used 8-millimeter-diameter threads, shafts, and bearings, I used 3-mm-diameter components to keep things compact. Also, moving the objective lens caused problems in eliminating stray light, so I decided to move the camera sensor instead. I built a stage that allowed the object being imaged to be moved along the x and y axes and rotated. In total, I wound up with six miniature stepper motors with gearboxes that allow me to move the stage, tilt the microscope, adjust its distance to the object, and focus the image.

I often design my own Arduino boards for a more compact implementation. This time, I designed a board measuring 18 by 18 mm and featuring an ATtiny84 microcontroller and a DRV8834 [PDF] stepper-motor driver. The setup gave surprisingly good image quality, for not only beauty pictures of chips but also for examining features with dimensions of a few micrometers, and even as a digital goniometer for measuring contact angles. I had started the project for a specific need, but it became clear to me that this could be a multipurpose imaging system that anyone can assemble and use at home or school.

IBM and my managers supported me in publicly sharing the assembly instructions. However, as I prepared the instructions for public releases, several issues started bothering me. I had built everything using a state-of-the-art 3D printer and a fully equipped mechanical workshop. Also, the small stepper motors I used were expensive and not available in popular hobby electronics stores. Programming the ATtiny84 via a dedicated ISP programmer was certainly not as easy as programming commercial Arduino boards with a USB port. I went back to the drawing board and redesigned everything using easily accessible components, for example Arduino boards and stepper-motor drivers from Adafruit Industries, and 28BYJ-48 stepper motors, which can be found anywhere for a few dollars. I also replaced the LED-matrix light source with a more maker-friendly and lower-cost version. I bought an LED backlight module from Adafruit for $3 and attached a high-power LED. The intensity was slightly lower than that of the original LED matrix but the uniformity was pretty good for both reflected- and transmitted-light microscopy. For the new linear actuators, I combined “sliding” pieces from Lego with a rack-and-pinion gear combination that I designed using FreeCAD’s gear toolbox and printed using my personal Creality Ender 3 Printer. The new design worked as well as the previous one, if not better.

There are probably still many things that could be improved, and I hope this prototype persuades other makers to try new and better ideas. Could it replace a laboratory microscope? Maybe not, but it’s a great solution for budget-constrained schools, which is why we have made the instructions open source for everyone to access and enjoy.

This article appears in the May 2020 print issue as “The Lego Microscope.”

Build This 8-Bit Home Computer With Just 5 Chips

Post Syndicated from Matt Sarnoff original https://spectrum.ieee.org/geek-life/hands-on/build-this-8bit-home-computer-with-just-5-chips

There’s something persistently appealing about 8-bit computing: You can put together a self-contained system that’s powerful enough to be user friendly but simple enough to build and program all by yourself. Most 8-bit machines built by hobbyists today are powered by a classic CPU from the heroic age of home computers in the 1980s, when millions of spare TVs were commandeered as displays. I’d built one myself, based on the Motorola 6809. I had tried to use as few chips as possible, yet I still needed 13 supporting ICs to handle things such as RAM or serial communications. I began to wonder: What if I ditched the classic CPU for something more modern yet still 8-bit? How low could I get the chip count?

The result was the Amethyst. Just like a classic home computer, it has an integrated keyboard and can generate audio and video. It also has a built-in high-level programming language for users to write their own programs. And it uses just six chips—an ATMEGA1284P CPU, a USB interface, and four simple integrated circuits.

The ATMEGA1284P (or 1284P), introduced around 2008, has 128 kilobytes of flash memory for program storage and 16 kB of RAM. It can run at up to 20 megahertz, comes with built-in serial-interface controllers, and has 32 digital input/output pins.

Thanks to the onboard memory and serial interfaces, I could eliminate a whole slew of supporting chips. I could generate basic audio directly by toggling an I/O pin on and off again at different frequencies to create tones, albeit with the characteristic harshness of a square wave. But what about generating an analog video signal? Surely that would require some dedicated hardware?

Then, toward the end of 2018, I came across the hack that Steve Wozniak used in the 1970s to give the Apple II its color-graphics capability. This hack was known as NTSC artifact color, and it relied on the fact that U.S. color TV broadcasting was itself a hack of sorts, one that dated back to the 1950s.

Originally, U.S. broadcast television was black and white only, using a fairly straightforward standard called NTSC (for National Television System Committee). Television cathode-ray tubes scanned a beam across the surface of a screen, row after row. The amplitude of the received video signal dictated the luminance of the beam at any given spot along a row. Then in 1953, NTSC was upgraded to support color television while remaining intelligible to existing black-and-white televisions.

Compatibility was achieved by encoding color information in the form of a high-frequency sinusoidal signal. The phase of this signal at a given point, relative to a reference signal (the “colorburst”) transmitted before each row began, determined the color’s underlying hue. The amplitude of the signal determined how saturated the color was. This high-frequency color signal was then added to the relatively low-frequency luminance signal to create so-called composite video, still used today as an input on many TVs and cheaper displays for maker projects.

To a black-and-white TV, the color signal looks like noise and is largely ignored. But a color TV can separate the color signal from the luminance signal with filtering circuitry.

In the 1970s, engineers realized that this filtering circuitry could be used to great advantage by consumer computers because it permitted a digital, square-wave signal to duplicate much of the effect of a composite analog signal. A stream of 0s sent by a computer to a television as the CRT scanned along a row would be interpreted by the TV as a constant low-analog voltage, representing black. All the 1s would be seen as a constant high voltage, producing pure white. But with a sufficiently fast bit rate, more-complex binary patterns would cause the high-frequency filtering circuits to produce a color signal. This trick allowed the Apple II to display up to 16 colors.

At first I thought to toggle an I/O pin very quickly to generate the video signal directly. I soon realized, however, that with my 1284P operating at a clock speed of 14.318 MHz, I would not be able to switch it fast enough to display more than four colors, because the built-in serial interfaces took two clock cycles to send a bit, limiting my rate to 7.159 MHz. (The Apple II used fast direct memory access to connect its external memory chip to the video output while its CPU was busy doing internal processing, but as my computer’s RAM is integrated into the chip, this approach wasn’t an option.) So I looked in my drawers and pulled out four 7400 chips—two multiplexers and two parallel-to-serial shift registers. I could set eight pins of the 1284P in parallel and send them simultaneously to the multiplexers and shift registers, which would convert them into a high-speed serial bitstream. In this way I can generate bits fast enough to produce some 215 distinct colors on screen. The cost is that keeping up with the video scan line absorbs a lot of computing capacity: Only about 25 percent of the CPU’s time is available for other tasks.

Consequently, I needed a lightweight programming environment for users, which led me to choose Forth over the traditional Basic. Forth is an old language for embedded systems, and it has the nice feature of being both interactive and capable of efficient compilation of code. You can do a lot in a very small amount of space. Because the 1284P does not allow compiled machine code to be executed directly from its RAM, a user’s code is instead compiled to an intermediate bytecode. This bytecode is then fed as data to a virtual machine running from the 1284P’s flash memory. The virtual machine’s code was written in assembly code and hand-tuned to make it as fast as possible.

As an engineer working at Glowforge, I have access to advanced laser-cutting machines, so it was a simple matter to design and build a wooden case (something of a homage to the wood-grain finish of the Atari 2600). The mechanical keyboard switches are soldered directly onto the Amethyst’s single printed circuit board; it does have the peculiarity that there is no space bar, rather a space button located above the Enter key.

Complete schematics, PCB files, and system code are available in my GitHub repository, so you can build an Amethyst of your own or improve on my design. Can you shave a chip or two off the count?

This article appears in the April 2020 print issue as “8 Bits, 6 Chips.”

How to Build a Hack-Proof Garage Door Opener

Post Syndicated from Pete Lewis original https://spectrum.ieee.org/geek-life/hands-on/how-to-build-a-hackproof-garage-door-opener

I’ve been making electronics projects for 15 years, but strong security was something I always considered out of my reach. Consequently, a fear of getting hacked limited the types of projects I would pursue, especially Internet-connected devices. But in May of 2019, I was handed the job of designing a cryptographic product for my employer, SparkFun. Among other things, SparkFun designs and sells breakout boards that allow makers to easily incorporate the capabilities offered by various integrated circuits into their designs. Now SparkFun wanted a board that would provide an easy on-ramp into the world of hardware-based cryptography.

It had to be user-friendly and Arduino compatible, which meant sifting through the specs of a lot of cryptographic hardware. What functions should our board offer, and how should it implement them? Ultimately, I chose to focus on ECC (elliptical curve cryptography) digital signatures. I’ll get into a quick explanation of what ECC is in a moment, but the appeal of digital signatures is that they have a great real-world equivalent—handwritten signatures—which makes them a good introduction to cryptography. And signatures are very useful in the world of embedded systems, especially for those communicating over an insecure channel, like a radio link.

I had an immediate test application: As I started my crypto research, I remembered that my garage door remote control had stopped working years ago. I had wanted to replace the system with something of my own design, but I was never confident I could make something secure. But now my research had an extra impetus.

Venturing into the world of cryptography was pretty daunting, but with enough reading I found my way to a few datasheets of chips that use ECC-based crypto. ECC is similar to the RSA encryption algorithm often used on the Internet—both use what’s called a trapdoor mathematical function, which is easy to do but very hard to reverse. In RSA’s case, the trapdoor function is the multiplication of two large prime numbers. If you have just the product of the numbers, it’s very hard to factorize that back to its constituent primes, but if you know one prime and the product, it’s trivial to do division and recover the other prime. With a trapdoor function in hand, you can create a private key and a public key. Anything encrypted with the public key can be decrypted only with the private key, and vice versa. In ECC’s case, the trapdoor function is a hairy bit of math that exploits properties of points along an elliptic curve described by a formula of the form y² = x³ + ax + b. If you’re willing to take on the math, ECC lets you use shorter keys than RSA does, so it’s better for embedded devices with limited power and bandwidth budgets.

After quite some searching, and following the advice of Josh Datko at Cryptronix, I came to the ATECC508A chip. It can do ECC signature creation and verification and talks I2C, the two-wire communications bus protocol that is well suited for Arduino compatibility. Time to order some samples!

The printed-circuit-board layout was fairly straightforward, and I had prototypes in no time. I plugged one in to my nearest Arduino, and it popped up on the correct I2C address. The hardware was verified. Now it was time for the difficult stuff: software!

The biggest hurdle was configuration. The ATECC508A has 126 configuration registers and there are many dependencies. If you attempt to change one thing, you often break another. Plus, in order to ensure the system is secure, once a configuration is chosen, it gets irreversibly locked: You only get one chance with these security ICs, so if you mess it up, then your IC is useless. Working very slowly and carefully, I nevertheless bricked several ICs (proud to say I never hit double digits). But I eventually found a suitable configuration that allowed for ECC signatures and verification. Whew! Finally I could begin writing examples for an Arduino library, demonstrating things like how to sign messages.

Now that the cryptographic coprocessor was completed, it was time to focus on fixing my garage door remote. The next big step was to add wireless communication. I opted to use a pair of SparkFun Pro RFs. They were nice to work with because they use an SAMD21 microcontroller with an I2C buffer large enough to handle the communications needs of the crypto coprocessor, and they have an onboard LoRa wireless transceiver, the RFM95. I initialized a crypto coprocessor, which creates a permanent private key—locked inside the coprocessor—and a public key which I could download via the I2C connection. (Step-by-step construction instructions and a bill of materials are available from the SparkFun site.)

I housed my remote in a sturdy aluminum case with a duck antenna and a single push button. Internally, it consists of my initialized crypto coprocessor board, a Pro RF, and a rechargeable lithium polymer battery. The normally open push button is wired between the battery and the Pro RF, so the board is off most of the time. Pressing the button for three seconds gives the board enough time to start up and complete the entire sequence to open the garage.

The sequence plays out like this: After boot up, the remote sends the string “$$$” to the base station in the garage (consisting of the other Pro RF and another ATECC508A crypto board with a copy of my remote’s public key). The base station creates a token of random data using its ATECC508A and broadcasts it. The remote receives this token and creates a signature by combining the token with its private key, and transmits the signature. The base verifies the signature using the remote’s public key. The security comes from the fact that the only place in the world that contains the unique private key necessary to make a valid signature is inside the remote’s coprocessor. If all is good (within a strict time window), then the base opens the garage.

Next up, I plan to venture into areas that I was previously uncomfortable with. Now with this coprocessor in my bag of tricks, and good security in my hands, I’m ready to take on even the most concerning of IoT devices: my front door lock.

This article appears in the March 2020 print issue as “Make a Hack-Proof Garage Door Opener.”

About the Author

Pete Lewis is a quality control manager at SparkFun Electronics, a DIY electronics company based in Niwot, Colo.

A DIY Audio Induction Loop for the Hard of Hearing

Post Syndicated from David Schneider original https://spectrum.ieee.org/geek-life/hands-on/a-diy-audio-induction-loop-for-the-hard-of-hearing

I regularly attend an unprogrammed Quaker meeting, where a lot of the folks are older and have hearing impairments. This style of worship poses a special challenge for these people because, unlike the convention at many other religious gatherings, there is no one person who addresses the congregation. At an unprogrammed Quaker meeting, anyone may speak from anywhere in the room.

Some years ago, the congregation installed microphones in the room, which pick up voices and amplify them. These signals are then transmitted by FM radio over special frequencies near the radio broadcast band. The thing is, a person who needs help hearing others must use a small FM receiver and earphones, which is a little awkward, in part because it makes you stand out.

One way to mitigate this problem is to take advantage of the fact that some of these people wear hearing aids equipped with a telecoil (or T-coil). These hearing aids can be switched to a mode whereby they pick up audio-frequency signals electronically instead of using their built-in microphones. This system for passing the signal wirelessly doesn’t involve radio transmissions—it just uses magnetic induction. Suitable audio induction loops for energizing T-coils are found in all sorts of places, including museums and theaters; even some taxicabs are equipped with them. You may see their presence advertised with a blue-and-white sign that looks like an ear with a “T” next to it.

Many of the hearing-aid wearers who attend our Quaker meeting live in a nearby retirement community where induction loops have been installed to help hearing-impaired residents enjoy lectures and films. These people have had good experiences in such settings, and so they have been hoping that an audio induction loop would help them to hear what’s being said at our Quaker meeting, too.

I worried, though, that their disappointment with our current system reflected the difficulty of picking up voices cleanly in a reverberant room using microphones positioned at the periphery. And commercial installers of this equipment charge thousands of dollars—a lot for something that’s probably not going to solve our particular problem. But for very little money, I figured, we could install a DIY audio induction loop and at least let people try it out.

A little searching online uncovered some brief commentary posted by someone who installs such systems at music festivals. What he described was quite simple—creating a multiturn loop using a multiconductor wire (one for which the total resistance is between 4 and 8 ohms), and attaching it to a 200-watt audio amplifier, just as you would an 8-ohm speaker.

Before diving into this, I enlisted an older friend (a retired electrical engineer) who wears a T-coil hearing aid to perform an experiment. I constructed an induction coil from a six-turn square loop of magnet wire that was about a half meter on a side (I taped the wire to a flattened cardboard box), using wire of the right diameter to make the loop resistance 8 ohms. I then attached it to the speaker terminals of an ordinary stereo receiver, one that was collecting dust in the back of my garage.

Using that arrangement, I was able to convey audio to the T-coil in his hearing aid with his head about a meter and a half away (on axis) from my coil. This test was tougher than needed to assess requirements, because the magnetic field at my friend’s head was mostly horizontal, and my understanding is that T-coils are positioned to pick up vertical fields.

Based on that test (and the Biot-Savart Law), I figured out that I should be able to create a magnetic field of the same strength about 3 meters away from a long wire, which is exactly what you would need if said long wire were part of a loop installed in the attic of the building where the meeting is held.

Next I used a wire-resistance table to determine that 240 meters of 20-gauge wire should be around 8 ohms. That would be long enough for me to create a six-turn loop in the attic. So I bought a roll of 1,000 feet (304 meters) of two-conductor 20-gauge wire for about US $125 on Amazon. Using two conductors would allow me to create two parallel loops, powering each through one channel of my stereo receiver. Because each channel of the receiver can output as much as 80 watts, I figured I’d be close to the 200-watt figure I saw quoted online. Preliminary tests with six turns of this wire laid out on the floor of the building showed the signal-pickup range to be about 5 meters.

Encouraged by those initial tests, another friend and I recently placed a similar wire loop in the attic of the building—which was a lot harder than laying it on the floor because we had to snake the wire around an obstacle course of roof trusses and HVAC ducting. We ended up with a loop that’s got a rather complicated geometry and doesn’t lay flat on the joists in many places.

Nevertheless, this cobbled-together induction loop appears to convey signals just fine to hearing-aid wearers below. At least that’s what my retired electrical engineer friend reported when I set the stereo receiver attached to the loop to output a program from our local public-radio station. The only dead spots he found as he walked around the room were in the far corners.

That said, I don’t expect the addition of this informally constructed induction loop—or even a professionally installed one—could ever make up for the weak link in our system: the mounting of the microphones on the walls of the room, far from the people speaking. Unfortunately, there’s not much of an alternative, short of giving everyone TED-talk-style microphones to wear, which wouldn’t really mesh with the Quaker penchant for simplicity.

This article appears in the February 2020 print issue as “A DIY Audio Induction Loop.”

Build a Vector Graphics Display Clock with a Cathode-Ray Tube

Post Syndicated from Stephen Cass original https://spectrum.ieee.org/geek-life/hands-on/build-a-vector-graphics-display-clock-with-a-cathoderay-tube

Once upon a time, there was a type of particle accelerator so popular that it was mass-produced by the million. Engineers and scientists at their benches, and folks at home in their living rooms, would carefully arrange themselves to watch the dancing glow of a beam of subatomic particles smashing into a phosphorescent screen. This attention-hogging accelerator was, of course, the cathode-ray tube (CRT), which reigned supreme as the electronic display technology for decades, before being unceremoniously relegated to the figurative and literal trash heap of history by flat-screen technologies.

But there are still CRTs to be found, and you can put some of them to great use with Howard Constantine’s US $100 Oscilloscope Clock Kit. The kit works with many CRTs that were designed to be used in oscilloscope-type displays and operated with relatively low voltages—in the range of hundreds, rather than thousands, of volts.

As CRTs are becoming as unfamiliar to modern engineers as amplifier tubes did to the transistor generation, a quick recap of a few salient points is likely in order here. Oscilloscope-type CRTs are different from those found in televisions and most computer monitors. TV-type CRTs use magnetic fields generated by coils located outside the vacuum tube to deflect an electron beam, which is scanned line by line across the screen to build up what’s called a raster image. Oscilloscope-type CRTs use two pairs of horizontally and vertically oriented plates located inside the tube to electrostatically deflect the beam: This approach was handy for oscilloscopes because an analog input voltage can control the vertical position of the beam directly (albeit filtered through some signal-conditioning circuitry), while an internal timing circuit controls the horizontal deflection, letting engineers see time-varying signals.

The beam’s horizontal deflection can also be controlled with a second input voltage (called X-Y, or vector, mode). This made oscilloscope CRTs appealing to early computer-graphics pioneers, who pressed them into service as displays for things like radar defense networks. Some seminal computer games were made using vector displays, including arguably the first-ever video game, the 1958 Tennis for Two, and the massive 1979 arcade hit Asteroids. But vector displays struggled when it came to, say, showing bitmaps or even simply a large area filled with a solid color, and so eventually lost out to raster displays.

But CRT vector displays have a distinct look that’s hard to replicate—not least when the screen is round, which was the easiest shape to make back in the day. (I do find it a little ironic that after decades of engineers striving to create the most perfectly flat and rectangular displays possible, smartphone makers have begun rhapsodizing about offering partially curved screens with rounded corners.)

The Oscilloscope Clock Kit allows you to recapture that look. The kit itself comprises the printed circuit board and all the accompanying components, including two PIC microcontrollers—one controls the clock and generates the graphics and text, while the other is dedicated to periodically shifting the clock around the screen to avoid phosphor burn-in. Normally you have to supply your own enclosure and CRT (eBay usually has listings), but as Constantine has a limited stock he uses to make fully assembled clocks for sale, he kindly let me buy a 7-centimeter-wide DG7-6 from him for $75 and one of his acrylic enclosures for $40.

Getting a clear enclosure was important to me because I wanted to be able to show off the tube for maximum effect, while also keeping fingers safely away from the electronics. This is important because even though the CRT is considered “low voltage,” that still means 300 volts in some parts of the circuitry. Perhaps I was particularly skittish on this topic because of childhood memories: When I demonstrated a burgeoning propensity for taking things apart with a screwdriver, my father, a broadcast engineer, headed off any designs I might have had on our TV set with lurid true tales of people being zapped by the charge stored in a television’s high-voltage capacitors even after the set had been unplugged.

Fortunately for my nerves, the clock kit’s smaller capacitors pose much less of a hazard. Nonetheless, now that even 5 V is increasingly shunned as a circuit-melting torrent of electricity, I recommend builders work with a little more caution than they are used to, especially as checking stages of the build do require probing it with a multimeter when the board is plugged in.

Soldering the through-hole components was straightforward, although because the tallest component—a transformer—is one of the first required, it’s likely you’ll need to use some kind of circuit-board holder rather than trying to lay the board flat when working. The biggest obstacle came when it was time to wire up my DG7-6 CRT. The kit provides 10 leads for operating a CRT—two that supply a few volts of alternating power to the heater filament to raise the cathode temperature enough for thermoelectric emission to come into play, one that has a constant negative voltage of about 295 V to provide the cathode’s supply of electrons, three that connect to a train of accelerating and focusing electrodes in the neck of the CRT, and four that connect to the horizontal and vertical deflecting plate pairs. But my DG7-6 only had nine pins! A check of the DG7-6’s data sheet [PDF] (which I found on Frank Philipse’s wonderful archive) showed that the cathode and one side of the heater filament shared a pin. A quick email to Constantine revealed the solution was a quick fix: All I had to do was jumper the cathode connection to one of the filament leads. After that, the instructions stepped me through the calibration steps required to produce a sharp bright test dot in the center of the screen rather than a fuzzy dim elliptical blob off to the side.

When building the kit, you can incorporate one of two optional $40 add-on circuits that eliminate the need to set the clock manually—a Wi-Fi module and a GPS module. Without one of those, the clock automatically detects whether it is plugged into a 50- or 60-hertz wall socket and uses that frequency as a reference time base. Setting the clock manually is simply a matter of pushing a “fast set” and “slow set” button until the clock shows the correct time.

The end result is an eye-catching timepiece that restores a CRT to its rightful place: the center of attention.

This article appears in the January 2020 print issue as “Oscilloscope Clock.”

Got an Old Canon Point-and-Shoot Camera? Hack It

Post Syndicated from Stephen Cass original https://spectrum.ieee.org/geek-life/hands-on/got-an-old-canon-pointandshoot-camera-hack-it

A decade is a long time in technology—long enough for a technology to go from hot product to conspicuously obsolete to retro cool. In 2010, IEEE Spectrum’s David Schneider wrote about a hack to supplant the firmware in Canon point-and-shoot cameras and add new features, such as motion detection. As it turns out, at the time point-and-shoot cameras were near their zenith of popularity. Since then, while compact stand-alone digital cameras are still being made, their sales have shrunk dramatically. As the smartphone camera became the most ubiquitous type of camera on the planet, point-and-shoot cameras found themselves relegated to the back of the closet.

That was certainly the case with our Canon PowerShot S80. My wife bought it in 2008 primarily to document her paintings in between professional photo shoots, and a few years later we replaced it with a mirrorless Nikon 1 J-1 with interchangeable lenses. So when I found the S80 while decluttering recently, I wondered: Was it just e-waste now, or could it be combined with today’s technology to do interesting things?

I decided the perfect test case for my S80 was variable time-lapse photography. This is a task for which even an 11-year-old digital camera, with its larger optics, can compete with today’s smartphones on image quality. This scenario makes mobility a moot point, but the task also requires more sophistication than even CHDK—the open-source firmware replacement David Schneider wrote about in 2010—can easily offer alone.

My S80’s original firmware had a function that would take a photograph at fixed intervals of between 1 and 60 minutes, in 1-minute increments. CHDK provides a script that allows a more fine-grained increment of 1 second, but I wanted to try time-lapse photography of the Empire State Building, which we happen to have a good view of from Spectrum’s New York office. During the day, the light changes slowly, so I wanted to shoot one photo every few minutes. At dusk, however, the lighting on and around the building changes more dramatically, so I wanted photos taken at a faster rate.

The first thing was to test my camera. It’s a credit to Canon that despite years of disuse, all the parts sprang to life. The only problem was on the battery side. I had three batteries, one of which refused to charge at all, and two others I no longer trusted for a long-duration experiment, so I found a DC adapter on eBay that powers the camera from a wall socket.

Then I installed CHDK. Fortunately, this is one of those rare pieces of open-source software for which the documentation is a comprehensive and intelligible wiki. Looking up the instructions for my S80, I determined its current firmware, which turned out to be 1.00f. Only the 1.00g version is compatible with CHDK, so I followed the instructions to upgrade the factory firmware, the biggest obstacle to which was finding the right utility software to open the 7z format that the firmware file was compressed with.

A cross-platform tool called Stick makes finishing the CHDK install easy: Drop a photo taken with a camera onto the tool’s interface and it analyzes the metadata and downloads the exact version of CHDK required onto a SD card. Launching CHDK on my camera just requires putting the prepared card in and pressing the S80’s “shortcut” button.

CHDK provides an interface for remote control of the camera via the USB link normally used to download photographs directly to a PC. A number of programs can use this PTP standard, including chdkptp, which offers both a command line version and a graphical user interface (GUI) version that lets you see what is being displayed in the viewfinder screen live. One of the nice things about chdkptp is that a precompiled binary, bundled with required supporting libraries, is available for the Raspberry Pi, thus eliminating dependency hell.

I ran into two problems, which were resolved after searches of CHDK’s user forums. The first was that chdkptp couldn’t connect to the S80—a helper process on the Pi was grabbing the connection, assuming I wanted to download photos. The simplest solution was to find the offending process using a “ps -ax | grep gphoto2” command, and “kill -9” it. (This works only on a per-session basis; if you want to permanently disable the helper, you’ll have to edit some deep configuration files.)

My camera and chdkptp could now connect, but I still couldn’t actually take a photo. This was solved by writing a script with some mode commands I found on a forum. CHDK runs the script when I press the camera’s shutter, and then it is happy to accept remote commands.

To implement my variable time-lapse schedule, I wrote a short Python program on the Pi. I looked up the time of the sunset and set the Python program to check the clock. Outside a half-hour window around sunset it would take a photo every 10 minutes, and one every 30 seconds inside the window. To control the S80, I just issued an OS call to the chdkptp command line tool that connected and triggered the shutter—that is, os.system(“./chdkptp.sh -c -eshoot”).

I left the system running from the early afternoon till dusk, and when I returned I had 113 images, which I dumped into iMovie to make a time-lapse video. Ta-da!

Now that I have my proof of concept, it would be a straightforward task to write a Python script that could download the times of sunrise and sunset and adjust itself automatically. I can also save images directly to the Pi. Then I could access and download these images remotely over a wireless network, allowing for the option of leaving the camera and Pi in place for long periods of time for truly epic time-lapse movies.

This article appears in the December 2019 print issue as “Hack Your Old Point-and-Shoot.”

Build a Long-Distance Data Network Using Ham Radio

Post Syndicated from F4HDK original https://spectrum.ieee.org/geek-life/hands-on/build-a-longdistance-data-network-using-ham-radio

I have been a hobbyist and maker for almost 15 years now. I like inventing things and diving into low-level things. In 2013, I was looking at a protocol called NBP, used to create a data network over amateur radio links. NBP was developed in the 2000s as a potential replacement for the venerable AX.25 protocol [PDF] that’s been in use for digital links since the mid-1980s. I believed it was possible to create an even better protocol with a modern design that would be easier to use and inexpensive to physically implement.

It took six years, but the result is New Packet Radio (NPR), which I chose to publish under my call sign, F4HDK, as a nom de plume. It supports today’s de facto universal standard of communication—the Internet’s IPv4—and allows data to be transmitted at up to 500 kilobits per second on the popular 70-centimeter UHF ham radio band. Admittedly, 500 kb/s is not as fast as the megabits per second that flow through amateur networks such as the European Hamnet or U.S. AREDN, which use gigahertz

frequencies like those of Wi-Fi. But it is still faster than the 1.2 kb/s normally used by AX.25 links, and the 70-cm band permits long-distance links even when obstructions prevent line-of-sight transmissions.

Initially, I considered using different frequency bands for the uplink and downlink connections: Downlinks would have used the DVB-S standard, originally developed for digital satellite television. Uplinks would have used a variation of FSK (frequency-shift keying) to encode data. But the complexity involved in synchronizing the uplink and downlink was too high. Then I tried using a software-defined radio equipped with a field-programmable gate array (FPGA). I had some experience with FPGAs thanks to a previous project in which I had implemented a complete custom CPU using an Altera Cyclone 4 FPGA. The goal was to do all the modulation and demodulation using the FPGA, but again the method was too complex. I lost almost two years chasing these ideas to their dead ends.

Then, in one of those why-didn’t-I-think-of-this-earlier moments, I turned to ISM (industrial, scientific, and medical) chips. These are transceivers designed to operate in narrow radio frequency bands that were originally allocated for noncommunication purposes, such as RF heating. However, the ISM band has become popular for communications as well because typically a license is not required for its use. In Africa, Europe, and North Asia, there is an ISM band lying inside the 70-cm ham radio band at 434 megahertz, so commercial ISM chips are available for this frequency.

I chose to build my hardware around the Si4463 [PDF] ISM transceiver: It’s cheap, flexible, and available in many modules and breakout boards, and it can handle a raw data rate up to 1 megabyte per second. It’s designed for short-range applications, so the radio part of the chip is not optimal, but it works. In order to reach reasonable distances, you need an amplifier to provide more RF power. For my NPR plan, I needed an amplifier that can also switch very rapidly between transmitting and receiving. I found some widely available external 20-watt amplifiers for handheld radios designed for the European-developed Digital Mobile Radio (DMR) standard, which was ratified in 2005. In the DMR standard, radio equipment must be able to handle a complete transmit/receive cycle within 60 milliseconds. I established a minimum of an 80-ms-long cycle time for NPR with this bound in mind.

The ISM transceiver is connected to an Mbed Nucleo STM32 L432KC microcontroller, which uses an Arm Cortex CPU.

This microcontroller is in turn connected to an Ethernet interface, and it takes care of all the details of running the NPR protocol. Any connected PC or network sees the radio link as just another IPv4 connection with no need to install specific NPR software. The NPR modem can be configured over this link or via a USB connection. The total cost of the hardware is about US $80, and a partner, Funtronics, will be making kits available for purchase online. If you want to build a modem yourself from scratch, detailed instructions and the NPR protocol software are available from my Hackaday project page.

The NPR protocol is based on a hub-and-spoke model, in which a central modem links several client modems. Currently there can be as many as seven modems, although I plan to expand this to 15. The theoretical maximum distance between a client modem and the central modem is 300 kilometers. This limit arises because NPR uses a managed time-division multiple access (TDMA) technique, in which the central modem and the clients each transmit on the same frequency but at different times, with the central modem dictating when each client can transmit, and making scheduling adjustments to account for time delays due to distance. The complete transmit/receive cycle is between 80 ms and 200 ms, depending on the exact type of modulation and data rate chosen.

The creation of the NPR protocol was a very fun part of the project for me: deciding how data should be packed and arranged inside radio frames and how the NPR modems should interact with each other. But after two more years it was time to stop working alone, so I shared NPR with my local ham radio community in France. By the end of 2018, we began testing it in real-world conditions. We have already achieved distances over 80 km, and I am now getting help from the global amateur community, especially in Germany. Currently, NPR is primarily being used to access existing local high-speed amateur radio networks from places that cannot have the line-of-sight radio links required for 2.4- and 5.6-gigahertz signals.

Although it’s usable, I would be the first to admit that NPR is a young technology and probably not totally mature. In addition to increasing the number of clients that can be supported by a central modem, I have a number of enhancements in mind, such as adding support for QoS (quality of service) prioritization, so that NPR could be used to transmit digital voice; allowing Ethernet frames to be transported directly; and separating downlink and uplink frequencies. 

This article appears in the November 2019 print issue as “Ham Radio Does Distant Data Networking.”

Track the Movement of the Milky Way With This DIY Radio Telescope

Post Syndicated from David Schneider original https://spectrum.ieee.org/geek-life/hands-on/track-the-movement-of-the-milky-way-with-this-diy-radio-telescope

A young friend recently spent a week learning about radio astronomy at the Green Bank Observatory in West Virginia. His experience prompted me to ask: How big a radio antenna would you need to observe anything interesting? It turns out the answer is a half meter across. For less than US$150 I built one that size, and it can easily detect the motions of the spiral arms of the Milky Way galaxy. Wow!

My quest began with a used satellite-TV dish and a “cantenna” waveguide made from a coffee can placed at the dish’s focus. Unfortunately, I had to abandon this simple approach when I figured out that a coffee can was too small to work for the wavelength I was most interested in: 21 centimeters. That is the wavelength of neutral hydrogen emissions, a favorite of radio astronomers because it can be used to map the location and motion of clouds of interstellar gas, such as those in the spiral arms of our galaxy.

Some research revealed that amateur radio astronomers were having success with modest horn antennas. So I copied the example of many in an online group called Open Source Radio Telescopes and purchased some aluminized foam-board insulation as antenna construction material. But I was troubled when my multimeter showed no evidence that the aluminized surface could conduct electricity. To make sure the material would have the desired effect on radio waves, I built a small box out of this foam board and put my cellphone inside it. It should have been completely shielded, but my cellphone received calls just fine.

That experiment still perplexes me, because people definitely do build radio telescopes out of aluminized foam board. In any case, I abandoned the board and for $13 purchased a roll of 20-inch-wide (51-centimeter-wide) aluminum flashing—the thin sheet metal used to weatherproof tricky spots on roofs.

The width of my roll determined the aperture of my horn’s wide end. The roll was 10 feet (3 meters) long, which limited the length of the four sides to 75 cm. An online calculator showed that a horn of those dimensions would have a respectable directional gain of 17 decibels. Some hours with snips and aluminized HVAC tape ($8) resulted in a small horn antenna. Attaching a square of ordinary foam board (not the aluminized kind) to the open end made it plenty robust.

I also purchased a 1-gallon can of paint thinner ($9) and gave away its contents. The empty can serves as a waveguide feed at the base of the horn antenna. A handy online waveguide calculator told me this feed would have an operating range that nicely brackets the neutral-hydrogen line frequency of 1420 megahertz.

Some folks contributing to Open Source Radio Telescopes were using similar cans. But none of the projects’ documentation showed exactly how to construct the feed’s “pin”: the part that picks up signals inside the waveguide and passes them to the telescope’s receiver. Many cantenna tutorials say to make the pin a quarter of a wavelength long, which in this case works out to 53 millimeters. The tricky part is figuring out where to place it in the can—it needs to be a quarter of a wavelength from the base. However, in this case the relevant wavelength isn’t 21 centimeters but what’s called the guide wavelength, which corrects for the difference between how the signal propagates in free space versus inside the waveguide. An online tutorial and another calculator showed the appropriate distance from the base to be 68 mm. So that’s where I drilled a hole to accommodate an N-type coaxial bulkhead connector that I had purchased on Amazon.com for $5, along with an N-to-SMA adapter ($7).

For my receiver, I went with a USB dongle that contains a television tuner plus a free software-defined radio application called HDSDR. (The software was chosen on the basis of a report from two amateur radio astronomers in Slovenia who had used it to good effect.)

I purchased the dongle from Nooelec.com ($37) because that company had also recently started selling a gizmo that seemed perfect for my application: It contains two low-noise amplifiers and a surface-acoustic-wave (SAW) filter centered on 1420 MHz ($38). The dongle itself provides power for the amplifier through the coaxial cable that connects them, a 30-cm (12- inch) length of coax purchased on Amazon.com ($9). The dongle just sits on the ground next to my horn and is attached to a Windows laptop through a USB extension cable.

At my instrument’s “first light,” I was able to detect the neutral hydrogen line with just a little squinting. After getting more familiar with the HDSDR software, I figured out how to time-average the signal and focus on the spectral plot, which I adjusted to display average power.

This plot distinctly showed a hydrogen “line” (really a fat bump) when I pointed my horn at the star Deneb, which is a convenient guide star in the constellation of Cygnus. Point at Cygnus and you’ll receive a strong signal from the local arm of the Milky Way very near the expected 1420.4-MHz frequency. Point it toward Cassiopeia, at a higher galactic longitude, and you’ll see the hydrogen-line signal shift to 1420.5 MHz—a subtle Doppler shift indicating that the material giving off these radio waves is speeding toward us in a relative sense. With some hunting, you may be able to discern two or more distinct signals at different frequencies coming from different spiral arms of the Milky Way.

Don’t expect to hear E.T., but being able to map the Milky Way in this fashion feels strangely empowering. It’ll be $150 well spent.

This article appears in the October 2019 print issue as “Build Your Own Radio Telescope.”