Jump to content


  • Content Count

  • Joined

  • Last visited

About davebranton

  • Rank
  • Birthday 12/10/1973

Profile Information

  • Gender
  • Location
    Christchurch, NZ
  1. Wonderful. I'm going to completely steal this, and use the extra space on the left side of my MIDI drum pads and play stadiums: http://forum.43oh.com/topic/8340-midi-drum-pads/
  2. 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 hook
  3. Also, one more pic I forgot, here's everything plugged together showing some text. After reading something about how the text needs to be antialiased to allow for smooth scrolling, I modified the text rendering code to allow the characters to be placed by quarter pixels. This made a huge difference to the readability of text on such a small display, but makes it look a bit weird in photographs. The idea is to intersperse the timer display with occasional inspirational/subliminal messages Well, actually probably just stuff to entertain a bit - although I've not really had any good idea
  4. Having done quite a bit of work in the past with inertial sensors, I can say that it's next to impossible to distinguish one type of motion from another using accelerometers & gyros. Especially with the kind of cheap accelerometers that would fit on the back of a toothbrush. So although it's a pretty nice idea, I think in the end I'll have to trust them. I'll probably be behind them in the bathroom policing the whole thing anyway, and the timer is as much for me as it is for them. AND of course the whole thing is only an excuse to play with electronics and spend some cash of parts and PCB
  5. @@cubeberg Fantastic project, and impressive results. I wonder if you would be better off transmitting the co-ordinates in binary rather then text too? That might improve your bandwidth. I have a few questions if you'll permit me: 1) How much current do the motors draw? 2) How have you implemented the z-axis? 3) What kind of pen have you used? Have you experimented with others? Biro vs. a felt-tip for instance?
  6. Completed control board arrived. Still got a two-week wait for the parts though...
  7. @@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":"%.
  8. Two great suggestions, thanks. I have the PCBs on order from seeed as it happens, and I have some other boards in the pipeline so maybe I'll look into that. I couldn't find the ones you mentioned spirilis, but I did find this: http://www.seeedstudio.com/depot/the-nevergoingtomiss-glaringdevileye-huge-red-push-button-p-378.html?cPath=85 Costs as much as 10 custom PCBs!! We do have a fantastic thrift shop round these parts that I'll hit up first to see what I can find. Anyway, I wrote the code I mentioned earlier up in assembly, and unrolled the loops, and got the inter-byte time dow
  9. @@igor , that's not a bad idea, I probably will Also, I wonder if anyone knows of any nice big smackable buttons that would be suitable for something like this. Kid proof, waterproof, and nice and big and satisfying. The kind you often find on slot machines I guess.
  10. 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
  11. Thanks abecedarian, I'll do that next time. Ok, so I took a look at the assembly version of the loop I mentioned above, and I'm not all that impressed with the compiler's output. I'm probably expecting too much, because I've seen it do pretty clever stuff in the past. output = 0; for(bit = 8; bit ; bit--) { output <<= 1; output |= (framebuffer[row][bit] > pwm) ? 0 : 1; // on if over pwm } And here's the assembly, annotated to help with my own understanding of it. This is a release build using CCS with optimisations at maximum speed. MOV.B &line+0,r14 ; []
  12. 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 thei
  13. Well it looks like the culprit was Grace - which I think loaded the USICNT register with 8, causing the SPI clock to start. So by the time I got to my code the clock had already been running for a bit, and so writing 8 to the register caused me to see about 12 bits on the output. Once I threw away the grace project and started again doing everything by hand it all worked fine. I'm going to start another thread about this project because it involves a couple of custom boards and I don't want to have my stupid question at the top of the thread
  14. So I've finally finished this, and I thoght I might share the code I used to talk to the indoor temperaure and humidity sensor - a DHT-22. These sensor output their data using a 1-wire protocol that's completely different to the 1-wire protocol used by the dallas sensors. Sigh. I somethimes think that although hardware designers talk alot about compatibility, they hate it really because it cramps their style. Anyway, here's what I did. I've attached all the code to this post, but here's the relevant parts. First, setting up the one pin for the sensor, which I'd connected up to P2.0, and se
  15. I have a schematic and board layout for an MSP that supports the following features - it's not a boosterpack though it's a standalone board that breaks out the debug pins so you can connect it to a launchpad for programming. I personally find this a more cost-effective approach because the chips by themselves are a couple of bucks, and the final product is more flexible. This board will be used in several projects. An LED matrix, A robot with ultrasonic sensors, and some audio project or other. Perhaps a digital guitar effects pedal or something. Two power supply options: Step up power s
  • Create New...