UBXGNSS GNSS Receiver

$130.00

Out of stock

Compact multi-constellation GNSS receiver with a DroneCAN interface for UAV flight controllers

Part number UBXGNSS · Datasheet Revision 2

Request Volume Pricing Engineering / Customization Inquiry

Volume pricing available for production orders, recurring purchases, and OEM integration programs. Contact us to discuss quantities and lead times.

SKU: UBXGNSS Category:
  • 5 VNominal supply
  • ≈ 120 mWTypical power (estimated)
  • 31 × 31 mmBoard size
  • 28 sCold-start time to first fix

Overview

The UBXGNSS is a compact, self-contained GNSS receiver board that provides reliable position and navigation data to a UAV flight controller over a DroneCAN (UAVCAN) interface. It integrates a ceramic patch antenna, a ublox MAXM10M00B GNSS receiver module, an STM32G0B1KBT6 microcontroller and an MCP2562FD CAN transceiver on a single 31 × 31 mm board.

The MAXM10M00B receives GPS and Galileo signals (with QZSS and SBAS) from the on-board antenna and sends the resulting navigation messages to the microcontroller over an I²C interface. The STM32G0B1KBT6 processes this data, packages the relevant navigation information into DroneCAN messages and transmits them to the flight controller over the board’s FDCAN bus.

Key features

  • Concurrent GPS and Galileo reception, with QZSS and SBAS (ublox MAXM10M00B)
  • On-board ceramic patch GNSS antenna, 1575.42–1602 MHz
  • DroneCAN (UAVCAN) communication over classic CAN at 1 Mbit/s (FDCAN peripheral, MCP2562FD transceiver), with selectable 120 Ω bus termination
  • STM32G0B1KBT6 microcontroller with 128 KB flash
  • 144 KB SRAM (128 KB with hardware parity check)
  • Position output at 10 Hz, receiver configured for airborne use
  • Node ID selected by header jumpers (16 to 31), or any value from 1 to 127 set over CAN
  • STDC14 debug and programming port for the ST-LINK-V3MINIE
  • Compact 31 × 31 mm board

Technical specifications

ParameterValueUnit
Electrical
Nominal supply voltage5V
Minimum operating voltage4.5V
Maximum operating voltage5.5V
Typical power consumption (estimated)≈ 120mW
Typical input current (estimated)≈ 24mA
Performance
Maximum altitude50km
Maximum velocity500m/s
Velocity accuracy0.05m/s
Dynamic heading accuracy0.3°
Horizontal position accuracy (CEP)1.5m
Position update rate10Hz
Time to first fix (cold start)28s
Time to first fix (hot start)1s
Tracking sensitivity-165dBm
Antenna
Antenna frequency range1575.42–1602MHz
Antenna gain (maximum)3.0dBi
Antenna polarizationRHCP
Environmental
Operating temperature-40 to +85°C

Power and current are estimates from the typical supply currents given in the data sheets of the components (the 3.3 V rail loads, the regulator quiescent current and the CAN transceiver) at 5 V with the receiver tracking satellites; they have not been measured. Each fitted ID jumper adds about 0.33 mA.

Altitude and velocity limits assume the airborne 4 g platform model, which the firmware selects at start-up. Position accuracy, velocity and heading accuracy, start-up times and sensitivity are the ublox MAXM10M00B figures for GPS and Galileo (CEP at 50 % over 24 hours, static, -130 dBm; velocity and heading at 30 m/s). The hot-start time applies only while the receiver stays powered: the board has no backup supply for the receiver, so a start after power-up is a cold start.

The board measures 31 × 31 mm and is 1.6 mm thick, with four M2 mounting holes (2.2 mm) on a 25 × 25 mm pattern. All dimensions in the drawings are in millimetres.

UBXGNSS mechanical drawing, top view: 31 by 31 mm board, 25 by 25 mm mounting pattern, J3, J5, J1 and JP1 positions
Mechanical drawing (top view)
UBXGNSS mechanical drawing, bottom view: 31 by 31 mm board, 25 by 25 mm mounting pattern
Mechanical drawing (bottom view)

Absolute maximum ratings

Stresses beyond these values may cause permanent damage. They are estimated from the absolute maximum ratings of the board’s components (the lowest limit among the parts connected to each pin) and have not been tested on the board. The 5 V input has no reverse-polarity or over-voltage protection, and the voltage ratings of the capacitors were not assessed.

ParameterMinMaxUnitLimited by
Supply voltage, 5V pin (J3 pin 2)-0.37.0VMCP2562FD supply
Voltage on CAN_H and CAN_L (DC)-58+58VMCP2562FD
Transient on CAN_H and CAN_L (ISO 7637)-150+100VMCP2562FD
ESD on CAN_H and CAN_L (HBM)±8kVMCP2562FD
Voltage on J1 and J5 signal pins-0.33.6VSTM32G0B1KBT6 (3.3 V I/O)
Storage temperature-40+85°Cu-blox MAX-M10M-00B

The receiver module is supplied from the on-board 3.3 V rail. Its own limits (supply -0.3 to 6 V, RF input +15 dBm, operating and storage temperature -40 to +85 °C) apply inside the board.

Interfaces and connectors

Ref.FunctionConnector / mating part
J3Power and CAN data busMating part: Phoenix Contact 1027605
JP1120 Ω CAN termination1 mm pitch jumper
J5Debug and firmware programming14-pin STDC14 Cortex ribbon cable
J1Hardware ID pins8-pin header, 1.27 mm pitch
Power and CAN Data Bus (J3)

J3 carries power input and the CAN bus. The mating connector is the Phoenix Contact 1027605.

J3 connector pin diagram: pins 1 to 3 in the top row and 4 to 6 in the bottom row
J3 connector pin diagram
PinNetType
1NCNot connected
25VPower input
3GNDPower input
4GNDPower input
5CAN_HI/O
6CAN_LI/O
120 Ω Termination Jumper (JP1)

Fitting a jumper on JP1 connects a 120 Ω termination across the CAN bus. Jumper pitch: 1 mm.

STDC14 Debug Connector (J5)

J5 is designed for use with the ST-LINK-V3MINIE and can be used to debug the board or load firmware onto the receiver. Mating part: 14-pin STDC14 Cortex ribbon cable.

PinSignal
3+3.3V
4SWDIO
5, 7, 11GND
6SWCLK
12NRST
1, 2, 8, 9, 10, 13, 14Not connected
Hardware ID Pins (J1)

J1 is an 8-pin header (1.27 mm pitch) with four ID rows. Each row has an ID pin and, beside it, a ground pin. Fitting a jumper across a row sets that bit of the hardware ID to 1; an open row reads 0. The node ID is 16 plus this 4-bit number, so the jumpers select 16 to 31, and the node ID is 16 with no jumpers fitted. The pins are read at start-up only: reset or power-cycle the board after changing a jumper. Each fitted jumper draws about 0.33 mA. An ID from 1 to 127 can also be stored over CAN; a stored ID takes priority over the jumpers.

J1 hardware ID header: rows 1 to 4, ID pins in the left column and ground pins in the right column
J1 hardware ID pin diagram (rows 1 to 4, from pin 1; the right-hand column is ground)
Row 1 (bit 0)Row 2 (bit 1)Row 3 (bit 2)Row 4 (bit 3)Node ID (decimal)Node ID (hex)
0000160x10
1000170x11
0100180x12
1010210x15
1111310x1F

Software and firmware

This board is a DroneCAN (UAVCAN v0) node. It uses classic CAN (CAN FD is not used) at 1 Mbit/s with 29-bit identifiers.

Node ID

Every node on a DroneCAN bus has a unique node ID from 1 to 127, which is the source address of the messages it sends. The ID is 16 plus the jumper setting, unless an ID has been stored over CAN.

To set the ID over CAN, use the standard DroneCAN parameter services (for example in the DroneCAN GUI tool): write the integer parameter NODE_ID (1 to 127) with uavcan.protocol.param.GetSet. The value is stored in flash straight away and is used after the node restarts, which can be requested with uavcan.protocol.RestartNode. Writing 0, or the ExecuteOpcode erase command, removes the stored ID so that the jumpers decide again. Values outside 0 to 127 are ignored. Writing flash stops the processor for a few tens of milliseconds, so do not change the ID while the aircraft depends on the GNSS data.

Priority

DroneCAN priorities run from 0 (highest) to 31 (lowest). The position message uses priority 16; the auxiliary and node status messages use priority 24.

Message Definitions

The board publishes the standard GNSS messages that flight controllers such as PX4 and ArduPilot use:

MessageType IDRatePriority
uavcan.equipment.gnss.Fix2106310 Hz16
uavcan.equipment.gnss.Auxiliary10611 Hz24
uavcan.protocol.NodeStatus3411 Hz24

The board also answers the services uavcan.protocol.GetNodeInfo (name, software version, unique ID), uavcan.protocol.param.GetSet and ExecuteOpcode (node ID, see above) and uavcan.protocol.RestartNode.

Fix2 fields
FieldDescription
gnss_timestampUTC time of the solution in microseconds since 1970-01-01. 0 until the receiver knows the date and time.
gnss_time_standard2 (UTC), or 0 when the time is not known.
timestampNetwork-synchronised time. Not available, always 0.
latitude_deg_1e8, longitude_deg_1e8Signed latitude and longitude in degrees × 10⁸.
height_ellipsoid_mm, height_msl_mmHeight above the ellipsoid and above mean sea level, in millimetres.
ned_velocityNorth, east and down velocity in m/s, from ground speed and course. The down component is 0.
sats_usedNumber of satellites used in the solution.
status0 = no fix, 2 = 2D fix, 3 = 3D fix.
mode0 = single; 1 = DGPS and 2 = RTK when the receiver reports them.
pdopPosition dilution of precision.
covarianceNot provided (empty). Receivers derive accuracy from the dilution of precision in Auxiliary.

Auxiliary fields

FieldDescription
pdop, hdop, vdopPosition, horizontal and vertical dilution of precision.
gdop, tdop, ndop, edopNot provided (NaN).
sats_visible, sats_usedSatellites in view and satellites used in the solution.
NodeStatus health

Having no fix is not a fault. The node status reports a fault only when the GNSS receiver is missing or silent:

HealthVendor status codeMeaning
OK0The receiver is producing solutions.
WARNING2The receiver has sent no solution for 3 seconds.
ERROR1The receiver has not answered on I²C.

Firmware

Firmware source code and firmware binaries are published in the Ether Form Inc GitHub organization:

github.com/Ether-Form-Inc

Resources

References

[1] “4.1 CAN bus transport layer – DroneCAN,” GitHub Pages, 2025. https://dronecan.github.io/Specification/4.1_CAN_bus_transport_layer/ (accessed Sept. 9, 2026).

Request a quote or discuss your integration

Choose the inquiry type that fits. A standard bulk quote only needs a quantity and your contact details; engineering and customization inquiries need a short description of what you need.