A DISPLAY PROGRAM FOR PALM PDA'S

This section describes a display program written to run on Palm PDA's. ( Portable Digital Assistants ) These are small, handheld computers, about the size of a calculator, with limited capabilities. I am using the Palm model M100, which I bought specifically for this task... I got mine ( new ) for US$150 in October 2000... prices have dropped even lower since then.


Palm M100 PDA's are the most economical version of the Palm series of PDA devices... they all have similar features and use the same "operating system", so this program should run on any of them. Like other Palm devices, the M100 has a built-in serial RS232 port, a 160 x 160 graphical LCD display with electroluminescent ( EL ) backlighting, a piezoacoustic speaker, half a dozen buttons, and a touch - sensitive screen. There is also an infrared serial port, which is not employed in this program, but most of the other features are used.

Palm is a brand name for PDA's... they are ( presently ) the most abundant and popular vareity of PDA's on the market, with a wide range of accessories and options, including modems, "fold-up" keyboards, and wireless links.

Their website address is :

[www.palm.com]


THE DOWNLOADS

The program actually consists of 3 separate files which must be downloaded to the Palm using a special cable and a serial RS232 download program called "hotsync"... hotsync ( and the cable ) are provided with all Palm devices, so if you buy a Palm, you will automatically get them, and several other software applications, as well. If you borrow someone else's Palm to use this program, be aware you will ( minimally ) need the hotsync program ( and the cable ) to install it...

The total size of the downloads is about 170K, which takes about 2 minutes at 14.4K.

Here are the downloads for the three programs :

[PalmDop1] ( 32K )

[NSBRuntime] ( 87K )

[Mathlib] ( 50K )

Here are some NOTEPAD ".txt" files that can also be downloaded, and used with the Windows HYPERTERMINAL utility to generate serial messages for reciept by the Palm device... If you can't figure out how to do this, send me an e-mail and I'll explain it... HYPERTERMINAL is provided with all Windows operating systems, so you should already have it.

( NOTE : There is a chance your web browser will simply display these files on the screen, instead of downloading them and saving them as separate files... if that happens, you will have to "capture" the text manually, and save it yourself as a .txt file )

[TEST1] ( no compass data )

[TEST2] ( with compass data )

The display program is actually a tokenized form of Basic, which requires an interpeter and a math program to run it... that's why 3 files are required, to run it... all 3 programs can be freely distributed.

Mathlib is purely "public domain", and has no special conditions associated with its distribution... you can ( I am told ) learn more about it here :

[www.probe.net/~rhuebnet/mathlib.html]

PalmDop1 is my program, and can be freely distributed PROVIDED THAT no profits are made from it, and I am given due credit as the author... I have posted my call sign on the display, and complete "contact information" on the "sign - on" page, ( where the baud rate is selected ) and that information must remain with the program to fulfill this requirement.

The "runtime" interpeter ( NSBRuntime ) is provided by NSBasic Corporation... I have contacted them, and they have no objections to its free distribution on the web... They produced the development software that I used to write and compile the display code.

Their website address is :

[www.nsbasic.com]

I will provide the source code on request, but you won't be able to do anything with it unless you get NSBasic, which is about US$150... The interpeter provided here only works on "tokenised" code, ( not readable by mere mortals ) which is "compiled" by the NSBasic development program...


THE PROGRAM

The Palm display program is similar in many respects to the IBM PC display program, also posted on this website... I have tried to keep the two programs as similar as possible, but several comprimises were required to make it practical with the ( limited ) capabilities of the Palm device. Still, it's pretty nice, and it provides an economical alternative to purchasing a $1500 portable IBM PC.

If you are not familiar with the IBM PC display program, I suggest you get it and use it, to become familiar with its features and operation... It has a "simulation" mode ( so does the Palm program ) so you can "play" with it and learn about it... I just don't want to repeat all the information here...

If you ARE familiar with it, be aware this Palm program has some differences...

There are 4 screen, total... the first is just some "eye candy", provided to waste your time for about 15 seconds, while the program builds a look-up table of trig values, used by the rest of the program.


The second "sign-on" screen allows you to select a baud rate... the default baud rate is 1200 baud.


The third screen is the main display screen, and it comes up in the "simulate" mode.


I had to "stabilize" the display with true north at the 12 o'clock position of the azimuth scale... there wasn't enough processor speed for me to offer a display with the vehicle heading located at the 12 o'clock position, like the IBM display program... each time the vehicle heading changes ( even one degree ) it would require a complete "re-paint" of the screen, and that takes several seconds, on the Palm. Instead, true north is located at the 12 o'clock position, and the vehicle heading is indicated with a "V bug".

The DF numeric readout is expressed in degrees relative to the vehicle, but the DF "bug" ( indicated by the small circle ) is painted in true degrees, so don't allow this to confuse you.

The fourth screen provides controls for the display... there wasn't room for them on the main display. It can be accessed by tapping the ( touch - sensitive ) main screen, anywhere in the top 25 percent of the screen...


The controls ( on the fourth screen ) are quite small, so it will probably be necessary to use something finer than a fingertip to operate them... the Palm devices include a pen - like "stylus" which is stored in a sleeve located on the device itself, for this purpose.

Most of the controls don't trigger until the pen is lifted from the screen, and that is intended to prevent false triggers... the selected controls are "highlighted" when they are selected, so if you see that the wrong control is highlighted when you touch the screen, you can move the pen and avoid a mistake.

An exception to this is the controls for vehicle heading and magnetic variation, which are repetitive... holding the pen down on these controls will cause the associated values to automatically increment or decrement, as long as the pen is held down...

The HEADING UP and HEADING DOWN buttons operate slightly differently... HEADING UP increments in steps of 10 degrees, but HEADING DOWN decrements in steps of only 1 degree... the "repeat rate" of the buttos was so slow that it would take a long time to enter a 180 degree change with 1 degree increments on both buttons...

Hit RETURN on the control page to return to the display page... it will take about 5 seconds to "re-paint" the display screen, and this is indicated with a two tone ( descending ) "warble", played through the piezo speaker at the start of the "re - paint" process.

Hit EXIT on the control page to terminate the program.

The REDUCE function is identical to the corresponding function on the IBM program... It subtracts 10 percent of the present display range from all vectors, which enhances the differences between them. It can be invoked several times in succession to achieve the desired result, but you must return to the DISPLAY page to view the results.

Unlike the IBM program, the DECAY function is not automatic, and must be manually invoked. It reduces all vectors by 10 per cent.

The SECTOR function is limited to a few different values, and you can "scroll through" them with successive pen strokes... Larger values of SECTOR will slow down the program quite a bit, so they are not very desirable.

SECTOR is also irreversable, ( unlike the original display program ) and cannot be applied to DF vectors that were previously recorded.... their original SECTOR values will remain unchanged, and the new SECTOR value will only apply to vectors stored from that point, onward.

The scale "auto-ranges" up, but ( presently ) does not auto-range "down"... the only way to "down-range" is to clear the display, using CLEAR on the controls page. While it is up-ranging, all the DF vectors are multipled by a specific fraction to re-scale them for the new range... this takes about 5 seconds, and when this begins, an ascending two - tone "warble" is played to indicate the start of the operation. Following this, a descending two - tone "warble" indicates the start of the the screen "re-paint" operation.

When data from the DF is being used as the source, ( as opposed to the simulator ) the piezo speaker will beep ( softly ) once a second with brief ( 1000 Hz ) "beeps", if no data is arriving. When data arrives, this will change to ( loud ) 1500 Hz beeps, which occur once per DF message, which is somewhat faster than once per second, assuming a large value for SECTOR has not been selected.

There are 3 MEMORY slots available on the controls page... if you retrieve one of them, it will automatically turn off acquisition...

If you are using a DF with no compass option, the RS232 message is different from that of a DF with a compass option... If you select the compass input in the display program, but the DF message contains no compass information, the program will not work properly.

REMARKS

This program will be enhanced, but probably not soon... I have too many other tasks that need my attention. I will ( eventually ) try to make it more similar to the IBM program, and I will also "adapt" it for use with a Yagi / compass combination, which is my next project. I will probably have to buy some expensive development software to get maximum speed from the Palm devices, and without that, more features will ( mostly ) slow down the display.

The display update rate is reasonable now, ( slightly faster than once per second ) but it presently takes 6 seconds to "re-paint" a display screen when returning from the CONTROL page, and it takes 11 seconds to "uprange" and re-paint the screen... The simulation mode is deliberately "slowed down" to simulate the ( approximate ) data rate when a real ( DF - generated ) signal is applied.


[HOME PAGE][NEXT PAGE]