Serial (COM) port
COM port is short for a serial communication port. Most serial communication software communicates with a computer through a communication port, and most IBM and IBM-compatible computers support up to four serial ports COM1, COM2, COM3, and COM4. Additional ports can be added by adding additional hardware.
GPS Tracker Data Logger can manipulate with many serial ports at the same time (up to 255 serial ports).
You can open serial ports in GPS Tracker Data Logger software in two modes:
If one or more ports are configured already, then GPS Tracker Data Logger is opening these ports and starting logging. If the port is opened successful, then the status bar in the main window displays a status of this port (fig. 1.1.1). However, before you should configure serial port parameters. The configuration can include one or more serial ports with identical settings. For example, if you have many identical devices, that connected to different serial ports, then you can specify port numbers in one configuration only. However, if you want to use a serial port with different settings, then you should create more than one configuration.
You can create the new configuration by clicking the "Plus" button in the main window (fig. 1.1.1) or through the "Options" menu. After you clicked the "Plus" button, the dialog window will be opened (fig. 2.1.2). The dialog window contains few sections with parameters. The "COM port" section is described in this chapter.
You can manage the configuration created with a drop-down menu near the "Plus" button (fig. 2.1.1).
Fig. 2.1.1 Access to the port configuration
The "COM port settings" tab contains indispensable settings of any serial port: baud rate, data bits, etc. You should configure it with the same values, that your external device uses for data exchange.
Fig. 2.1.2 COM port parameters
If you are logging data over RS-485 with an additional hardware converter and your converter doesn't support data direction auto-detection, then specify "RS485 interface mode". This option instructs GPS Tracker Data Logger to set the RTS line at a low level while data receiving and vice versa. The serial port driver can detect errors while data receiving (for example, bad quality of a connection line). You can specify with the "At data receive error clean incoming buffer" option to ignore data blocks, that contain errors and clean an incoming buffer.
In some cases, the program can't open a serial port while starting (for example, the port is already used by other application). With the "Try to open after an unsuccessful attempt" option you can specify to try to open the serial port again after the interval specified. The program will try to open the serial port until an attempt will succeed.
The Windows communication API provides two methods to check for received data and line/modem status changes: API calls (polling) and an event word. The event word is maintained by the Windows communications driver. As data is received or line/modem status changes occur, the driver sets bits in the event word. The application can check the bits to determine if any communication events occurred. If so, the application can make the appropriate API call to clear the event word and retrieve the data or the new line/modem status values.
Windows also provides API calls to retrieve the same status information provided by the event word but the API calls are slower. GPS Tracker Data Logger uses the event word by default for the fastest possible performance. Unfortunately, there is at least one communication driver (WRPI.DRV, included with some U.S. Robotics modems) that doesn't appear to support the event word. For this and similar drivers, select another mode before GPS Tracker Data Logger will receive data.
If you want to rise data transmit adequacy you can use hardware and/or software data flow control (fig. 2.1.3). When using hardware data flow control are used some lines (wires) of connecting cable. Depending on used lines, you must configure checks against corresponding fields.
Hardware flow control
When the hardware flow control options are an empty, as they are by default, there is no hardware flow control. The options can be combined to enable hardware flow control.
"Receive flow control" stops a remote device from transmitting while the local input buffer is too full. "Transmit flow control" stops the local device from transmitting while the remote input buffer is too full.
Receive flow control is enabled by including the "Use RTS" and/or "Use DTR" elements in the options. When enabled, the corresponding modem control signals (RTS and/or DTR) are lowered when the input buffer reaches the 90% size of the buffer. The remote must recognize these signals and stop sending data while they are held low.
As the application processes received characters, buffer usage eventually drops below the 10% size of the buffer. At that point, the corresponding modem control signals are raised again. The remote must recognize these signals and start sending data again.
Transmit flow control is enabled by including the "Require CTS" and/or "Require DSR" elements in the options. With one or both of these options enabled, the Windows communications driver doesn't transmit data unless the remote device is providing the corresponding modem status signal (CTS and/or DSR). The remote must raise and lower these signals when needed to control the flow of transmitted characters.
Note that flow control using RTS and CTS is much more common than flow control using DTR and DSR.
Software flow control
This routine turns on one or both aspects of automatic software flow control based on the value assigned to the property.
"Receive flow control" stops a remote device from transmitting while the local receive buffer is too full. "Transmit flow control" stops the local device from transmitting while the remote receive buffer is too full.
Receive flow control is enabled by assigning "On receiving" or "Both" to the "Type" property. When enabled, a Xoff character is sent when the input buffer reaches the 10% level of of the buffer size. The remote must recognize this character and stop sending data after it is received.
As the application processes received characters, buffer usage eventually drops below the 10% level of the buffer. At that point, a Xon character is sent. The remote must recognize this character and start sending data again.
Transmit flow control is enabled by assigning "On transmitting" or "Both" to the "Type" property. The 10% and 90% size of the buffer are not used in this case. When transmit flow control is enabled, the communications driver stops transmitting whenever it receives a Xoff character. The driver does not start transmitting again until it receives a Xon character, or the user sets software flow control to "None'.
Software data flow control can be configured on receive, transmit, or both modes, but so as the great number of a device doesn't need data sending, select the "On receive" control mode. In case of activation of data transmit control, a remote object (your device) can send special codes, signalizing about data transmit stop or start. On default, received from device character 0x11 Hex signalizes to COM port driver to start data receive and character 0x13 Hex - to stop data receiving from a device.
Fig. 2.1.3 Data flow control
In this mode, GPS Tracker Data Logger doesn't send and receive any data, and only spies on data exchange, made by other programs. You should enable the "Spy mode" checkbox.
Also, you must start the logger before any other program that can use the selected COM port.
After this, the logger will capture and show data exchange over the selected COM port in the main window.
Note: You must close the program you monitor, before closing GPS Tracker Data Logger.
Line errors can occur during data exchange and displayed in the main program window in the status bar.
UART receiver parity error - occurs if you configured an invalid parity type.
UART receiver overrun,
UART receiver framing error - occurs if you configured an invalid number of stop or data bits.
Transmit timeout waiting for CTS,
Transmit timeout waiting for DSR,
Transmit timeout waiting for RLSD - occurs if you configured invalid hardware flow control, or your serial interface cable isn't wired for hardware flow control.
Transmit queue is full - occurs if GPS Tracker Data Logger can't send data to a remote device.
Break - Break signal is received.
You can also set the program to initiate the serial interface at the specified time. On some old versions of the Windows NT operating system it could help to avoid the loss of data when the program has been working for a long time without restarting. Please use the "Additional options" tab (fig. 2.1.4)
Fig. 2.1.4 Additional options
Here you can also select the terminal emulation mode. In this mode, the program will remove or interpret some special terminal sequences automatically.