| 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).