For the Network Objects class final I’m considering creating a detection system using Bluetooth. These sensors will read locally detected Bluetooth IDs and send the results to a display system connected to a database. The database will associate the Bluetooth ID with other information about a person. For example, on the ITP floor it could be used to detect when a particular person is present, and display his or her photo on a local monitor. Initially these sensors would be connected via the Internet using an XPort module. Later on, they could connect and pass information using mesh networking, so that only one member of the network would need to be connected to the display system.
Java, and therefore Processing, interprets a byte as being a number between -127 and +127. Other environments, including the PIC, interpret a byte as being a number between 0 and 255. To be exact, Java uses only signed bytes and the PIC uses only unsigned bytes, so translations have to happen when the two talk to each other.
Here’s how to get your numbers back and forth intact:
When sending from Processing, create an int and then cast it as a byte before sending it out, like this:
int myValue = 200; // a number you want to send out (must be between 0 and 255)
byte myValueByte = (byte) myValue; // cast the int as a byte, now it's ready to send
When receiving a byte value from the PIC, Java will interpret the incoming data as a signed byte. To convert it to an unsigned byte between 0 and 255, here’s a handy snippet of binary math:
byte myReceivedByte = -2; // this negative signed byte is the same as an unsigned 254
myReceivedInt = myReceivedByte & 0xFF; // this binary math operation effectively restores the byte to its unsigned state
I got some good info on this from conversations with Dan O’Sullivan, Jeff LeBlanc and from the Internet
Here’s a system diagram for the Tap ‘n Tell toy we’re creating for your Toy Design Workshop project. There will be at least two of these toys, linked together directly, or via through a base station. Click on the image above to marvel at the diagram properly.
I spent this evening reading up on the two Easy Radio ER400TRS-02 Transceivers that arrived in the mail from England this week. Our plan is to use these in a networked toy to create a direct wireless link between two similar toys, or between one toy and a base station that can carry its signal over the Internet. The data sheet was full of good surprises. The transceivers are expected to run on +5.0 Volts and offer full Hardware Handshaking (CTS, RTS) functions which will allow for better control of communications with the buffer-less PIC microcontrollers. There is also a “Busy Output” and “Host Ready Input” pin (DTE, DTR) that will prevent lost messages in cases where either the transceiver or the microcontroller is powering up or coming out of sleep mode. Finally, the Easy Radios use very little power if they are not communicating, unlike the power-hungry WiPort, so there can be plenty of play time between battery changes.
I’ve been working on getting to know RS-232 Serial communications. There’s tons of acronyms, and it turns out everything relates back to “dumb” terminals talking to modems. To better understand it, I made myself this chart of the pin assignments:
(click to enlarge chart)
I also created a chart organized around the types of information passed between the two devices:
(click to enlarge chart)
The information includes definitions for each pin:
1. DCR (Data Carrier Detect): The modem turns this on when it has a carrier signal from another modem.
2. RX (Receive Data): Information sent from the modem to the dumb terminal
3. TX (Transmit Data): Information sent to the modem from the dumb terminal
4. DTR (Data Terminal Ready): The terminal turns this on when it’s ready to use the modem.
5. GND (Signal Ground): A common ground for all signaling
6. DSR (Data Set Ready): The modem turns this on when it’s ready to be used
7. RTS (Request To Send): The terminal turns this on when it’s ready to receive data
8. CTS (Clear To Send): The modem turns this on when it is ready to receive data
9. RI (Ring Indicator): The modem turns this on when it is receiving a phone call
There’s also great information in the WikiBook on Serial Programming.
We’ve configured the WiPort for basic communication in both directions. Our code takes an analog value and sends it out. At the same time, it waits for a control character (here set to “Z” for ease of use in debugging via telnet) and then checks to see if it’s followed by a data byte (specifically the letter “A”, again for debugging ease). If it gets the proper sequence of “ZA” then it turns on a piezo buzzer.
We have 12 1.5″ force sensing resistors on order, and will hook these up to the circuit when they arrive next week. In addition, we are going to install a vibrator motor and audio feedback inside each cube, so that game actions will create local feedback, and FSR switch state will be obvious to the user.
At this point I’d like to learn a lot more about serial data communications so that I can navigate my way thought the bewildering level of alphabet soup, and configure connections to reliably transfer data.
Travel Bugs are tags used for items that “hitchhike” between geocaches. They are attached to items that people find in a cache and are intended to be transported to the next cache that the finder visits. This is essentially an asynchronous ad-hoc routing protocol for objects. It would be interesting to describe a desired destination for the Travel Bug, thereby enlisting each finder as an attempt to get closer to the destination. This would a kind of warped version of how an electronic packet might travel in distance-vector routing.
For midterm, Christian Croft and I plan to extend on the Cube drawing interface from the pair gaming assignment. We intend to focus our energies on implementing WiPorts in the physical cube interface. In addition to adding WiFi, each side of the cube will now have an analog switch (most likely an FSR sensor), and sensory feedback (either vibration or sound) according to what is happening on screen. We hope to improve the actual fabrication of the cube by cutting plexiglas with the lasercutter at ITS. Eventually, we plan to expand beyond the 3D drawing task in the current processing applet and introduce some enhanced gaming and entertainment features.
The ITP program lobby display screen faces Waverly Street through a double-paned glass window. This setup is fine for showing off purely visual work, but doesn’t work for anything with an audio component. Sounds played behind the double-paned glass cannot be heard on the street, and the facility will not allow speakers to be placed on the outside of the building. Our solution is to reach passers-by via their mobile phones. When works with audio are shown on the screen, we will display a phone number to dial so that the public has a way to hear audio from the screen.
We initially considered using a SoundBug to transmit audio through the glass, but this does not work on windows with more than one layer of glass. We also considered using an iTrip type of FM transmitter, however it is uncommon for pedestrians in New York to carry a radio these days. The solution was to accept calls into a Voice Over Internet Protocol (VOIP) service so that the computer itself could receive a call from the mobile phone network. We chose a Skype setup because it allows for calls to be automatically answered and will work on Macintosh, Windows or Linux. Next we plugged the audio OUT from the server back into its audio IN jack. When a Skype call is answered, it transmits whatever is on the audio IN–in this case the sound that would otherwise be coming out of the computer’s speakers. Beta testing of this setup began today, and it seems to work great!
Continue reading ‘Mobile Phone as Audio Output for Public Display Screen’
