Reverse Engineering Quadcopter Protocols

Necessity is the mother of invention, but cheap crap from China is the mother of reverse engineering. [Michael] found a very, very cheap toy quadcopter in his local shop, and issued a challenge to himself. He would reverse engineer this quadcopter’s radio protocol. His four-post series of exploits covers finding the right frequency for the radio, figuring out the protocol, and building his own remote for this cheap toy.

[Michael] was already familiar with the capabilities of these cheap toys after reading a Hackaday post, and the 75-page, four language manual cleared a few things up for him. The ‘Quadro-Copter’ operated on 2.4GHz, but did not give any further information. [Michael] didn’t know what channel the toy was receiving on, what data rate, or what the header for the transmission was. SDR would be a good tool for figuring this out, but thanks to Travis Goodspeed, there’s a really neat trick that will put a 2.4GHz nRF24L01+ radio into promiscuous mode, allowing [Michael] to read the transmissions between the transmitter and quadcopter. This code is available on [Michael]’s github.

A needle in an electromagnetic haystack was found and [Michael] could listen in on the quadcopter commands. The next step was interpreting the ones and zeros, and with the help of a small breakout board and soldering directly to the SPI bus on the transmitter, [Michael] was able to do just that. By going through the nRF24 documentation, he was able to suss out the pairing protocol and read the stream of bytes that commanded the quadcopter.

What [Michael] was left with is a series of eight bytes sent in a continuous stream from the transmitter to the toy. These bytes contained the throttle, yaw, pitch, roll, and a ‘flip’ settings, along with three bytes of ‘counters’ that didn’t seem to do anything.  With that info in hand, [Michael] took an Arduino Nano, an nRF04L01+ transceiver, and a Wii nunchuck to build his own transmitter. If you’re looking for a ‘how to reverse engineer’ guide, it generally doesn’t get better than this.

You can check out a video of [Michael] flying his Wiimoted quadcopter below.

Continue reading “Reverse Engineering Quadcopter Protocols”

Retrotechtacular: ASCII Art in the 19th Century

Computer graphics have come a long way. Some video games today exceed what would have passed for stunning cinema animation only a few years ago. However, it hasn’t always been like this. One of the earliest forms of computer-generated graphics used text characters to draw on printers.

snoopy-calendarEarly computer rooms were likely to have a Snoopy character on green and white fan-fold paper. Calendars with some artwork were also popular (see left, and find out about the FORTRAN that created it, if you like). Ham radio operators who use teletypes (RTTY, in ham parlance) often had vast collections of punched tape that held artwork. Given that most hams in the 1950s and 1960s were men and the times were different, a lot of them were more or less “R” rated.

nixonNot all of them were, though. For example, Richard Nixon was decidedly “G” rated (see right). Simple pictures would use single characters, but sophisticated ones would use the backspace character to overprint multiple characters.

Ham Radio Art

You often hear this described as ASCII art, today, although hams usually use 5-bit BAUDOT code, so that’s a misnomer for those images, at least. Of course, today, people aren’t keen on storing roll after roll of paper tape (or even owning a tape reader) so there have been several projects to capture this art in a more modern format.

Although there is still some RTTY art activity, picture sending has been mostly replaced by slow scan TV (SSTV) which sends actual still images or other modes like FAX. Some of the newer digital modes even have the ability to send pictures. You can be discussing your radio for example, and then show the other ham a photo of the radio.

Continue reading “Retrotechtacular: ASCII Art in the 19th Century”

E Pluribus Unix, QR-Style

It’s been a long time since we’ve logged into a UNIX mainframe (other than our laptop) but one of our fond memories is the daily fortune: small, quirky, sometimes cryptic sayings that would pop up on the login screen if your system administrator had any sense of humor.

Apparently, we’re not alone. [Alastair] made his own fortune clock which gives you a new “fortune” every second instead of every login. There’s a catch, of course. It’s a QR clock — the fortune is encoded in a QR code instead of being displayed in human-readable form. You have to take a picture of the tiny OLED screen to know what it says. (Watch it sending him Shakespeare sonnets in the video below.)

You probably know QR codes are good for conveying URLs, but their use as general-purpose text containers is underappreciated in our book, so we’re glad to see this example. Now, we’ve seen QR clocks before (here, and here), and this version does have the disadvantage that you can actually tell what time it is. But we’re grateful for the trip down memory lane.

Continue reading “E Pluribus Unix, QR-Style”

Serially, Are You Syncing or Asyncing?

I know you’ve heard of both synchronous and asynchronous communications. But do you really know the differences between the two?

Serial communication was used long before computers existed. A predecessor is the telegraph system using Morse Code, one of the first digital modes of communication. Another predecessor is the teletype, which set standards that are still used today in your Arduino or Raspberry Pi.

All you need is two wires for serial communications, which makes it simple and relatively robust. One wire is ground and the other the signal. By interrupting the power with predefined patterns, information can be transferred over both short and long distances. The challenge is receiving the patterns correctly and quickly enough to be useful.

I was a bit surprised to find out the serial port on the Arduino Uno’s ATmega328P microcontroller is a Universal Synchronous Asynchronous Transmitter Receiver (USART). I’d assumed it was only a UART (same name, just leave out synchronous) probably because my first work with serial communications was with the venerable Intel 8251 “Programmable Communication Interface”, a UART, and I didn’t expect the microcontroller to be more advanced. Silly me. Later I worked with the Zilog 8530 Serial Controller Chip, a USART, the term I’ll use for both device types.

All these devices function in the same way. You send a byte by loading it into a register and it is shifted out one bit at a time on the transmit (TX) line as pulses. The receiver accepts the pulses on a receive (RX) input and shifts them into a register, which is then read by the system. The transmitter’s job is pretty easy it just shifts out the bits at a known clock rate. The receiver’s task is more complex because it needs to know when to sample the incoming signal. How it does this is the difference between asynchronous and synchronous communications.

Continue reading “Serially, Are You Syncing or Asyncing?”

Raspberry Pi Gets Turned On

The Raspberry Pi and other similar Linux-based single board computers simplify many projects. However, one issue with Linux is that it doesn’t like being turned off abruptly. Things have gotten better, and you can certainly configure things to minimize the risk, but–in general–shutting a Linux system down while it is running will eventually lead to file system corruption.

If your project has an interface, you can always provide a shutdown option, but that doesn’t help if your application is headless. You can provide a shutdown button, but that leaves the problem of turning the device back on.

[Ivan] solved this problem with–what else–an Arduino (see the video below). Simplistically, the Arduino reads a button and uses a FET to turn off the power to the Pi. The reason for the Arduino, is that the tiny processor (which draws less than a Pi and doesn’t mind being shut down abruptly) can log into the Pi and properly shut it down. The real advantage, though, is that you could use other Arduino inputs to determine when to turn the Pi on and off.

Continue reading “Raspberry Pi Gets Turned On”

AVR vs PIC, Round 223: Fight!

Get ready to rumble! [Thierry] made the exact same Hello-World-esque project with two microcontrollers (that are now technically produced by the same firm!) to see how the experience went.

It’s not just an LED-blinker, though. He added in a light-detection function so that it only switches on at night. It uses the Forest Mims trick of reverse-biasing the LED and waiting for it to discharge its internal capacitance. The point is, however, that it gives the chip something to do instead of simply sleeping.

Although he’s an AVR user by habit, [Thierry] finds in favor of the PIC because it’s got a lower power draw both when idling and when awake and doing some computation. This is largely because the PIC has an onboard low-power oscillator that lets it limp along at 32 kHz, but also because the chip has a lower power consumption in general. In the end, it’s probably a 10% advantage to the PIC on power.

If you’re competent with one of the two chips, but not the other, his two versions of the same code would be a great way to start familiarizing yourself with the other. We really like his isDarkerThan() function which makes extensive use of sleep modes on both chips during the LED’s discharge period. And honestly, at this level the code for the two is more similar than different.

(Oh, and did you notice [Thierry]’s use of a paper clip as a coin-cell holder? It’s a hack!)

Surprisingly, we’ve managed to avoid taking a stray bullet from the crossfire that occasionally breaks out between the PIC and AVR fans. We have covered a “shootout” before, and PIC won that round too, although it was similarly close. Will the Microchip purchase of Atmel calm the flames? Let’s find out in the comment section. We have our popcorn ready!

Hackaday Prize Entry: MyComm Handheld Satellite Messenger

We live in a connected world, but that world ends not far beyond the outermost cell phone tower. [John Grant] wants to be connected everywhere, even in regions where no mobile network is available, so he is building a solar powered, handheld satellite messenger: The MyComm – his entry for the Hackaday Prize.

The MyComm is a handheld touch-screen device, much like a smartphone, that connects to the Iridium satellite network to send and receive text messages. At the heart of his build, [John] uses a RockBLOCK Mk2 Iridium SatComm Module hooked up to a Teensy 3.1. The firmware is built upon a FreeRTOS port for proper task management. Project contributor [Jack] crafted an intuitive GUI that includes an on-screen keyboard to write, send and receive messages. A micro SD card stores all messages and contact list entries. Eventually, the system will be equipped with a solar cell, charging regulator and LiPo battery for worldwide, unconditional connectivity.

2016 will be an interesting year for the Iridium network since the first satellites for the improved (and backward-compatible) “Iridium NEXT” network are expected to launch soon. At times the 66 Iridium satellites currently covering the entire globe were considered a $5B heap of space junk due to deficiencies in reliability and security. Yet, it’s still there, with maker-friendly modems being available at $250 and pay-per-use rates of about 7 ct/kB (free downstream for SDR-Hackers). Enjoy the video of [Jack] explaining the MyComm user interface:

Continue reading “Hackaday Prize Entry: MyComm Handheld Satellite Messenger”