(only available for certain terminals with a sutable serial aynchronous interface, and a special firmware)
This document describes how the terminal's asynchronous serial interface can be used to receive position data from an external GPS receiver. Inside the terminal, the received (and decoded) data can be accessed through the interpreter.
Note: Only a few terminals support this optional function - see Feature Matrix : "GPS decoder" !
This feature must be unlocked (by the manufacturer, or via password) before using it .
Note: The GPS/NMEA decoder inside the terminal is an optional feature,
which must be unlocked to use it. You can use this function for
testing purposes (before paying for it) in "evaluation mode". In evaluation
mode, the position returned by the NMEA decoder will jump around the true
position by a few hundred meters. This is not a bug, but a motivation to
contact the manufacturer to have this feature unlocked.
The general feature unlocking procedure is described here.
In the simulator (i.e. in the programming tool), NMEA strings received from a serial port is always possible. Connect a suitable GPS mouse (which sends NMEA strings) to your PC, and select its COM port number on the programming tool's Settings tab. After issuing the command gps.prot="NMEA", the programming tool 'connects' the serial port to the GPS decoder, and you can process the GPS data in the simulator just as on the target device. A simple adapter between GPS-mouse and the PC's serial port may be required, because a standard RS-232 port doesn't have the necessary 5- or 12-Volt supply for the receiver.
None/Off: There is no GPS receiver installed on the system, and the firmware must not occupy the 'GPS' port.
NMEA 4k8: A standard NMEA-0183 receiver with 4800 bits/second serial output
NMEA 9k6: An NMEA receiver with 9600 bits/second serial output. This baudrate does NOT match the NMEA-0183 standard but is frequently used.
NMEA 19k2: An NMEA receiver with 19200 bits/second serial output
"4-Hz"-mouse: A proprietary receiver which is should report 4 positions per second (but sometimes failed to do so)
"10-Hz"-mouse: An exotic receiver which should have reported 10 positions per second (but never worked properly)
@gps.baud=4800sets the baudrate of the serial port to 4800 bit/sec (this is what most GPS receivers use by default).
gps.pos( <latitude>, <longitude>)
proc OnLocationChanged() // Called whenever the GPS has reported a new location local tCANmsg msg; // 'hard-wired' transmission of GPS data to the CAN bus: msg.id := 0x501; // CAN message id for 1st part of the GPS data msg.len := 8; // data length code (number of data bytes) msg.f64 := gps.lon_d; // longitude in degrees as 64-bit 'double' can_transmit( msg ); // send CAN message msg.id := 0x502; // CAN message id for 2nd part of the GPS data msg.len := 8; // data length code (number of data bytes) msg.f64 := gps.lat_d; // latitude in degrees as 64-bit 'double' can_transmit( msg ); // send CAN message msg.id := 0x503; // CAN message id for 3rd part of the GPS data msg.len := 8; // data length code (number of data bytes) msg.f64 := gps.unix_time; // seconds since 1970-01-01 00:00:00.0 UTC can_transmit( msg ); // send CAN message // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Alternative: Copy GPS data into *display variables* (below) // and let the system (firmware) do the rest, i.e. map to CAN. // Those signals have been declared as 'transmit signals' when // importing the CAN database (*.dbc) in the programming tool. // (source : programs/GPS_to_CAN.dbc) . // If the variable's "update time" (transmit interval) is set // to ZERO (on the variable definition tab), the CAN message // will be sent 'event-driven' by the firmware, e.g. "if a value // was modified". Thus, the CAN messages with the following // display variables will be transmitted at the same rate as the // GPS receiver emits '$GPRMC' or '$GPGGA' sentences. // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - display.GpsLat := gps.lat_d; // latitude in degrees display.GpsLon := gps.lon_d; // longitude in degrees display.GpsTime := gps.time; // number of seconds since midnight display.GpsDate := gps.mjd - 40587; // number of DAYS since Unix was born display.GpsSpeed := gps.speed; // speed in km/h (!) display.GpsHeight := gps.hasl; // height above sea level in meters display.GpsUnixSeconds := gps.unix_time + 0.0001; // 64-bit 'double', // with 0.1 milliseconds added to check resolution of the CAN signal endproc; // OnLocationChanged
Note: This is NOT a replacement for a nice graphic GPS display. It was designed for a quick test of the GPS receiver, without having to load a special test application into the terminal.
To start the GPS test, enter the terminal's system menu, then select "System
Test" ... "GPS Receiver". If the receiver is not initialized yet (by the
application), select the init function from the test menu. The current position
(lat + lon in degrees, minutes, seconds), date+time in UTC, speed in km/h,
height above sea level in meters, number of satellites in view, and the HDOP
value will be displayed on the screen:
(Built-in GPS receiver test, here in an MKT-View IV)
A more comprehensive GPS test can be performed with the GPS sample application - see appendix .
Hint: For testing, you can also connect the GPS receiver directly to the PC. The programming tool emulates the entire device firmware, including the parser for NMEA sentences. Furthermore, the raw NMEA sentences ($GPRMC, $GPGGA, ..) can be displayed on the programming tool's 'Errors & Messages' tab (if the port is assigned to GPS, i.e. after setting gps.prot="NMEA"). To show the raw NMEA sentences, check 'Enable messages from ...' / 'Other protocols'.
Some of the GPS-related interpreter functions use latitude and longitude in the internal format, which uses 32-bit integer values (no floating point!). The unit for lat+lon is one hundredth of an arcsecond (*). Furthermore,
To retrieve the present coordinate in this format, use the functions gps.lat and gps.lon .
(*) Note on resolution vs accuracy: 0.01 arc seconds correspond with a spatial resolution of about 30 cm on the earth's surface, which exceeds the accuracy of most civilian GPS receivers.
There is a small test file for the MKT-View which demonstrates some of the NMEA-decoder functions. You can load it from \programs\GPS_test.cvt .
On this screen of the test application, the most important interpreter functions for the GPS / NMEA0183 decoder are displayed, along with the results when testing the decoder with a GPS receiver in front of the author's office window.
Note that the "gps.rbuf" does not contain a complete NMEA sentence in this screenshot yet. This is not an error - it's the purpose of the "gps.rbuf"-function : Take a look at the received characters before the sentence is complete. The last completely received NMEA sentence is displayed by "gps.rstr".
The GPS receiver parameters (baudrate and protocol) are set in the display page's "page-enter"-event, so they will be executed once when the display page is invoked. In a real-world application, you should do this on page zero of your display application.
Besides displaying the current GPS data, the demo application (gps_test.cvt) also sends some data via CAN-Bus (position, time of day, date, GPS speed, height above sea level). Other CAN-nodes may receive and display/log/process those data, as shown in application programs/GPS_from_CAN.cvt (also contained in the installation archive).
As usual, the message structure is defined in a database for CAN (programs/GPS_to_CAN.dbc). The self-defined GPS data signals on CAN (GpsLat, GpsLon, GpsTime, GpsDate, GpsSpeed, GpsHeight) were imported into gps_test.cvt and declared as transmit-signals; in gps_from_CAN.cvt the same signals were imported as receive-signals.
Details about sending signals defined in a database for CAN (*.dbc) can be found here.
Of course, the structure of the messages sent by this 'GPS→CAN-Gateway' can be tailored for your own needs. We suggest to use a DBC editor for this purpose, for example Kvaser's (Kvaser Database Editor).
Originally, the serial port was exclusively used to download the terminal application ("user program") through the PC's RS-232 interface. Since the serial port may now be occupied by the GPS receiver, the terminal cannot (always) listen for commands from the PC. Why ?
The program download between PC and Terminal uses a block-oriented protocol for the serial port called "3964R". When you select "Send application to the terminal through the serial port", but the serial port is occupied by the application (as described in this document), the 3964R-handler may be passive to avoid interference with the protocol which your terminal-application uses (through appropriate interpreter commands). The PC will therefore never receive the expected response from the terminal .... and your terminal application will, at least, be "irritated" by the characters received from the serial port.
So what to do in this case, when your application occupies the terminal's serial port, but you want to download a new application through just this port ? The solution is:
The terminal will reprogram the serial port for communication with the PC in this case, which includes the initialisation of the 3964R-protocol.
If the serial port is not occupied by the terminal-application or the GPS-decoder (which is the default, see gps.prot), you don't necessarily have to use the system menu to activate the download.
Related subject: Command gps.prot="NMEA" to 'occupy' the serial port for the GPS receiver
Author: W.Büscher, MKT Systemtechnik
Last modified: 2017-08-15 (ISO8601, YYYY-MM-DD)
back to top