Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by davebranton

  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
  16. Hi, I'm building a simple LED matrix display, using 4094's to drive the columns of the matrices, and I would like to use the universal serial module to clock the data into the shift registers. So I set up a simple test, and had the serial module clock out 7 bits (I have three 7x5 matrix panels, and at first I'm just using one), but I didn't see the results I expected. When I got a scope on the outputs, I saw the serial module clocking out 11 bits! I had to set the bit counter register USICNT to 4 to convince the serial module to output 7 bits. The code looks something like //set stro
  17. Well I ran the same code through CCS, and it's a damn clever compiler. It even figured out that my sequence of shifts and adds constituted a multiply and jumped off into some subroutine apparently called __mspabi_mpyi. Impressive - assuming that this would be faster than the shifts and adds of course, but I'll give it the benefit of the doubt. So I'll be sticking with CCS, even though I'll have to run it in a VM it's going to save me a lot of time. Thanks very much for your advice.
  18. Thanks for the hint about the multiplier, I decomposed the multiplies into various shifts and adds, and the c version of the code works great! ...So I thought to myself, even though I don't actually need to, I'll have a crack at using the inline assembly to get the same results and free up some cycles. ...But... inline assembly is a strange beast in msp430-gcc land. I honestly can't make head nor tail of the documentation, and very strange things started to happen. But in any case, I did have a question about this code: mov &fade_shifts_counter, r15 add #llo(-1), r15 mov r
  19. So, with an eye to the exponential chirp code above, and following some-one else's advice in youtube, I've got a phased linear chirp plus some filtered white noise sounding quite nice in matlab (m-file attached for those who happen to have access to matlab and are interested laser.m.txt). I'm probably going to need to code this in assembly in order to keep up with the 20kHz ouput frequency, since at 8Mhz I'll have only 400 cycles to calculate each sample. Actually, that's probably plenty, but assembly is interesting anyway, and presumably there are some great resources on assembly on
  20. That's a very good point about the supply voltage. I'll have to run some experiments to see how much speed I'll need to generate good sound effects. 6Mhz might well be enough because I'll be sending samples to a DAC at probably only 20kHz or so. At 16 bits per sample (even though it's only a 10 bit dac, it still wants 16 bits before it'll output...) that's about 320kHz, or 0.3Mhz SPI clock speed. So from that point of view 6Mhz would be plenty to drive the DAC. Then it's just a question of writing some really tight code with a lookup table / algorithmic outputs and seeing what comes out.
  21. Here's a picture of the device in position, still no progress on tidying up the indoor unit - it's still on breadboard.
  22. Hi, Since I have two of the MSP430's left over from the two launchpads I bought, I though I'd breathe new life and fun into the now-obsolete PlayStation one light guns. Using an MS430, an 8-pin DAC in a DIP package (an MCP4911) and an LM386 for amplification. Thus far, the basic plan is: Run the 430 of two AAs directly Use a DC converter (TPS61041) to step this up to 5 volts ish for the LM386, Use a FET to turn this 5v side off when in sleep mode Use the 430 to generate some incredibly awesome laser gun sound... ..and actually a cool reloading (yes I know laser guns don't reload) soun
  23. I used two lines for the sensors simply because I couldn't be bothered to figure out the rom search stuff for them. With two lines I just use the skip rom command and then I can read data from them at the same time. I had the spare pins anyway, so it was no problem. That's a great idea about the 74HC595, but it's all soldered down now so it's too late! About building circuits on verboard - I certainly used to just jump in, but ended up having to rework half of it. Getting interrupted by the kids didn't exactly help VeeCAD looks great - I'll give it a try.
  24. 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
  • Create New...