davebranton

I decided to have a crack at building some drum pads, because the keyboard that I'd acquired for the kids to learn piano on had a midi input, and somewhat acceptable drum sounds to boot. After several months of sitting around half-completed under a cupboard, I decided to pull it out over the easter weekend and actually make it work.
 
In words, here's what I did.
 
Six drum pads, made of a square of hardboard with 5mm closed-cell foam glued to the top and standing on 15mm foam pads. Each pad has a piezo electric transducer underneath, attached using hot glue. These six piezos are each hooked up to a buffer and biasing and clamping circuit, like below. The op-amp I used was an LMC648, which is great for this application but isn't that cheap.
These six analog channels are connected to six of an MSP430's analog inputs. This micro samples these six inputs continuously, and uses a simple filter and threshold algorithm to determine when they've been hit. Once it detects a hit, it outputs the pad ID (zero to five) and the 'velocity' of the hit over I2C to another MSP430. This second micro in turn outputs the MIDI command, through a completely un-necassary additional chip to drive the MIDI output completely to spec. I know it's possible to output midi using 3.3v, but I used a driver chip anyway to run it at 5v - a TC4428 FET driver that I happened to have left over from another project. The second micro also translated the pad ID to a MIDI note, and can be reprogrammed via a couple of buttons that are used to change the drum sound that's assigned to the most recently hit pad. The assignments are stored in the MSP430's "information memory" segment, so that it remembers how you set it up when you turn it off. I'd originally planned to put a 16x2 LCD on there, but I ended up using that for something else.  
In pictures, here's what it looks like.
 
Overall:

PCB closeup - I would normally have a full eagle schematic and layout for this, even if I'm building it on stripboard, because I just make fewer mistakes that way. In this case though the layout of the six clamping circuits turned out to be much easier if I stood those components up out of the board (look on the right side of the picture) and wired them up over the top, and you can't really do that so easily in Eagle. 

Piezo closeup (under the pads)

 
And finally, in code, here's the two projects.
 
The ADC sampling micro : main.c
The MIDI outputting micro : main.c
 
Probably the most interesting aspect of this for me at least, was that when I was designing the (admittedly still rather crude) algorithm to determine how hard the pad had been hit, I needed to get the ADC samples off the chip so that I could experiment with algorithms offline and tweak their performance. I happen to have one of the rather wonderful saleae USB logic analysers (https://www.saleae.com/logic/), and so if you compile the ADC sampling micro's code with OUTPUT_SAMPLES defined, it will run the I2C at 1Mhz (instead of a much more reasonable 125kHz) and output all the ADC data as it receives it. This is pretty borderline for I2C, but if you keep the track length for the I2C nice and short you should be ok. In my case it's the orange and yellow wires in the PCB photo above - and of course you'll need both micros there because the I2C won't work if nothing's there to ACK.
 
Anyway, doing this I was able to get the samples back into my PC, and using python and pylot etc, plot handy graphs like this:
 

Python file, and two text files recorded from the inputs using I2C and the USB logic analyser : Archive.zip
 
The algorithm just detects when the input rises over some threshold, and while integrates the value before it crosses back over zero again (this is after the ADC samples have had 512 subtracted from them of course, making them signed). This is then considered the 'velocity', and the MIDI micro then divides that down to get a 7-bit velocity value for MIDI. This works 'ok', but very light hits aren't detected, and sometimes hits are quite a bit louder than you'd expect.
 
It's still fun though. 

I decided to have a crack at building some drum pads, because the keyboard that I'd acquired for the kids to learn piano on had a midi input, and somewhat acceptable drum sounds to boot. After several months of sitting around half-completed under a cupboard, I decided to pull it out over the easter weekend and actually make it work.
 
In words, here's what I did.
 
Six drum pads, made of a square of hardboard with 5mm closed-cell foam glued to the top and standing on 15mm foam pads. Each pad has a piezo electric transducer underneath, attached using hot glue. These six piezos are each hooked up to a buffer and biasing and clamping circuit, like below. The op-amp I used was an LMC648, which is great for this application but isn't that cheap.
These six analog channels are connected to six of an MSP430's analog inputs. This micro samples these six inputs continuously, and uses a simple filter and threshold algorithm to determine when they've been hit. Once it detects a hit, it outputs the pad ID (zero to five) and the 'velocity' of the hit over I2C to another MSP430. This second micro in turn outputs the MIDI command, through a completely un-necassary additional chip to drive the MIDI output completely to spec. I know it's possible to output midi using 3.3v, but I used a driver chip anyway to run it at 5v - a TC4428 FET driver that I happened to have left over from another project. The second micro also translated the pad ID to a MIDI note, and can be reprogrammed via a couple of buttons that are used to change the drum sound that's assigned to the most recently hit pad. The assignments are stored in the MSP430's "information memory" segment, so that it remembers how you set it up when you turn it off. I'd originally planned to put a 16x2 LCD on there, but I ended up using that for something else.  
In pictures, here's what it looks like.
 
Overall:

PCB closeup - I would normally have a full eagle schematic and layout for this, even if I'm building it on stripboard, because I just make fewer mistakes that way. In this case though the layout of the six clamping circuits turned out to be much easier if I stood those components up out of the board (look on the right side of the picture) and wired them up over the top, and you can't really do that so easily in Eagle. 

Piezo closeup (under the pads)

 
And finally, in code, here's the two projects.
 
The ADC sampling micro : main.c
The MIDI outputting micro : main.c
 
Probably the most interesting aspect of this for me at least, was that when I was designing the (admittedly still rather crude) algorithm to determine how hard the pad had been hit, I needed to get the ADC samples off the chip so that I could experiment with algorithms offline and tweak their performance. I happen to have one of the rather wonderful saleae USB logic analysers (https://www.saleae.com/logic/), and so if you compile the ADC sampling micro's code with OUTPUT_SAMPLES defined, it will run the I2C at 1Mhz (instead of a much more reasonable 125kHz) and output all the ADC data as it receives it. This is pretty borderline for I2C, but if you keep the track length for the I2C nice and short you should be ok. In my case it's the orange and yellow wires in the PCB photo above - and of course you'll need both micros there because the I2C won't work if nothing's there to ACK.
 
Anyway, doing this I was able to get the samples back into my PC, and using python and pylot etc, plot handy graphs like this:
 

Python file, and two text files recorded from the inputs using I2C and the USB logic analyser : Archive.zip
 
The algorithm just detects when the input rises over some threshold, and while integrates the value before it crosses back over zero again (this is after the ADC samples have had 512 subtracted from them of course, making them signed). This is then considered the 'velocity', and the MIDI micro then divides that down to get a 7-bit velocity value for MIDI. This works 'ok', but very light hits aren't detected, and sometimes hits are quite a bit louder than you'd expect.
 
It's still fun though. 

@@bluehash
 
I'm using a python script, and url2lib2:
try: r = urllib2.Request('http://api.xively.com/v2/feeds/100842', json_data, {'Content-Type': 'application/json', 'X-ApiKey':apikey}) r.get_method = lambda: 'PUT' urllib2.urlopen(r) except urllib2.HTTPError, error: contents = error.read() print >> sys.stderr, contents s.write('E') continue except Exception as e: print >> sys.stderr, e s.write('E') continue where json_data is built up like so:
json_data = '{"version":"1.0.0","datastreams":[{"id":"Humidity", "current_value":"%.1f"},{"id":"InsideTemp","current_value":"%.1f"}]}'%(float(temps[1])/10.0,float(temps[2]) / 10.0) and apikey is the api key as provided by cosm for write access to your datastream.
 
Notice the line that set the get method - this is a hack because url2lib2 technically support HTTP PUT. It works though. It's running on a mac mini, if that helps.
r.get_method = lambda: 'PUT' But I've actually moved away from cosm, although all the data is ending up there. They've been bought by someone else now, and I don't like their graphs so much anymore. Now I'm also logging the data to a local mysql server, and serving the data up to my personal devices using apache. I'm doing the plots using the javascript library flot, which I think makes nicer plots that the ones cosm uses.
 
I'd hand out the URL here, but I rather think my mac mini won't thank me

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave

What you're attempting may very well be beyond the capabilities of an MSP430. I did a project a while back driving RGB LEDs, and that required multiple FPGAs to actually drive the LEDs fast enough, and used megabit serial (!) to transmit data to the FPGAs. This was generated by an LPC1768 running at a clock speed well out of reach of an MSP430.
 
Anyway, let's do some calculations:
 
You have 16x16 display, which means you have 256*3 = 768 bits of data to output if all you were going to do is have each LED either on or off (no PWM).
 
You are trying to PWM with 255 brightness levels for each LED, which means you must output 768 bits of data 255 times over, and fast enough to not perceive any flickering. I've found 75Hz is about what's required to avoid any perception of flickering, so you'll have to output 768*255*75 bits of data per second. That's about 14 megabits, which means you'd need a clock speed of 30Mhz just to get the data out - leaving no time over to calculate anything or load any data into registers or anything.
 
Also, if you want to get this data into the MSP over serial, I presume you'll want to store the image data in RAM on the MSP. Your 16x16x3 bytes of memory is 768 bytes, which is more RAM than is available in the MSP.
 
So my advice is to drop the number of brightness levels you need to (say) four, this is two bits per channel per pixel. Forget about trying to calculate HSV to RGB transformations on the MSP430. Work on just getting the LEDs on or off to start with, to make sure you can get everything running fast enough to get that going. And then try four brightness levels.
 
My feeling is though that to get enough speed for this project you will either need to get into assembly or use a more powerful micro. The LPC1768 is a nice one, but anything with a bit more grunt is probably what you'll need. Your shift registers go up to 100Mhz input, why not use a micro that can give you that kind of speed?

Earlier this year I happened to be in Singapore in transit, and took the opportunity to visit Sim Lim Tower - a high-rise mall full of electronic components shops! Amazing place, and amongst other things (including super-cheap kits for the kids to build!) I picked up three 5x7 LED matrix panels for a dollar each (!!). They didn't have any part numbers that I could see, but after experimentation they turned out to be row-anode devices and once I figured out the pinout I decided to build a project out of them.
 
As any of us who have children know, it's a daily battle to get kids to brush their teeth for long enough, and as any of us who have children also know, time spent on projects goes down better if there's a kid angle to it.
 
So I decided to make a tooth brush timer, that will display a countdown from two minutes - interspersed with inspirational text and probably amusing patterns and other things to keep the kids entertained during their twice-daily two-minute ordeal. Poor things.
 
Being given to doing things the hard way, I decided to design two boards - one for the LED panels, and one for the controller. I'll get to the controller board in a later post because it's quite complicated (since the board fab place makes 10 identical boards I decided to try to make it as multi-purpose as possible). The LED boards though are simpler, they just use a 4094 shift register to handle the columns (or rows, I decided to use my three matrices abutted end to end rather than side to side, giving me a display that's five LEDs high and twenty-one across. I found a nice 5x5 bitmap font on dafont.com, and decided that I had enough space for what I needed to display.
 
Because if all the LEDs are on the 4094 will be over it's specified current limit, it drives the columns through seven PNP transistors. This meant quite a bit of routing, which is what led me to use a board fab house rather than attempt it all on veroboard.
 
So, onto the code (I have attached the eagle files if anyone is interested). I wanted to use the USI module to drive the 4094's. Looking at the datasheet for a 4094, it clocks in it's data on a rising edge of the clock. So the USI module will need to be configured thusly (I'm running the CPU at 12Mhz).
// Reset USI logic to allow configuration USICTL0 |= USISWRST; // Setup serial output for a 4094 shift register USICTL0 = USIPE6 // SDO enabled + USIPE5 // CLK enabled + USIMST // master mode + USIOE // output enable + USISWRST // leave in reset ; // clock phase = 1, interrupts enabled SICTL1 = USICKPH // phase = 1 + USIIE // interrupt enabled ; USICKCTL = USIDIV_4 // divide by 16, giving 500khz clock + USISSEL_2 // SMCLCK as clock source ; // release SPI for operation USICTL0 &= ~USISWRST; Now, the tricky part of this project is that I want to have greyscale (redscale!) on my LEDs. To do this I will have to not only row-scan the matrix, but also PWM each LED individually. And I want to do all this in the USI interrupt handler, and have a framebuffer in RAM that I can just write to at any time without having to worry about getting the LEDs to update. So first thing is the framebuffer, I'm just using one LED matrix at the moment so it's only a 5x7 array:
unsigned char framebuffer[5][8]; // greyscale framebuffer So, for those unfamiliar with how to drive these types of LED matrices, here's a bullet-pointed flow-chart.
Start at the first row. Clock bits into the 4094 shift register, corresponding to which LEDs in the current row are on. Because I'm using PNP transistors as high-side switches, a zero in the 4094 outputs will correspond to an LED being on.  Once the bits are clocked in, set the 'strobe' input into the 4094 to high. This will latch the outputs of the 4094, causing them all to change at once to whatever you just clocked in. Now that the high-side transistors are all either on or off, according to which LED in the current row you want to be on, it's time to turn that row on using the low-side switch for that row. Of course there could be quite a bit of current flowing out through the row pin if all the LEDs in that row are on, so it's not safe to just hook it up to a GPIO pin. A FET is instead used as a low-side switch. Now the row is lit up. Move to the next row and goto 2. If we're at the last row, then instead goto 1 (which means start over). The above method, if run fast enough, will cause all the LEDs to appear illuminated in whatever pattern you desire. But it won't allow brightness control of individual LEDs. To get that we need another variable, that I'll call PWM.
 
PWM will start at zero, and will be incremented at step 1 of the above bullet-pointed flowchart. When it reaches 16, it will be reset back to zero. So it's a rolling counter that will count up each time a frame is output to the matrix, and will roll over at 16. Using this, and the greyscale framebuffer above, we can modify the flowchart so that instead of just clocking in whichever LEDs are on into the 4094, we clock in whichever LEDs have a brightness value that is greater than the current PWM counter.
 
Thus, when the framebuffer entry is zero for a particular LED, that LED is never illuminated because it's brightness value (zero) is never greater than the PWM value (zero to fifteen). And when the framebuffer entry is sixteen, it's always greater than the PWM counter, and thus that LED is illuminated every frame. In between values illumiate the LED for varying numbers of frames, which - if you run the whole process fast enough - will cause them to appear dimmer.
 
The heart of this code is the following loop, which I would love some advice on how to optimise:
output = 0; for(bit = 8; bit ; bit--) { output <<= 1; output |= (framebuffer[row][bit] > pwm) ? 0 : 1; // on if over pwm } This loop calculates what to output to the 4094 shift register for each row. It's quite alot of work for an interrupt handler, and it needs to be three times more work once I add the additional two LED panels. I'm sure the compiler in CCS does a good job of figuring out the loop and optimising it for me, but I should take a look at the assembly output and determine if I can do any better.
 
Anyway, to kickstart the process, the main program calls NextRow(), and then sets up a timer and fiddles with the framebuffer at intervals. So, here's NextRow and the USI interrupt handler:
unsigned char pwm = 0; unsigned char row = 0; void NextRow() { unsigned char bit; unsigned char output; // strobe low ready for next thingy P1OUT &= ~BIT3; // next row's data - work out if each pixel should be on output = 0; for(bit = 8; bit ; bit--) { output <<= 1; output |= (framebuffer[row][bit] > pwm) ? 0 : 1; // on if over pwm } USISRL = output; // 8 bits out, we'll come back to _usi once these bits have been clocked out. USICNT = 8; } #pragma vector = USI_VECTOR interrupt void _usi() { USICTL1 &= ~USIIFG; // reset interrupt flag // turn off rows P2OUT = 0; // latch data P1OUT |= BIT3; // Strobe high // turn on rows P2OUT = (1 << row); // next row row++; if (row == 5) { pwm++; pwm &= 0x0F; // loop pwm back to zero when it hits sixteen row= 0; // start at row zero again. } NextRow(); } I've left alot of stuff out here, setting up the clock module and the GPIO pins etc etc. Also there's code in the project that makes a pretty (ish) pattern, and the displays some numbers. The code and eagles files are attached, and assuming I can use the video feature of BBcode correctly, here's a video!
 

http://www.youtube.com/watch?v=gvPZ8LyGYGY
 
--Edit---
 
Well that youtube embed didn't work. Here's a link. How do you embed videos anyway?

LED control.zip

It is. One of many reasons I use CCS - easy to mix asm with C, better documentation, usually faster code, and overall just much more productive.
 
 
 
 
Try this,  Think in asm, write in C.
 
if(--fade_shifts_counter) {   fade_shifts_counter = FADE_SHIFTS_STEP;   ++fade_shift; }

Wikipedia has a nice table of instructions: http://en.wikipedia.org/wiki/TI_MSP430#MSP430_CPU
 
Details of the instruction set are in the 2000 series users guide: http://www.ti.com/litv/pdf/slau144i
 
An example of using C & asm for sound synthesis: http://forum.43oh.com/topic/912-32k-interupts-a-second/?p=10283
 
Details of using assembly: http://www.ti.com/litv/pdf/slau132g and http://www.ti.com/litv/pdf/slau131e
Basically R12 to R15 are passed from C code and you can trash them - preserve all others.
 
The multiplications in your code (in the IIR filter) will take by far the most time because the 2000 series does not have a hardware multiplier,.

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave

I've built a wireless temperature monitor with the following features:
 
Very low-power (7uA) sleep mode Dual 1-wire dallas temperature sensor inputs, to measure two temperature sensors at the same time. A 2-line LCD display that displays the current measurement for 15 seconds when a button is pushed. 2xAA battery supply, with charge pump to power the LCD, temperature sensors and 433Mhz wireless module. Uses VirtualWire to transmit the data to an MSP430-powered receiver module. This is all currently sitting outside, and the indoor rx unit is uploading the measured temperatures as well as the battery voltage to Cosm.
 
https://cosm.com/feeds/100842
 
I've attached to this post the eagle files for the outdoor unit, and the veroboard layout for the same. I'll upload some photos also, and details of the indoor unit and the python script that uploads the data to cosm. The indoor unit is currently sitting on a breadboard, not in a nice project box, but its time will come
 
TempSensor.zip
 
I've hacked the VirtualWire library to bits, leaving only the transmitting portion of the code. This was so that I could understand it, and so that I could have it running at a lower timer speed for (very slightly) lower power.
 
There's a few things in the schematic that might not really be necessary. I've used two fets to switch off the radio and the lcd/sensor separately, because I was under the impression that the radio transmitted the whole time while powered on. I now realise that it only transmits when the data pin is high, so I could have saved myself a component there. Also I'm using a whole hex level shifter IC just for the one input into the radio, because the other shifter's lines are all used up by the LCD. This also isn't necessary, since a singe fet would have done the job if I'd inverted the output of VirtualWire in software.
 
But in any case, it all works, and seems (so far) fairly reliable. There are some spurious readings that I accidentally uploaded to cosm while working on the receiver end, but other than that I'm pretty happy. What I'm really quite interested in is how the battery voltage is going to change over the coming few years.
 
Please feel free to use any of the code that I've uploaded, but be aware that in the words of some other forum poster somewhere, it's not supposed to be pretty - it's just supposed to work!
 
-dave