Friday, January 20, 2006


I bought a usb-serial adapter today (amazingly only $15) and hooked it into the s'ware I've been writing for a few weeks. Like magic, it worked!

Therefore, there are some *known* bugs to be worked out, but... when I walk into my bathroom with my laptop in hand, it makes a flushing sound *childish grin*

I created abstract regions too [they aren't convex hull or anything, just circles and rects] -- if a condition, like being in a region, fails -- the event that was triggered is stopped.

I do *not* support any kind of triangulation at the moment. Each beacon is a singularity as far as it's concerned. But I have function calls in place waiting to be filled.

Tuesday, January 17, 2006

Oh... and we still need to get a 9 pin serial->USB adapter if we hope to use this on any modern laptop. As it is I'm still using the serial off my desktop (with a nice long cable ;)

Java Gallery Progress

Now that I finally finished cs161, I've been working on the user-end code and spent a while refactoring it and making it nice and somewhat painless to create somewhat expressive 'galleries' -- meaning, extending a Gallery class to define how a particular gallery works, e.g. RISD gallery, or CIT computer museum gallery, etc...

There is still lots that could be done on it (it's not a hack, it's a very elegant, well-thought-out hack). I'm hoping to connect it to a live cricket data stream in linux in a few days (I've been using a prerecorded session) -- InputStreams are data sources, so it's pretty easy to wire into a file, a socket, or a terminal in Linux.

Of course, this means that the implementation requires a laptop, preferably running Linux (the Cricket code that broadcasts readings from the serial port is *Nix only -- we'd have to port it otherwise), and necessarily running Java. This could be changed by rewriting the code in another language, but Java is good for prototyping.


Ideally the user code would be extended to server code, which would understand stateful sessions of users running the same gallery. And that we could recieve readings via BT or WiFi TCP, and stream audio packets back over BT. (there's more to worry about, like mixing the audio, or making sure there's only one stream playing -- not really within the realm of what we've got now).

Saturday, December 10, 2005

Bluetooth Progress (cont.)

The server/client using OBEX is running well now with the JavaWirelessToolkit 2.1. The obex implementation of JWT is actually a simulation for Bluetooth, it is not the 'real' bluetooth but we at least have the picture that it would work.
Zach Shubert was very helpful with installing Bluez to some of the CS Machine which we worked on. However at this point we still couldn't get access to the Bluetooth stack (which we think may be caused by some restriction of the Kernel). Zach is not reachable over the weekend so we hope to continue the work as soon as he can help us figure out the problem.

Thursday, December 08, 2005

Bluetooth Progress

We have been trying to contact Vesko to access the code for Bluetooth with no hope. However, we have made quite a progress.
What we found out:
- An implementation of JSR82 for linux. It is called avetanaBluetooth and it's at
This implementation of the JSR82 supports javax.bluetooth and javax.obex, which is good to use for our application, and the best thing about it is that it's FREE!
- We developed a server-client application using Java for transfering data via bluetooth on the Linux environment. The server application is running well, but the client is not because the machines of the CS lab does not have Bluez, a package for bluetooth.
- We are working with Zach Schubert to resolve this issue. Hopefully we will have an API for transfering files/data via bluetooth on Linux Machines in a few days.

Tuesday, November 29, 2005

Status on Cricket

Currently I can get raw cricket readings via serial port (forwarded over TCP). So at the least, if we have a laptop with a serial port moving around, we will be set.

I do not have proper localization working, per se -- but I am simplifying what we want cricket to do for us (for now): Rather than localizing where someone is based on multiple crickets, we will do what our initial goal was which is just consider distance to a single cricket. Meaning that we will know our radius to a node independent of what other nodes are saying, and can calculate our position to an accruacy of 1cm.

This way we can determine when someone is close to a point and trigger an event.

One way to improve this is to increase the sampling frequency on the nodes so we can get a more continuous gradient and potentially get acceleration. Neat.

For now, I recorded a dump of the communication as a listener moves towards a node, and will use it as 'training' data while I work on a Java client that parses the stream and triggers events.

Monday, November 07, 2005

Progress Report

The progress report is now available in PDF and PS

Thursday, October 13, 2005

Project Proposal

Excitement! The project proposal is now available:
For those that read PDF... and those that run PS