Geigers On A Plane

[Thomas] took a Geiger counter he built on a plane. Why? Because he can, much to the chagrin of airport security.

[Thomas]’ Geiger counter is built around an old Russian SBT-10A detector containing ten separate Geiger tubes. This tube was connected to a circuit containing a LiPo battery, a few high-voltage components, and an audio jack connected to the tubes themselves. When alpha, beta, or gamma radiation hits one of the Geiger tubes, an enormous click is sent to the audio jack and into the microphone jack of a small netbook.

Right after boarding a plane in Dublin, [Thomas] booted up his computer, started recording in Audacity, plugged in his Geiger counter, and stored his experiment safely in the overhead compartment. After landing in Prague a few hours later, [Thomas] saved the 247 MB .WAV file and began working on a way to convert clicks in an audio track into usable data.

The audio output on the Geiger counter overloaded the mic input on his netbook, making ‘event detection’ very easy with a small C app. After plotting all the data (seen above), [Thomas] had a complete record of the radiation on his 2-hour flight.

Because there was far less atmosphere to absorb cosmic radiation, [Thomas]’ radiation dose was 9.1 microsieverts. Much more than at sea level, but nothing even air crews need to worry about.

Emulating The DCPU On An AVR

[skywodd] just finished his own DCPU emulator (French, translation) based on [notch]’s upcoming game, 0x10c. The neat thing about [skywodd]’s build is his emulator uses the lowly ATMega328, the same microcontroller found in (some) Arduinos.

The DCPU specification goes over the operations required of any DCPU emulator. There’s a lot of crazy stuff here – a division instruction that takes only 3 clock cycles, using an overflow for carry conditions, and a complete lack of a JMP instruction – but [skywodd] was able to tease something apart from DCPU studio and a VGA interface

Everything in this emulator is built on a solderless breadboard, but the ROM and RAM isn’t complete yet. As of now, everything is handled by the ‘328, using 478 bytes of RAM on the microprocessor.

We promised we would be holding a contest for the best physical implementation of the DCPU when we caught wind of 0x10c, and [skywodd]’s build is starting to look like the beginnings of the winning entry. We honestly have no idea when we’ll be holding this contest, but it’ll probably be shortly after the first playable release. Go bug [notch] if you’d like to speed up the progress, because obviously Twitter abuse speeds up software development.

How’s The 60Hz Coming From Your Wall?

If you’ve ever wondered why NTSC video is 30 frames and 60 fields a second, it’s because the earliest televisions didn’t have fancy crystal oscillators. The refresh rate of these TVs was controlled by the frequency of the power coming out of the wall. This is the same reason the PAL video standard exists for countries with 50Hz mains power, and considering how inexpensive this method of controlling circuits was the trend continued and was used in clocks as late as the 1980s. [Ch00f] wondered how accurate this 60Hz AC was, so he designed a little test.

Earlier this summer, [Ch00f] bought a 194 discrete transistor clock kit and did an amazing job tearing apart the circuit figuring out how the clock keeps time. Needing a way to graph the frequency of his mains power, [Ch00f] took a small transformer and an LM311 comparator. to out put a 60Hz signal a microcontroller can read.

This circuit was attached to a breadboard containing two microcontrollers, one to keep time with a crystal oscillator, the other to send frequency data over a serial connection to a computer. After a day of collecting data, [Ch00f] had an awesome graph (seen above) documenting how fast or slow the mains frequency was over the course of 24 hours.

The results show the 60Hz coming out of your wall isn’t extremely accurate; if you’re using mains power to calibrate a clock it may lose or gain a few seconds every day. This has to do with the load the power companies see explaining why changes in frequency are much more rapid during the day when load is high.

In the end, all these changes in the frequency of your wall power cancel out. The power companies do the same thing [Ch00f] did and make sure mains power is 60Hz over the long-term, allowing mains-controlled clocks to keep accurate time.

Servos, Servos, And More Servos

For one reason or another, a lot of Hackaday readers are doing stuff with servos as of late. Here’s a few servo hacks that made their way into our tip line over the past day or so:

USB servo controller and a Stewart Platform

[Patricio] needed a way to control a bunch of servos for his thesis project. He came up with a USB servo controller (Spanish, here’s the translation) powered by a 40-pin PIC 18F microcontroller. The board connects to the USB port of a computer and supports up to 8 servos with 8 additional digital I/Os. Why all this horsepower? It’s for a Stewart Platform [Patricio] and his partner [Natalia] built.

Continuous rotation servos

Standard servos are usually limited to a rotation angle of somewhere between 140 and 160 degrees. Sometimes you need a continuous rotation servo, and those are a little more expensive. Every servo is a continuous rotation servo if you disable a the variable resistor as [Valentin] shows us. It’s a simple, if old, hack. It’s new to someone, though.

Eight servos on a Raspi

[Mikael] made a little board to attach to the GPIO header of his Raspberry Pi and control up to 8 servos. The board is running a serial interface with a small microcontroller on board. There’s nothing in the way of schematics or code, a testament for why you should always use a good email address when sending something into the HaD tip line. It seems [Mikael] is making a proper board, and we’ll more than happily give it a full post when it’s complete.

A Hardware Random Number Generator For Your FPGA

[Zach] sent in a project he’s been working on that brings hardware random number generators to common hardware you might have lying around. It’s called Whirlyfly and it turns an FPGA dev board into a hardware random number capable of outputting random bits over a USB connection at 3 Mbps.

Previously, the whirlygig ran on a custom CPLD that interfaced to a *nix box and provided high quality random numbers via /dev/hw_random. [Zach]’s efforts takes the core of the whirlygig and ports it to the very popular and inexpensive Papilio One FPGA dev board.

As for what [Zach] can do with his random number generator, it’s extremely easy to write a Monte Carlo experiment to approximate the value of π with a better accuracy than [Ptolemy] was able to muster 1900 years ago. There’s also the aspect of encryption, and – why you would do this we have no idea – making an uncompressable file is also possible.

Cracking Open An Ancient Avionics Gyroscope

This artificial horizon might as well have come from an alien ship. [Mike] somehow manages to get his hands on most interesting equipment, this time its a very old piece of avionics equipment. The mechanical gyroscope functioned as the artificial horizon, and he’s going to take us inside for a look. He doesn’t spend quite as much time on it as he did that thermal imaging camera, but this electro-mechanical odyssey is just as interesting.

To get the accuracy needed to help keep a plane in the air (well to keep the pilot well-informed anyway) the device needed to be very well manufactured. [Mike] comments several times along the way on how the different rotating parts are so well-balanced and machined that they seem nearly frictionless. It appears that a lot of the positional feedback depends on wirewound resistor rings which connect to a rotating piece via a series of very fine spring wires. As the parts rotate the resistance changes and that’s what gives the feedback. There are also mercury switches to help along the way.

He does his best to explain, but to us the inner workings are still a big mystery. See if you can get a clearer picture from the video after the break.

Continue reading “Cracking Open An Ancient Avionics Gyroscope”

Rocket Telemetry From UAV Hardware

When we posted our call for rocketry hacks and builds, we expected to see a few altitude sensors and maybe a GPS module or two. Apparently, we forgot similar hardware is very popular in the remote-controlled aircraft world, and can be successfully added to a rocket as [Kevin] and his ArduPilot equipped J motor rocket showed us

The ArduPilot is a small Arduino comparable board designed for UAVs, quadcopters, and other whirligigs not powered by rocket motors. To get real-time telemetry from his rocket, [Kevin] attached a GPS receiver and an XBee transmitter. When launched on an H165 motor, [Kevin] was able to keep a radio lock on his rocket, allowing him to pull down data in real-time.

There are a few drawbacks to using the ArduPilot to collect flight data; the ArduPilot only reports ground speed, a somewhat useless feature if the vehicle is going straight up. Also, there is no way for [Kevin] to record data to an SD card; the ground team must be able to receive the XBee, lest bits of data go missing. For most rockets the radio issue shouldn’t be a problem. [Kevin] launched the same hardware on a J motor and was able to receive data from 3600 AGL.