Monday 30 January 2012

Playing with LEDs

I decided to take a break from the work on my wireless sensor network to play around with some components from my ARDX starter kit which I hadn't used yet.

This was all pretty straightforward. I used the following tutorials.
The circuit I ended up with looked like this.


From the left, this has a dimmer switch, two regular LEDs, a light sensor, a push button and on the far right is an RGB LED which oomlout includes for free with orders.

In the end I disabled the regular LEDs and the light sensor and just controlled the RGB LED. In my first configuration I used the button to cycle between the R/G/B LED and the potentiometer to change the brightness of the selected color. This was nice but fiddly so I changed the code to only use the button to start/stop a programmed sequence of colors. The colors are generated by ramping the R/G/B LEDs from 0 up to 255 and back down to 0 again. Each color uses a different increment so that the overall color shifts smoothly through all of the colors which are possible.

The results turn out to be very hard to film because my iPhone does a good job of adjusting the color balance to cancel out the changing LED. However, here are a couple of attempts.

 


As ever, my source code is available here.

Sunday 29 January 2012

Wireless sensor node - turning off subsystems (5)

In my last post I spoke about the watchdog timer which can be used to enter a deep sleep on the ATtiny85. This time I want to take a quick look at the other power saving options available on the ATtiny85.

The ATtiny has several subsystems which can be separately turned on and off. The datasheet describes all of these systems but we just want to find out how to turn them off! Thankfully, you can skip straight to looking at power.h. This header exposes some methods which make power management more straightforward. From this header file you can quickly find all the subsystems on the ATTiny85 which can be switched off. 
  • power_adc_disable()
  • power_timer0_disable()
  • power_timer1_disable()  
  • power_usi_disable() 
In practice, I can't actually switch all of these off in my project.
  • Timer1 - used by Manchester lib. The datasheet says that timer1 is always stopped while we are asleep
  • ADC - used to read analog value from sensor. ATTINYWATCHDOG already explicitly turns off the ADC when we sleep. 
The ATtiny datasheet has a section on power saving. This recommends that when not in use, pins should be set to input mode so that they are not driving anything. 

The wiring of my project currently connects the VCC of my TX module to the battery VCC line. However, I can improve power use by connecting TX VCC to a pin on the ATtiny. This allows me to power down the TX while the ATtiny sleeps. 

There is one change which I should make which will actually consume more power. I am planning to run an ATtiny from battery power for long periods of time. At some point the battery will start to run out and the battery voltage will drop. The ATtiny can operate over a fairly wide range of voltages. However, but the voltage drops too low the ATtiny can actually be damaged. To avoid this happening, we can enable a Brown Out Detection (BOD) circuit. This is enabled by setting a fuse on the ATtiny. 

The details about how to set the fuse are listed on this page. I used the command line approach which involved the following steps.
  1. Open a command line in: \path\to\arduino-0022\hardware\tools\avr
  2. Run the following command to read the current fuses

    avrdude -C "\path\to\arduino-0022\hardware\tools\avr\etc\avrdude.conf" -p ATtiny85 -c stk500v1 -b 19200 -p COM3 -v


    Note that the stk500v1 works fine when using the Arduino as an ISP. Also note that the fuse values get output twice. For example:

    avrdude: Device signature = 0x1e930b
    avrdude: safemode: lfuse reads as E2
    avrdude: safemode: hfuse reads as DD
    avrdude: safemode: efuse reads as FF

    avrdude: safemode: lfuse reads as E2
    avrdude: safemode: hfuse reads as DD
    avrdude: safemode: efuse reads as FF
    avrdude: safemode: Fuses OK

  3. Use this site to work out your new fuse values. Select "ATtiny85", the default features value is correct. The "current settings" section will likely show fuse values matching what you read from your chip.
  4. To enable BOD, select your desired level, in my case "Brown-out detection level at VCC=2.7 V; [BODLEVEL=101]". Click "Apply feature settings". The updated fuse settings are shown in the "Current settings" section. In my case, the default of DF changed to DD. In binary this means 0b11011111 changes to 0b11011101.
  5. To apply this change, run the following command:

    avrdude -C "\path\to\arduino-0022\hardware\tools\avr\etc\avrdude.conf" -p ATtiny85 -c stk500v1 -b 19200 -p COM3 -U hfuse:w:0xDD:m


    The output of this command should include the following lines:

    avrdude: 1 bytes of hfuse written
    avrdude: 1 bytes of hfuse verified
    avrdude: safemode: Fuses OK
    avrdude done.  Thank you.

The results after making all of these changes are as follows. 
  • Sleep current - 0.025mA (up from 0.006mA). This makes it clear how much current the Brown Out Detection support requires.
  • Wake current - 7.8mA (down from 8.5mA). This is a rough figure - the reading on the multimeter jumps around as the RF TX happens and the ATtiny sleeps between transmits. 7.8mA is about the highest reading I saw so I am going to use that for now.
Finally, there is one mode thing which I could do in software to improve power usage. This would be to rewrite my code to be interrupt driven. This would allow the ATtiny to spend more time asleep. However, the resulting code would be more complex and I don't need the extra power savings at the moment.

Friday 27 January 2012

Wireless sensor node - code management

I have moved the Manchester library into its own GitHub repository. Full instructions for using the library can be found on that page.

This new repository now includes Mike's latest changes to allow a variable number of bytes to be transmitted.

Monday 23 January 2012

Wireless sensor node - sleeping (4)

Now that I have RF comms working I can start to consider the other aspects of building wireless sensor nodes. 

The next item on my todo list is to improve the battery life of my wireless sensors. Note: The content of this article was heavily based on the following blog posts:
The first step in this process is to understand the expected battery life before I make any optimisations. The amount of energy stored in batteries is normally measured in milliamp hours (mAh). Therefore, to work out battery life we just need to measure the current used by the circuit. Current is measured by placing a multimeter (e.g. this one) in series with the circuit. This is how I do this on my circuit. 



Using this setup I can see that my circuit uses about 8.5mA (Note: the first picture actually shows a lower current as I took it at the end of this article). To work out the battery life from this number you just divide the available mAh by this reading. Note that using multiple batteries only increases the voltage, it does not increase the mAh and if each battery is different, the overall mAh available is the lowest value. 

My 3 AA batteries are all 1700mAh and I measured a current of 8.5mA. This gives a battery life of 1700/8.5 = 200 hours ~ 8 days. Not bad but not ideal - I don't want a new weekly chore of changing batteries! Especially if I deploy 5+ of these nodes!

Thankfully there is a straightforward code change we can make to dramatically reduce our current usage. The key point is that I don't plan to take readings constantly. I expect I will configure each wireless sensor to take readings no more often than once every 5 minutes. The rest of the time, the code will just sit in a delay() call. However, during this period of inactivity we can actually take advantage of a feature of the ATtiny85 to use much less power. 

The ATtiny85 supports being put into a sleep mode. In this mode, the power usage is MUCH lower and no code is executed. We can configure this sleep to end when either an input pin changes or when a fixed amount of time has passed. The second of these is what I will use. The timeout which wakes us is called the watchdog timer. Full details about the ATtiny including how to use the watchdog timer can be seen in the datasheet.

Without further ado, here is the code which I have added to make use of the watchdog timer. This comes in several parts.

1) Includes and defines:

#include <avr/sleep.h>
#include <avr/wdt.h>

#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

2) Prep work. Note that I have excluded a lengthy comment from this quote which is itself a cutdown extract from the datasheet. The interested reader should refer to the ATTiny85 datasheet as the proper reference for what this code is doing. 

// Watchdog timeout values
// 0=16ms, 1=32ms, 2=64ms, 3=128ms, 4=250ms, 5=500ms
// 6=1sec, 7=2sec, 8=4sec, 9=8sec
void setup_watchdog(int ii)

 // The prescale value is held in bits 5,2,1,0
 // This block moves ii itno these bits
 byte bb;
 if (ii > 9 ) ii=9;
 bb=ii & 7;
 if (ii > 7) bb|= (1<<5);
 bb|= (1<<WDCE);
 
 // Reset the watchdog reset flag
 MCUSR &= ~(1<<WDRF);
 // Start timed sequence
 WDTCR |= (1<<WDCE) | (1<<WDE);
 // Set new watchdog timeout value
 WDTCR = bb;
 // Enable interrupts instead of reset
 WDTCR |= _BV(WDIE);
}

void setup()
{  
  ...
  setup_watchdog(8);
}

3) Support methods:

void system_sleep()
{
 cbi(ADCSRA,ADEN); // Switch Analog to Digital converter OFF
 set_sleep_mode(SLEEP_MODE_PWR_DOWN); // Set sleep mode
 sleep_mode(); // System sleeps here
 sbi(ADCSRA,ADEN);  // Switch Analog to Digital converter ON
}

// wait for totalTime ms
// the wait interval is to the nearest 4 seconds
void deepsleep(int waitTime)
{
  // Calculate the delay time
  int waitCounter = 0;
  while (waitCounter != waitTime)
  {
    system_sleep();
    waitCounter++;
  }
}

4) Actually going to sleep - note that deepsleep replaced delay. 

void loop()
{
  Tdata +=1;
  sendMsg(Tdata);
  // deep sleep for 2 * 4 seconds = 8 seconds
  deepsleep(2);
}

The result of all this is that the ATtiny spends most of its time asleep. Using a multimeter I measured the sleep current of my circuit to be 0.006mA. This can be used to calculate the overall battery life by entering the following figures into this website:
  • Battery capacity: 1700mAh
  • Sleep current consumption: 0.006mA
  • Wake current consumption: 8.5mA
  • Duration of wakeup: 2000ms
  • Number of wakeups per hour: 12 (once every 5 minutes)
The result: 2.6 years! Much better! 120x better than the previous battery life which I calculated.

As ever, the full source code is available here.

Sunday 22 January 2012

Wireless sensor node - code fixes (3 - redux)

In my last post I realised a few things which needed to be fixed. These are now done!
  • My RX code no longer checks the range of the node ID and msg number which by definition were always in range.
  • The Manchester RX code now checks for low/high frequency interference during the data reception.
  • I have fixed a bug in the Manchester RX code which didn't properly check the timings of the pre-amble.
These changes can be seen here.

Wireless sensor node - manchester lib (3)

Last night I spent several hours trying to improve the RF comms which I am using.

MANCHESTER encoding

The first step was to add indenting and more details comments to MANCHESTER.cpp. I am quite pleased that I spent the time doing this as I now understand how the library works. I will try and describe what I have learnt here for my future reference.

RF comms can be tricky due to a combination of interference and trying to ensure that the TX and RX don't drift out of sync. For example consider a TX which wants to send the number 0 as a 16 bit number. In a naive scheme this would involve TXing 0 for the duration of 16 bits. However, if the receiver is running a bit too fast or slow they could easily read this as 15x 0 or 17x 0. The naive approach is also vulnerable to low frequency interference. The RX could detect bit transitions that were too fast and assume this was interference but there is no limit to how far apart bit transitions can be so low frequency interference will not be detected.

Manchester encoding addresses this by sending each bit as a transition. Zero is HI to LO. One is LO to HI. This means that the midpoint of every sent bit will always contain a transition. The edges of a bit will only contain a transition if the previous bit was the same. For example
  • 00 - (HI,LO)(HI,LO)
  • 01 - (HI,LO)(LO,HI)
To correctly receive these bits the RX must get in sync with the TX. This ensures that HI,LO,HI,LO is correctly interpreted as 00 instead of the RX missing the initial HI, reading a 1 and then discarding the final LO.

The MANCHESTER library which I am using sends messages as follows.

TX sends
  • 14x 0 followed by 1x1 - this is the sync pattern
  • 16x data bits
  • 2x 0 - I'm not sure why these are sent at the end
RX listens for
  • 10x 0 followed by 1x 1
  • 16x data bits
The RX listens for a shorter sync sequence because the first few bits are likely to be corrupted. The RX chip uses an amplifier to receive faint signals. This means that when there is no signal the RX will amplify background RF noise until it detects some ones and zeros. When the TX starts sending a message the RX chip needs a few transitions to adjust its amplifier to the correct level.

The reformatted and better commented MANCHESTER code is available here.

Reliable transmission

The Manchester library is really good and over short distances the RF link is good enough that the transmission is very reliably. However, when I have tested moving the TX into another room at the other end of my house I have found the link gets much more lossy and sometimes messages come through corrupted.

I don't think there is much more that could be done at the MANCHESTER level. As I wrote this I realised that the sync sequence explicitly checks for high/low frequency interference. However, the data receiving code doesn't do this checking so a clean sync followed by interference will lead to corrupted data. I will need to take a look at improving this.

I decided to add an extra layer of functionality on top of the MANCHESTER library. This extra layer would do the following.
  • Send each message 3 times with a random delay between each retransmission.
  • Add a message level pre-amble, node ID, message ID and checksum to each transmission.
The detailed message format is best described by the code I wrote to send it.

// Send a message with the following format
  // 6 bits pre-amble
  // 5 bit node ID
  // 5 bit reading number
  // 16 bit data
  // 16 bit data (repeated)
  //
  // This is a total of 3x unsigned ints
  unsigned int preamble = (0b010101 << 10);
  unsigned int nodeID = ((NODE_ID & 0b11111) << 5);
  unsigned int firstByte = preamble | nodeID | (msgNum & 0b11111);
  
  MANCHESTER.Transmit(firstByte);
  MANCHESTER.Transmit(data);
  MANCHESTER.Transmit(data);

Since I only have a single unsigned int of data, sending the data twice is essentially an XOR checksum. I previously XOR'd the data byte with the firstByte but this caused problems because for any data values with the top 6 bits set to 0, the checksum ended up starting with the 6 bit pre-emable which confused the RX code.

The RX code stores an array of node ID to message Nums. This allows it to ignore retransmissions. The RX code also checks for the pre-emable, checks the checksum, checks the nodeID and readingNum are within the expected range. As I write this I have realised that these last two checks are silly because these numbers are constrained to 5 bits each so actually HAVE to be in the correct expected range.

The full code for my TX and RX code can be seen here:
Pictures

Every blog post should have pictures. I will conclude this post by pointing out a mistake I made when wiring my circuit up again last night.



This is the small breadboard I use for my TX circuit. I had real issues getting my TX to work last night. I eventually realised that the broken red line along the bottom means that the left half and right half of the power line are disconnected. I initially had my battery plugged in on the left.where it was powering nothing. Moving it to the right got everything working!

Saturday 21 January 2012

A couple of interesting links

Here are a couple of excellent websites which post a LOT of content about Arduino/ATtiny related topics.

http://jeelabs.org/
This is a blog run by someone who has invented their own platform similar to Arduino but called a JeeNode. The main difference is that a JeeNode includes an RF link. This is actually pretty cool as a complete JeeNode is only EUR18.50!

http://hackaday.com/category/attiny-hacks/
This site is frequently updated with interesting hacks which people have built around ATtinys.

Thursday 19 January 2012

Wireless sensor node - rf link working (2)

Good news! I have managed to get my RF link working! (Part 1 of this series)

Here are the pictures:

1) The RF base station receiver.


2) The RF transmitter - powered by 3x AA batteries.


OK, so what did it take to get this working?

0) You may wish to read my previous post about getting started with ATtiny85.

1) Two versions of the Arduino IDE.
  • Arduino 0022 - I use this for programming the Arduino and ATTiny
  • Arduino 1.0 - I use this to set the clock on the ATTiny
2)  The config files to add support for ATTiny. I used a combination of 3 distributions.
  • damellis-attiny-6bff522.zip - This adds support for ATTiny85 to Arduino 1.0.
  • attiny45_85.zip - This adds support for ATTiny85 to Arduino 0022.
  • manchester.zip - This contains the RF link library along with some modified attiny45_85 files which need to be extracted and used to overwrite the files from attiny45_85.zip. This file is from this thread.
NOTE: Combining the last two of these is a bit awkward so I have combined them into a new zip file which I have hosted here. The contents of manchester.zip\manchester\hardware should be unzipped into your <sketchbook-location>\hardware folder.

EDIT (29/01/2012) - The latest files are now available here.

However, you will still need to get the damellis file to get Arduino 1.0 support.

3) Use Arduino 0022 to program your Arduino as an ISP using the ArduinoISP example.

4) In Arduino 1.0 select the correct ATTiny board and programmer.

Tools -> Board -> ATtiny 85 (internal 8Mhz clock)
Tools -> Programmer -> Arduino as ISP

Set the clock speed by choosing Tools -> Burn Bootloader.

5) Use Arduino 0022 to program your ATTiny. Remember to choose the correct board.

Tools -> Board -> ATtiny85 (/w Arduino as ISP)

Here is the ATtiny85 project which I programmed my ATtiny with: https://github.com/mchr3k/arduino/tree/master/wsn_attiny

The only interesting point with the main .pde file is that the #include of the MANCHESTER.h file uses "" instead of <> (#include "MANCHESTER.h"). I had to change this from the example included with the manchester.zip file.

6) Use Arduino 0022 to program your Arduino. Remember to choose the correct board, "Arduino Uno" in my case.
____

Wiring up the actual circuits was straightforward.

The result of all of this was an ATtiny85 which was able to send a count back to the base station over the RF link. I carried the transmitter around the house and the link mostly worked great. Some numbers came through wrong but the vast majority came through fine and the link recovered after each transmission error.

Next steps? I think it's time to write some code to add error detection and possibly correction to the link.

Wireless sensor node - all on one breadboard (1)

Just a quick post to record the fact that I have now started to build my first wireless sensor node. The attached pics show the wired up circuit with space on the breadboard for 3 distinct circuits:

- Arduino ISP
- ATTiny wireless TX
- Arduino wireless RX

After a lot of fiddling I finally got my Manchester encoding library to build. Sadly when I tried to test my circuit I was only receiving a stream of zeros instead of the expected stream of digits counting up. Debugging that is the next step!

I will of course share the details once I get something working.

Wednesday 18 January 2012

DIY Drones

In my previous post I wrote about my Parrot AR Drone. However, in the course of writing that post I came across an awesome site.



This site is dedicated to people building their own UAVs. This is not a cheap hobby but the results look really awesome! I really enjoyed the video on the following page which explains why it is so important to start with a low cost UAV.

9 Reasons why you should start with a cheap foamie

If I had ~£1000 to burn I would love to buy a pre-build UAV from this site.

Tuesday 17 January 2012

Parrot AR Drone - Ideas

For Christmas I got a Parrot AR Drone - a remote control quadrocoptor.

The AR Drone produces its own wifi network which the iPhone connects to. This connection allows remote control along with live video from both an onboard front facing camera and a downward facing camera.

Its a great toy - I've been having fun flying it! However, the obvious question is what kind of modding is possible.

Background
Firstly, some interesting sites
RC Hack
The remote control range on the Parrot is fairly limited  (~50M) since the connection is over wifi. One of the more practical hacks which I have read about is to add RF control to extend the range to 500M+.

The RF hack is described in detail on these pages
The real limit with this mod is the cost - £150+ depending on the RC transmitter/receiver which you choose. This is a bit out of my range for now.

Infrared Hack
The Parrot Drone does a good job of auto stabilisation. The 60fps downward facing camera is used for stabilization to allow the drone to hover without drifting. However, when it is dark this can't see clearly and the control interface shows a low light warning.

It should be possible to improve this situation by fitting an IR LED or even a visible light LED to the bottom of the parrot. This would allow for stable flight in the dark. I will definitely be trying this out at some point!

Sunday 15 January 2012

Home Wireless Sensor Network - Battery Life

In my last post I mentioned building some battery powered wireless sensors. There are several choices to make about what kind of batteries to use.
  • Rechargeable or non-rechargeable.
  • CR2032 (~220mAh) or 3xAA (800 - 3000+mAh depending on price).
  • Battery brand - there are so many, argh!

It seems likely that for battery life reasons I will go with the 3xAA approach. What kind of battery life will this give me? This requires that I work out the current use of my planned circuit. Time to consult some datasheets!

If all of these components were active I would need 8.35mA. Lets round that up to 9mA. Lets also assume that I use a 2500mAh battery. This gives the following battery life.

  • 2500 / 9 / 24 = 11.5 days

I don't want to change batteries every 11 days - I can do better by putting the components to sleep when they aren't being used.

Let's assume that I only wake up the circuit to transmit a reading every 5 minutes and that the wakeup lasts for 30 seconds - I will need to transmit the reading 3 times to try and ensure that it gets through. This means every 60 minutes the circuit is at full current 12 times for a total of 6 minutes. The remaining 54 minutes the power usage will be as follows.

  • ATTiny85 - 0.0001mA (sleep mode)
  • TMP36 - 0mA - assume I can disconnect from PWR e.g. with a transistor
  • RF Transmitter - 0mA - assume I can disconnect from PWR e.g. with a transistor

This gives an idle power usage of 0.0001mA. The overall mA/hour requirement is as follows.

  • (54/60) * 0.0001 + (6/60) * 8.35 = 0.84mA
  • 2500 / 0.84 / 24 / 7 = 17 weeks = 4+ months

Much better!

Home Wireless Sensor Network - Making Plans

My current main project is to build a wireless sensor network. However, for various reasons I am currently blocked from doing any real work on this project - so I thought I would blog about my plans instead!

The goal of this project is to be able to take readings from wireless nodes placed around my house (and possibly in my garden). This provides the following requirements.
  • I want to build 5-10 of these sensor nodes so they need to be very cheap.
  • I need to be able to place them wherever is best for measurements without regard for plug sockets so they need to be battery powered.
  • I don't want to be replacing 5-10 batteries a week so they need to be very low power so that they can run for a few months between each battery change.
  • Each node should be able to collect multiple readings although initially they will all only collect temperature.

To meet these requirements I plan to combine the following into a single wireless sensor node.

  • ATTiny85 (~£1.50) microcontroller
  • TMP36 (£1.50) temperature sensor
  • RF Link Transmitter (~£1.50)
  • Tripad stripboard (£4/sheet, need ~1/4 of a sheet, hopefully less)
  • Battery holder (£1)
  • Batteries (~£4)

This comes to a grand total of about £11 for a single wireless node. This seems to be about as cheap as you can get it.

The rest of the setup will be made of the following parts.
  • An Arduino base station receives the readings from all of the wireless sensor nodes and writes them to SD card.
  • A Raspberry Pi connects to the Arduino over Bluetooth and downloads the stored readings. The Raspberry Pi connects to the internet over Wifi and uploads the readings to Pachube.

Here's a picture of a Raspberry Pi because every blog post should have a picture.

I also have plans to build a physical display to show the latest readings.

Wednesday 11 January 2012

Time Lapse - Pigs 2

Today I setup my camera + servo to take time lapse photos of a couple of my guinea pigs. This was an interesting test as in my last post I made a time lapse video using my iPhone.

Here is what the setup looks like:



And here are the results:



It's interesting to note how low quality the result is. This digital camera is 4+ years old and doesn't deal well with the low artificial light in my kitchen. I will try again another day during daylight. It's also a pity that the camera doesn't have a wide angle lens.

Time Lapse - Pigs

Following on from my last post I did some research into what programs I could use to stitch together time lapse photos into a video. I ended up finding some details about iPhone apps which make time lapse videos. I should have known there would be an app for that...

Making a time lapse video with my iPhone is both good and bad. Good because the iPhone camera is pretty good (I have a 4S) and bad because I don't really want to leave my iPhone in one place for extended periods of time.

Anyway, to test the app I left my phone taking pictures of two of our guinea pigs. The app took a picture once a second while I nipped out to Tesco. When I got back I stitched the pictures together at 15fps to produce the following video.

Time Lapse Camera

I still don't have my RF link modules. I therefore decided to see if I could build a timelapse camera. I have an old Sony DSC S90 which I was happy to play with.

Sadly the Sony doesn't have any interfaces for electronically triggering the shutter. This meant I had to resort to taping a servo to the camera to press the shutter button. This is what the results look like.



I have only tested this with the batteries out of the camera so far so I don't have a results video yet. I will hopefully make one in the next few days.

The code which drives my servo is available here.

Tuesday 10 January 2012

History - Getting Started With ATTiny85

Background

An Arduino Pro Mini costs ~£15. A Bluetooth module costs ~£27. This sounds fairly cheap until you consider deploying 5-10 wireless sensor nodes. If these were all Bluetooth Arduino modules this would cost at least £42/module!

There has to be a cheaper way! Thankfully there is!

An ATTiny85 costs less than £2/unit (so long as you buy at least 10). This is much less powerful than an Arduino but is much more suitable to simple low power wireless sensors.

In place of a Bluetooth connection I plan to use a simple RF Link using one way RX and TX modules. The transmitter costs less than £2.

Plan

To produce a wireless sensor will actually require a few more components:
  • Some Stripboard
  • 8 pin DIL socket
  • battery holder (either watch battery or multiple AA)
  • battery(s)
I am hoping that including all these items I can produce a wireless sensor for <£15/node including battery(s).

Getting Started

An ATTiny can be programmed from the Arduino UI. To make this work requires a few steps. I followed these steps.

1) Program the Arduino to act as a programmer for the ATTiny. The correct sketch can be loaded by selecting File -> Example -> Arduino ISP.

NOTE: The example included in Arduino 1.0 didn't work for me. I used the copy from Arduino 0.22 instead and this worked great.

2) Download ATTiny support. This needs to be unzipped into your project folder in the following structure.

\hardware\attiny

3) Select the correct Board and Programmer.

Tools -> Board -> ATTiny 85 (internal 1Mhz clock)
Tools -> Programmer -> Arduino as ISP

4) Wire up the ATTiny as per this diagram.


EDIT: The linked page was down the other day so here are the crucial diagrams. Firstly, the pin layout.
And here is the wiring.

Pin connections:
  • ATtiny Pin 2 to Arduino Pin 13 (or SCK of another programmer)
  • ATtiny Pin 1 to Arduino Pin 12 (or MISO of another programmer)
  • ATtiny Pin 0 to Arduino Pin 11 (or MOSI of another programmer)
  • ATtiny Reset Pin to Arduino Pin 10 (or RESET of another programmer) 
This is what the final result looks like,
    You're ready! To test whether the programming is working you should load the Blink example, replace pin 13 with pin 0 and download it to the ATTiny.



    History - Windows Temp Download UI

    To make the best use of my Bluetooth temperature sensor I decided to write a Windows application to automate the download and graphing of the temperature data. I used the following tools to do this.

    The first page lets you pick a port, or to skip this step if you just want to reload some old data.

    If you select a port, the program handles connecting including any retries.

    Once connected, the data is downloaded and graphed. The actual data isn't timestamped so the fetched data is assumed to be readings stretching backwards in time from now.

    The full code is available here.

    History - Bluetooth temp sensor - Redux

    In my last post I described my Bluetooth temperature sensor. In the project I connected my Bluetooth module to pins 2/3 on the Arduino and used SoftwareSerial to communicate over the Bluetooth connection.

    I did this so that I could still use the normal Serial connection in parallel. In fact I spent some time trying to write a library that would output data to both a Serial and SoftwareSerial connection. In the end this turned out to not work for reasons that I never got to the bottom of. The only solution I couldLink come up with was to use a #define to allow me to quickly switch between a Serial and softwareSerial connection. Worse, the softwareSerial connection only worked when I reduced the baud rate to 9600.

    This is a crap solution. Why not just connect the Bluesmirf module to pins 0/1 and get the hardware Serial support to do it magic. So I've tried this and it works!

    Interestingly, with the Bluetooth module connected to pins 0/1 I can cannot to the module and send/receive data to the Arduino. However, I can't connect over the USB Serial port unless I disconnect the Bluetooth module. I don't even need to restart the Arduino!

    The result of all this fiddling is that I can now connect at 115200 instead of 9600! Thats a 12 times speed up!

    History - Bluetooth temp sensor

    I really liked the idea of deploying some sensors around my home to record data. I started by skipping ahead in my ARDX kit and completing the temperature sensor example.

    With this complete, I modified the example to log multiple readings at a fixed rate and store the values into an array in memory.

    As an aside, the Bluetooth module which I used has a great interface. There are 4 pins. 2 pins plug into PWR/GND. The other two pins act as Serial RX/TX pins. Normally you would plug the Bluetooth module into pins 0/1 which are part of the Arduino's hardware serial support. Instead, I decided to use pins 2/3 on the Arduino. This is possible thanks to the SoftwareSerial library.

    With the Bluetooth module connected, I added code to regularly check for an incoming message and respond with a dump of the saved readings. This is what the completed circuit looks like.



    The complete code for my Bluetooth temp sensor is available here.

    History - Intro

    This blog is going to act as my work log as I get to grips with Arduino and the various electronics projects which I am working on.

    This post and the next few which are titled History give the details of what I have done between getting my Arduino and when I started this blog.

    In November 2011 I got an ARDX starter kit from my wonderful wife. I quickly started by building the first two LED control projects:

    At the same time I also got a Bluesmirf Silver Bluetooth module. This is a through hole component so I needed to solder some wires to it to enable me to plug it into my breadboard.

    The results can be seen here - this is the top.



    This is the view from the bottom including my half-decent soldering.



    With this soldered up, and my PC equipped with Bluetooth, I was able to get started with my first project.