A lot of the Arduino and hardware-related posts as of late will start going over onto the new site, freeing this site back up for things relating to (enterprise) software development.

Read More >

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 Wire library 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 Code
void
  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 back
    while(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 code
int main(void)
{
  // initialize as slave with id 1
  usiTwiSlaveInit(1);

  // enable interrupts (must be there, i2c needs them!)
  sei();

  // handle commands
  while (1)
  {
    // check if data is in the i2c receive buffer
    if(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;
}

Works like a charm!

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

1. 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
2. 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
3. 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.

Read more about the setup and software here.

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 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.

Read it here.

See: http://online.wsj.com/article/SB125798004542744219.html

The Hardware

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).

Feel free to grab the source code .

The Entire Thing in Action

Watch the top Arduino’s built-in LED go on and off and the bottom one follow (top – transmitter, bottom – receiver).

RF-Remote Controlled Arduinos from Jochen Toppe on Vimeo.

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.

Part List

• A 5V Relay like the Omron G5SB ($1.95 at Sparkfun)
• 470Ω, 1kΩ, 10kΩ resistors (one each)
• 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.

Result

Arduino LED Driver from Jochen Toppe on Vimeo.

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.