Figure 1: Serial Port Multiplexer for Handspring Visor (example)
GPS4Palm - PalmOS Mapping GPS Application * displays GPS information * displays current position on map * automatic/manual map selection * automatic map download from internet using external application FetchMap * navigation to selected waypoint * navigation along a route * track logging * waypoint, route, and track data exchange with host Copyright (c)01/2003 M.Prinke <matthias.prinke(...)surfeu.de> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Please do not use this program for navigation!
See GNU GENERAL PUBLIC LICENSE for complete license.
| Specs | |
|---|---|
| Name | GPS4Palm |
| Version | 0.9.4 beta |
| Creator ID | Gps4 |
| Size | 145KB |
| Palm OS | >=3.0 |
| Libraries | MathLib, ZLib, gpslib |
| Misc | required: GPS Receiver opt.: FetchMap (Application), Serial Port Multiplexer (Hardware), GPSMan (PC Application) |
Example:
/dev/ttyS0 on Linux / COM1: on Windows)
The Perl/Tk application [NMEA-Sim] allows to simulate a GPS receiver. It sends NMEA messages to the specified PC serial port. Connecting this serial port to the serial port used by POSE with a null-modem cable allows to receive the NMEA messages in GPS4Palm.
The Linux tool [ttypatch] provides a very convenient replacement for the null-modem cable. See ttypatch documentation for additional features. (Unfortunately, for Windows only a commercial tool seems to exist.)
Example:
ttypatch (in its default configuration, it provides a
virtual connection between /dev/ttyp0 and /dev/ttyp1)
/dev/ttyp1
nmea_sim.pl --port /dev/ttyp0
To check the serial connection to the PDA, the Terminal Emulator mode of the PalmOS application [ptelnet] can be very helpful. [NMEA Mon] allows to Monitor the data (NMEA messages) sent by the GPS receiver.
The article Daten von Bluetooth GPS-Maus auslesen decribes
how to connect a Linux PC with a Bluetooth USB dongle to a Bluetooth GPS
receiver. The GPS data can then be read from a virtual serial port
(e.g. /dev/rfcomm0).
-D<sermux_option> in the CFLAGS option of the
Makefile.<sermux_option>.SERMUX_PALMIII_RTS | Palm III RTS Pin (not tested thoroughly, now obsolete) |
SERMUX_VISOR_HS | Handspring Visor Hotsync Pin |
SERMUX_VISOR_KBD | Handspring Visor Keyboard Pin |
| Pin | Resistor | I/O Port | Bit |
|---|---|---|---|
| /HS1 (Hotsync) | 100R | Port D | 4 |
| /KBD (Keyboard) | 330R | Port E | 7 |
With this information (and the help of the [Motorola
Dragonball User Manual]), the multiplexer control functions sermux_enable()
and sermux_select() in Utils.c have been implemented.
Care has to be taken regarding the voltage levels of all interfaces involved.
The schematic in figure 1 shows a multiplexer circuit. In this example, the GPS
receiver provides an output level slightly lower than the power supply (VCC).
The GSM phone is attached using an adaptor cable with an interface logic
similar to the circuit implemented with Q1/Q2 (see below). The Visor provides
3.3V logic levels and is attached without further interface logic to the
circuit shown below. One drawback of this circuit is that a 5V power supply is
required.
Figure 2 shows an improved version of the multiplexer circuit. The 74VHCXXX series is ideal for interface circuits like this, because input voltages may even exceed VCC! Please refer to the 74VHC157 datasheet and your GPS receiver's datasheet for the actual supply voltage range. Since my GPS mouse already works with 3.8V, I can use 4 NiCd batteries as power supply.
Note:
The solutions described above are specific to the Handspring Visor
Deluxe. As far as I know, some Palm PDAs use internal level shifting circuits to
generate true RS-232 voltage levels on the serial interface. Any information
regarding other PDAs such as
| Signal Name | Function |
|---|---|
| SG | Signal Ground |
| RXD (in) | Receive Data |
| TXD (out) | Transmit Data |
| CTS (in) | Clear To Send (Hardware Flow Control Handshake) |
| RTS (out) | Request To Send (Hardware Flow Control Handshake) |
| DTR | Data Terminal Ready |
See [Hardware Connection Diagrams] for the following documents:
The DTR signal would be the ideal choice for controlling the multiplexer,
because it is not required for Hardware Flow Control. The New Serial Manager
Feature Set of the Serial Manager API provides the control code
srmCtlSetDTRAsserted for the function SrmControl() to
assert/deassert the DTR pin. However, according to the PalmOS Programmer's
API Reference (SDK-4): "This is not supported by all hardware."
On a Tungsten T3, the function call
returns the error code
err = SrmControl(gPortID, srmCtlSetDTRAsserted, &value, &valueLen);
serErrNotSupported.
This leaves the RTS signal for controlling the multiplexer, provided that
RTS/CTS Hardware Flow Control is not required. For the GPS receiver with a data
rate of 4800 baud this is the case. For the network connection (e.g. over a GSM
phone), this might restrict the possible baud rate to a low value to prevent
receive FIFO overflows.
The Serial Manager API function SrmControl() allows to disable
hardware flow control and to control RTS by software.
Note: Due to a bug in the Serial Port Driver of PalmOS V5.2.1 on the Palm
Tungsten T3, serial communications without hardware flow control seems not to
work on this PDA. (see GPilotS Bugs page for a short note)
As a workaround, it is proposed to connect the RTS and CTS signals of the
Tungsten T3, however this conflicts with the usage of RTS for controlling the
multiplexer.
PalmOne did not
provide a patch yet, but a commercial bug fix
SerialFix by Larson Computing is available.
The application note [Multiplexer Enables Pseudomultidrop RS-232 Transmission] describes a 4-to-1 multiplexer for RS-232 signals (true RS-232 signal levels). Even if reduced to a 2-to-1 multiplexer, the hardware effort is relatively high. Other proposals are welcome.
gPrefs.mapprefs.select:
gPrefs.mapprefs.fetch:
gPrefs.mapprefs.download:
gPrefs.mapprefs.select == SEL_USER)
gPrefs.mapprefs.select == SEL_AUTO)
gPrefs.mapprefs.select == SEL_AUTO)
unused has been ommitted.
cmnt (comment) has been moved to the end of the
structure and is packed.
The resulting datatype is:
Each waypoint record requires 22..61 bytes. The Waypoint Database has the name
"Waypoints-Gps4" and the type 'WAYP'. The waypoint records are sorted
alphanumerically within the database according to their identifier.
typedef struct {
char ident[6]; /* identifier (string) */
Semicircle_Type posn; /* position */
float dst; /* proximity distance (meters) */
Symbol_Type smbl; /* symbol ID */
byte dspl; /* display option */
char cmnt[1]; /* comment, actually may be */
/* longer than 1, but no more */
/* than 40 */
/* (including null terminator) */
} packed_waypoint_t;
items provides the number of waypoints contained in
the route.
wpt_rec_id stores the internal unique waypoint record
ID for each route waypoint.
The resulting datatype is:
Each route requires 24 bytes for the header plus 4 bytes for each route
waypoint. The Route Database has the name "Routes-Gps4" and the type 'ROUT'. The
route records are sorted within the database according to the route number.
typedef struct {
G_byte nmbr; /* route number */
G_char cmnt[21]; /* comment */
UInt16 items; /* number of waypoints on route */
UInt32 wpt_rec_id[1]; /* array of waypoint record IDs, */
/* actually may be longer than 1 */
} route_t;
The track header record datatype is:
Currently
typedef struct
{
G_boolean dspl; /* display on the map? */
G_byte color; /* color (same as D108) */
G_char trk_ident[50]; /* null-terminated string */
}
D310_Trk_Hdr_Type;
trkhdr.dspl is set to true and
trkhdr.color is set to Default_Color upon creation of
a new route. The Track Header Database has the name "Trkheaders-Gps4" and the
type 'TRKH'.
The track points are stored in a separate database for each track. The Track Point Databases have the naming scheme "Trkpoints-Gps4-xxxxxx", where "xxxxxx" is the 3-byte unique record ID (hex; 0..9,A..F) of the associated track header. The Track Point Database type is 'TRKP'.
The GPS4Palm track point database format stores the track points according to the D300_Trk_Point_Type described in the [GARMIN GPS Interface Specification]. The maximum number of track points per track is 65535 (maximum number of records per PalmOS database).
Each track header requires 52 bytes, eack track point requires 13 bytes.
Note:
Exchange of track header information with the host is currently not
supported.
GPS product ID: 72 Software version: 100 Product description: GPilotS managerCurrently only the following exchange protocols/data types have been implemented:
Have a look at my homepage for updates and other interesting things. For comments or suggestions send me an email.
http://members.surfeu.de/matthias.prinke/gps4palm_e.html| created: | 2004/01/03 17:45:00 |
| last update: | $Date: 2005-05-28 10:19:15 $ |
| $Revision: 1.18 $ |