Following on my look at the types of sensors that are available to convert physical properties to electrical information, I will next present a survey of micro-processor boards. These are specifically designed to facilitate the capture of sensor data, and the massaging of this into a format usable by a computer (or even another device). Before I do so, however, I need to discuss my methodology and some of the characteristics of these boards, factors you might use to determine which you need for your particular application. The following article will give you the lowdown on the particular boards themselves.
All the information here was first gathered between 12 and 6 months ago, but verified just before publication. Intriguingly, not much had changed over the intervening time. This data is summarised from manufacturers' websites, and so cannot be confirmed by myself to be absolutely true. Nonetheless, I think it provides a good baseline for evaluation. Though there are some other comparisons available on the web, I did not consult them before writing this document, in order to prevent bias. (You may wish to peruse the out-dated info at IRCAM or the more useful table at the sensor wiki.)
I have omitted defunct devices, since I am not interested in a historical perspective, but rather what can practically be achieved today. Nonetheless I have included some units that may be going the way of the dinosaur soon, and note any availability problems.
This is to be a long list of boards. Many individual research programmes into physical computing at universities around the world had the same need for a more-or-less easy interface kit at around the same time. The availability of chips with embedded controllers that were easy to programme encouraged a flood of solutions. The result is that there are perhaps too many possibilities.
There are several characteristics that can help us differentiate these boards; deciding first on your criteria can facilitate the evaluation process. You may wish to consider the following:
* The price of the unit. Not all artists are rich.
* Whether the project is open source or closed. This can be a philosophical issue but has practical importance to the life and vitality of the unit.
* The number of inputs and outputs, plus how many are digital or analog. This determines how extensive the connected sensor network can be. (And not just sensors -- do you wish to drive any actuators from the board? You will need outputs for those.)
* The output communication protocol and connector. The protocol may be OSC, MIDI or serial. Serial data can be carried on USB or RS-232 (colloquially called "serial") cables.
* The size of the device -- important for embedded applications.
* The type of connectors. Some manufacturers enjoy using proprietary plugs. These will require more work to wire, or greater expense as you find yourself locked into one vendor's solution.
* How much electronics is involved. Some kits require you to obtain parts and build from scratch, others give you the parts but require soldering, still other devices work out of the box with simple screw connectors. And some are completely turn-key, but likely require you to buy sensors with the correct connectors directly from the same vendor, limiting your choice and increasing costs.
* What control software is available and on which platforms it runs. Do you have to tweak the firmware? Is this easy to do? How much coding is required?
* The data rate or resolution of the device may be important in particular applications. I haven't explicitly listed these, but the Sensor Wiki table referenced above does.
* The quality of documentation and helpfulness of the developer community. This can be difficult to evaluate, but is especially important for kit projects.
In the next article you get to apply your criteria to18 22 possible solutions. Ready... Get Set... Go!
I thank the Arts Council for their support in this research.
I have omitted defunct devices, since I am not interested in a historical perspective, but rather what can practically be achieved today. Nonetheless I have included some units that may be going the way of the dinosaur soon, and note any availability problems.
This is to be a long list of boards. Many individual research programmes into physical computing at universities around the world had the same need for a more-or-less easy interface kit at around the same time. The availability of chips with embedded controllers that were easy to programme encouraged a flood of solutions. The result is that there are perhaps too many possibilities.
There are several characteristics that can help us differentiate these boards; deciding first on your criteria can facilitate the evaluation process. You may wish to consider the following:
* The price of the unit. Not all artists are rich.
* Whether the project is open source or closed. This can be a philosophical issue but has practical importance to the life and vitality of the unit.
* The number of inputs and outputs, plus how many are digital or analog. This determines how extensive the connected sensor network can be. (And not just sensors -- do you wish to drive any actuators from the board? You will need outputs for those.)
* The output communication protocol and connector. The protocol may be OSC, MIDI or serial. Serial data can be carried on USB or RS-232 (colloquially called "serial") cables.
* The size of the device -- important for embedded applications.
* The type of connectors. Some manufacturers enjoy using proprietary plugs. These will require more work to wire, or greater expense as you find yourself locked into one vendor's solution.
* How much electronics is involved. Some kits require you to obtain parts and build from scratch, others give you the parts but require soldering, still other devices work out of the box with simple screw connectors. And some are completely turn-key, but likely require you to buy sensors with the correct connectors directly from the same vendor, limiting your choice and increasing costs.
* What control software is available and on which platforms it runs. Do you have to tweak the firmware? Is this easy to do? How much coding is required?
* The data rate or resolution of the device may be important in particular applications. I haven't explicitly listed these, but the Sensor Wiki table referenced above does.
* The quality of documentation and helpfulness of the developer community. This can be difficult to evaluate, but is especially important for kit projects.
In the next article you get to apply your criteria to
I thank the Arts Council for their support in this research.
RELATED POSTS
No comments:
Post a Comment