Listening To Electromagnetic Interference With A RTLSDR Dongle

Being curious by nature, [Marios] decided to see what kind of radio-frequency emissions may be generated by an Arduino connected to a simple breadboard wire, and more importantly try to pick them up using a RTLSDR dongle. Electromagnetic interferences are disturbances that affect electrical circuits due to either electromagnetic induction or electromagnetic radiation. Before going into the market, all electrical devices are thoroughly checked for unwanted electromagnetic emissions so they usually aren’t obvious suspects when such problems arise.

Using the Arduino embedded PWM controller in fast PWM mode and by manipulating the duty cycle, he actually managed to create a primitive form of amplitude modulation and was able to transfer a very simple audible signal at several frequencies up to 1.75GHz. Embedded after the break here is video of the system at work.

As a side note, did you know that during the solar storm of 1859 the EMI were so strong that the telegraph operators received several shocks? Pipelines maintenance systems also have to be aware of such events, that can lead sensors to provide inaccurate results.

Continue reading “Listening To Electromagnetic Interference With A RTLSDR Dongle”

Developed On Hackaday: Security And Arduino Compatibility

2013-12_Developed_on_Hackaday

Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Cordwood Puzzle Kit Without Instructions

What you see above is a cordwood circuit, an interesting circuit construction technique from before the days of integrated circuits. The circuit consists of two circuit boards arranged parallel to each other with components holding them apart. This was, for its day, the densest circuit construction technique, used in everything from late 50s aerospace tech to huge computers that filled rooms.

The folks over at Boldport have a love for interesting PCBs and are apparently aficionados of antiquated tech, leading them to create their own cordwood circuit. Here’s the best part: it’s a kit, without assembly instructions.

The cordwood puzzle assembles into a bunch of LEDs that will light up when power is applied. Not much, but there’s a few FETs in there that allow you to control them all individually with a microcontroller. The real fun is trying to assemble the kit: both sides of the cordwood circuit are identical, meaning there’s going to be holes that aren’t meant to be filled, components that will need to be soldered, and most likely a bit of swearing.

Still, this is an exceptionally small circuit for something using this construction technique. If you know of a denser and more modern cordwood circuit out there, leave a note in the comments. If you want to know what the kit looks like when it’s built, [Phil Wright] has your back.

Developed On Hackaday: Coding Conventions And GitHub Pull Requests

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)
{
    if (foo)
    {
        functionCall();
    }
    else
    {
        foo = 0;
        anotherFunctionCall();
    }
}
– 79 characters line length as a soft requirement
– 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.

I Can Fix The Space Station With A Metronome, A Metronome, A Metronome

ISS

If the space station were left to its own devices, the living quarters would get incredibly hot. There are computers, hardware, and six crew members, all generating heat that must be gotten rid of. To do this, there are two heat exchangers inside the station that take warm water, dump that heat to ammonia, and send that ammonia out to panels outside the station. On December 11, 2013, Loop A of the thermal control system shut down, putting the station one failure away from evacuation. Plans for a spacewalk were tabled, but the ground crew managed to fix this hardware failure by telling the astronauts to push buttons, a metronome, and a software patch.

The problem with Loop A of the Internal Thermal Control System was a flow control valve that regulated the amount of ammonia flowing through the heat exchange. Too much ammonia, and the station would be far too cold. Too little, and it would be too hot. This valve is electronically controlled and takes exactly 13 seconds to move from open to closed. The first attempt at fixing the problem was having ground crew send the command to open the valve and cut the power halfway through. This involved using a metronome app on a phone to send two commands 6.5 seconds apart. It worked, but not quite well enough.

The failure of the metronome technique led [Todd Quasny] to write a script to turn the ‘on’ and ‘off’ commands from the ground to the ISS with millisecond resolution. This meant the commands to control the valve could be sent with the right delay, but they weren’t received with the right delay. This is a problem that had to be fixed from the station’s computers.

To finally solve the problem, ISS software engineer [Steve Joiner] was called in to write a software patch for the thermal control system. This is spaceflight and writing software is a long a laborious process of testing and code reviews. Nevertheless, the team managed to write and upload a patch in just two days.

This patch gave controllers the ability to control the valve with a resolution of 100 milliseconds, good enough for very fine control of the thermal system, and all without requiring the massive amount of planning that goes into a spacewalk or resupply mission.

Ups to [Ed Van Cise] for this tip. If you’re curious about the headline….

The Mystery Of Zombie RAM

[Josh] had a little project where he needed to keep a variable in RAM while a microcontroller was disconnected from a power source. Yes, the EEPROM on board would be able to store a variable without power, but that means writing to the EEPROM a lot, killing the lifetime of the chip. He found an ATTiny can keep the RAM alive for a variable amount of time – somewhere between 150ms and 10 minutes. Wanting to understand this variability, he decided to solve the mystery of the zombie RAM.

The first experiment involved writing a little bit of code for an ATTiny4313 that looked for a value in RAM on power up and light up a LED if it saw the right value. The test circuit consisted of a simple switch connected to the power pin. Initial tests were astonishing; the ATTiny could hold a value in RAM for up to 10 minutes without power.

With the experiment a success, [Josh] updated his project to use this new EEPROM-saving technique. Only this time, it didn’t work. The value hidden away in RAM would die in a matter of milliseconds, not minutes. After tearing his hair out looking for something different, [Josh] rigged up an Arduino based test circuit with humidity and temperature sensors to see if that had any effect. It didn’t, and the zombie RAM was still not-undead.

The key insight into how the RAM in an ATtiny could stay alive for so long came when [Josh] noticed his test circuit had a LED, but the actual project didn’t. Apparently this LED was functioning as a very tiny solar cell, generating a tiny bit of current that kept the RAM alive. A dark room with a flashlight confirmed this hypothesis, and once [Josh] gets his uCurrent from Kickstarter he’ll know exactly how much current this LED is supplying.

Turning A Tiny CRT Into A Monitor

TV

[GK] picked up a few tiny 2″ CRTs a while back and for the longest time they’ve been sitting in a box somewhere in the lab. The itch to build something with these old tubes has finally been scratched, with a beautiful circuit with Manhattan style construction.

[GK] has a bit of a fetish for old oscilloscopes, and since he’s using an old ‘scope tube, the design was rather simple for him; there aren’t any schematics here, just what he could put together off the top of his head.

Still, some of [GK]’s earlier projects helped him along the way in turning this CRT into a monitor. The high voltage came from a variable output PSU he had originally designed for photomultiplier tubes. Since this is a monochrome display, the chrominance was discarded with an old Sony Y/C module found in a part drawer.

It’s a great piece of work that, in the words of someone we highly respect is, “worth more than a gazillion lame Hackaday posts where someone connected an Arduino to something, or left a breadboard in a supposedly “finished” project.” Love ya, [Mike].