I've recently switched to using an x-OSC (http://www.x-io.co.uk/products/x-osc/) for my ADC stuff, and it works a dream (no more parsing/bitshifting to get hi-res ADC input!) but the problem is it only provides 3.3v.
Now, for now I've been powering the x-OSC and the wind sensor off a sparkfun 5v regulator, but this still means the wind sensor is spitting out 5v range. In trying a bunch of different things I think I've managed to fry my wind sensor. So rather than go at this again, I'm wondering if there's a wind/breath sensor solution that works off 3.3v.
The intended usage is having it built into a mask to pick up breathing patterns and general breath 'volume'.
Has anyone used a wind/breath sensor that runs off 3.3v?
But the 'k' section of the manual goes on to say that this only happens once, and that a 'j' command will be needed to repeat it.
The 'j' section of the manual (page 27) is more confusing particularly since the jump argument specifics lines to JUMP. I only have one line of 'real' code, so there's nothing to JUMP. I just want to read it again.
Does anyone know what the script would be to get the analog ins to correspond to RGB values on an infinite loop?
So I've been using Arduino stuff for music for some time, and I always use it as serial, and send it into Max/MSP where I parse the stuff. This works ok, but I often have pretty serious kernel panics (greyscreen on a mac) related to serial/buffer stuff.
So what I want to do is setup an Arduino to be a generic input device. So all digital inputs would be sent as 0/127 (binary) and analog inputs would end 0-127.
But the idea being that all inputs are being read and sent as midi. There's a sacrifice in resolution for analog inputs this way, but in exchange for bulletproof stability (class-compliant MIDI).
I know there's the Maxuino library that lets you control everything on the Arduino from Max, but it, too, uses serial, and I want to avoid that.
I've never reprogrammed the input chip on an Arduino, like you can with the newer ones, so that part is new to me.
So the two questions are:
1) Anyone know of a 'read all inputs and send all MIDI' sketch? 2) Is there a decent guide for programming the input chip on an Arduino to act as class-compliant MIDI?
I'm building a project onto/into a DIY guitar type instrument, and I'm getting a nice high pitched squeal when I get the MCU near the pickup. I tried some really rudimentary shield (ie a bit of grounded tin foil between the two).
Because of the room I have on the instrument, there's basically no other place for the processor to go.
Is there a good way to shield and/or minimize clock noise?
Whoops, I was cleaning up my webpage, and I had forgotten I linked it up here. I'm away at a festival at the files are on my external HD back home, but I'll upload it as soon as I get back (start of the week).
So I'm wanting to build a project that will let me control a series of switches from my computer. I've managed similar things before but the new things in this project that I'm unsure about are:
1. MIDI over USB I know the newer Arduinos have a programmable interface that can 'pretend' to be things. Can this be used to be a class compliant MIDI device? As in, I plug the USB cable in and it gets auto recognized as a MIDI device (rather than needing to use serial I/O).
150ms is already well beyond an acceptable latency (any sudden movements perceivably lag). I can try higher, but 1second is beyond useless for the type of application it's intended for (gesture sensing of a performers movements).
I'll give it a spin with 500ms maybe for testing purposes.
I'm only running at 57600 (it was originally 115200 but it would dropout after a couple seconds).
The thing is, with the call/response the transmitter is only sending data when it receives a packet back (and vice versa for the computer), so nothing should overflow that way (I would think).
I'm guessing the 'response' part of the message is getting dropped periodically, so going back to just streaming data might be more reliable, but that's how I was getting dropouts at the start anyways.
I'm not packing a packet number in, so unless the xbee is, there isn't one. I've tried to keep the messages as small/tight as possible, so I'm sending all my sensor values as bytes. I'm sending a 20-byte message per 'go', though I'm sure the xbee sticks some stuff on top of that for what it does.