TRyPTiCHON ::: hard- and software set up
 [download analysis as pdf] [emotional mapping] [technology]
[roamer's feedback] [about us] [link list] [ambient index]
Our setup consisted of two GPRS-enabled phone/PDAs (Palm Tungsten W), two Bluetooth GPS units, three G4 laptops, a stereo sound system and a monitor. 

The TRyPTiCHON Server

TRyPTiCHON uses a custom programmed server which receives TCP messages from the GPS-enabled handheld device via GPRS and translates them into the OSC (Open Sound Control) protocol, a protocol that can be understood by applications such as MAX/MSP/Jitter and Supercollider.

For this process to work the server has to run on a computer with a static IP address, as the GPRS TCP messages are being sent from the handheld device to the network provider (in this case, Orange). The provider then forwards messages to the TRyPTiCHON server. Obtaining a static IP address while using a shared ADSL line is made possible using port forwarding. The router at the performance space has to be modified to forward requests made at a specific port to TRyPTiCHONÝs own server.

This custom server takes the incoming messages, translates them via the OSC Java library into Open Sound Control packages, and transmits these via UDP over the Local Area Network (LAN). Any computer on the LAN that is targeted by the server will receive the OSC messages and then be able to use them as control data in, for example, Max patches.

The TRyPTiCHON server translates the following data from the GPS units into OSC:
´UserID é to distinguish the roamers
´PerformanceMode é The roamer has the choice of different modes, which have effect in later Jitter patch implementations
´Longitude & Latitude /The position of the performer
´Speed é Speed of the performer
´Course over Ground - A degree value specifying the bearing that the performer is moving on
(The last three items of data are parsed out of standard GPS sentences sent by the GPS unit via the handheld PDA to the server).

The Java code of the TRyPTiCHON server as well as the underlying Java OSC Library for constructing the OSC packages is open source and will be distributed by ambientTV.NET (server code) and Soda Creative Ltd (OSC Lib). Please contact us if this is of interest to you and we will provide the source code and documentation.

Evaluation of mobile phone Motorola A920
“A brick in a walled garden”.


First choice for platform: A 3G phone with built-in AGPS, the Motorola A920. We were looking for a consumer device which would allow us to send voice and location data to a server. The Motorola A920 phone which operates in the UK on the “3” network seemed to fulfil the requirements at a reasonable price. It runs Symbian OS (an operating system that allows Java applications to be implemented), is GPS- (global positioning system) and GPRS- (general packet radio service) enabled, includes video messaging, and in combination with a one year contract costs a reasonable £130.


There was also an amusing coincidence: our deadline for the DMZ festival and the deadline for a coding competition from “3” for developing A920 software for the A920 shared the same date, November 14th 2003.


Soon after the hardware arrived and we had become familiar with the details of the A920’s development environment, we encountered the first problems. Apart from the appalling battery life (a couple of hours at best), the first major issue was with signing (a process that certifies an application as OK to be installed on a particular piece of hardware) particular to the A920 handset. Applications have to be approved by “3” first to enable installation. “3” claims that this decision has been made to prevent malicious software, which might make use of an extended java library, to be distributed by 3rd party providers. The other side of the coin is, of course, that “3” would be the only source of software. This signing issue prevented us from any reasonable user testing of the phones GPS functionality.

The signing issue also found its way into Hutchinson’s developer competition: applications have to be signed for installation even on the A920 emulator (using an emulator-specific key available to the public), adding another layer of complication for testing software. When contacting the developer support for the competition, we didn’t receive too much help regarding our dilemma, as this email from Hutchinson tech support illustrates:

  “There’s been much publicity on the fact that only 3 can sign the applications for the commercial units. This is the reason that the competition will be judged on the SDK. The handsets for the top 20 applications entered and judged on the handset will receive a unit that enables the developer to load any application onto the handset. I am currently developing an online signing process to enable you to do this on commercial handsets. The reason for having this security implementation on the handset is that there is no granular security model on OS7 or able to be implemented by Motorola. This creates a risk in that the sensitive API’s such as Phone API and Location API have legal implications. For example the phone API could be used to automatically phone premium rate number.
I am trying to find a solution to this as it restricts development. We’re close but it’s untested currently. I’ll try to get some work around for this week. Sorry I can’t do more than this.”
 


After a certain time period of waiting for the promised solution, we luckily came across a small community of A920 users who had developed a way of manipulating the PC-syncing software that came with the handset so that it could access the entire directory of the phone. This basically enabled us to install our home-cooked applications onto the phone despite the “security policy”.


Just as soon as installation of new software on the handset itself was made possible, another flaw of the A920 became apparent: its AGPS (assisted GPS) has a much slower update frequency than GPS, with new location data being available only about every 5 minutes. This update frequency clearly was too slow for our needs. So after a period of repeated tweaking, testing and giggling we decided to seek out other hardware solutions (overleaf).
The discovery of an online petition to Hutchinson 3G reassured us that we were not alone in having misplaced faith in the capabilities of A920:
(http://www.petitiononline.com/a920/petition.html)

  A call to Hutchinson 3G to open up the Motorola A920, and break down the “walled garden”.
We, the undersigned, petition Hutchinson 3G, with respect to the limited functionality, and plain dis-functionality of the Motorola A920.
Most if not all of the undersigned have bought this phone in the firm belief that it was an advanced mobile phone with Internet, PDA, AGPS, bluetooth and open email functionality. Certainly the phone has been advertised on-line by numerous sites that it will have all the above functionality, only to slowly discover after it was purchased that it had none of these abilities (…)
A conducted survey of Motorola A920 owners particularly speak out, and strongly agree that they would like to see the A920 have:
1.) Full Internet access.
2.) 3rd Party applications to work.
3.) Bluetooth functionality.
4.) Own email address capability.
We request that Hutchinson 3G take this petition into consideration, listen to i’s client base, and open the phone up.
 


We eventually ran TRyPTiCHON with the Palm Tungsten W with added Bluetooth SD card to couple it to a Rikaline Bluetooth GPS unit. This equipment combination has disadvantages: it is quite expensive, voice and GPRS cannot function simultaneously, Bluetooth is unreliable, and the mobile unit consist of two separate boxes; however, it works (!), and the Palm’s battery life is excellent (several days as opposed to the A920’s few hours). A better solution would involve a smaller, more integrated solution (Treo 600 + SD GPS card might be one possibility).