Category Archives: Play the Room

Sparkfun’s Internet-of-Things Database: Phant

Phant (think elePHANT, I guess) “acts as a logging tool which allows any device to read and write data to and from the service”. After creating an account with Sparkfun, one can create feeds by interactively describing the data that will be included. Two keys are then supplied to the user: a private (read-write) one that can be used to submit or modify the data, and a public read-only one (all feeds are publicly viewable).
To submit data, one simply sends it in an html GET or POST request. It will then be captured by the database and a confirming reply sent. Similarly, one can retrieve data with a GET or POST request.

There is a space limit and a bandwidth limit, but these are set reasonably so that most users won’t be inconvenienced by them.

I have been storing data automatically into Phant for a few months now. I have a solar-powered ESP8266 WiFi-enabled processor which wakes up every ten minutes, takes temperature and battery-voltage readings, connects to my home network, and sends them up to Phant. You can view them as raw data at https://data.sparkfun.com/streams/2J5rnpZllATNjOOmqLrq, or graphed by another free service at https://analog.io/#/s5EV.

I am working with MQTT also as another, fairly different, IoT data broker, and will publish another blog entry about MQTT. A key difference between the two is that Phant is entirely passive – you can get data from it or put data into it, but it won’t notify you when new data arrives. MQTT is designed with a publish/subscribe architecture; you subscribe to a topic and when new data is published to that topic, you are notified with the new data.

DP123 Monday Madness Crazy!!!

Who gave M5 a welder, and a grinder?  And all that safety gear and clothing that renders one anonymous, and rather frightening-looking?

Team Proteus5, subdivided into further teams, now has a cacophony of grinding and sawing noises to accompany their workings-on as the build team fires up the power tools in the corner of the backroom, the future site of the M5 fabrication lab, dubbed Fab5.

Fab5 is a the future facility that will expand the build capabilities of M5 to include metalworking, woodworking, and plastic and glass work.  We have, so far, a welder and grinder.

At this week’s Play the Room, we decided against playing the room in the literal sense, with solenoids on the pipes and ducts and such throughout the Good Room, primarily to cut down on the amount of tubing and mounting hardware required for such an endeavor, as to save time and fully realize our goal of an electromechanical, MIDI-controlled instrument.
We have decided, instead, to use a metal cabinet that housed some sophisticated-looking engineering equipment, including a piece at the bottom (the power supply, perhaps) that features a sign: DANGER / LETHAL VOLTAGE.
We gutted all the cables out of it and found some promising locations for the pneumatic actuators we have arriving soon.  Also–our arduino software is looking good!  More on all of this soon!

Play The Room – Third Class

Imagine this.  You sit before a humble, MIDI keyboard.  It looks like a truncated piano.  You can’t help but notice the colored wires spewing from a small box behind it to places scattered around the room.  The walls.  The ceiling.  You press down a key, and involuntarily clench as a clang from overhead rings out, as a solenoid’s core slams into the ventilation duct.  You hit the key again.

We at the Play the Room class are getting there, and quickly.  By the end of this week’s class, we had a fully functional proof of concept–a solenoid controlled by MIDI keyboard.  Check out the schematic.

A MIDI cable carries the performance information from the source, whether it is a computer sequencer (Ableton Live in the video below) or a keyboard, into the Arduino.  The software in the Arduino detects the incoming MIDI message, and sends a pulse of power to the solenoid, which then strikes whatever is before it.  The software in the Arduino must be able to filter out irrelevant MIDI information (there are many kinds of messages useless to us in this context), and as we add more solenoids to be controlled, the software must send a voltage pulse to the correct solenoid depending on the MIDI note that is received.  That is, when you hit different notes on the keyboard, it plays different solenoids.  Both of these goals are easily achieved in software.

Issues we will consider in future classes include the design of a robust mounting scheme and velocity control.  Ideally, the solenoids and their control mechanism will remain intact and usable for decades, or until our neighbors tire of the noise.  And if you were to hit the key on the keyboard softly (or strike it proudly with vigor), wouldn’t it be great if the solenoid responded with appropriate force?  To be continued…

VIDEO!!!
http://www.youtube.com/watch?v=4s2aRMzjkhg

Arduino Code (thank you Alden!)

//****************************************
byte incomingByte;

void setup () {
Serial.begin(31250);
pinMode(11, OUTPUT);
}

void loop () {
if (Serial.available() > 0) {
incomingByte = Serial.read();
if (incomingByte > 143 && incomingByte < 160) {
//note on
digitalWrite(11, HIGH);
} else if (incomingByte > 127 && incomingByte < 144) {
//note off
digitalWrite(11, LOW);
}

}
}
//****************************************

Play the Room — First Class

Play The Room had its first class last week!  Having solidified the roster, we broke out the solenoids and, well, played around with them.

In order to better get to know the solenoids, we hooked them up on a breadboard, as shown.  The mosfet shown acts like a switch, controlled by the arduino through pin 11 in this schematic.  When the program in the arduino tells pin 11 to go HIGH (+5 V), the mosfet allows current to flow through the other two leads, providing the solenoid with a path to ground.  Current then flows through the coil of the solenoid, and the metal core inside it is forced outward, striking whatever may be in its path (percussion!).

When pin 11 goes low, as determined by the Arduino’s software, current ceases to flow through the other two leads of the mosfet, therefore no current flows through the coil of the solenoid.  This means there is no longer a magnetic force pushing its metal core outward, allowing it to return to its internal position.  However, the solenoids we ordered to not have a spring to make the core return to its starting position, and one cannot simply reverse the direction of the current through the solenoid’s coil and expect a magnetic force in the opposite direction (http://en.wikipedia.org/wiki/Right-hand_rule).  Our (hopefully temporary) solution was to use a rubber band to bring the core back to its starting position.

By the end of the class, the solenoid cacophony had drawn a small crowd.  Check it out!

http://www.youtube.com/watch?v=bisMUvgiogU

Here is the arduino code:

//***********************************
int solPin = 11;

void setup() {
pinMode(solPin, OUTPUT);
}

void loop() {
//give the mosfet a voltage pulse to activate the solenoid
digitalWrite(solPin,HIGH);
delay(30);
digitalWrite(solPin,LOW);

//wait one second
delay(1000);
}

//***********************************