Since my RF receivers require a full hardware-based UART to function reliably, I decided to opt for adding a simple attiny2313 as a controller connected to an Arduino. Ready to build a simple protocol, I decided to do a little more research into I2C — the inter-integrated-circuit protocol which puts multiple digital micro-controllers on a low-speed bus. As it turns out, the attiny controllers actually implement the full protocol, even if Atmel calls it TWI (two-wire-interface). The protocol defines a master device as well as up to 127 slave devices (7-bit addressing).
The hardware is very easy to hook up and it simply requires two wires (TWI is not just a clever name) – one called SDA, to transmit the data, and one called SCL, to transmit a clock signal. On an Arduino Duemilanove SDA is analog pin 4 and SCL is analog pin 5. On the attiny2313 controller, SDA is pin B5 (pin 17, also MOSI), and SCL is on pin B7 (pin 19) — also refer to Alex’s cheat sheet for the pins. Just connect SDA to SDA and SCL to SCL.
Arduinos have the Wirelibrary built straight into them, and after some hunting I found a small library for atttiny adapted from the original Atmel code by a Donald Blake (can be found on avrfreaks.net or my subversion repository). The Arduino is quickly configured as a master and set up to send and receive characters typed into the serial console to and from the slave controller:
// Arduino Codevoid
setup() {
Serial.begin(57600);
// initialize as i2c master
Wire.begin();
Serial.println("OK>");
}
// loop forever..void loop()
{
// data available from computer?if (Serial.available()) {
// read the incoming byte from the serial port
sByte = Serial.read();
// begin transmission to device 1
Wire.beginTransmission(1);
// send
Wire.send(sByte);
// done
Wire.endTransmission();
// request data from device 1
Wire.requestFrom(1,1);
// echo out whatever we get backwhile(Wire.available()) {
Serial.print(Wire.receive());
Serial.print("-");
}
}
delay(100);
}
On the slave, simply link the Donald Blake’s library into the code and this then does all the magic:
// attiny2313 codeint main(void)
{
// initialize as slave with id 1
usiTwiSlaveInit(1);
// enable interrupts (must be there, i2c needs them!)
sei();
// handle commandswhile (1)
{
// check if data is in the i2c receive bufferif(usiTwiDataInReceiveBuffer())
{
// get it
uint8_t b = usiTwiReceiveByte();
// echo it back
usiTwiTransmitByte(b);
}
// Do something else while waiting for the TWI transceiver to complete.
asm volatile ("NOP" ::);
}
return 0;
}
In the implementation of the “reverse” channel of my home automation system, the RF receiver will transmit radio data back to the master controller which in return sends it to the computer. Since the atmega168/328′s processors used in the standard Arduino only have one hardware-based serial port (UART), I tried for the software-based serial that ships with the Arduino IDEs. Transmitting data out works like a charm (as seen previously), but receiving it is quite a challenge, mostly due to timing problems. The software serial port doesn’t work unless all the sketch does is gather data — there’s no time for processing or it will start losing data.
My next attempt was to use an interrupt-based version of the software serial port. I briefly thought about writing one, but then I found this great libary, the New SoftSerial. It is as simple to use as the original library, but unfortunately once I connect the RF receiver, the processor is too busy handling interrupts and nothing really works. The noise picked up by the RF module must simply overwhelm it. That’s too bad, this works beautifully on my attiny2313-based receiver when using the hardware UART.
A software-based solution is clearly not the answer, some hardware is required. I can think of a few options
Abandon the Arduino altogether and use an AVR controller with multiple UARTs — not ideal, I like the idea of basing the master on Arduino for the hackability factor
Use a logic gate and an external clock generator to sample/filter the signal exactly at the right timing required for 1200 bps (the maximum reliable speed I could get to work for the RF modules) – this could still lead to timing issues
Create an attiny2313-based “daughter-board” which handles all the nitty gritty of the RF communication using the hardware-UART and then communicates to the Arduino via a few of the regular digital ports (I’m thinking asynchronously via about 4 pins)
Clearly this requires a little more thinking, but I’m leaning towards the third option — it encapsulates all the protocol logic on the attiny’s and the Arduino library that would need to be written to communicate with it would be very light-weight. And let’s not forget the attiny’s are only about two bucks.
You keep forgetting your keys but would never let your precious iPhone out of sight? Then nothing should seem more obvious than the need to open your garage door with your iPhone. An Arduino and a few microcontrollers, relays, rf link transmitters and receivers and some firmware later, it’s now reality. Check out the prototype (and excuse the slightly shaky video, it was bitter cold outside):
As I’m in the process of building a full home-automation suite so I can finally open my garage door with my iPhone (stay tuned, more on that soon), I wanted to quickly post this since it actually wasn’t really easily found online and I spent a few minutes (ok, more like an hour) fiddling with this before I got it to work.
The code below takes data (you should pass in numeric 8-bit values, i.e. between 0×0 and 0xFF) and then read them out on the Arduino as usual. As a general note, working in dynamically typed language like Ruby is a major pain in the a** when you’re trying to fiddle with every bit and work with an 8-bit microcontroller on the other side of the wire. On a positive note, Ruby has bit manipulation capabilities and it’s just so easy to build webapps with it…
The gist of the code below: Put the data into an array, pack it as unsigned characters, and then pump it into the serial port. The code below requires the ruby-serial gem.
class SerialGateway
def initialize()
puts "Starting serial gateway"
begin
# 9600, 8N1 on USB0
@sp = SerialPort.new"/dev/ttyUSB0", 9600, 8, 1, SerialPort::NONE
# release port on shutdown
at_exit { do_at_exit() }
rescue => e
# sophisticated error handling
puts "Cannot initialize usb device"
end
# only one serial access per time
@send_mutex = Mutex.new
end
#
# Send a command to the master device.
#
def sendCommand(command, targetAddress, data=[])
if(data.length >4)
raise "Sorry, maximum command data length is 4."
end
# first one ASCII R (remote, 0x52)
cmd = [ 0x52, command, targetAddress, data.size()]
# add data array
data.each { |d| cmd << d}
# pack it into unsigned chars
cmd = cmd.pack("C*")
@send_mutex.synchronize do
cmd.each_byte { |c| @sp.putc c }
end
end
end
Oh, and flipping back and forth between Ruby and C is a little weird :-)
The Wall Street Journal has another article on open source hardware and Arduinos up today.
The palm-sized Arduino serves as an electronic brain running everything from high schoolers’ robots to high-end art installations. But perhaps the oddest thing about the device is the business model behind it.
The Wall Street Journal has an article today about tinkering, real hardware, and Arduinos. It’s trying to link it to the financial crisis, more power to them. I started playing with light bulbs and batteries when I was 7 (or was it 8? ;-) and the Arduino is the microcontroller electronics kit I never got in the 80s (right here, I feel old). Has nothing to do with the crisis :-)
I got a pair of these extremely cheap RF Link receiver and transmitter pairs for under $5 each. They operate at 434 MHz and supposedly can transmit at up to 2400bps. I was hoping to be able to build some nifty firmware which allowed these things to flawlessly communicate bidirectionally (well, one at a time), essentially making them into a cheap variant of the XBees. It turns out, these little devices are not quite as stable as I hoped they would be. But there’s still a lot of cool stuff that can be done with them.
The Hardware
434 MHz Transmitter
434 MHz Receiver
They can easily be hooked up to the Arduino data pins. If you want to boost the transmitter’s power, hook the third pin (Vcc) to more than 5V. It can take up to 12V and the more juice you give it the more power it has to transmit, the less dropped data.
The Software
Here is where all the fun started. Hooking it up was easy, using the Arduino software serial library to establish the communication is also a no-brainer. Yet if the receiver finds no signal for 10ms, it automatically turns itself into an auto-sensing mode in which is cranks up the antenna gain and starts just outputting noise. This is not only annoying, but also very counterproductive when trying to get a clean transmission. Also keep in mind that these modules are really bare-bones. They send and receive data. There’s no automatic receipt acknowledgement, no automatic resending of packets, nothing. That’s especially hard considering that these devices only provide a one-way communication path.
The easiest way to go around this is to just have the transmitter continuously transmit data, even if it’s just empty bytes. While I got this to work just fine, I didn’t think this was very practical.
My second attempt created an elaborate packet structure around the data and the receiver software parses the packets that come across the wire and rejects them if it can’t parse them. I also ended up having to prepend the packets with a number of unused initialization bytes just to get the receiver to listen again. And since there’s no way to know whether the package made it, I ended up re-sending them a bunch of times to actually get the receiver to acknowledge. From a software perspective that means you have to make sure the commands you send are idempotent.
With all this error correcting logic and re-sending I can easily transmit across the entire room, probably further than that.
I am getting pretty good results with this, but the main takeaway is really already written into the data sheets. The manufacturer outlines that the main application for these modules are remote controls. For anything more advanced which includes multiple transmitter/receiver endpoints and clean easy data communications, XBees are really the way to go (and they’re only around $20).
Finally having re-submerged from project chaos, I finally have a little time to spend playing with circuits again. While I’m toying with pieces to ultimately automate the entire house, like an RFID-based garage door opener. I figured I might as well post about individual pieces along the way.
The first one is a relay driving circuit. The goal is to simply drive a single relay (for now) from one of the Arduino data pins. Since I want to use the built-in 5V power, I opted for a simple 5V relay. It’s powerful enough to drive 5 amps on 220V, so that should be enough for most applications. I can’t recommend you hooking up 110V or 220V to a breadboard though! Getting circuit boards printed for this will be my next undertaking, but let’s dive into the circuit a little first.
A NPN resistor capable of driving the relay (2n2222 or these do the trick)
A diode such as a 1N4001 or 1N4148 (like this one or this one)
An LED (every circuit needs LEDs!)
A breadboard and some cables
The Circuit
The circuit itself is fairly simple. The signal from the Arduino data pin goes into pin 4 via the resistor R1 to the transistor which switches the relay on and off. Notice R3 which is pulls the data line to ground (reduces unwanted triggering of the Relay while the Arduino is not initialized). The diode is also required as it protects the circuit and ultimately the Arduino from so-called back EMF current.
Fun stuff, but all it really does it go click-click-click. But it is controlled via C-code! I omitted the code here because it’s as simple as 1-2-3. If needed, go to the Arduino site and read about how to make an LED blink.
Stay tuned for a write-up about getting the RF Link transmitter-receiver pairs going and hooked up to this.
Jochen Toppe
-->