The PalmOS display program for the PicoDopp DF is a simplified version of the IBM display program, with many similar features. It provides a powerful visual tool to assist identification of signal direction, especially for weak signals. The visual integration of dozens ( or even hundreds ) of consecutive DF readings allows the user to discern the signal direction with confidence, even when the instantaneous DF display is "dancing wildly" around the dial, apparently at random.

The display is similar to a radar screen, and consists of DF "vectors" that are "painted" at each possible bearing in the azimuth plane. The length of each vector is proportional to the number of DF messages received for that bearing. If no signal is present, then the reported DF bearings will be completely random, yielding a formless, directionless "blob" on the screen. If there is any "non-randomness" in the reported DF bearings, the ( favored ) bearings will eventually "pump up" ( = visual integration ) and reveal themselves as a "lobe" on the display.

The PalmOS PDA program uses the infrared data port ( standard on all PalmOS devices ) to receive data from the PicoDopp DF, yielding a completely cordless / handheld display. The touch-sensitive screen ( also standard on all PalmOS PDAs ) is used to switch from the DISPLAY screen to the CONTROLS screen. Touching the bottom right corner of the DISPLAY screen will clear the display. ( CLR button ) Touching the remaining portion of the DISPLAY screen will cause the program to switch to the CONTROLS screen. On the CONTROLS screen, the user can return to the DISPLAY screen or exit the program using buttons on that screen.

The IR Data Link

One of the best features of this display program is the wireless infrared data link, which provides a handheld / cordless display for the PicoDopp DF. Some older models of PDAs will not work with this data link, so beware when purchasing a used PDA. In particular, PDAs with OS versions earlier than 3.5 will not work, but compatibility with some of the newer OS versions ( 5.0 and above ) have also not yet been experimentally confirmed. Some older models of PDAs can be upgraded to OS3.5 or later, but not all...

To help deal with this issue, the display program has an IR TEST feature, which allows the PDA to generate an artificial PicoDopp IR message. This message can be used to test other PDAs, to ensure "infrared compatibility" before a PDA purchase is made. The IR test message consists of a fixed bearing at 045 degrees, which "paints" at a bearing of 060 due to the 15 degree ( default ) value for magnetic variation.

To use the IR TEST utility, switch to the CONTROLS page and press the IR TEST button... the PDA will then generate a series of beeps, one beep for each IR message sent by the PDA. Directing the IR beam towards another PDA that is running the PicoDopp display program should cause the second PDA display to indicate a DF bearing of 045 on the numeric readout, and "paint" a vector at a bearing of 060. The IR TEST can be aborted by touching any other control ( or the background ) on the CONTROLS page.

If the IR TEST fails to generate a display on the second PDA, the results are inconclusive... it is possible that the first PDA is not TRANSMITTING an IR message, due to a compatibility issue. At this time, ( Aug 2003 ) the following PDAs have been confirmed to work properly :

To fully utilize the ( weak signal ) virtues of this display, the vehicle heading must be ( manually ) updated whenever the vehicle heading changes more than a few degrees. This is necessary because the DF reports bearings in "relative" degrees, ( as do all DFs ) which simply means the 12 o’clock position on the display of a "regular / ordinary" DF always represents the vehicle’s present heading.

If the vehicle changes direction, then the reported DF bearings will also change, by an equal amount in the opposite direction… turning the vehicle 90 degrees left will cause the DF reading to rotate 90 degrees right. This is not a problem for a realtime display, but for a display which integrates hundreds of successive DF readings, such a turn will "invalidate" all the data that was received and integrated into the display, before the turn was executed. ( loss of DF "history" )

To allow for this situation, the display program has manual button inputs ( on the CONTROLS screen ) that allow the user to change the vehicle heading data, to compensate for vehicle turns. Using this feature, DF data that is accumulated before a vehicle turn can be retained and used after the turn.

To use this feature, knowledge of the vehicle’s heading is required, expressed in magnetic or true degrees. This can be obtained from a magnetic compass or a GPS receiver. The precision required for this data can be "compromised" ( to some degree ) by using the SECTOR function, described below.

Maintaining accurate heading data is a "chore". It requires constant vigilance on the part of the DF operator, who must faithfully update the vehicle heading at all times. If the signal is strong enough, the user may simply choose to CLEAR the display instead, ( = erase the old data ) and wait a few seconds to accumulate a "fresh batch" of DF readings, after every turn. The problem can also be mitigated to some degree by choosing a large value for SECTOR. ( described below )

The start up screen runs for a few seconds, building a trig table for use in the display program. When completed, the display switches to the DISPLAY screen, and enters the IR input mode. If no IR signal is present, the display will "beep" ( softly ) about once every 2 seconds, at 1000 Hz. If valid DF data is being received, the display will "beep" ( loudly ) about twice a second, at 1500 Hz.

An image of the display screen is shown below. Due to the limited size of the PDA screen, no controls are directly displayed on the screen, except the CLR button, which clears the display. Tapping anywhere else on the screen will trigger an "invisible" control that will switch the PDA to the CONTROLS page, where most of the controls are actually located.

The readouts in the top left corner indicate the last DF bearing reported by the DF, ( in relative degrees ) and the total number of DF readings obtained ( and displayed ) since the display was last cleared. The last reported DF bearing is also indicated ( graphically ) on the display by a small empty circle, located just outside the azimuth scale. The vehicle heading is indicated ( graphically ) by a small "V", also located just outside the azimuth scale. The numeric value for the vehicle heading is also indicated at the 12 o’clock position of the azimuth scale, ( in reversed video ) along with its source, ( MAN = manual input ) and its "units of measure", expressed either as MAGnetic degrees or TRUe degrees. ( user selectable, on the CONTROLS page )

The top right corner shows the data source, ( IR or SIMulator ) and the current status of ACQUIRE. ( ON or OFF )

The bottom left corner shows the current values for RANGE and SECTOR. RANGE identifies the size of the DF vector that will reach the outside edge of the azimuth scale. For example, if RANGE = 100, then the DF must report a reading 100 times ( on the same bearing ) for the resulting display vector to reach the outside edge of the azimuth scale. SECTOR is expressed in degrees, ranging from 3 to 15, and is explained below.

The program starts up with a selected display range of 25 readings. When a DF vector reaches the edge of the azimuth scale, the program will automatically "uprange" to a scale of 50 readings. This is repeated for ranges of 50, and 100, and the final display range is 200 readings.

If a DF vector ever exceeds 200 readings, the display will NOT automatically "uprange". Instead, it will automatically REDUCE the DF vectors by 50 percent

Each time the program "upranges", the display is cleared and then re-painted with re-scaled DF vectors. This takes a few seconds, and progress is indicated "acoustically" by a descending and an ascending musical scale… The descending scale is played during the vector re-scaling process, and the ascending scale is played during the re-paint process.

An image of the CONTROLS screen is shown below. The present status of all the user-defined values are shown here. Due to space limitations, the controls associated with these values are triggered by invisible buttons that lie directly beneath the displayed values. For example, to change the SECTOR value, the user would touch the PDA stylus to the word SECTOR on the screen. The SECTOR value will increment to the next available value, as a result.

The present stylus "trigger point" is indicated by reversed video, to provide visual feedback to the user about which control is presently selected by the stylus. The actual trigger event does not occur until the stylus is lifted from the screen, so the user can move away from "wrong" selections ( caused by bad aiming ) before lifting the stylus and triggering the event.

There is an exception to this rule, for the HEADING buttons… ( HDG UP and HDG DN ) The HEADING buttons will trigger IMMEDIATELY when pressed by the stylus, and will continue to trigger ( in repetition ) as long as the stylus is down… this allows rapid changes of vehicle heading. Furthermore, the HDG UP button will increment the heading value by ten degrees, but the HDG DN button will only decrement the heading by one degree. This further accelerates the process of heading updates, since vehicle heading changes are usually 90 degrees or more, in size.

There are only three "visible" buttons on the CONTROLS screen, called IR TEST, EXIT and RETURN. The RETURN button will return the PDA to the DISPLAY screen, and the EXIT button will terminate the program. ( These buttons are deliberately small to prevent "accidental" triggering. ) The IR TEST button is used to test IR compatibility of another PDA, by generating an artificial PicoDopp DF message, as explained in an earlier section of this webpage.

The SECTOR function causes each ( received ) DF bearing to be "painted" in adjacent bearings, as well as the proper ( DF - reported ) bearings. SECTOR sets the width of the adjacent bearings that receive this data. For example, if the SECTOR width is set to 12 degrees, and the DF reports a bearing of 037 degrees, the program will "paint" this reading into ALL bearings between 031 and 043 degrees. ( the bearing count for ALL bearings in this sector will be increased by one )

The SECTOR function is useful to enhance the display. For example, a single display vector that is ten units long is much more ( visually ) "obvious" than ten individual ( adjacent ) vectors that are each one unit long, even though all ten adjacent vectors probably originated from a single radio source. SECTOR therefore allows the user to adjust the angular resolution of the DF display.

The SECTOR function can also be used to relax the accuracy requirements for the ( manual ) vehicle heading inputs. For example, by setting the SECTOR value to 15 degrees, the vehicle heading can be entered with less precision, ( within 15 degrees ) without compromising the visual integration of signals.

The SECTOR function is "data-destructive" and irreversible. The original DF data is completely replaced by the new data. If the user wishes to recover the original display, a copy of the data must be made into one of the three memory slots, before using the DECAY function. Due to CPU speed limitations of PDAs, larger values of SECTOR may result in a noticeably slower update rate for the display.

The DECAY function is used to "wash out" old DF data, in a way that simulates an exponential decay. In the IBM display program, this feature ( when enabled ) is automatically performed at user-defined intervals, but the PalmOS display program offers it as a user-triggered function… triggering the DECAY button will reduce all the vector lengths by 10% of their present values. In practice, the button may be triggered several times in succession, to achieve greater reductions.

For example, if a particular display vector = 100, triggering the DECAY button once will reduce the vector length to 90. Triggering it again will reduce it to 81, and again will yield 72. ( 72 = 100 x 0.9 x 0.9 x 0.9 )

The DECAY function is "data-destructive" and irreversible. The original DF data is completely replaced by the new data. If the user wishes to recover the original display, a copy of the data must be made into one of the three memory slots, before using the DECAY function.

The REDUCE function is similar to the DECAY function, except it is manually operated. The REDUCE function also operates differently, because it subtracts a specific number from all DF vectors, instead of multiplying them all by a specific fraction. This tends to enhance the differences between vectors and increase the display clarity, since smaller vectors will suffer a greater "percentage" of reduction than the larger vectors. This is particularly useful when no major lobe can be ( easily ) discerned in the display.

The REDUCE function is manually operated, and usually is repeated several times in succession until the desired clarity is achieved. The amount of reduction for each operation is related to the presently displayed range on the screen. In all cases, it equals ten percent of the presently displayed range. For example, if the present display range is 200, then operating the REDUCE function ( once ) will reduce all the DF vectors by 20 readings.

The REDUCE function is "data-destructive" and irreversible. The original DF data is completely replaced by the new data. If the user wishes to recover the original display, a copy of the data must be made into one of the three memory slots, before invoking the REDUCE function.

The infrared data port on PalmOS PDAs is generally located somewhere on the top edge of the PDA, and it generally "looks forwards" from the PDA, but not always… for example, the IR port on HandSpring Visor Neo PDAs is located on the left underside ( near the top of the PDA ) and it looks outward from the PDA to the left, and slightly down. This bears some consideration when selecting a PDA for a display, since it will determine where the IR diode must be installed, in the vehicle.

Palm products ( and other PDAs that use the public PalmOS ) are constantly evolving and changing, and are vulnerable to the caprices and "fashions" of the commercial marketplace… it is entirely possible ( in the future ) that some particular PDA will not operate properly with this display program, due to hardware differences that are not adequately addressed by the operating system software… The display program should run properly on ANY PDA that uses PalmOS 3.5 or later, but Palm is coming out with a new OS version 5, and several new models of PDAs that do not use Motorola micros, like the original Palm does.

There isn’t much that can be done about this, but any particular PDAs that are incompatible with this display program will be noted, ( when identified ) as well as those that ARE compatible. Inquiries directed to us via e-mail will provide this information. We will do our best to upgrade the display program, ( when required ) to retain compatibility with the widest variety of PDAs.

The PalmOS display program is written in NSBasic 3.0. Source code is available on request, by e-mail. NSBasic is very similar to MicroSoft VisualBasic, but much simpler and with far fewer features. It is available for US$ 150. There is also a fully functional ( but time limited ) version of NSBasic available for download on their website, free of charge :