Posts Tagged ‘arduino’

Turning an Arduino into a Tweetject

Thursday, April 24th, 2008

A couple weeks ago I bought an Ethernet shield for my arduino with a plan to get it connecting to the world directly. The stripped down TCP implementation that comes with it is much more geared towards making the board act as a web-server rather than client. This means you have to poll for information rather than have the arduino send it out. Unfortunately, it is this second case that I am most interested in.

Julian Bleecker’s paper “Why Things Matter” introduced the term “blogjects” - objects that blog. A natural extension of which are “tweetjects” - objects that twitter. A good example being Tower Bridge which twitters whenever the bridge opens or closes and announces which ship is passing by. (Roo has written more on this stuff here.)

I see an ethernet-enabled arduino as a perfect platform for building such objects from. But to do this, it needs to establish the outgoing connection itself.

There is another shield that provides a much more powerful option based on the Lantronix XPort ethernet hardware. It even has a demo sketch that will post to twitter. The advantage of this shield is that it provides a serial interface to run the connection - putting much less strain on the arduino. However, this power comes at a cost - the XPort itself is around $50, whereas the Nuelectronics shield is £12.99 already assembled.

So for now, I am persevering with the cheaper board and have been learning far more about TCP packets than I ever thought necessary. So far, I have got my board doing an ARP request to map IP to MAC address, establishing a TCP connection and then sending a single blob of data (naturally, “HELLO WORLD”). This is all a couple layers lower down in the OSI model than I am used to working with in my day job.

It is still a bit too hard-coded to be easily reused and attempts to re-factor what I’ve done has broken it all; so I still have lots to do.

One thing I have discovered whilst playing with this all is Wireshark - a superb tool for sniffing packets on the network and examining their content. This has helped a lot in working out which bits and bytes are going awry in my packets.

DIY and decorating allowing, I hope to make progress on this over the next couple weeks.

Getting the doorbell online

Sunday, April 13th, 2008

Following Andy’s example, I have setup a twitter account for my own house to share its thoughts with the world on.

So far, it is busy twittering the changing temperature of my living room, as measured by the CurrentCost meter. At the moment it only tweets when the temperature changes at least 10 minutes since the previous change. This reduces some of the noise, but I think there is more to do. I don’t necessarily care if the living room is 16°C rather than 17°C but do care if it is too cold or hot. This is a subject I will come back to another time once I have done some more experiementing.

More immediately, I set myself a challenge this weekend; to get the doorbell twittering.

To begin with I bought a cheap wireless doorbell set from Wickes to play with. This came with two receivers; a portable battery-powered one and a mains-powered one. Wasting no time I took one of them apart to find this:

The circuit has a very conveniently packaged daughterboard containing the wireless receiver. The clue was the aerial connecting to it (the white wire to the right) and even better, in the top left corner are the four pins connecting to the rest of the circuit. With my trusty multimeter, and the labels printed on the board, it didn’t take long to work out the leftmost pin is ground, the rightmost pin is +3v and the other two are the magic data pins.

With my newly acquired arduino, itself a topic for another day, I hooked-up the four pins and fairly instantly had the arduino writing over its serial link to my laptop whenever the doorbell button is pushed. Of the two data pins, I found the one labeled “DAT” is the best trigger to use; the other one, “IDEL”, seems to be more noisy and needs investigating.

The doorbell lets you pick from one of 15 channels to ensure you don’t get interference from the neighbours. It also lets you pick one of three chimes to use, from the traditional ding-dong to the full Big Ben. As that setting is on the button itself, it must be sending it over the wireless signal. Currently my circuit triggers regardless of the channel setting of the button. I assume I need to do some more signal analysis on both the DAT and IDEL pins to figure this part out. For now, it works enough to prove the idea.

Here is the sketch I used. It does some simple debouncing by not triggering twice within 3 seconds.

int potPin = 5; // Connected to 'DAT'
int val = 0;

long time = 0;
long debounce = 3000;

void setup() {
  Serial.begin(9600);
}

void loop() {
  val = analogRead(potPin);

  if (val > 0) {
    if (millis()-time > debounce) {
      Serial.print("ON:");
      time = millis();
    }
  }
}

From this point, a bit of python and mqtt magic and the doorbell would be twittering. I say “would” as I haven’t done this final piece of plumbing yet. I only have one arduino at the moment and I am not yet ready to dedicate it to any one task. Clearly I need to order a second arduino - its always good to have separate development and production systems.

Links for 2007-12-27

Friday, December 28th, 2007

Note to self: now these are being auto-blogged, make more of an effort to add useful descriptions!