API Reference¶

Complete API documentation for the qt-test application components.

This reference is automatically generated from source code comments using Doxygen and Breathe. For usage examples, see Programming Guide.

Architecture Overview¶

Performance-Driven Design¶

The qt-test application architecture is optimized for real-time GPS data processing at 8-10 Hz update rates. This section explains the architectural decisions and their performance rationale.

Why C++/QML Split:

GPS data arrives at 8-10 Hz from the BLE device, requiring efficient processing in C++. QML handles the user interface, which updates at a much slower rate (user interaction speed).

C++ Layer: Real-time data processing, BLE communication, NTRIP parsing
QML Layer: User interface rendering, user input handling, visual feedback
Benefit: Decouples high-frequency data processing from UI rendering

Why Global Variables (extern):

For maximum performance, the application uses global variables (extern myLla, myStatus, myConfig) for rapid data sharing between managers:

// Declared in BLEManager.cpp, accessed via extern
extern SqspLla_t myLla;
extern SqspStatus_t myStatus;
extern SqspLbConfig_t myConfig;

Performance Comparison:

Access Method	Latency	Use Case
Direct extern access	~5ns	Real-time rendering, high-freq logging
Qt Signal/Slot routing	~500-1000ns	UI updates, event notifications
Function call with copy	~100ns	Occasional data access

When to Use Each:

Direct extern: MapManager (real-time map updates), performance-critical loops
Signals: UI notifications, event-driven updates (change detection reduces load)
Getter functions: Encapsulated access for non-critical paths

The Manager Pattern¶

Each major subsystem has a dedicated Manager class that follows these principles:

Manager Responsibilities:

BLEManager: BLE communication, SQTP protocol, device connection
NTRIPManager: NTRIP client, TCP connection, RTCM parsing
DataManager: Data formatting, batched properties, device status tracking
MapManager: Minimalist real-time map coordinate provider

Common Patterns:

Inherit from QObject for Qt signal/slot support
Use QML_ELEMENT macro for automatic QML registration
Expose Q_PROPERTY for QML data binding
Use extern access to shared global data structures for performance
Emit signals only when data actually changes (change detection)

Data Flow:

GPS Device (8-10 Hz) → BLEManager → extern globals (myLla, myStatus, myConfig)
                                          ↓
                                     MapManager → QML Map (direct read)
                                          ↓
                                     DataManager → QML UI (formatted strings)

Manager Classes¶

The application provides three primary manager classes for different subsystems:

BLEManager - Bluetooth Low Energy communication with GPS devices
NTRIPManager - NTRIP client for correction data streaming
DataManager - Data formatting and UI integration

BLEManager¶

Complete Bluetooth Low Energy interface for SitePoint GPS devices.

Handles device discovery, connection management, RTCM transmission, and GPS data reception via SQTP protocol.

class BLEManager : public QObject¶

Manages Bluetooth Low Energy communication with SitePoint GPS devices.

The BLEManager class provides comprehensive BLE functionality for communicating with SitePoint GPS devices. It handles:

Device discovery and connection management
RTCM v3 correction data transmission with queuing and FSM
SQTP (SitePoint Transport Protocol) message handling
SQSP (SitePoint Protocol) data reception (LLA, Status, Config)
Battery and Device Information Service support
MTU negotiation and automatic fragmentation

Usage¶

Basic workflow:

Create BLEManager instance
Call startScan() to discover nearby SitePoint devices
Connect to desired device using connectToDevice()
Queue RTCM messages using queueRTCMMessage()
Monitor GPS data via llaDataChanged(), statusDataChanged(), configDataChanged() signals

Characteristics¶

The BLEManager works with two primary BLE characteristics on the SitePoint service:

0x0102 (RTCM): Write-only characteristic for sending RTK correction data
0x0105 (SQTP): Read/Write/Notify characteristic for bidirectional protocol communication

RTCM Transmission Architecture¶

RTCM messages are queued and transmitted via a finite state machine (FSM) that:

Uses a pre-allocated 50-message buffer pool (no heap allocation)
Paces transmission to match BLE connection intervals
Automatically fragments messages exceeding MTU limits
Prioritizes RTCM over SQTP (queues SQTP when RTCM active)

Global Data Structures¶

The following global variables (extern) provide fast access to device data:

myLla: GPS position data (latitude, longitude, altitude, accuracy)
myStatus: Device status (GPS state, satellites, corrections, aidingBins)
myConfig: Device configuration (base station position, mode settings)

These are updated automatically when notifications arrive on the 0x0105 characteristic. Change detection is implemented to emit signals only when data actually changes.

See also

QBluetoothDeviceDiscoveryAgent, QLowEnergyController, QLowEnergyService

Note

The RTCM characteristic uses WriteWithoutResponse for maximum throughput. Messages are sent and forgotten - retransmission is not supported as stale corrections are useless for RTK positioning.

Private Helper Methods

Reads all characteristics of a service (legacy, unused)

RTCM Queue Management Methods

Initializes the RTCM buffer pool

Public Functions

explicit BLEManager(QObject *parent = nullptr)¶

Constructs a BLEManager instance.

[blemanager-constructor]

Initializes the BLE discovery agent, RTCM buffer pool, transmission timer, and SQTP protocol handlers. The manager is ready to scan for devices after construction.

Parameters:: parent – Parent QObject for memory management

Q_INVOKABLE void startScan ()

Starts scanning for nearby BLE devices.

[blemanager-constructor]

Initiates Bluetooth Low Energy device discovery using the Low Energy method. Only devices advertising the SitePoint service UUID will be reported via the deviceDiscovered() signal.

[blemanager-startscan]

See also

stopScan(), deviceDiscovered()

Note

Requires Bluetooth to be enabled on the host system. Will emit errorOccurred() if Bluetooth is unavailable or powered off.

Q_INVOKABLE void stopScan ()

Stops the ongoing BLE device scan.

[blemanager-startscan]

Halts the device discovery process if currently active. Safe to call even if no scan is in progress.

See also

startScan()

Q_INVOKABLE void connectToDevice (const QString &deviceAddress)

Connects to a discovered SitePoint device.

[blemanager-connect]

Establishes a BLE connection to the specified device and initiates service discovery. Upon successful connection:

deviceConnected() signal is emitted
Services are discovered automatically
RTCM and SQTP characteristics are configured
MTU is negotiated
Notifications are enabled on the SQTP characteristic

Note

The device must have been discovered via startScan() first.

Parameters:: deviceAddress – Bluetooth address of the device (from deviceDiscovered signal)

Q_INVOKABLE void disconnectFromDevice ()

Disconnects from the currently connected device.

Terminates the BLE connection, clears all queues, stops transmission timer, and resets all device data (myLla, myStatus, myConfig) to zero. Emits deviceDisconnected() and sqtpDisconnected() signals.

See also

connectToDevice(), deviceDisconnected()

Q_INVOKABLE void readCharacteristic (const QString &characteristicUuid)

Legacy characteristic read function (deprecated)

[blemanager-connect]

Deprecated:: This function is no longer used. Characteristic reading is now handled automatically during service discovery.

Parameters:: characteristicUuid – UUID of characteristic to read (unused)

Q_INVOKABLE SqspLla_t getLlaData ()

Returns the current GPS position data.

Provides direct access to the global myLla structure. Data is updated automatically when notifications arrive from the device.

See also

llaDataChanged()

Note

For high-frequency access (8-10 Hz), consider using extern myLla directly to avoid function call overhead.

Returns:: SqspLla_t structure containing latitude, longitude, altitude, and accuracy

bool sendRTCMData(const QByteArray &data)¶

Sends RTCM data immediately (low-level method)

Low-level method that writes RTCM data directly to the 0x0102 characteristic using WriteWithoutResponse. Does not use the queue or FSM.

See also

queueRTCMMessage()

Note

Message must fit within MTU-3 bytes or transmission will fail.

Warning

Most applications should use queueRTCMMessage() instead, which provides queuing, pacing, and fragmentation support.

Parameters:: data – RTCM message bytes to send
Returns:: true if sent successfully, false on error

bool queueRTCMMessage(const QByteArray &data)¶

Queues an RTCM message for transmission (recommended method)

[blemanager-queuertcm]

Adds an RTCM message to the transmission queue. The FSM will automatically transmit messages at appropriate intervals matching the BLE connection timing. Messages larger than MTU will be automatically fragmented.

Queue capacity: 50 messages (pre-allocated, no heap allocation)

See also

sendRTCMData()

Note

This is the recommended method for RTCM transmission. The FSM handles:

Proper pacing to match BLE connection intervals
Automatic fragmentation for large messages
Buffer management and overflow protection

Parameters:: data – RTCM message bytes to queue
Returns:: true if queued successfully, false if queue full or device not ready

SqtpStatus_t sendSQTPMessage(const QByteArray &data)¶

Sends an SQTP message on the 0x0105 characteristic.

Sends an SQTP protocol message to the device. If RTCM transmission is active, the message is queued in a single-slot pending buffer and sent when RTCM idle.

Note

Used internally by SQTP protocol handlers. Applications typically don’t call this directly - use sendModeChangeCommand() or sendConfigData() instead.

Parameters:: data – SQTP frame bytes to send
Returns:: SQTP_STATUS_SUCCESS on success, error code on failure

int getCurrentMtu() const¶

Returns the current negotiated MTU value.

The MTU (Maximum Transmission Unit) determines the maximum packet size. Usable payload is MTU-3 bytes (3 bytes for BLE ATT header).

Note

Not all platforms expose MTU (e.g., Linux returns -1). Default MTU of 23 bytes is assumed if platform doesn’t report.

Returns:: Current MTU in bytes, or 0 if not connected/unknown

SqtpStatus_t sendModeChangeCommand(DeviceMode mode)¶

Sends a device mode change command.

Changes the operating mode of the GPS device by sending an SQTP configuration message with the appropriate mode bits set.

Supported modes:

DEVICE_MODE_ROVER: Standard rover mode (no corrections)
DEVICE_MODE_ROVER_NTRIP: Rover with NTRIP corrections via BLE
DEVICE_MODE_ROVER_NEAREST: Rover with nearest base corrections (Tripod network)
DEVICE_MODE_FIXED_BASE: Fixed base station mode
DEVICE_MODE_FIXED_BASE_BROADCAST: Fixed base with RTK broadcast

See also

DeviceMode, sendConfigData()

Parameters:: mode – Desired device mode (ROVER, ROVER_NTRIP, ROVER_NEAREST, FIXED_BASE, etc.)
Returns:: SQTP_STATUS_SUCCESS on success, error code on failure

Q_INVOKABLE bool sendConfigData (double longitude, double latitude, double height, double hMSL, double hAcc, double vAcc, int duration)

Sends custom configuration data to the device.

Sends a complete configuration message to the device including base station position, accuracy estimates, and survey duration. Uses the current mode settings from myConfig.mode.

See also

sendModeChangeCommand()

Note

Typically used in Fixed Base mode to set the known base station position.

Parameters:

longitude – Base station longitude in degrees
latitude – Base station latitude in degrees
height – Base station ellipsoidal height in meters
hMSL – Base station height above mean sea level in meters
hAcc – Horizontal accuracy in meters
vAcc – Vertical accuracy in meters
duration – Survey duration in seconds

Returns:

true on success, false on failure

Q_INVOKABLE int getBatteryLevel () const

Returns the current battery level.

Battery level is read from the Battery Service characteristic 0x2A19. Updates automatically via notifications if the device supports them.

Returns:: Battery percentage (0-100), or -1 if unknown

Q_INVOKABLE QString getBatteryPowerState () const

Returns the battery power state as a formatted string.

Provides detailed information about battery presence, wired/wireless power connection, and charging state. Read from Battery Power State characteristic 0x2A1A.

Returns:: Human-readable power state (e.g., “Battery: Present | Wired: Connected | Charge: Charging”)

Q_INVOKABLE QString getBatteryLevelState () const

Returns the battery level state.

Categorical battery level indication from Battery Level State characteristic 0x2A1B.

Returns:: “Unknown”, “Critical”, “Low”, or “Good”

Public Members

bool m_sqtpActive = false¶: True when SQTP protocol is actively connected.

Signals

void deviceDiscovered(const QString &deviceName, const QString &deviceAddress)¶

Emitted when a SitePoint device is discovered during scanning.

This signal is emitted for each SitePoint device found during BLE scanning. Only devices advertising the SitePoint service UUID (00000100-34ed-12ef-63f4-317792041d17) are reported.

See also

startScan(), connectToDevice()

Note

May be emitted multiple times for the same device as more details are discovered.

Parameters:

deviceName – Advertised name of the device
deviceAddress – Bluetooth address of the device (use with connectToDevice())

void deviceConnected()¶

Emitted when BLE connection to device is established.

Indicates successful connection. Service discovery begins automatically after this signal is emitted.

See also

connectToDevice(), deviceDisconnected()

void deviceDisconnected()¶

Emitted when BLE connection to device is lost.

Emitted when connection is lost (either intentionally via disconnectFromDevice() or due to connection failure). All queues are cleared and device data is reset.

void errorOccurred(const QString &errorString)¶

Emitted when a BLE error occurs.

Reports BLE-related errors such as Bluetooth unavailable, connection failure, or characteristic access errors.

Parameters:: errorString – Human-readable description of the error

void inputReceived(const QString &input)¶

Legacy signal (unused)

Deprecated:: This signal is not currently used in the implementation.

Parameters:: input – Input data (unused)

void serviceDiscovered(const QString &serviceUuid)¶

Emitted when a BLE service is discovered on the device.

Emitted during service discovery for each service found on the device.

Parameters:: serviceUuid – UUID of the discovered service

void characteristicDiscovered(const QString &characteristicUuid)¶

Emitted when a characteristic is discovered.

Deprecated:: This signal is not currently used in the implementation.

Parameters:: characteristicUuid – UUID of the discovered characteristic

void characteristicValueRead(const QString &characteristicUuid, const QByteArray &value)¶

Emitted when a characteristic value is read.

Deprecated:: This signal is not currently used in the implementation.

Parameters:

characteristicUuid – UUID of the characteristic
value – Raw bytes read from the characteristic

void llaDataChanged()¶

Emitted when GPS position data (LLA) changes.

Indicates that the global myLla structure has been updated with new position data from the device. Change detection ensures this signal is only emitted when data actually changes (not on every 8 Hz update).

Access updated data via:

getLlaData() method
Direct extern access to myLla global variable

void statusDataChanged()¶

Emitted when device status data changes.

Indicates that the global myStatus structure has been updated with new device status information (GPS state, satellites, corrections, aidingBins).

Access updated data via direct extern access to myStatus global variable.

See also

llaDataChanged(), configDataChanged()

void configDataChanged()¶

Emitted when device configuration data changes.

Indicates that the global myConfig structure has been updated with new configuration information (mode settings, base position, etc.).

Access updated data via direct extern access to myConfig global variable.

See also

llaDataChanged(), statusDataChanged()

void mtuChanged(int newMtu)¶

Emitted when MTU value changes.

Emitted when the BLE MTU (Maximum Transmission Unit) is negotiated or changes. Usable payload size is newMtu - 3 bytes.

See also

getCurrentMtu()

Parameters:: newMtu – New MTU value in bytes

void batteryLevelChanged(int level)¶

Emitted when battery level changes.

Emitted when battery level is read or updated via notification.

See also

getBatteryLevel()

Parameters:: level – New battery level (0-100 percent)

void sqtpConnected()¶

Emitted when SQTP protocol connection is established.

Indicates that the first valid SQTP subframe has been received from the device. After this signal, the device is ready for full bidirectional communication.

See also

sqtpDisconnected()

void sqtpDisconnected()¶

Emitted when SQTP protocol connection is lost.

Indicates SQTP connection has been lost (either due to user disconnect, BLE connection loss, or device reporting disconnected state).

See also

sqtpConnected()

Public Static Functions

static BLEManager *getInstance()¶

Returns the global BLEManager instance.

Provides access to the BLEManager from C callbacks that don’t have direct object access (e.g., SQTP protocol handlers).

Note

Only one BLEManager instance should exist per application.

Returns:: Pointer to the singleton BLEManager instance

NTRIPManager¶

NTRIP client for receiving RTCM correction data from network casters.

The NTRIPManager establishes a TCP connection to an NTRIP caster, performs HTTP authentication, and receives RTCM v3 correction messages. These corrections are then queued for transmission to the GPS device via BLEManager.

Key Features:

TCP socket connection to NTRIP caster
HTTP Basic Authentication support
RTCM v3 message parsing using libntrip callback architecture
Real-time connection status monitoring
Automatic RTCM message framing and validation
Integration with BLEManager via rtcmDataReceived() signal

Typical Data Flow:

User configures caster host, port, mountpoint, credentials
NTRIPManager connects via connectToServer()
HTTP request sent with Basic Auth header
Caster responds with RTCM stream (typically 1 Hz)
RTCM parser validates messages and emits rtcmDataReceived()
Application connects signal to BLEManager::queueRTCMMessage()
BLE FSM transmits corrections to GPS device

Properties:

bool connected - True if connected to NTRIP caster
QString connectionStatus - Human-readable status string
QString serverHost - Caster hostname or IP address
int serverPort - Caster port number (typically 2101)
QString mountPoint - NTRIP mountpoint path (e.g., “/RTCM3”)
QString username - NTRIP account username
QString password - NTRIP account password

Key Methods:

connectToServer() - Establish connection to configured caster
disconnectFromServer() - Close NTRIP connection
setServerHost(), setServerPort(), etc. - Property setters

Signals:

connectionStateChanged() - Emitted when connection status changes
connectionStatusChanged() - Emitted when status string changes
rtcmDataReceived(QString rtcmId, int length, QString crc) - RTCM message received
errorOccurred(QString error) - Connection or parsing error
ntripStateChanged(bool isActiveAndSending) - Active transmission state

Performance Notes:

NTRIP streams are typically 1 Hz (one correction per second), which is much slower than the 8-10 Hz GPS data rate. The RTCM queue in BLEManager buffers corrections to handle any burst traffic.

QML Integration:

Registered as ntripManager context property in main.cpp. Used by NTRIPClient.qml for connection configuration and status display.

class NTRIPManager : public QObject¶

DataManager¶

Data formatting and conversion utilities for UI presentation.

The DataManager serves as a bridge between the high-frequency raw GPS data (updated at 8-10 Hz) and the QML user interface. It formats data for display, implements batched properties for performance, and tracks device status.

Design Philosophy - Batched Properties:

Instead of exposing dozens of individual Q_PROPERTY values (which would cause many signal emissions), DataManager uses batched properties with QVariantMap:

// SLOW: 15+ separate property signals
Q_PROPERTY(QString latitude READ latitude NOTIFY latitudeChanged)
Q_PROPERTY(QString longitude READ longitude NOTIFY longitudeChanged)
// ... 13 more properties ...

// FAST: Single batched property with 1 signal
Q_PROPERTY(QVariantMap llaData READ llaData NOTIFY dataChanged)

Performance Benefit:

Reduced signal emissions: 1 signal instead of 15+
Reduced QML property bindings: Single map lookup instead of 15 bindings
Cached formatted strings: Formatting done once in C++, reused in QML
Atomic updates: All related data updates together

Three Data Categories:

LLA Data (llaData): Position, accuracy, GPS time
Status Data (statusData): Satellites, solution type, corrections
Config Data (configData): Base station position, survey settings

Direct Extern Access:

DataManager reads directly from global structures for maximum performance:

extern SqspLla_t myLla;
extern SqspStatus_t myStatus;
extern SqspLbConfig_t myConfig;

void DataManager::onLlaDataChanged() {
    // Direct access, no function call overhead
    processLlaData(myLla);
    emit dataChanged();
}

Properties:

QVariantMap llaData - Formatted LLA data (lat, lon, height, accuracy, iTOW)
QVariantMap statusData - Formatted status (satellites, solution, corrections)
QVariantMap configData - Formatted configuration (base position, duration)
QVariantMap deviceStatus - Device mode, state, aiding input, broadcast status
bool isConnected - True if SQTP connection established
bool isNtripActive - True if NTRIP corrections actively being transmitted

Key Methods:

setDeviceMode(QString modeString) - Change device operational mode
onLlaDataChanged() - Slot connected to BLEManager::llaDataChanged()
onStatusDataChanged() - Slot connected to BLEManager::statusDataChanged()
onConfigDataChanged() - Slot connected to BLEManager::configDataChanged()
onNtripStateChanged(bool) - Slot connected to NTRIPManager::ntripStateChanged()

Signals:

dataChanged() - Emitted when LLA data updates
statusDataChanged() - Emitted when status data updates
configDataChanged() - Emitted when config data updates
deviceStatusChanged() - Emitted when device status changes

Formatting Examples:

The DataManager applies consistent formatting:

Coordinates: 9 decimal places with ° symbol ("43.641130095°")
Height: 4 decimal places with unit ("123.4567m")
Accuracy: 4 decimal places with unit ("0.0234m")
Percentages: Integer with % symbol ("87%")
Time: Formatted duration ("1h 23m 45s")
Booleans: Yes/No strings ("Yes", "No")

Device Status Tracking:

DataManager also implements device status tracking (migrated from ConfigManager):

Determines connection state (CONNECTED/NOT CONNECTED)
Determines device mode (ROVER, FIXED BASE, etc.)
Determines device state (VALID/NOT BUSY, SURVEYING, etc.)
Determines aiding input mode (OFF, NTRIP BLE, NEAREST BASE)
Determines broadcast status (BROADCASTING, NOT BROADCASTING)

QML Integration:

Registered as dataManager context property in main.cpp. Used extensively by DeviceDataWindow.qml for live data display and configuration editing.

class DataManager : public QObject¶

MapManager¶

Real-time coordinate provider for QtLocation map display.

The MapManager is intentionally minimalist - it provides direct access to GPS coordinates for the QtLocation Map component with absolute minimum overhead. This design prioritizes performance for smooth real-time map updates at 8-10 Hz.

Design Philosophy - Maximum Performance:

MapManager is the fastest data path in the application:

// MapManager.cpp - Absolute minimum overhead
double MapManager::lat() const {
    return myLla.lat;  // Direct extern access, ~5ns
}

void MapManager::onLlaDataChanged() {
    m_centerUpdateCount++;
    emit locationChanged();  // Single signal, no processing
}

Why This Design:

No data processing: Returns raw coordinates directly
No string formatting: QML does formatting only when displaying title
No caching: Always reads live data from myLla
Single signal: Only emits locationChanged() for all coordinate changes
Minimal state: Only tracks update counter

Comparison with DataManager:

Aspect	MapManager	DataManager
Data access	Direct extern (myLla.lat)	Direct extern with processing
Formatting	None (done in QML)	All formatting in C++
Caching	None	Cached formatted strings
Signal count	1 (locationChanged)	4 (llaData, status, config, deviceStatus)
Use case	Real-time map rendering	UI display with formatted text

Properties:

double lat - Current latitude in degrees (direct from myLla.lat)
double lon - Current longitude in degrees (direct from myLla.lon)
double height - Current height in meters (direct from myLla.height)
QString formattedTitle - Pre-formatted window title (lat, lon, height + counter)
int centerUpdateCount - Number of times map center has updated

Key Methods:

lat(), lon(), height() - Direct coordinate accessors
formattedTitle() - Returns formatted string for map window title
onLlaDataChanged() - Slot connected to BLEManager::llaDataChanged()

Signals:

locationChanged() - Emitted when GPS position updates

QML Integration:

Registered as mapManager context property in main.cpp. Used by MapWindow.qml for real-time map center updates:

Map {
    // Real-time binding to GPS coordinates
    center: QtPositioning.coordinate(mapManager.lat, mapManager.lon)

    MapCircle {
        // Device position marker
        center: QtPositioning.coordinate(mapManager.lat, mapManager.lon)
        radius: 5  // 5 meter radius
        color: "red"
    }
}

Performance Benchmark:

At 8-10 Hz GPS update rate:

MapManager overhead: ~5-10ns per coordinate access
QML Map rendering: ~16ms per frame (60 FPS)
Bottleneck: Map rendering, not data access

The minimalist design ensures that coordinate access never becomes a performance bottleneck, even at high update rates.

class MapManager : public QObject¶

Data Structures¶

SQSP Protocol Structures¶

These structures are defined in the SQSP (SitePoint Structures Protocol) library and contain GPS data, device status, and configuration information.

SqspLla_t - Position Data¶

Contains latitude, longitude, altitude, and accuracy information.

Updated at 8-10 Hz from the GPS receiver.

struct SqspLla_t¶

SqspStatus_t - Device Status¶

Provides real-time information about GPS receiver state, satellite tracking, and correction status.

Updated at 8-10 Hz.

struct SqspStatus_t¶

SqspLbConfig_t - Configuration Data¶

Contains device configuration including base station position for RTK operations.

Updated when device mode changes or configuration is modified.

struct SqspLbConfig_t¶

Enumerations¶

Device Modes¶

Device operational mode constants (defined in sqsp.h):

DEVICE_MODE_ROVER - Standard rover, no corrections
DEVICE_MODE_ROVER_NTRIP - Rover with NTRIP corrections via BLE
DEVICE_MODE_ROVER_NEAREST - Rover with Tripod network corrections
DEVICE_MODE_FIXED_BASE - Fixed base station
DEVICE_MODE_FIXED_BASE_BROADCAST - Fixed base with broadcast

See Device Configuration for detailed mode descriptions.

Solution Types¶

GPS solution quality indicators (SqspLla_t::solutionType):

0 - No fix
1 - Autonomous GPS (no corrections)
2 - DGPS / SBAS
4 - RTK Fixed (cm-level accuracy)
5 - RTK Float (dm-level accuracy)

Global Variables¶

High-Performance Data Access¶

For applications requiring high-frequency access to GPS data (8-10 Hz), direct extern access to global variables provides optimal performance:

// Declared in BLEManager.cpp
extern SqspLla_t myLla;        // GPS position data
extern SqspStatus_t myStatus;  // Device status
extern SqspLbConfig_t myConfig; // Configuration data

// Direct access (fast, no function call overhead)
double lat = myLla.latitude;
double lon = myLla.longitude;
float acc = myLla.hAcc;

Performance: Direct extern access (~5ns) vs function call (~100ns)

Usage: Recommended for rendering loops, high-frequency logging, real-time processing. For occasional access, use BLEManager getter functions for better encapsulation.

See Programming Guide section “High-Performance Data Access” for details.

Signals and Slots¶

BLEManager Signals¶

Device Discovery and Connection¶

deviceDiscovered(const QString &name, const QString &address)

Emitted when a SitePoint device is discovered during scanning.

param name:: Device name (e.g., “SitePoint-1234”)
param address:: Bluetooth MAC address (e.g., “12:34:56:78:9A:BC”)

deviceConnected()

Emitted when BLE connection is successfully established and services are discovered.

deviceDisconnected()

Emitted when device disconnects (either intentionally or unexpectedly).

errorOccurred(const QString &errorMessage)

Emitted when a BLE error occurs.

param errorMessage:: Human-readable error description

Data Update Signals¶

llaDataChanged(): Emitted when GPS position data (SqspLla_t) changes. Uses change detection to prevent emission on every 8 Hz update.
statusDataChanged(): Emitted when device status data (SqspStatus_t) changes.
configDataChanged(): Emitted when device configuration data (SqspLbConfig_t) changes.

BLE Information Signals¶

mtuChanged(int mtu)

Emitted when MTU (Maximum Transmission Unit) is negotiated or changed.

param mtu:: New MTU value in bytes (typically 23-527)

batteryLevelChanged(int level)

Emitted when device battery level changes.

param level:: Battery percentage (0-100)

NTRIPManager Signals¶

Connection Signals¶

connectionStatusChanged(bool connected)

Emitted when NTRIP connection status changes.

param connected:: True if connected, false if disconnected

errorOccurred(const QString &errorMessage)

Emitted when an NTRIP error occurs.

param errorMessage:: Human-readable error description

Data Signals¶

rtcmDataReceived(const QByteArray &rtcmData)

Emitted when RTCM correction message is received from caster.

param rtcmData:: Complete RTCM v3 message (binary)

sourcetableReceived(const QString &sourcetable)

Emitted when NTRIP source table is received.

param sourcetable:: Source table text (lists available mountpoints)

Public Methods¶

See individual class documentation above for complete method listings.

Key methods are summarized here for quick reference:

BLEManager Key Methods¶

Device Management:

startScan() - Begin scanning for SitePoint devices
stopScan() - Stop device scanning
connectToDevice(const QString &address) - Connect to specific device
disconnectFromDevice() - Disconnect from current device

Data Access:

getLlaData() - Get current position data (returns SqspLla_t)
getStatusData() - Get current status data (returns SqspStatus_t)
getConfigData() - Get current configuration (returns SqspLbConfig_t)

RTCM Transmission:

queueRTCMMessage(const QByteArray &rtcmData) - Queue RTCM message for transmission

Device Control:

sendModeChangeCommand(int mode) - Change device operational mode

Information:

getCurrentMtu() - Get current negotiated MTU
getBatteryLevel() - Get device battery level (0-100)

NTRIPManager Key Methods¶

Connection Management:

connectToNtrip(host, port, mountpoint, username, password) - Connect to NTRIP caster
disconnect() - Disconnect from NTRIP caster
requestSourcetable() - Request list of available mountpoints

Status:

isConnected() - Check if currently connected to caster

Constants and Definitions¶

RTCM Queue Parameters¶

Defined in BLEManager.cpp:

RTCM_QUEUE_SIZE: 50 messages
RTCM_BUFFER_SIZE: 2048 bytes per message

BLE UUIDs¶

SitePoint custom service and characteristics:

Service UUID: 00000100-34ed-12ef-63f4-317792041d17
RTCM Characteristic: 0x0102 (WriteWithoutResponse)
SQTP Characteristic: 0x0105 (Read, Write, Notify)

Standard BLE services:

Device Information Service: 0x180A
Battery Service: 0x180F

SQTP Subframe IDs¶

Common SQTP subframe identifiers (defined in sqtpSubframeIDs.h):

SQTP_ID_SITEPOINT_LLA (0x1244) - Position data
SQTP_ID_SITEPOINT_STATUS (0x1243) - Status data
SQTP_ID_SITEPOINT_LOCAL_BASE_CONFIG (0x1245) - Configuration and mode changes
SQTP_ID_RTCM (0x00D3) - RTCM correction messages (legacy)

Aiding Data Bitmap¶

Aiding data availability flags (SqspStatus_t::aidingBins):

#define AIDING_EPHEMERIS    (1 << 0)  // Satellite orbit data
#define AIDING_ALMANAC      (1 << 1)  // Approximate positions
#define AIDING_UTC          (1 << 2)  // Time correction
#define AIDING_IONO         (1 << 3)  // Atmospheric correction
#define AIDING_RTCM         (1 << 4)  // RTK corrections active

Usage Examples¶

For complete usage examples, see:

Programming Guide - Comprehensive programming guide
BLE Communication with SitePoint GPS Devices - BLE implementation details
Device Configuration - Device modes and configuration

API Reference¶

Architecture Overview¶

Performance-Driven Design¶

The Manager Pattern¶

Manager Classes¶

BLEManager¶

Usage¶

Characteristics¶

RTCM Transmission Architecture¶

Global Data Structures¶

NTRIPManager¶

DataManager¶

MapManager¶

Data Structures¶

SQSP Protocol Structures¶

SqspLla_t - Position Data¶

SqspStatus_t - Device Status¶

SqspLbConfig_t - Configuration Data¶

Enumerations¶

Device Modes¶

Solution Types¶

Global Variables¶

High-Performance Data Access¶

Signals and Slots¶

BLEManager Signals¶

Device Discovery and Connection¶

Data Update Signals¶

BLE Information Signals¶

NTRIPManager Signals¶

Connection Signals¶

Data Signals¶

Public Methods¶

BLEManager Key Methods¶

NTRIPManager Key Methods¶

Constants and Definitions¶

RTCM Queue Parameters¶

BLE UUIDs¶

SQTP Subframe IDs¶

Aiding Data Bitmap¶

Usage Examples¶

Index and Search¶