Category Archives: Hacking

A Smarter PSU Converter Leaves the Magic Smoke Inside

Over the years, computers have become faster, but at the same time, more power hungry as well. Way back around the 386 era, most PCs were using the AT standard for power supplies. Since then, the world moved on to the now ubiquitous ATX standard. Hobbyists working on older machines will typically use these readily available supplies with basic adapters to run old machines, but [Samuel] built a better one.

Most AT to ATX adapters are basic passive units, routing the various power lines where they need to go and tying the right pin high to switch the ATX supply on. However, using these with older machines can be fraught with danger. Modern supplies are designed to deliver huge currents, over 20 A in some cases, to run modern hardware. Conversely, a motherboard from the early 90s might only need 2 or 3A. In the case of a short circuit, caused by damage or a failed component, the modern supply will deliver huge current, often damaging the board, due to the overcurrent limit being set so high.

[Samuel]’s solution is to lean on modern electronics to build an ATX to AT adapter with programmable current protection. This allows the current limit to be set far lower in order to protect delicate boards. The board can be set up in both a “fast blow” and a “slow blow” mode to suit various working conditions, and [Samuel] reports that with alternative cabling, it can also be used to power up other old hardware such as Macintosh or Amiga boards. The board is even packed with extra useful features like circuitry to generate the sometimes-needed -5V rail. It’s all programmed through DIP switches and even has an OLED display for feedback.

It’s an adapter that could save some rare old hardware that’s simply irreplaceable, and for that reason alone, we think it’s a highly important build. We’ve talked about appropriate fusing and current limiting before, too – namely, with LED strips. 

 

from Blog – Hackaday https://ift.tt/2Lt0lIw
via IFTTT

Ask Hackaday: How Do You DIY a Top-Octave Generator?

One of the great joys of Hackaday are the truly oddball requests that we sometimes get over the tip line. Case in point: [DC Darsen] wrote in with a busted 1970s organ in need of a new top-octave generator, and wondered if we could help. He had found a complicated but promising circuit online, and was wondering if there was anything simpler. I replied “I should be able to get that done with a single Arduino” and proceeded to prove myself entirely wrong in short order.

So we’re passing the buck on to you, dear Hackaday reader. Can you help [DC Darsen] repair his organ with a minimum amount of expenditure and hassle? All we need to do is produce twelve, or maybe thirteen, differently pitched square waves simultaneously.

Top-Octave What?

Pipe organs make sound by vibrating air in tremendously large tubes, one per pitch. Then along came the Hammond organ, which from 1935 to the mid 1970s made sound by spinning metal disks with periodic cutouts in the presence of an electronic pickup. A Hammond is still not a small machine, but it was positively compact compared to the pipe organ. By the 1980s, all of this sound generation could be contained in a dedicated IC, ending the era of the giants. (At least for mass-market instruments: a real pipe organ in a big space is still a delight to hear in person.)

But for a brief period of time between the tonewheel and the VLSI eras, there was a decade of home organs that were designed with the readily available wonder technology of that era, discrete logic ICs. In particular, these designs leverage the ability of a flip-flop to take an input frequency and divide it by two easily and cheaply. Dividing a frequency by two lowers its perceived pitch by an octave which meant that, if you could accurately generate one pitch for each of the twelve tones in the scale, you could use flip-flops and divide down to cover the entire keyboard.

Reference Pitch Chip

Providing an accurate set of twelve reference pitches is the job of the top-octave generator (TOG) chip, a part which isn’t made anymore. But what if you want to repair a 1970s organ that used them? You might be able to order expensive old-stock spares, but where’s the fun in that?

Almost all of the TOGs took an input frequency derived from a 2 MHz crystal oscillator circuit and provided twelve or thirteen square waves of the right pitches by dividing this input frequency by factors from 239 to 478. If we had to implement this in silicon, we’d build up twelve 9-bit counters, all driven by the same 2 MHz master clock, and cause them to reset when the right counts were reached. This should be easy to replicate in firmware on an Arduino, right?

Microcontroller Non-Solutions

The highest “C” on a piano clocks in at 4,186.01 Hz, meaning that we’d have to toggle a pin approximately every 1,911 cycles for an AVR ATmega Arduino clocked at 16 MHz. One pitch would be easy. This might suggest that you could implement this naively in software, keeping track of twelve counter variables and testing in a loop if each should be reset.

while (1) {
    C7_TOGGLE;
        for (volatile uint8_t i=0; i<12; i++){
        if (counts[i] > tops[i]){
            counts[i]=0;
        }
        ++counts[i];
    }
}

But it doesn’t scale. If you implement it this way, the time between counts is simply too long, and you’re unable to define any of the pitches accurately enough that it’s musically useful.  The loop above runs around 20 kHz, which is nowhere near fast enough, and all the pitches are out of tune.

An alternative approach would be to let a hardware timer run free, set up a timer variable for each oscillator, and toggle each oscillator when its individual time is reached and then update the GPIO pins.

But because the divided-down oscillators are running at different frequencies, even with only two such oscillators, they will phase in and out. Eventually two transitions will come so close to overlapping that going through the loop takes too much time to service them both, and one will reset late. With twelve oscillators running, the resulting jitter is audible, and it sounds horrible.

These concerns, and a desire to do away with the flip-flop dividers, is what lead Tom [Electric Druid] Wiltshire to build his TOG with twelve PICs, one for each note of the scale. To run in tune together, though, they need to run on the same master clock, and Tom reports problems with the PLL he was using as a master clock. I have aesthetic concerns with using twelve PICs, though I suppose it’s not worse than using twelve synchronous counter ICs for the octave divisions.

Most microcontrollers have onboard hardware timer circuitry that can do exactly what we need, but twelve independent timers is pushing it. An ATmega-powered Arduino has three hardware timers, and one is tied up by the Arduino firmware. If you’re willing to ditch millis(), you could implement three of these oscillators in hardware and probably run a fourth on the CPU. You’d only require three Arduinos for a full octave. We might be getting somewhere.

Overkill, But Plausible

Some fancier microcontrollers have twelve or more hardware timers. I looked around and found that the high-density STM32F407 boards, which are available for not too much from the usual sources, have twelve 16-bit timers. I’m not sure if all of them are available, or operable at once. Still, the all-hardware approach has the advantage of rock-solid timing, and 16-bit resolution on the pitches is an improvement over the old-school TOGs. But throwing a higher-end microcontroller at the job just to leave the 168 MHz CPU completely idle seems somehow wasteful.

A TOG is actually a perfect application for an FPGA. You could implement the divide-down-by-counter design of the original ICs fairly faithfully, and each of the sub-circuits in and FPGA run independently and truly in parallel. Implementing the flip-flops for division would be easy enough as well, and as long as the FPGA has 88 free output pins you could generate all desired pitches in one piece of silicon. That would be pretty sweet.

Your Turn

My gut feeling is that the FPGA solution is the best, although it won’t be DIY-friendly for the majority of organ-repair hobbyists. Everyone knows Arduino, but syncing up three or four of them sounds like trouble. The high-end microcontroller solution should work, but feels wasteful.

What are we missing? Where is the clever hack that will allow twelve independent timers to run in software on a single AVR Arduino? Just for the mental exercise we’re really interested in hearing a working microcontroller solutions. But maybe you have some secret trick to keep a dozen 555 timers in tune? (We’ll believe it when we hear it!) Anyone want to show us how easy the FPGA solution could be? How would you implement a TOG?

from Blog – Hackaday https://ift.tt/2KOvrJo
via IFTTT

How Hertha Aryton Enabled the Titanic to Call SOS

[Kathy] recently posted an interesting video about the connection of an electronics pioneer named [Hertha Aryton] to the arc transmitter. The story starts with the observation of the arc lamp — which we learned was a typo of arch lamp.

[Hertha] was born into poverty, but — very odd for the day — obtained a science education. That’s probably a whole story in of itself. During her schooling, she fell in love with her professor [William Aryton] and they wed.

[Hertha] took over her husband’s research into arcs and made impressive results in understanding the physics of an arc. The key finding was that in some cases increasing the voltage would decrease the current. This implied that the arc had negative resistance.

There’s a lot more to the story involving one of [William’s] graduate students and a man named [Poulsen] who made the arc transmitter more reliable. We’ll let you watch the video to find out more.

The end of the story about [Jack Phillips] on Titanic is pretty well known. But we didn’t know all the background about how the arc transmitter came to be or that the improved [Poulsen] transmitter would have possibly averted the disaster.

Our old friend [Reginald Fessenden] makes a surprise appearance at the end of the video. Watch for him. If you think these old radios weren’t subject to being hacked, think again.

from Blog – Hackaday https://ift.tt/2Lprnk4
via IFTTT

Modern Wizard Summons Familiar Spirit

In European medieval folklore, a practitioner of magic may call for assistance from a familiar spirit who takes an animal form disguise. [Alex Glow] is our modern-day Merlin who invoked the magical incantations of 3D printing, Arduino, and Raspberry Pi to summon her familiar Archimedes: The AI Robot Owl.

The key attraction in this build is Google’s AIY Vision kit. Specifically the vision processing unit that tremendously accelerates image classification tasks running on an attached Raspberry Pi Zero W. It no longer consumes several seconds to analyze each image, classification can now run several times per second, all performed locally. No connection to Google cloud required. (See our earlier coverage for more technical details.) The default demo application of a Google AIY Vision kit is a “joy detector” that looks for faces and attempts to determine if a face is happy or sad. We’ve previously seen this functionality mounted on a robot dog.

[Alex] aimed to go beyond the default app (and default box) to create Archimedes, who was to reward happy people with a sticker. As a moving robotic owl, Archimedes had far more crowd appeal than the vision kit’s default cardboard box. All the kit components have been integrated into Archimedes’ head. One eye is the expected Pi camera, the other eye is actually the kit’s piezo buzzer. The vision kit’s LED-illuminated button now tops the dapper owl’s hat.

Archimedes was created to join in Google’s promotion efforts. Their presence at this Maker Faire consisted of two tents: one introductory “Learn to Solder” tent where people can create a blinky LED badge, and the other tent is focused on their line of AIY kits like this vision kit. Filled with demos of what the kits can do aside from really cool robot owls.

Hopefully these promotional efforts helped many AIY kits find new homes in the hands of creative makers. It’s pretty exciting that such a powerful and inexpensive neural net processor is now widely available, and we look forward to many more AI-powered hacks to come.

Instagram Photo

from Blog – Hackaday https://ift.tt/2IHaVhq
via IFTTT

ESP32 Boards With Displays: An Overview

The ESP8266 has become practically the 555 chip of WiFi connected microcontrollers. Traditionally, you’d buy one on a little breakout board with some pins and a few connectors, and then wire up anything else you need. The ESP8266’s big brother, the ESP32, hasn’t quite taken over from the ESP8266, but it has a lot more power and many more options. [Andreas] has a new video that shows seven new ESP32 boards that have integral displays. These boards can simplify a lot of applications where you need both WiFi and a user interface.

Of the boards examined, six of them have OLED displays, but one has an E-paper display. To summarize results, [Andreas] summarized his findings on these seven along with others in an online spreadsheet.

The boards include:

  • TTGO with 2.9 E-paper display
  • TTGO TS V1.2
  • TTGO T4
  • TTGO Pro V2
  • TTGO LoRa V2
  • Wemos
  • Wifi Kit32

There are two pieces of software to do testing and those are available on GitHub if you want to test new boards or do your own testing.

The review is very practical, examining power consumption, available pins, and how easy it is to use on a breadboard. Since [Andreas] comes tot his with a voice of experience he also looks at things like battery switches, and whether the device crashes if you disconnect the USB power. Spoiler alert: He was not happy with the E-paper display board.

These display-bearing devices are much easier than using a separate ESP32 for each pair of digits. If you need a much bigger display, there’s always this.

from Blog – Hackaday https://ift.tt/2GHxSuZ
via IFTTT

Using TensorFlow To Recognize Your Own Objects

When the time comes to add an object recognizer to your hack, all you need do is choose from many of the available ones and retrain it for your particular objects of interest. To help with that, [Edje Electronics] has put together a step-by-step guide to using TensorFlow to retrain Google’s Inception object recognizer. He does it for Windows 10 since there’s already plenty of documentation out there for Linux OSes.

You’re not limited to just Inception though. Inception is one of a few which are very accurate but it can take a few seconds to process each image and so is more suited to a fast laptop or desktop machine. MobileNet is an example of one which is less accurate but recognizes faster and so is better for a Raspberry Pi or mobile phone.

Collage of images for card datasetYou’ll need a few hundred images of your objects. These can either be scraped from an online source like Google’s images or you get take your own photos. If you use the latter approach, make sure to shoot from various angles, rotations, and with different lighting conditions. Fill your background with various other things and even have some things partially obscuring your objects. This may sound like a long, tedious task, but it can be done efficiently. [Edje Electronics] is working on recognizing playing cards so he first sprinkled them around his living room, added some clutter, and walked around, taking pictures using his phone. Once uploaded, some easy-to-use software helped him to label them all in around an hour. Note that he trained on 24 different objects, which are the number of different cards you get in a pinochle deck.

You’ll need to install a lot of software and do some configuration, but he walks you through that too. Ideally, you’d use a computer with a GPU but that’s optional, the difference being between three or twenty-four hours of training. Be sure to both watch his video below and follow the steps on his Github page. The Github page is kept most up-to-date but his video does a more thorough job of walking you through using the software, such as how to use the image labeling program.

Why is he training an object recognizer on playing cards? This is just one more step in making a blackjack playing robot. Previously he’d done an impressive job using OpenCV, even though the algorithm handled non-overlapping cards only. Google’s Inception, however, recognizes partially obscured cards. This is a very interesting project, one which we’ll be keeping an eye on. If you have any ideas for him, leave them in the comments below.

from Blog – Hackaday https://ift.tt/2xdLI8G
via IFTTT

Retro Rebuild Recreates SGI Workstation Demos On The Go

When [Lawrence] showed us the Alice4 after Maker Faire Bay Area last weekend it wasn’t apparent how special the system was. The case is clean and white, adorned only with a big red button below a 7″ screen with a power switch around the back. When the switch is flicked the system boots to display a familiar animation and drops you at a menu. Poking around from here elicits a variety of self-contained graphics demos, some interactive. So this is a Raspberry Pi in a box playing videos, right? Not even close.

Often retro computing focuses on personal computer systems. When they were new the 8-bit graphics or intricate 2D sprites were state of the art, but now their appeal tends towards learning opportunities and the thrill of nostalgia. This may still be true of Alice4, the system [Brad, Lawrence, Mike, and Chris] put together to run Silicon Graphics (SGI) demos from the mid 1980’s but it’s not the whole story. [Lawrence] and [Brad] had both worked at SGI during its heyday and had fond memories of the graphics demos that shipped with those mammoth workstation. So they built Alice4 from the FPGA up to run those very same demos in real-time.

Thanks to Moore’s law, today’s embedded systems put yesterday’s powerhouses within reach. [Lawrence] and [Brad] found the old demo code in a ratty FTP server, and tailor-made Alice4’s software and hardware to run them natively. [Brad] wrote a libgl which implements the subset of the IrisGL API needed to support their selected set of demos. The libgl emits sets of triangles to the SDRAM where [Lawrence’s] HDL running on the onboard FPGA fetches them to interpolate color and depth and draw the result on-screen. Together they allow the $99 Altera Cyclone V development board at Alice4’s heart to run these state of the art demos in the palm of your hand.

Alice4 is open source and extensively documented. Peruse the archeology of reverse engineering the graphics API or the discussion of FIFO design in the FPGA. If those don’t sate your appetite check out a video of Alice4 in action after the break.

from Blog – Hackaday https://ift.tt/2IFsnTo
via IFTTT