Projects: TEEMSS2 : SensorPortHelper
This page last changed on Feb 15, 2006 by stepheneb.
SensorPortHelperSensorPortHelper 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 Librariesfrom: http://www.palmos.com/dev/support/docs/palmos40/
|
Document generated by Confluence on Jan 27, 2014 16:43 |