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.
This is the Experience Brief (11.2 MB) that I presented along with Myra Einstein, Arly Ross and David Yates on our Penn Station project for Interaction Design class. It looks as if the concept of a dynamic overhead signage system, trigged by Bluetooth IDs, will be the one we prototype for our final project. I’m hoping to being working with BlueSMiRF adaptors for this sometime next week.
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.
These are the re-presentations of my Alarm Clock and 1000 Floor Elevator projects.
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.
Our personas presentation for the Penn Station project.
