GPSPATRON

Document ver. 1.0

TABLE OF CONTENTS

• 1. Introduction
• 2. Physical Interface Overview
• 3. Device Behavior When Connected to a USB Host
  • 3.1 Charging Mode Before the First Command
  • 3.2 Switching to External API Control Mode
• 4. General Packet Format
  • 4.1 ASCII Command Format
  • 4.2 Binary Packet Format
• 5. Basic Integration Workflow
• 6. Basic Command Reference
  • 6.1 Device Identification Command (GET_IDN)
  • 6.2 Start Data Stream Command (START_STREAM)
  • 6.2.1. Measurement Data Frames
  • 6.3 Stop Data Stream Command (STOP_STREAM)
• 7. Conclusion: Basic Integration Procedure

1. Introduction

GP-Probe NANO L1 is a compact GNSS L1-band interference detector designed to continuously measure RF power and notify the user when the measured power exceeds a configured interference detection threshold.

The device periodically measures the RF power level within the monitored GNSS frequency band. The measurement rate depends on the active operating mode:

• in autonomous modes, measurements may be performed once per second;

• when the device is connected to a host through USB and operates in streaming mode, measurement data is provided up to 10 times per second.

For each measurement, the device compares the detected RF power against the configured threshold. When the threshold is exceeded, the device identifies a potential interference event and can notify the user through its built-in visual, audible, and vibration indicators.

In addition to its standalone operation, GP-Probe NANO L1 can provide real-time RF power measurements to an external application. This allows the detector to be integrated into custom monitoring software, mobile applications, data acquisition systems, or third-party interference detection platforms.

This guide describes how to communicate directly with GP-Probe NANO L1, including:

• physical connection to the device;

• USB-to-UART interface parameters;

• serial communication settings;

• supported commands;

• command response formats;

• real-time measurement data streaming.

2. Physical Interface Overview

GP-Probe NANO L1 is equipped with a USB Type-C male connector. The USB interface is implemented using an integrated Silicon Labs CP2102N USB-to-UART bridge.

When the detector is connected to a computer, smartphone, embedded controller, or another compatible USB host, it is recognized as a Virtual COM Port. Applications can communicate with the device by opening this serial port and exchanging commands using the protocol described in the following sections.

USB Driver Installation

A compatible Silicon Labs CP210x Virtual COM Port (VCP) driver must be available on the host system. The VCP driver allows the operating system and application software to access the GP-Probe NANO L1 as a standard serial port.

Official CP210x VCP driver packages and installation resources are available for Windows, macOS, Linux, and Android on the Silicon Labs website. Linux support may already be included in the operating system kernel, depending on the distribution and kernel version.

Download Silicon Labs CP210x USB-to-UART VCP Drivers

After installing the required driver and connecting the device, identify the serial port assigned to the GP-Probe NANO L1:

• Windows: a COM port, for example COM5;

• Linux: typically /dev/ttyUSB0 or a similar device;

• macOS: typically /dev/cu.SLAB_USBtoUART or a similar device.

The exact port name may vary depending on the operating system and the number of connected serial devices.

Default Serial Port Parameters

The host application must enable RTS/CTS hardware flow control before initiating communication with the device.

Physical Device Connection

The device uses a USB Type-C connector. Standard USB Type-C connectors are relatively delicate and do not provide the mechanical retention normally expected in industrial installations.

For this reason, GPSPATRON provides a dedicated protective cable cap and retention accessory. It secures the USB cable and protects the connector against:

• accidental pulling or disconnection;
• vibration;
• mechanical stress;
• impacts and movement of the cable;
• damage caused by repeated handling.

The protective cap should be installed whenever the device is used in a permanent, unattended, mobile, or industrial installation.

Detailed installation instructions are available here:

https://support.gpspatron.com/en/support/solutions/articles/101000562678-protective-cap-for-gp-probe-nano

3. Device Behavior When Connected to a USB Host

When GP-Probe NANO L1 is connected to a powered USB port, its behavior depends on whether a command has already been received from the host.

3.1 Charging Mode Before the First Command

Immediately after the device is connected to a USB charger, computer, smartphone, or another powered USB host, it initially operates in charging mode.

At this stage:

• the internal battery is charged automatically;

• no communication command is required to start charging;

• the LED scale displays the current battery charge level.

This charging behavior is controlled by the device hardware and is activated whenever USB power is present.

Therefore, connecting the device to a computer does not immediately place it into external-control mode. Until the first command is received, the device behaves in the same way as when connected to a standard USB charger.

3.2 Switching to External API Control Mode

As soon as the device receives the first command through the communication interface, it automatically switches to external API control mode.

No separate command is required to activate this mode.

After switching to external API control mode:

• audible notifications are disabled;

• vibration notifications are disabled;

• all other autonomous interference notifications are disabled;

• the LED scale no longer displays the battery charge level;

• the LED scale displays the currently measured RF power level.

The number of illuminated LEDs increases as the measured RF power increases. A lower measured power level is represented by fewer illuminated LEDs, while a higher power level is represented by more illuminated LEDs.

The device continues to perform RF power measurements, but notification handling and any required response logic must be implemented by the connected host application.

4. General Packet Format

The GP-Probe communication interface uses a mixed ASCII and binary protocol.

This approach simplifies device discovery, manual testing, and debugging while retaining a structured binary format for parameter transfer.

The protocol defines three main command classes:

1. Control commands — used to start, stop, enable, or disable device functions.
2. Setter commands — used to modify device parameters.
3. Getter commands — used to request device parameters or data.

Most control commands are transmitted as plain ASCII command strings. Setter and getter commands are normally transmitted as structured binary packets.

Some discovery commands, such as GET_IDN, also use the ASCII command format to simplify initial device detection and communication verification.

4.1 ASCII Command Format

ASCII commands are transmitted from the host to the device as exact character sequences.

Examples include:

• GET_IDN
• START_STREAM
• STOP_STREAM

ASCII commands have the following properties:

• the command is transmitted as plain ASCII characters;
• The host must not append CR, LF, CRLF, or a null terminator unless explicitly stated in the corresponding command description. 

For example, the START_STREAM command must be transmitted as the following exact byte sequence: 

53 54 41 52 54 5F 53 54 52 45 41 4D

4.2 Binary Packet Format

Setter commands, getter commands, and command responses are generally transmitted using the binary packet format described below.

Each binary packet must follow this structure:

Packet Structure

The protocol uses the CRC16-Modbus checksum algorithm.
All multi-byte numeric values are transmitted in little-endian format, with the least significant byte transmitted first.

CRC16 Checksum

Binary packets use the CRC16-Modbus checksum algorithm.

The resulting 16-bit checksum is split into two bytes and transmitted in little-endian order:

1. CRC16 Low Byte
2. CRC16 High Byte

For example, if the calculated CRC16 value is:

0x1234

the checksum bytes must be transmitted as:

0x34 0x12

The CRC requirement applies to binary command packets and to binary response frames that explicitly contain CRC fields.

Some short acknowledgment frames may use the simplified structure defined in the corresponding command description. Therefore, the host application must follow the exact frame definition provided for each individual command.

5. Basic Integration Workflow

The device supports an extensive set of commands, operating modes, and configurable parameters. However, most of these functions are not required for basic third-party integration.

To simplify integration, this document describes only a small subset of essential commands required to:

• verify communication with the device;
• start and stop measurement streaming;
• receive measured RF power values;
• process these values in the host application.

The basic integration model is intentionally simple: the device continuously measures RF power and sends the measurement data to the host. The host application is responsible for analyzing the received values, comparing them against application-specific thresholds, and performing any further actions required by the integrated system.

Integration Sequence Summary

The complete basic integration sequence is shown below:

1. Physically connect the device using the USB cable.

2. Install the required CP210x Virtual COM Port driver.

3. Identify and open the assigned Virtual COM Port.

4. Send GET_IDN.

5. Receive and validate the device identification response.

6. Send START_STREAM.

7. Receive measurement packets every 100 ms.

8. Extract the measured RF power values.

9. Compare the values against host-defined thresholds.

10. Perform the required application-specific actions.

11. Send STOP_STREAM when continuous measurements are no longer required.

The following sections provide detailed descriptions of each command, including the host request format, device response format, payload structure, and communication examples.

6. Basic Command Reference

This section describes the basic commands required for device discovery and measurement-stream control. These commands are sufficient for a typical integration in which the host verifies the connected device, starts receiving RF power measurements, and stops the stream when it is no longer required.

6.1 Device Identification Command (GET_IDN)

The GET_IDN command is used for:

• initial device discovery on the serial interface;

• verification that the host is communicating with a compatible GPSPATRON device;

• reading the unique device identifier;

• identifying the device model;

• checking the installed firmware version.

This command should normally be sent immediately after the host opens the Virtual COM Port.

Host Request

The host sends the following exact ASCII string:

GET_IDN

No carriage return, line feed, null terminator, or other end-of-line character is required.

The corresponding hexadecimal byte sequence is:

47 45 54 5F 49 44 4E

Device Response

The device returns a binary identification frame containing the device UID, manufacturer identifier, model code, and firmware version.

The complete response frame has a fixed length of 24 bytes.

Response Frame Structure

Example

ASCII view:

2026-07-15 11:47:22.831
GET_IDN

2026-07-15 11:47:22.834
@@@&...GPSPATROND...???

Hexadecimal view:

2026-07-15 11:47:22.831
47 45 54 5F 49 44 4E


2026-07-15 11:47:22.834
40 40 40 26 1A 06 56 3A 47 50 53 50 41 54 52 4F 4E 44 1E A5 A8 3F 3F 3F

6.2 Start Data Stream Command (START_STREAM)

The START_STREAM command starts continuous transmission of measurement data from the device to the host.

After the command has been accepted, the device transmits one measurement frame every 100 ms, corresponding to a data rate of 10 frames per second.

This command is intended for use through the host communication interface after the Virtual COM Port has been opened and communication with the device has been verified.

Host Request

The host sends the following exact ASCII string:

START_STREAM

No carriage return, line feed, null terminator, or other end-of-line character is required.

The corresponding hexadecimal byte sequence is:

53 54 41 52 54 5F 53 54 52 45 41 4D

Device Response

When the command is successfully received and executed, the device returns a binary acknowledgment frame.

The complete acknowledgment frame has a fixed length of 9 bytes.

The acknowledgment frame does not contain CRC fields. It uses the simplified response structure defined specifically for this command.

Successful Response:

ASCII view:

@@@.OK???

Hexadecimal view:

40 40 40 11 4F 4B 3F 3F 3F

6.2.1. Measurement Data Frames

After the START_STREAM acknowledgment has been received, the device begins transmitting measurement data frames every 100 ms.

Each frame contains the current measured RF power value. The measurement is transmitted directly in dBm as a signed 8-bit integer (int8_t). No additional scaling or conversion factor is required.

Measurement Frame Format

The complete measurement frame has a fixed length of 10 bytes.

Hexadecimal frame template:

40 40 40 28 XX XX XX 3F 3F 3F

Because the measured power field is an int8_t value, negative values are encoded using two’s-complement representation. 

Example:

40 40 40 28 9C D9 1F 3F 3F 3F

Frame interpretation :

40 40 40    Start Symbols
28          Measurement Data Function Code
9C          Measured Power: -100 dBm
D9          CRC16 Low Byte
1F          CRC16 High Byte
3F 3F 3F    Stop Symbols

The hexadecimal value 0x9C, when interpreted as a signed 8-bit integer, is equal to -100 dBm

The host application should validate the start symbols, function code, CRC16 checksum, and stop symbols before processing the measured power value. After validation, the value may be compared directly against the threshold configured in the host application.

Communication Example:

2026-07-15 12:10:26.259
53 54 41 52 54 5F 53 54 52 45 41 4D


2026-07-15 12:10:26.260
40 40 40 11 4F 4B 3F 3F 3F


2026-07-15 12:10:26.270
40 40 40 28 9C D9 1F 3F 3F 3F


2026-07-15 12:10:26.373
40 40 40 28 9C D9 1F 3F 3F 3F


2026-07-15 12:10:26.473
40 40 40 28 9C D9 1F 3F 3F 3F


2026-07-15 12:10:26.571
40 40 40 28 9C D9 1F 3F 3F 3F


2026-07-15 12:10:26.673
40 40 40 28 9C D9 1F 3F 3F 3F

In this example:

53 54 41 52 54 5F 53 54 52 45 41 4D

is the ASCII command START_STREAM.

The frame:

40 40 40 11 4F 4B 3F 3F 3F

confirms successful execution of the command.

STOP_STREAM

53 54 4F 50 5F 53 54 52 45 41 4D

40 40 40 12 4F 4B 3F 3F 3F

This guide describes only a small subset of the commands and functions available through the GP-Probe NANO L1 communication interface. If your integration requires additional commands, configuration options, data formats, or custom functionality, please contact us at support@gpspatron.com or submit a request through the GPSPATRON technical support website.