This page last changed on Feb 15, 2006 by stepheneb.

SensorPortHelper

SensorPortHelper will be an updated and expanded version of CCBeam for the TEEMSS2 Project SuperWaba program SensorPort. As a SuperWaba program SensorPort lacks access to some native features. SensorPortHelper will in effect be a proxy for these services for SensorPort.

CCBeam was the helper program for CCProbe the first version of SensorPort developed for the first TEEMSS project. The source code for CCBeam and the rest of the older CCProbe software is available here: CCProbe source. There is an architectural description of CCProbe here. Much of this still applies to SensorPort.

SensorPort is a handeld version of the desktop Java application SensorPortfolio. SensorPort is a SuperWaba application that compiled with an updated version of the SuperWabaJump Toolkit and is deployed on PalmOS 5.x devices with high-resolution screens (320x320 or greater). We used an older version of SuperWaba (version 4) that is compatible with SuperWabaJump.

These systems include:

Model           PalmOS      IrDA    Bluetooth   Wi-Fi
----------------------------------------------------------
Zire 71         5.2.1       yes     no          no
Zire 72         5.2.8       yes     yes         no
Tungsten T      5           yes     yes         no
Tungsten T2     5.2         yes     yes         no
Tungsten C      5.2.1       yes     no          yes
Tungsten E      5.2.1       yes     no          no
Tungsten E2     5.4         yes     yes         no
Tungsten T3     5.2         yes     yes         no
Tungsten T5     5.4         yes     yes         no
Treo 650        5.4         yes     yes         no
Palm TX         5.4.9       yes     yes         yes

SensorPortHelper Functionality:

1) Beaming and Sending SensorPort Databases

SensorPort needs a helper application to be able to beam or send both LabBook objects and also entire LabBooks from one Palm to another. This functionality is very similar to that in the existing CCBeam. SensorPortHelper will accept databases from SensorPort and either beam or send them using the standard PalmOS native interfaces to another Palm with SensorPortHelper installed. SensorPortHelper will also receive incoming beams of SensorPort objects and transfer them to SensorPort.

Beaming consists of IrDA communication while sending usually refers to other methods such as Bluetooth.

PalmOS 4.0 changed the way the Exchange Manager worked which is probably while CCBeam does not currently work with newer PalmOS devices.

http://www.palmos.com/dev/support/docs/palmos/PalmOSCompanion2/ExchangeManagerConcept.html#996099

I'd like to know whether it is practical to compress large databases before sending them? The SensorPort LabBooks are approaching 4MB in size and consist of easily compressed data (typical compression = 35%). It can take more than 5 minutes to beam a LabBook! The webclipping library in palmos 4.0 has lz77 compression built-in but this feature does not seem to be exposed. If we can always guarantee that there will be memory available SensorPortHelper could make a compressed copy of the database before sending it and do the reverse on receiving a compressed database. It may be possible to use a streaming compression algorithm with the callback function but that sounds harder.

There is an open source Palm library for zlib compression optimized for ARM processors (works with palmos 5):

zlib ARMlet Port: http://www.copera.com/zlib-armlet/

2) Interface with the native PalmOS Alarm Manager to support scheduled data logging from sleep.

In order to do DataLogging on the Palm we need a native program that sets a wakeup alarm and puts the Palm to sleep. When the alarm wakes up the Palm the PalmOS calls back into the native program that set the alarm. We cannot do this from a Waba program so we will add this to SensorPortHelper. When SensorPortHelper gets the wake-up call it can launch SensorPort and have it collect a set of data samples after which the Palm will go back to sleep.

SensorPortHelper will need to handle both initiation of this service as well as discontinuation in addition to the Alarm Manager proxy services it provides during the datalogging.

Alarm Manager: http://www.palmos.com/dev/support/docs/palmos/PalmOSCompanion/AttnsAndAlarms.html#1042539

From SensorPort we will setup a datalogging wakeup time and pass that off to SensorPortHelper. SensorPortHelper will either register itself or register a function with the Alarm Manager with the wakeup time and pass control back to SensorPort.

After finishing use of of SensorPort the user will normally put the Palm to sleep.

When the alarm condition occurs SensorPortHelper will be called and it will then launch SensorPort and ask it to complete whatever datalogging operation it has setup. SensorPort will collect and store the probe data and launch SensorPortHelper with a new wake up time. SensorPortHelper will create a new Alarm condition and put the Palm to sleep. If SensorPort either has an error communicating with the probeware interface or it completes the final collection sample for that datalogging experiment it will return to SensorPortHelper where SensorPortHelper will either put the Palm to sleep or return to whatever other program was operating when the Alarm when off.

There is the complication of how to manage this process when the Palm is awake and either running SensorPort or another application. If practical in either case it would be good to save the state of the running app, run SensorPortHelper, run SensorPort (without changing the saved state of SensorPort if possible) to collect the data, return to SensorPortHelper and return to the original application.

It could be simpler with a separate SuperWaba application just for collecting datalogging data that won't conflict with SensorPort. The only conflict would then be if the user was already collecting data at the time the alarm went off.

Exchange Manager and Exchange Libraries

from: http://www.palmos.com/dev/support/docs/palmos40/

The Exchange Manager has been modified to handle multiple Exchange Libraries above and beyond just IR. Exchange Libraries can be registered with the Exchange Manager, which provides both a central API for developers as well as a standard UI for users to pick which library they want to use.

Exchange Libraries are Palm shared libraries and are defined in the ExgLib.h header file. They are registered for the appropriate schemes, provide UI for addressing information, progress, errors, etc., and handle the actual sending and receiving of data. In OS 4.0 there is a "send" scheme defined; applications can send to the system's default send mechanism by using this in the name field of their ExgSocketType structure. Further, the Exchange Manager will popup UI with all options registered for the "_send" scheme if you precede the name with a "?". In addition to "_send", libraries should register for a second scheme that is unique to your application (we recommend "" followed by your creator ID) . This allows you or another developer to default to your library by choosing your unique scheme.

An example of the UI associated with the Exchange Manager is found in the Palm PIM applications that now use both a "beam" option and a "send" option for transmitting data. "Beam" still denotes sending via IR, while "Send" allows the user to pick from a list of all the exchange libraries registered for the send scheme. For this example, the "Beam" option uses "_beam" as a scheme, while the "Send" option uses "?_send" to pop up the UI and allow the user to pick from everything registered for "_send".

The above means that there is very little modification needed to extend an application that already "Beams" via the Exchange Manager, to send via SMS, Bluetooth or any other exchange transport available on the device. On the flip side, when you register to receive data, this data can be received via any exchange transport. Your application need not do anything special.

Applications can also register for schemes through the Exchange Manager. An example of this would be the "http" scheme for applications that display web content. In this case you could also just handle the launch command sent out in response to this scheme.

Bluetooth

Bluetooth is not an intrinsic part of Palm OS 4.0 but the OS is Bluetooth-aware such that when the Bluetooth libraries are loaded, the connection panel, Exchange Manager, HotSync, etc. will magically know what to do with them. For more information about Bluetooth and how you can start developing early, see the Bluetooth technology page.

Some places the word "call" is used when then word "launch" would be more clear. Whenever one palm app starts another it is called launching. So SensorPortHelp launches SensorPort not calls it.

It might not be possible for SensorPort to return to SensorPortHelper, because SensorPort is a large gui application. I don't know that for sure but I wouldn't count on it working. So in the case where an alarm goes off, SPH (sensorporthelper) launches SP (spensor port), then SP has an error. In that case SP might not be able to return to SPH. If SPH needs to do something SP can just launch it again.

This is a good summary of what needs to be done. It might be worth while to plan out the same thing for the pocketpc. Then perhaps the same SensorPort code for working with the helper application can be used.

Posted by scytacki at Feb 03, 2006 11:13
Document generated by Confluence on Jan 27, 2014 16:43