Hacking Google Daydream To Work With IOS

December 20, 2016 by Elliot Williams 11 Comments

The Google Daydream is a VR headset with a controller, and according to the folks at Google, “It’s not currently compatible with iOS and won’t be for several years probably.” OK.

This inspired [Matteo Pisani] to get to work on the protocol that it uses to speak with Android phones. Cutting to the chase, he got it working in several days.

There really wasn’t all that much to it. The controller sends data over Bluetooth, and [Matteo] noticed an “unknown” device on the network. Looking inside the data that it sent, it changed when he moved the controller. Not so unknown now! The rest of the work consisted of writing applications to test hypotheses, waving the controller around, and finding out if he was right. Read up if you’re interested in implementing this yourself.

We love protocol hacks here. From running quadcopters on your own remotes, to simply trying to turn on a lightbulb, it’s getting more and more important that we understand the various languages that our devices speak.

PJON, Fancy One Wire Arduino Communications Protocol For Home Automation

March 31, 2016 by Gerrit Coetzee 44 Comments

PJON, pronounced like the iridescent sky rats found in every city, is a cool one wire protocol designed by [gioblu].

[gioblu] wasn’t impressed with the complications of I2C. He thought one-wire was too proprietary, too complicated, and its Arduino implementations did not impress. What he really wanted was a protocol that could deal with a ton of noise and a weak signal in his home automation project with the smallest amount of wiring possible.

That’s where is his, “Padded Jittering Operative Network,” comes in. It can support up to 255 Arduinos on one bus and its error handling is apparently good enough that you can hold an Arudino in one hand and see the signals transmitted through your body on the other. The fact that a ground and a signal wire is all you need to run a bus supporting 255 devices and they’ll play nice is pretty cool, even if the bandwidth isn’t the most extreme.

Aside from the cool of DIY protocols. We really enjoyed reading the wiki describing it. Some of the proposed uses was running your home automation through your ducting or water pipes (which should be possible if you’re really good at isolating your grounds). Either way, the protocol is neat and looks fun to use. Or check out PJON_ASK if you want to do away with that pesky single wire.

Decoding And Replicating Xantrex Solar Charge Data

May 3, 2015 by Mike Szczys 13 Comments

This is a story mostly of decoding data, but there is a happy ending that includes turning that decoding work into an open source receiver. Xantrex solar charge controllers monitor a lot of data about what is happening with your solar panels, and they stream it over RJ25 but you need their add-on hardware to receive it. [Eric Herbers] figured if the data is being transmitted, a resourceful hackers should be able to decode it. And he did just that with a little help from his friends in the Hackaday community.

We asked on Twitter what people were working on and [Eric] posted his scope screenshot. The conversation that followed helped point him in the right direction and others knowing about the project surely drove him to finish it. The decoding isn’t perfect, but achieve enough to decode and display voltage, amperage, and temperature. [Eric] built the display unit using an Arduino Pro Mini and a character LCD housed in you most common of black project boxes.

Teletext On A Raspi With Zero Additional Parts

February 13, 2015 by Brian Benchoff 45 Comments

Way back in the 70s, the UK and BBC rolled out teletext – an information retrieval service that’s much closer to the ‘television screens connected to computers the size of a room’ popularized by 1960s futurists than the Internet and world wide web. For about 30 years, teletext was one of the most reliable means of information distribution until it was quietly shelved with the rollout of digital television.

Playing with dead protocols is fun, though, and since the Raspberry Pi has an analog video out, [Alistair] thought it would be fun to turn his Pi into a teletext generator and display.

This isn’t [Alistair]’s first teletext rodeo; earlier he built an add-on board for the Raspi that uses an AVR and an LM1881 video sync separator to mux the video output of a Raspi with teletext signals. The new build does away with this completely, allowing any Raspberry Pi to generate and display information from a teletext service. Right now there are two demos, a Raspi status display that shows the CPU frequency, usage, memory, and temperature. There’s also a ‘clock cracker’ with a picture of Tux that should help diagnose reception issues.

All the code is available on the project’s github, although [Alistair] hasn’t released the scripts to output teletext pages captured from broadcast signals years ago.

Continue reading “Teletext On A Raspi With Zero Additional Parts” →

The Development Of A Lightweight Wireless Protocol

June 12, 2014 by Brian Benchoff 30 Comments

BANO [Texane] had been thinking about how to monitor the state of his garage door from a remote place. The door itself isn’t around any power outlets, and is a few floors away from where his server would be located in his apartment. This presented a few design challenges – namely, the sensor itself should have a wireless connection to the server, and being low power would be a great idea. This led to the development of a minimalist framework for wireless communication that allows a sensor to run for weeks without a battery swap.

The wireless protocol itself is based on a simple key value pair; each individual sensor, coupled with a NRF905 radio, has passes an address, a key, and a value. There are allowances for checksums and acknowledgement, but as the PDF says, this is a very minimal protocol.

With the software out of the way, [Texane] turned to the hardware. The microcontroller is a simple Arduino clone, paired with a radio and a coin cell on a small board. The micro spends most of its time in a low power state, with the sensor, in this case a reed switch, tied to an interrupt pin.

There was a problem with the power consumption of the radio, though: when the short 17-byte message was transmitting, there was a significant voltage drop. This was okay with a fully charged battery, but with a partially drained coin cell, the possibility of brownouts was high. A big cap in parallel was enough to offset this voltage drop.

It’s still a little expensive for an all-in-one home automation and monitoring system, but developing a functional wireless protocol and the hardware to go with it is no small feat. It’s actually a great piece of kit that [Texane] is sure to find a few uses for.

How A Dial-up Modem Handshake Works

January 31, 2013 by Mike Szczys 56 Comments

If you’re old enough to have used a dial-up modem we’d bet you can do an imitation of the sounds it made while connecting. Those not-so-beautiful sounds heralded the dawning of a technological era. But few actually know what each of those distinct sounds were doing. Now’s your chance to learn. This post explains each step in the dail-up handshake process.

This may be the most useful infographic we’ve ever seen. Normally we just seem them as gimmicks, but [Oona Räisänen] really put together something special with this one. Her blog post includes an audio clip so that you can play back the full handshake sounds. The main box on the graphic shows the audio spectrum from that clip, with an explanation below it. But you’ll also want to read through her full write-up for a more narrative description.

The part we found the most interesting is that these modems needed to disable the echo suppression used by the telephone system in order to operate at full-duplex. Apparently land lines disabled the speaker while you were talking so that you didn’t hear your own voice. This was a problem if the modem was trying to send and receive at the same time.

[via Reddit]

Communication Protocol For An Indoor Helicopter

January 21, 2013 by Mike Szczys 6 Comments

propel-execuheli-ir-protocol-revealed

There’s a special type of satisfaction that comes from really understanding how something works at the end of a reverse engineering project. This grid above is the culmination of [Spencer’s] effort to reverse engineer the IR protocol of a Propel ExecuHeli indoor helicopter toy.

The first thing he looked at was the three different controller channels which can be selected to allow multiple helicopters to be used in the same area. [Spencer] was surprised that they all used the same carrier frequency. The secret must be in the coded packets so his next challenge was to figure out how the data was being transmitted via the Infrared signal. It turns out the packets are using pulse-length coding (we were unfamiliar with this protocol but you can read a bit more about it here). The last piece of the puzzle was to capture packets produced by each unique change of the control module. With each bit (except for bit 11) accounted for he can now format his own codes for a controller replacement. Perhaps he’s looking to make the helicopter autonomous?