Inventing Networking Protocols For Dozens Of Arduinos

December 3, 2012 by 35 Comments

chain

When you don’t want to use I2C or SPI, and MIDI and DMX are old hat, [Scott] comes along and invents a very strange networking protocol that is just daisy chaining a few Arduinos together with serial connections.

Strange as it may seem, this networking protocol actually makes a whole lot of sense. [Scott] is working on an animatronic birdhouse in the vein of Disney’s Imagineers and needed to network a whole bunch of Arduinos without using up precious IO pins.

The networking stack [Scott] came up with capitalizes on the hardware UART in each Arduino by simply daisy-chaining several boards together. By adding an FTDI breakout at the beginning of the chain, [Scott] can control dozens of Arduinos straight from a terminal

[Scott] isn’t using off-the-shelf Arduinos for this project – a few months ago he found 100 Arduino-compatible stepper motor controllers while dumpster diving at his job, giving him more than enough nodes to come up with some pretty crazy networking protocols. It’s a great use of the hardware he has on hand, and a very clever solution to controlling dozens of microcontrollers at once.

Check out [Scott]’s demo after the break.

Continue reading “Inventing Networking Protocols For Dozens Of Arduinos” →

Reverse Engineering A Syma 107 Toy Helicopter IR Protocol

August 27, 2012 by 9 Comments

Half the fun of buying toys for your kids is getting your hands on them when they no longer play with them. [Kerry Wong] seems to be in this boat. He bought a Syma S107G helicopter for his son. The flying toy is IR controlled and he reverse engineered the protocol it uses. This isn’t the first time we’ve seen this type of thing with the toy. In fact, we already know the protocol has been sniffed and there is even a jammer project floating around out there. But we took a good look at this because of what you can learn from [Kerry’s] process.

He starts by connecting an IR photo diode to his oscilloscope. This gave him the timing between commands and allowed him to verify that the signals are encoded in a 38 kHz carrier signal. He then switched over to an IR module designed to demodulate this frequency. From there he captures and graphs all of the possible control configuration, establishing a timing and command set for the device. He finishes it off by building a replacement controller based on an Arduino. You can see a video of that hardware after the break.

Continue reading “Reverse Engineering A Syma 107 Toy Helicopter IR Protocol” →

Reverse Engineering An AC Signal Protocol

February 4, 2012 by 22 Comments

[Arpad] has spent quite a bit of time reverse-engineering a home automation system, and, as he is quick to point out, presents the information learned for informational purposes only. He’s really done his homework (and documented it well), looking into the US patent application, and figuring out how the protocol works.

If you’re wondering how someone is able to send a signal over an AC sine wave, at least one technique is the proprietary [Universal Powerline Bus]. This works by sending precisely times pulses in conjunction with the wave that would exist normally. Given the correct software on the other end, this can then be decoded and used for whatever data transfer is necessary.

Although as engineers and technologists, we certainly don’t condone stealing patents,  part of point of one is that others are allowed to learn your secrets in exchange for some legal protection. [Arpad]’s motivation in doing this is that the technology is only widely available in the US with our puny 120 VAC 60Hz power. With this knowledge, he’s been able to transfer it to work with European 230 VAC 50Hz.

Continue reading “Reverse Engineering An AC Signal Protocol” →

Diving Deep Into The Game Boy LCD Protocol

November 10, 2010 by 22 Comments

[Craig] wanted to make the original Game Boy LCD screen do his bidding so he sniffed out the data protocol that it uses. We were amused when he mentions that there’s an army of people out there looking to build pointless crap as part of a hobby. Guilty. And he goes on to outline why this LCD screen is a great resource for hobbiests.

As you can see in the pinout above, it uses 5V logic, with a 4 MHz data clock. These traits are both very friendly to a wide range if inexpensive microcontrollers. If you know how to address the display it should be very easy to use. Furthermore, the low pin count is thanks the to a 4-shade grayscale screen, limiting the data pins to just two. [Craig] hooked up his Saleae Logic probe to capture communications and walks us through what he discovered. During this process he proved to himself that he had figured out the protocol by exporting captured data from the logic probe and reassembling it into an image on his computer.

IPv6 To 1-wire Protocol Translator

December 2, 2009 by 16 Comments

[Fli] assembled an AVR based system that can assign IPv6 addresses to 1-wire components. An AVR ATmega644 microcontroller is used in conjunction with an ENC28J60 ethernet controller chip. To get up and running with IPv6 on this meek hardware [Fli] ported the uIPv6 stack from the contiki project over to the AVR framework. Although he encountered some hardware snafus along the way, in the end he managed to get five sensors connected to the device, each with their own IP assigned using the stack’s alias capability.

This is great if you’re looking for a low-cost IPv6 solution. We’re not sure if there’s much demand for that, but it’s useful for that 1-wire home automation setup you’re considering.

IPhone 3.0 Adds Custom Protocol Support For Addons

March 17, 2009 by 26 Comments

iphone301

In middle of all the adding features that should have been available day-one, Apple announced something really interesting for the hardware hacking community. The new iPhone 3.0 OS will support application communication over bluetooth or through the dock connector using standard or custom protocols. From Engadget’s coverage:

10:19AM “They talk over the dock, and wirelessly over Bluetooth. Things like playing and pausing music, getting artwork — or you can build your own custom protocols.”
10:19AM “Now here’s a class that we think will be really interesting — medical devices.” Scott’s showing off a blood pressure reader that interfaces with the iPhone — wild.
10:18AM “Here’s an example — an FM transmitter. With 3.0, the dev can build a custom app that pairs up with it, and automatically finds the right station and tunes it in.”
10:18AM “With 3.0, we’re going to enable accessory developers to build custom apps that talk directly to that hardware.”

No solid connection specification has been published yet. We’re excited about the prospect of developing our own accessory hardware, but we wonder what sort of hoops you’ll have to jump through. Apple doesn’t have the best track record when it comes to approvals. Just this week they denied MSA Remote client App Store entry; it’s a multitouch client that uses the standard TUIO protocol. Prepare for similar roadblocks in the future.

[via adafruit]

Manual Protocol Analysis

January 24, 2009 by 2 Comments

packetfu

As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.