User Manual
Autonomous Navigation Solutions

Inertial Sense, Inc.
©2022

Table of Contents

Table of Contents
1. Overview

5

1.1 IMX-5 (IMU, AHRS, and GPS-INS)

5

1.2 Features6

1.3 Interfaces

6

1.4 Applications

7

2. Data Sheets9

2.1 IMX-5 (IMU, AHRS, GNSS-INS)

9

2.2 GPX-1 (Multi-Band L1/L5 Dual GNSS Receiver)9

2.3 uINS-3

9

3. Dimensions and Pinouts

10

3.1 IMX-5 Series

10

3.2 µINS-3 Series

10

3.3 Hardware Design Files10

4. Getting Started

11

4.1 1. Installing Software11

4.2 2. Connecting Your Hardware

11

4.3 3. Configuring Settings

11

4.4 4. Evaluation and Testing12

4.5 Demonstration Videos

12

4.6 Troubleshooting

12

5. IS Hardware

13

5.1 Hardware Integration: IMX-5 Module

13

5.2 Hardware Integration: GPX-1 Module

19

5.3 Hardware Integration: uINS-3 Module

28

5.4 Hardware Integration: RUG-3-IMX-5 (Rugged-3)

33

5.5 Hardware Integration: Rugged-2

39

5.6 Hardware Integration: Rugged-1

44

5.7 Hardware Integration: IG-1-IMX-551

5.8 Hardware Integration: IG-2 (IMX5 + GPX1)

58

5.9 Hardware Integration: EVB-2

65

5.10 Hardware Integration: EVB-1

76

5.11 Hardware Design Files84

5.12 Reflow Soldering

85

6. IS Software87

6.1 CLTool87- 2/348 -©2022

Table of Contents

6.2 EvalTool

92

6.3 SDK

107

6.4 Log Inspector

109

7. Communication Protocols

112

7.1 Protocol Overview

112

7.2 Data Sets (DIDs)

113

7.3 Inertial Sense Binary (ISB) Protocol

177

7.4 NMEA 0183 (ASCII) Protocol

183

7.5 SPI Protocol

198

7.6 CAN Protocol

201

8. GNSS - RTK

209

8.1 Multi-band GNSS

209

8.2 External NMEA GNSS

236

8.3 GNSS Antennas

238

8.4 GNSS Satellite Constellations

243

8.5 RTK Positioning

244

8.6 Dual GNSS RTK Compassing

260

9. Dead Reckoning

267

9.1 Ground Vehicle Dead Reckoning

267

9.2 IMX Dead Reckoning Examples

270

10. General Configuration276

10.1 Infield Calibration276

10.2 Platform Configuration279

10.3 IMU INS GNSS Configuration

280

10.4 System Configuration

285

10.5 Time Synchronization

286

10.6 Zero Motion Command

290

10.7 UART Interface291

11. SDK

292

11.1 Inertial Sense SDK

292

11.2 Example Projects

294

12. Data Logging/Plotting

311

12.1 Data Logging/Plotting

311

12.2 Logging

314

12.3 Plotting

316

13. Reference317

13.1 Bootloader

317

13.2 Coordinate Frames318- 3/348 -©2022

Table of Contents

13.3 Definitions

322

13.4 Interference Considerations

324

13.5 Magnetometer326

13.6 System Status328

14. User Manual PDF

333

15. Frequently Asked Questions334

15.1 What is a Tactical Grade IMU?

334

15.2 Why the name change from uINS to IMX?

335

15.3 What is Inertial Navigation?

336

15.4 What does an Inertial Navigation System (INS) offer over GPS alone?

336

15.5 Our Sensors - IMU vs AHRS vs INS

336

15.6 How long can the IMX dead reckoning estimate position without GPS?

337

15.7 Can the IMX estimate position without GPS?

337

15.8 How does the IMX estimate roll/pitch during airborne coordinate turns (acceleration only in the Z axis and not in the
X and Y axes)?

337

15.9 How does vibration affect navigation accuracy?

337

15.10 Can the IMX operate underwater?

337

15.11 Can the IMX operate at >4g acceleration?

338

15.12 Customer Support

338

16. Troubleshooting

339

16.1 Firmware Troubleshooting

339

16.2 Chip Erase342

16.3 IMX Firmware Troubleshooting346- 4/348 -©2022

1. Overview

Software Release 1.11.2 - 27 Feb 2024

1. Overview
1.1 IMX-5 (IMU, AHRS, and GPS-INS)The IMX-5™ is a 10-DOF sensor module consisting of a tactical grade Inertial Measurement Unit (IMU), magnetometer, andbarometer. Output includes angular rate, linear acceleration, magnetic vector, and barometric pressure and altitude. IMU
calibration consists of bias, scale factor, cross-axis alignment, and temperature compensation. The IMX-5 includes Attitude
Heading Reference System (AHRS) sensor fusion to estimate roll, pitch, and heading. Adding GNSS input to the IMX-5 enables
onboard Inertial Navigation System (INS) sensor fusion for roll, pitch, heading, velocity, and position.

- 5/348 -©2022

1.2 Features

The RUG-3-IMX-5™ series adds a rugged aluminum enclosure and RS232, RS485, and CAN bus to the IMX-5.
The RUG-3-IMX-5-RTK™ includes a multi-frequency GNSS receiver with RTK precision position enabling INS sensor fusion forroll, pitch, heading, velocity, and position.
The RUG-3-IMX-5-Dual™ includes two multi-frequency GNSS receivers with RTK precision position and dual GNSS heading/compass.
The Inertial Sense SDK is an open-source software development kit for quick integration to configure and communicate with
Inertial Sense products. The SDK includes data logger, math libraries, and interface for Linux, Windows, and embedded
platforms.

1.2 Features• Tactical Grade IMU• Gyro: 1.5 °/hr Bias Instability, 0.16 °/√hr ARW• Accel: 19 µg Bias Instability, 0.02 m/s/√hr VRW• 0.04° Dynamic Roll/Pitch• 0.13° Dynamic Heading• Surface Mount Reflowable (PCB Module)• Up to 1KHz IMU Output Data Rate
• Small Form Factor: 15.6 x 12.5 x 2.9 mm• Light Weight: 0.8 g• Low power consumption: <110mW• External GNSS Support (Multi-Band)• Attitude (Roll, Pitch, Yaw, Quaternions), Velocity, and Position UTC Time Synchronized• Triple Redundant IMUs Calibrated for Bias, Scale Factor, Cross-axis Alignment, and G-sensitivity• -40°C to 85°C Sensor Temperature Calibration• Binary and NMEA Protocol• Barometric Pressure and Humidity• Strobe In/Out Data Sync (Camera Shutter Event)• Fast Integration with SDK and Example Software

1.3 Interfaces
IMX Module

EVB-2

Rugged

USB

Yes

Yes

Yes

TTL/UART

Yes

Yes

Yes

RS232/RS422/RS485

No

Yes

Yes

CAN

Yes

Yes

Yes

SPI

Yes

Yes

Yes

Integrated XBee Radio (RTK)No

Yes (Option)

No

WiFi/BTLE

No

Yes

No

GPS Antenna Ports (Dual=Compassing)No

Dual (Option)

Dual (Option)- 6/348 -©2022

1.4 Applications

1.4 Applications• Drone Navigation• Unmanned Vehicle Payloads• Stabilized Platforms• Antenna and Camera Pointing• First Responder and Personnel Tracking• Pedestrian and Auto Outdoor / Indoor Navigation• Health, Fitness, and Sport Monitors• Hand-held Devices• Robotics and Ground Vehicles• Maritime

Inertial Sense, Inc.
3000 S Sierra Vista Way Suite 2, Provo, UT 84606 USA
Phone 801-610-6771
Email support@inertialsense.com
Website: InertialSense.com© 2014-2024 Inertial Sense
Inertial Sense®, Inertial Sense logo and combinations thereof are registered trademarks or trademarks of Inertial Sense, Inc.
Other terms and product names may be trademarks of others.
DISCLAIMER: The information in this document is provided in connection with Inertial Sense products. No license, express or
implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of
Inertial Sense products. EXCEPT AS SET FORTH IN THE INERTIAL SENSE TERMS AND CONDITIONS OF SALES LOCATEDON THE INERTIAL SENSE WEBSITE, INERTIAL SENSE ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY
EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO
EVENT SHALL INERTIAL SENSE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR
INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS- 7/348 -©2022

1.4 Applications

INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF
INERTIAL SENSE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Inertial Sense makes no representations or
warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to makechanges to specifications and products descriptions at any time without notice. Inertial Sense does not make any commitment to
update the information contained herein. Unless specifically provided otherwise, Inertial Sense products are not suitable for, andshall not be used in, automotive applications. Inertial Sense products are not intended, authorized, or warranted for use ascomponents in applications intended to support or sustain life. SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVEAPPLICATIONS DISCLAIMER: Inertial Sense products are not designed for and will not be used in connection with any
applications where the failure of such products would reasonably be expected to result in significant personal injury or death(“Safety-Critical Applications”) without an Inertial Sense officer's specific written consent. Safety-Critical Applications include,
without limitation, life support devices and systems, equipment or systems for the operation of nuclear facilities and weaponssystems. Inertial Sense products are not designed nor intended for use in military or aerospace applications or environments
unless specifically designated by Inertial Sense as military-grade.

- 8/348 -©2022

2. Data Sheets

2. Data Sheets
2.1 IMX-5 (IMU, AHRS, GNSS-INS)
Download Datasheet

2.2 GPX-1 (Multi-Band L1/L5 Dual GNSS Receiver)Download Datasheet

2.3 uINS-3
Download Datasheet- 9/348 -©2022

3. Dimensions and Pinouts

3. Dimensions and Pinouts
3.1 IMX-5 Series
3.1.1 IMX-5 (Module)
Download PDF

3.1.2 GPX-1 (Module)
Download PDF

3.1.3 RUG-3-IMX-5-IMU
Download PDF

3.1.4 RUG-3-IMX-5-Dual
Download PDF

3.1.5 IG-1-IMX-5-Dual (Module)
Download PDF

3.2 µINS-3 Series
3.2.1 µINS-3 (Module)
Download PDF

3.2.2 RUG-2.0
Download PDF

3.2.3 RUG-1.1
Download PDF

3.3 Hardware Design FilesThe Inertial Sense hardware design files are available on our IS-hdw repository to facilitate product hardware development andintegration.
• Products - 3D models and resources for the IMX, Rugged, EVB, and products useful for CAD and circuit board designs.
Libraries for schematic and layout designs for printed circuit board.

- 10/348 -©2022

4. Getting Started

4. Getting Started
The following video is a quick intro to the EvalTool for Windows. For other applications scroll below.

4.1 1. Installing Software
Inertial Sense software provides a way to view, manipulate, stream, and record the data generated by a µINS, µAHRS, or µIMU.

4.1.1 EvalTool (Windows Only)
The EvalTool is a graphical Windows-based desktop program that allows users to explore and test functionality of the Inertial
Sense products in real-time.
Download the EvalTool installer from the Inertial Sense releases page. Run the .exe file and follow the instructions to complete
the installation.

4.1.2 CLTool (Windows, Linux, and OS X)
The CLTool is a command line utility that can be used to read and display data, update firmware, and log data from Inertial Sense
products.
CLTool must be compiled from our source code. Follow the instructions on the CLTool page.

4.1.3 SDK (Windows, Linux)
Software development kit to interface with Inertial Sense products.
Download the file named "Source code" from our releases page. The extracted folder contains code libraries as well as example
projects.

4.2 2. Connecting Your Hardware
Select the evaluation product from the list below to view instructions on basic connection to a computer.
• Rugged-3 Units• Rugged-2 Units• IMX-5 PCB Module• GPX-1 PCB Module

4.3 3. Configuring Settings
The configuration settings found in DID_FLASH_CONFIG need to be set to appropriate values using either the EvalTool, the
CLTool, or the SDK. A full explanation can be found on the System Configuration page. Most users initially configure the unit

- 11/348 -©2022

4.4 4. Evaluation and Testing

using the EvalTool. This is done by going to the Data Sets Tab and selecting DID_FLASH_CONFIG. The values of each field canthen be edited. Pay special attention to the following fields:
1. gps1AntOffset[X-Z] - Position offset of sensor frame with respect to GPS1 antenna.
2. gps2AntOffset[X-Z] - Position offset of sensor frame with respect to GPS2 antenna.
3. dynamicModel - Dynamic model that most closely represents sensor application.**Note - This feature is experimental. For most applications setting 8 will yield the best results. The user is encouraged to try
different settings.

4.4 4. Evaluation and TestingOnce a connection to the unit has been established, please follow one of the following guides to get started with the software toolof choice:• EvalTool• CLTool• SDK Example Projects

4.5 Demonstration Videos
4.5.1 Rugged-3-G2 GPS Compassing Configuration Demo
4.5.2 Rugged-3-G2 RS-485/422 Configuration Demo

4.6 Troubleshooting
If at any time issues are encountered, please check the troubleshooting sections of this manual.

- 12/348 -©2022

5. IS Hardware

5. IS Hardware
5.1 Hardware Integration: IMX-5 Module

5.1.1 Pinout
The IMX-5 module is pin compatible with the uINS-3.

- 13/348 -©2022

5.1.1 Pinout- 14/348 -©2022

5.1.1 Pinout

Pin

Name

I/O

Description0

Not Connected-

Not connected internally. Connect to ground (GND).

1

USB_P

I/O

USB Data Positive Line

2

USB_N

I/O

USB Data Negative Line

3

VBKUP

I

GNSS backup supply voltage. (1.4V to 3.6V) enables GNSS hardware
backup mode for hot or warm startup (faster GNSS lock acquisition).
MUST connect VBKUP to VCC if no backup battery is used.

4

G1/Rx2/RxCAN/

I/O

SCL

GPIO1
Serial 2 input (TTL)
Serial input pin from CAN transceiver*I2C SCL line

5

G2/Tx2/TxCAN/

I/O

SDA/STROBEGPIO2Serial 2 output (TTL)
Serial output pin to CAN transceiver*I2C SDA line
Strobe time sync input

6

G6/Rx1/MOSI

I/O

GPIO6
Serial 1 input (TTL)SPI MOSI7

G7/Tx1/MISO

I/O

GPIO7
Serial 1 output (TTL)SPI MISO8

G8/CS/STROBE

I/O

GPIO8
SPI CS
Strobe time sync input

9

G5/SCLK/STROBE

I/O

GPIO5
SPI SCLK
Strobe time sync input

10

G9/nSPI_EN/

I/O

GPIO9

STROBESPI Enable: Hold LOW during boot to enable SPI on G5-G8/STROBE_OUT/

Strobe time sync input or output. SPI data ready alternate location

DRDY
11,21,P

GND-

Supply ground

12

nRESETI

System reset on logic low. May be left unconnected if not used.

13

G14/SWCLKI/OGPIO1414

G13/DRDY/XSDA

I/OGPIO13
SPI Data Ready
Alt I2C SDA

15

G12/SWO/XSCLI/OGPIO12Alt I2C SCL

16

G11/SWDIOI/O

GPIO11

17

G10/BOOT_MODE

I/O

Leave unconnected. BOOT MODE used in manufacturing. !!! WARNING!!! Asserting a logic high (+3.3V) will cause the IMX to reboot into ROM
bootloader (DFU) mode.

18

G4/Rx0I/O

GPIO4Serial 0 input (TTL)- 15/348 -©2022

5.1.2 Application

Pin

Name

I/O

Description

19

G3/Tx0I/O

GPIO3Serial 0 output (TTL)20

G15/GNSS_PPS

I

Input for GNSS PPS for time synchronization pulse.

22

VCC

I

3.3V supply input*External transceiver required for CAN interface.

5.1.2 Application
Serial Interface
The following schematic demonstrates a typical setup for the IMX-5 module. A rechargeable lithium backup battery enables the
GNSS to perform a warm or hot start. If no backup battery is connected, VBKUP (pin 3) should be connected to VCC and themodule will perform a cold start on power up. If the system processor is not capable of updating the IMX firmware, it isrecommended to add a header to an alternate IMX serial port for firmware updates via an external computer. The reset line is notnecessary for typical use.
Optional Firmware
Update Header

+3.3V

+3.3V

D1

IMX Module

1

R1
1K

22
3

BAT1
3V

1

+

C1
0.1uF

17
16
15
14
13
12
11
21

System Processor

U1(U9)VCC
GPS.VBAT

G1/Rx2/RxCAN
G2/Tx2/TxCAN/STROBE
G3/Tx0G4/Rx0G10/BOOT_MODE
G11/JTAG_SWDIO
G5/SCLK/STROBE
G12/JTAG_SWO
G6/Rx1/MOSI
G13/DATA_RDY
G7/Tx1/MISO
G14/JTAG_SWCLK
G8/CS/STROBERESET
G9/SPI_EN/STROBE
GPS.TIMEPULSE
GND
GND

USB.DP
USB.DN

4
5
19
18
9
6
7
8
10
20

TTL Serial Tx
TTL Serial Rx
Timepulse Input

1
2

IS-uINS-3.2-G2

The following are recommended components for the typical application. Equivalent or better components may be used.
Designator

Manufacturer

Manufacturer #Description

BAT1

Panasonic

ML-614S/FN

BATTERY LITHIMU 3V RECHARGABLE SMD

D1Panasonic

DB2J31400L

DIODE SCHOTTKY 30V 0.03A SMINI2

R1

RES 1.00K OHM 1/16W 1%

C1

CAP CER .10UF 50V X7R 10%

SPI Interface
The SPI interface is enabled by holding the pin 10 low during boot up.

- 16/348 -©2022

5.1.3 Manufacturing

+3.3V

+3.3V

D1

IMX Module

1

R1
1K

22
3

BAT1
3V

1

+

C1
0.1uF

17
16
15
14
13
12
11
21

System Processor

U1(U9)VCC
GPS.VBAT

G1/Rx2/RxCAN
G2/Tx2/TxCAN/STROBE
G3/Tx0G4/Rx0G10/BOOT_MODE
G11/JTAG_SWDIO
G5/SCLK/STROBE
G12/JTAG_SWO
G6/Rx1/MOSI
G13/DATA_RDY
G7/Tx1/MISO
G14/JTAG_SWCLK
G8/CS/STROBERESET
G9/SPI_EN/STROBE
GPS.TIMEPULSE
GND
GND

USB.DP
USB.DN

4
5
19
18
9
6
7
8
10
20

SPI CLKSPI MOSISPI MISOSPI CS
Data Ready
Timepulse Input

1
2

IS-uINS-3.2-G2

5.1.3 Manufacturing
Soldering
The IMX-5 can be reflow soldered. Reflow information can be found in the Reflow Information page of this manual.

Tape Packaging
The IMX-5 modules are available in cut tape as well as tape and reel packaging. The follow image shows the feed direction andillustrates the orientation of the IMX-5 module on the tape:- 17/348 -©2022

5.1.4 Hardware Design

The feed direction to the pick and place pick-up is shown by the orientation of the IMX-5 pin 1 location. With pin 1 location on thebottom of the tape, the feed direction into the pick and place pick-up is from the reel (located to the right of the figure) towards
the left.
The dimensions of the tapes for the IMX-5 are shown in the drawing below:

5.1.4 Hardware Design
Recommend PCB Footprint and Layout
A single ceramic 100nF decoupling capacitor should be placed between and in close proximity to the IMX pins 21 and 22 (GND
and Vcc). It is recommended that this capacitor be on the same side of the PCB as the IMX and that there not be any vias
between the capacitor and the Vcc and GND pins. The default forward direction is indicated in the PCB footprint figure and on
the IMX shield as the X axis. The forward direction is reconfigurable in software as necessary.
Download PDF

5.1.5 Design Files
Open source hardware design files, libraries, and example projects for the IMX module are found at theInertial Sense Hardware Design repository hosted on GitHub. These include schematic and layout files forprinted circuit board designs, and 3D step models of the InertialSense products usable for CAD and circuitboard designs.

Reference Design Projects
The EVB-2 and IG-1 circuit board projects serve as reference designs that illustrate implementation of the IMX PCB module.
EVB-2 evaluation board
IG-1 module- 18/348 -©2022

5.2 Hardware Integration: GPX-1 Module

5.2 Hardware Integration: GPX-1 Module

5.2.1 Pinout
The GPX-1 module footprint and pinout similar that of the IMX-5 such that the common power and interface pins are at the same
location. The GPX-1 is extended to accommodate additional GNSS inputs and output. The GPX-1 is designed to work in
conjunction with the IMX-5.

- 19/348 -©2022

5.2.1 Pinout- 20/348 -©2022

5.2.1 Pinout

Pin

Name

Type

Description

0

GND

Power

Supply ground on center pads.

1

USB_P

I/O

USB full-speed Positive Line. USB will be supported in futurefirmware updates.

2

USB_N

I/O

USB full-speed Negative Line. USB will be supported in futurefirmware updates.

3

VBKUP

Power

Backup supply voltage input (1.75V to 3.6V). Future firmware updates
will use voltage applied on this pin to backup GNSS ephemeris,almanac, and other operating parameters for a faster startup when
VCC is applied again. This pin MUST be connected to a backup
battery or VCC.

4

G1/Rx2/RxCAN/

I/O

SCL

GPIO1
Serial 2 input (TTL)
Serial input pin from CAN transceiver*I2C SCL line

5

G2/Tx2/TxCAN/

I/O

SDA/STROBEGPIO2Serial 2 output (TTL)
Serial output pin to CAN transceiver*I2C SDA line
Strobe time sync input

6

G6/Rx1/MOSI

I/O

GPIO6
Serial 1 input (TTL)SPI MOSI7

G7/Tx1/MISO

I/O

GPIO7
Serial 1 output (TTL)SPI MISO8

G8/CS/STROBE

I/O

GPIO8
SPI CS
Strobe time sync input

9

G5/SCLK/

I/O

STROBEGPIO5
SPI SCLK
Strobe time sync input

10

G9/nSPI_EN/

I/O

GPIO9

STROBESPI Enable: Hold LOW during boot to enable SPI on G5-G8/STROBE_OUT/

Strobe time sync input or output. SPI data ready alternate location

DRDY
11,13,15,31

GND

Power

Supply ground12

GNSS1_RFI

GNSS1 antenna RF input. Use an active antenna or LNA with a gainof 15-25dB. Place the LNA as close to the antenna as possible.
Filtered 3.3V from VCC is injected onto the pad to power active
antennas (power injection can be disabled in software). Connect toground with 5V-14V TVS diode for ESD and surge projection (e.g.
Littlefuse PESD0402-140).

14

GNSS2_RFI

GNSS2 antenna RF input. Same requirements as GNSS1_RF

16

VCC_RF

O

Supply output for GNSS active antenna. Connect VCC_RF through33-120nH inductor (e.g. Murata LQW15ANR12J00D, 110mA max) to
GNSS1_RF and GNSS2_RF to inject DC supply for active antenna(s).
VCC_RF is supplied from VAUX through an onboard 1A load switch
and 10 ohm resistor.

- 21/348 -©2022

5.2.1 Pinout

Pin

Name

Type

Description

20

G20/LNA-EN

I/O

GPIO2021

GNSS2_PPSO

GNSS2 PPS time synchronization output pulse (1Hz, 10% duty cycle)

22

nRESETI

System reset on logic low. May be left unconnected if not used.

23

G14/SWCLKI/OGPIO1424

G13/DRDY/I/O

GPIO13XSDA

SPI Data Ready
Alt I2C SDA

25

G12/XSCLI/O

GPIO12Alt I2C SCL

26

G11/SWDIOI/O

GPIO11

27

G10/

I/O

Leave unconnected. BOOT MODE used in manufacturing. !!!

BOOT_MODEWARNING !!! Asserting a logic high (+3.3V) will cause the IMX toreboot into ROM bootloader (DFU) mode.

28

G4/Rx0I/O

GPIO4Serial 0 input (TTL)29

G3/Tx0I/O

GPIO3Serial 0 output (TTL)30

GNSS1_PPSO

GNSS1 PPS time synchronization output pulse (1Hz, 10% duty cycle)

32

VCC

Power

1.8V to 3.3V supply input.

38

G16/QDEC0.A

I/O

GPIO1639

G17/QDEC0.B

I/O

GPIO17

40

VAUX

Power

Input supplies for the USB and VCC_RF (GNSS antenna supply).
Connect to +3.3V (3.0V to 3.6V) to supply USB and VCC_RF. Can beleft floating if USB or VCC_RF are not needed.

41

G18/QDEC1.A

I/O

GPIO1842

G19/QDEC1.B

I/O

GPIO19*External transceiver required for CAN interface.

- 22/348 -©2022

5.2.2 Application

5.2.2 Application
GNSS-INS Block Diagram- 23/348 -©2022

5.2.2 Application

Typical Application: GPX-1 IMX-5

Designator

Manufacturer

Part Number

Description

D1, D2

Littlefuse

PESD0402-140

TVS DIODE 14VWM 40VC 0402

I1, I4

Murata

LQW15ANR12J00D

FIXED IND 120NH 110MA 2.66OHM SM- 24/348 -©2022

5.2.3 Layout Guidance

5.2.3 Layout Guidance
GNSS_RF Trace
The GNSS_RF trace should be designed to work in the combined GNSS L1 + L5 signal band.
For FR-4 PCB material with a dielectric permittivity of for example 4.2, the trace width for the 50 Ω line impedance can becalculated.
A grounded co-planar RF trace is recommended as it provides the maximum shielding from noise with adequate vias to theground layer.
The RF trace must be shielded by vias to ground along the entire length of the trace and the ZEDF9P RF_IN pad should besurrounded by vias as shown in the figure below.
[INSERT LAYOUT FIGURE HERE]- 25/348 -©2022

5.2.4 Design Guidance

5.2.4 Design Guidance
Backup Battery
For achieving a minimal Time To First Fix (TTFF) after a power down (warm starts, hot starts), make sure to connect a backup
battery to V_BCKP.
• Verify your battery backup supply can provide the battery backup current specified in the ZEDF9P datasheet.
• Allow all I/O including UART and other interfaces to float/high impedance in battery backup mode (battery back-up connectedwith VCC removed).

RF Front-end Circuit Options

Important
Active antenna(s) are required for the GPX-1.

5.2.5 Manufacturing
Soldering
The GPX-1 can be reflow soldered. Reflow information can be found in the Reflow Information page of this manual.

Tape Packaging
The GPX-5 modules are available in cut tape as well as tape and reel packaging. The follow image shows the feed direction andillustrates the orientation of the GPX-1 module on the tape:

The feed direction to the pick and place pick-up is shown by the orientation of the GPX-1 pin 1 location. With pin 1 location on
the bottom of the tape, the feed direction into the pick and place pick-up is from the reel (located to the right of the figure)towards the left.
The dimensions of the tapes for the GPX-1 are shown in the drawing below:- 26/348 -©2022

5.2.6 Hardware Design

5.2.6 Hardware Design
Recommend PCB Footprint and Layout
A single ceramic 100nF decoupling capacitor should be placed between and in close proximity to the module pins 31 and 32(GND and Vcc). It is recommended that this capacitor be on the same side of the PCB as the GPX and that there not be any vias
between the capacitor and the Vcc and GND pins.
Download PDF

5.2.7 Design Files
Open source hardware design files, libraries, and example projects for the GPX module are found at theInertial Sense Hardware Design repository hosted on GitHub. These include schematic and layout files forprinted circuit board designs, and 3D step models of the InertialSense products usable for CAD and circuitboard designs.

Reference Design Projects
Coming soon

- 27/348 -©2022

5.3 Hardware Integration: uINS-3 Module

5.3 Hardware Integration: uINS-3 Module

Warning
Our module must be hand soldered ONLY! Solder reflow may result in damage! See Soldering for details.

- 28/348 -©2022

5.3.1 Pinout

5.3.1 Pinout

Top View
USB.DP

VCC

USB.DN

GND

GPS_VBAT

GPS_PPS

G1/Rx2/RxCAN

G3/Tx0G2/Tx2/TxCAN/STROBEG4/Rx0
G6/Rx1/MOSICHIP_ERASE

G7/Tx1/MISO

Reserved

G8/CS/STROBE

Reserved

G5/SCLK/STROBEG13/DATA_RDY
G9/nSPI_EN/STROBE Reserved
GND

nRESETµIMU, µAHRS, and µINS Module- 29/348 -©2022

5.3.2 Application

Pin

Name

I/O

Description

1

USB_P

I/O

USB Data Positive Line

2

USB_N

I/O

USB Data Negative Line3

GPS_VBAT-

GPS backup supply voltage. (1.4V to 3.6V) enables GPS hardware backup
mode for hot or warm startup (faster GPS lock acquisition). MUST connect
GPS_VBAT to VCC if no backup battery is used.

4

G1/Rx2*/RxCAN*

I/O

GPIO1. Serial 2 input (TTL). Serial input pin from CAN transceiver**.

5

G2/Tx2*/TxCAN*/

I/O

GPIO2. Serial 2 output (TTL). Serial output pin to CAN transceiver**.

STROBE

Strobe time sync input.

6

G6/Rx1/MOSII/OGPIO6. Serial 1 input (TTL). SPI MOSI7

G7/Tx1/MISO

I/O

GPIO7. Serial 1 output (TTL). SPI MISO

8

G8/CS/STROBEI/O

GPIO8. SPI CS. Strobe time sync input.

9G5/SCLK/

I/O

GPIO5. SPI SCLK. Strobe time sync input.

I/O

GPIO9. Hold LOW during boot to enable SPI on G5-G8. Strobe time sync

STROBE
10

G9/nSPI_EN/
STROBE

input or output.

/STROBE_OUT
11

GND

-

-

12

nRESETI

System reset on logic low. May be left unconnected if not used.

13

Reserved-

14

Reserved-

15

Reserved-

16

Reserved-

17

Reserved (CE)-

Leave unconnected. CHIP ERASE used in manufacturing. !!! WARNING !!!
Asserting a logic high (+3.3V) will erase all IMX flash memory, including
calibration data.

18

G4/Rx0I/O

GPIO4. Serial 0 input (TTL)19

G3/Tx0I/O

GPIO3. Serial 0 output (TTL)20

GPS_PPSOGPS PPS time synchronization output pulse (1Hz, 10% duty cycle)

21

GND

-

-

22

VCC

-

3.3V regulated supply*Available on IMX-3.2 and later.
**External transceiver required for CAN interface.

5.3.2 Application
Serial Interface
The following schematic demonstrates a typical setup for the μINS module. A rechargeable lithium backup battery enables the
GPS to perform a warm or hot start. If no backup battery is connected, GPS.VBAT should be connected to VCC and the module
will perform a cold start on power up. If the system processor is not capable of updating the μINS firmware, it is recommended
to add a header to an alternate μINS serial port for firmware updates via an external computer. The reset line is not necessary
for typical use.

- 30/348 -©2022

5.3.2 Application

Optional Firmware
Update Header

+3.3V

+3.3V

D1

IMX Module

1

R1
1K

22
3

BAT1
3V

1

+

C1
0.1uF

17
16
15
14
13
12
11
21

System Processor

U1(U9)VCC
GPS.VBAT

G1/Rx2/RxCAN
G2/Tx2/TxCAN/STROBE
G3/Tx0G4/Rx0G10/BOOT_MODE
G11/JTAG_SWDIO
G5/SCLK/STROBE
G12/JTAG_SWO
G6/Rx1/MOSI
G13/DATA_RDY
G7/Tx1/MISO
G14/JTAG_SWCLK
G8/CS/STROBERESET
G9/SPI_EN/STROBE
GPS.TIMEPULSE
GND
GND

USB.DP
USB.DN

4
5
19
18
9
6
7
8
10
20

TTL Serial Tx
TTL Serial Rx
Timepulse Input

1
2

IS-uINS-3.2-G2

The following are recommended components for the typical application. Equivalent or better components may be used.
Designator

Manufacturer

Manufacturer #Description

BAT1

Panasonic

ML-614S/FN

BATTERY LITHIMU 3V RECHARGABLE SMD

D1Panasonic

DB2J31400L

DIODE SCHOTTKY 30V 0.03A SMINI2

R1

RES 1.00K OHM 1/16W 1%

C1

CAP CER .10UF 50V X7R 10%

SPI Interface
The SPI interface is enabled by holding the pin 10 low during boot up.

+3.3V

+3.3V

D1

IMX Module

1

R1
1K

22
3

BAT1
3V

1

+

C1
0.1uF

17
16
15
14
13
12
11
21

System Processor

U1(U9)VCC
GPS.VBAT

G1/Rx2/RxCAN
G2/Tx2/TxCAN/STROBE
G3/Tx0G4/Rx0G10/BOOT_MODE
G11/JTAG_SWDIO
G5/SCLK/STROBE
G12/JTAG_SWO
G6/Rx1/MOSI
G13/DATA_RDY
G7/Tx1/MISO
G14/JTAG_SWCLK
G8/CS/STROBERESET
G9/SPI_EN/STROBE
GPS.TIMEPULSE
GND
GND

USB.DP
USB.DN

4
5
19
18
9
6
7
8
10
20

SPI CLKSPI MOSISPI MISOSPI CS
Data Ready
Timepulse Input

1
2

IS-uINS-3.2-G2- 31/348 -©2022

5.3.3 Soldering

5.3.3 Soldering
Warning
These parts must be hand soldered ONLY! Solder reflow may result in damage!

The IMX, uAHRS, and uIMU are designed as surface mount components that can be hand soldered onto another circuit board.
These parts are not designed to withstand the high temperatures associated with standard solder reflow processes. Solder
assembly must be done using a soldering iron.

5.3.4 Hardware Design
Recommend PCB Footprint and Layout
A single ceramic 100nF decoupling capacitor should be placed in close proximity between the Vcc and GND pins. It is
recommended that this capacitor be on the same side of the PCB as the μINS and that there not be any vias between thecapacitor and the Vcc and GND pins. The default forward direction is indicated in the PCB footprint figure and on the μINS
silkscreen as the X axis. The forward direction is reconfigurable in software as necessary.
Download PDF

5.3.5 Design Files
Open source hardware design files, libraries, and example projects for the IMX module are found at theInertial Sense Hardware Design repository hosted on GitHub. These include schematic and layout files forprinted circuit board designs, and 3D step models of the InertialSense products usable for CAD and circuitboard designs.

Reference Design Projects
The EVB-2 and IG-1 circuit board projects serve as reference designs that illustrate implementation of the IMX PCB module.
EVB-2 evaluation board
IG-1 module- 32/348 -©2022

5.4 Hardware Integration: RUG-3-IMX-5 (Rugged-3)

5.4 Hardware Integration: RUG-3-IMX-5 (Rugged-3)

The RUG-3-IMX-5 series adds a rugged aluminum enclosure and RS232, RS485, and CAN bus to the IMX-5.
The RUG-3-IMX-5-RTK includes a multi-frequency GNSS receiver with RTK precision position enabling INS sensor fusion forroll, pitch, heading, velocity, and position.
The RUG-3-IMX-5-Dual includes two multi-frequency GNSS receivers with RTK precision position and dual GNSS heading/compass.
• Integrated CAN transceiver, RS232, RS485, TTL serial, USB, and SPI interfaces.
• Dual onboard multi-band GNSS receiver(s).
• Dual antenna ports for GPS compassing.

5.4.1 Features• Tactical Grade IMU• Gyro: 1.5 °/hr Bias Instability, 0.16 °/√hr ARW• Accel: 19 µg Bias Instability, 0.02 m/s/√hr VRW• INS, AHRS
• Dynamic: 0.04° Roll/Pitch, 0.13° Heading• Static: 0.1° Roll/Pitch, 0.5° Heading• Up to 1KHz IMU Output Data Rate
• Dual onboard multi-band (L1/L2/E5) GNSS receivers• Dual MMCX antenna ports for GPS compassing• Size: 25.4 x 25.4 x 20.0 mm• Light weight: 14g• Low power consumption: <1500mW• UART x3, RS232, RS485, CAN, and SPI interfaces• Integrated CAN and RS232 / RS485 transceivers• Voltage regulation for 4V - 20V input- 33/348 -©2022

5.4.2 Applications

5.4.2 Applications• Drone Navigation• Unmanned Vehicle Payloads• Ground and Aerial Survey• Automotive Navigation• Stabilized Platforms• Antenna and Camera Pointing• First Responder and Trackers• Health, Fitness, and Sport Monitors• Robotics and Ground Vehicles• Maritime

5.4.3 Connecting Your Unit
For the purposes of basic evaluation, the easiest interface available on the rugged is the included USB to Gecko connector cable,
included in the evaluation kit. The cable provides power and communications with the installed module via USB virtual
communications port.

GPS Antenna Ports
If using GPS with the module, connect an appropriate antenna to MMCX port 1 (GPS1). If the module is used for RTK
compassing, connect a second antenna to MMCX port 2, (GPS2).

5.4.4 Pinout
Warning
The pin numbering of the Rugged main connector does not match that of the connector manufacturer. Please refer to the drawings in
the Dimensions and Pinouts page for the correct pin numbering.

- 34/348 -©2022

5.4.4 Pinout

The following table shows the Rugged-3 pinout. Note that pin function can change based on changing
DID_FLASH_CONFIG.platformConfig (see I/O Configuration below).

Rugged

IMX

Pin

Pin

1
2

G9

Name

I/O

Description

GND

PWR

-

G9_STROBE

I/O

G9-Strobe time sync input. (Includes 3K ohm
series resistor)

3

VIN

PWR

4V-20V supply voltage input

4

USB.D+I/O

USB Data Positive Line5

GPS_PPSOGPS PPS time synchronization output pulse(1Hz, 10% duty cycle)

6
7

8

9

10

11

12

USB.D-I/O

USB Data Negative Line

G3

Tx0

O

Serial 0 output (TTL or RS232)

G2

485Tx1+O

Serial 1 output+ (RS485/RS422)

G5

SCLK

I

SPI clock

G2

Tx2

O

Serial 2 output (TTL)G2

485Tx1-O

Serial 1 output- (RS485/RS422)

G7

Tx1, MISO

O

Serial 1 output (TTL or RS232), SPI MISO

G4

Rx0

I

Serial 0 input (TTL or RS232)

G1

485Rx1-

I

Serial 1 input- (RS485/RS422)

G8

CS, G8_STROBEI

SPI chip select, G8-Strobe time sync input

G1

Rx2

I

Serial 2 input (TTL)

G1

485Rx1+

I

Serial 1 input+ (RS485/RS422)

G6

Rx1, MOSII

Serial 1 input (TTL or RS232), SPI MOSI

G1

CANL*
Rx2**

I/O

G1

High level (CAN bus)
Serial 2 input (TTL)**

G2

CANH*

I/O

G2

Tx2,

I/O

I

G2_STROBE**

Low level (CAN bus)*.
Serial 2 output (TTL)**, G2-Strobe time sync
input*** (Default) To enable CAN bus on pins 11,12 remove R16,R17 and add 0402 zero ohm jumpers to R14,R15.
** To enable Serial2 TTL or STROBE on pins 11,12 remove R14,R15 and add 0402 zero ohm jumpers to R16,R17.

- 35/348 -©2022

5.4.4 Pinout- 36/348 -©2022

5.4.5 I/O Configuration

5.4.5 I/O Configuration
The Rugged 3 "MAIN" connector pinout can be configured for USB, TTL, RS232, RS485, and CAN by setting the
DID_FLASH_CONFIG.platformConfig .

RUG-3 Pin

7,9

8,10

11,12

IMX Pin

G3,G4

G1,G2

G1,G2

GPS1

GPS2

(G5,G8)I/O Preset
1*

S0-RS232

CAN

S1

2

S0-TTLCAN

S1

3

S0-TTL

S2-TTL or

S1

G2-STROBE
4

S0-RS232

S1-RS232

S2

5

S1-RS485

S1-RS485

S2

S0

6

SPI or

SPI

S2

S0

S1-RS232

S2

S0

S1

S0

S1

S0

G8-STROBE
7 **
8
9

CAN
S2-TTL* RUG-3-G0 default** RUG-3-G2 default

5.4.6 Hardware Versions
The following outlines differences in the RUG-3 hardware versions.
RUG-3.1
Use platform config RUG-3 with this hardware version.
• GPS1 PPS line connected to IMX G15 (pin 20).
• RS485 Tx pins polarity swapped between pins 7,8 (from RUG-2)
RUG-2.1 (RUG-3.0)
Use platform config RUG-2.1 with this hardware version.
• GPS1 PPS line connected to IMX G9 (pin 10).
• MAIN pin 5 is connected to IMX G15 (pin 20).
• MAIN pin 5 is not connected to GPS1 PPS.

- 37/348 -©2022

5.4.7 Related Parts

5.4.7 Related Parts
Part

Manufacturer

Manufacturer #Description

Main Connector

HarwinG125-

1.25MM F/F 12POS 26AWG 150MM

FC11205L0-0150L
GPS antenna SMA

Crystek

adapter

Corporation

CCSMX-FBM-RG178-6

6" MMCX to SMA GPS antenna adaptor

GPS antenna SMA

Crystek

CCSMX1-FBM-

6" R/A MMCX to SMA GPS antenna

adapter

Corporation

RG178-6

adaptor cable.

cable.

See the Multi-Band GNSS page for GNSS antenna options.

5.4.8 Using with Inertial Sense Software
Please return to the getting started page to get started programming, updating firmware, viewing data, and logging.

- 38/348 -©2022

5.5 Hardware Integration: Rugged-2

5.5 Hardware Integration: Rugged-2

The Inertial Sense Rugged-2.0 is a ruggedized carrier board and case for the Inertial Sense µINS, µAHRS, or µIMU module. The
Rugged-2.0 has similar functions compared to the EVB-1, but in a more compact form factor with the following added features:• Onboard multi-band GNSS receiver(s)• Dual antenna ports for GPS compassing• Integrated CAN transceiver

5.5.1 Connecting Your Unit
For the purposes of basic evaluation, the easiest interface available on the rugged is the included USB to Gecko connector cable,
included in the evaluation kit. The cable provides power and communications with the installed module via the on-board FTDI
chip.

GPS Antenna Ports
If using GPS with the module, connect an appropriate antenna to MMCX port 1. If the module is used for RTK compassing,connect a second antenna to MMCX port 2. MMCX port 1 is for GPS1 and MMXC port 2 is GPS2.

- 39/348 -©2022

5.5.2 Pinout

5.5.2 Pinout
Warning
The pin numbering of the Rugged main connector does not match that of the connector manufacturer. Please refer to the drawings in
the Dimensions and Pinouts page for the correct pin numbering.

Pin

Name

I/O

Description

1

GND

PWR

-

2

G5/STROBE

I/O

Strobe time sync input. (Includes 390 ohm series
resistor)

3

VIN

PWR

4V-20V supply voltage input

4

USB.D+I/O

USB Data Positive Line5

GPS_PPSOGPS PPS time synchronization output pulse (1Hz, 10%
duty cycle)

6

USB.D-I/O

USB Data Negative Line7

G3/Tx0/485Tx2-

I/O

Serial 0 output (TTL or RS232)
Serial 2 output- (RS485/RS422)

8

G2/Tx2/485Tx2+

I/O

Serial 2 output (TTL or RS232)
Serial 2 output+ (RS485/RS422)

9

G4/Rx0/485Rx2-

I/O

Serial 0 input (TTL or RS232)
Serial 2 input- (RS485/RS422)

10

G1/Rx2/485Rx2+

I/O

Serial 2 input (TTL/RS232)
Serial 2 input+ (RS485 or RS422)

11

G1/CANL1/Rx21

I/O

High level (CAN bus). Serial 2 input (TTL).

12

G2/CANH1/Tx21/

I/O

Low level (CAN bus). Serial 2 output (TTL). Strobe timesync input.

STROBE
1Only available with uINS-3.2 and later.

5.5.3 I/O Configuration
The "MAIN" connector pinout on the Rugged product line can be configured for USB, TTL, RS232, CAN, and RS485 by setting
the dipswitches.

- 40/348 -©2022

5.5.3 I/O Configuration- 41/348 -©2022

5.5.4 Dipswitch Config

5.5.4 Dipswitch Config
The Rugged-2.0 dip switches are used for setting the following I/O configurations.
Pins

Mode

Switches-

Tx0, Rx0: onboard GPS2

* 8 - ON7

Tx0 (RS232)

5,6 - ON9

Rx0 (RS232)

8 - OFF7

Tx0 (TTL)

6,8 - OFF9

Rx0 (TTL)

8

Tx2 (RS232)

5,6 - ON10

Rx2 (RS232)

7 - OFF8

Tx2 (TTL)

6,7 - OFF10

Rx2 (TTL)

7

Tx2- (RS485)

6 - ON8

Tx2+ (RS485)

5,7 - OFF9

Rx2- (RS485)

10

Rx2+ (RS485)

11

CAN-H

12

CAN-L

11

G1-Rx2, CAN-Rx**

7 - ON12

G2-Tx2, CAN-Tx**, STROBE

1,2,3 - OFF* 1,2,3,7 - ON

* Factory default settings:• Dual GPS units: All dip switches ON by default (Serial 0 used for onboard GPS2, CAN on pins 11 and 12)• Single GPS units: Dip switch 8 OFF by default (Serial 0 used for RS232 on pins 7 and 9, CAN on pins 11 and 12)** CAN transceiver bypassed.
See the Multi-Band GNSS page for configuration information.

- 42/348 -©2022

5.5.5 To open the Rugged-2.0:

5.5.5 To open the Rugged-2.0:
Caution! Use of a grounding strap or other ESD protection device is advised.
1. Completely remove power from the unit.
2. Remove the 3 5/16" screws from the bottom of the Rugged-2.0.
3. Gently separate the top and bottom halves from each other pealing them apart opening from the side with the green connector.
• The two halves maybe somewhat adhered due to the thermal pad used in the device. Consistent gentle pressure will separatethem.
• As the device starts to open, do not open the unit past 90 degrees. If flexed to often and beyond 90 degrees the ribbon will breakcausing the unit to be damaged beyond repair.
4. Remove Kapton tape from the DIP Switch. (Save the tape!)
5. Make your adjustment for the desired configuration. (see table above for switch configurations)• Use of a small screwdriver or tweezers work well.
• It should not take much of force to move the desired switch.
6. Replace the Kapton tape.
7. Closed the two halves and install the 3 5/16" screws back in the bottom.
Done!

5.5.6 Related Parts
Part

Manufacturer

Manufacturer #Description

Main Connector

HarwinG125-

1.25MM F/F 12POS 26AWG 150MM

FC11205L0-0150L
GPS antenna SMA

Crystek

adapter

Corporation

CCSMX-FBM-RG178-6

6" MMCX to SMA GPS antenna adaptor

GPS antenna SMA

Crystek

CCSMX1-FBM-

6" R/A MMCX to SMA GPS antenna

adapter

Corporation

RG178-6

adaptor cable.

cable.

See the Multi-Band GNSS page for GNSS antenna options.

5.5.7 Using with Inertial Sense Software
Please return to the getting started page to get started programming, updating firmware, viewing data, and logging.

- 43/348 -©2022

5.6 Hardware Integration: Rugged-1

5.6 Hardware Integration: Rugged-1

The Inertial Sense Rugged-1 is a ruggedized carrier board and case for the Inertial Sense µINS, µAHRS, or µIMU module. The
Rugged-1 has similar functions compared to the EVB-1, but in a more compact form factor with the following added features:• Dual antenna ports for GPS compassing• Integrated CAN transceiver

5.6.1 Connecting Your Unit
For the purposes of basic evaluation, the easiest interface available on the rugged is the included USB to Gecko connector cable,
included in the evaluation kit. The cable provides power and communications with the installed module via the on-board FTDI
chip.

GPS Antenna Ports
If using GPS with the module, connect an appropriate antenna to MMCX port 1. If the module is used for RTK compassing,connect a second antenna to MMCX port 2. MMCX port 1 is for GPS1 and MMXC port 2 is GPS2. These port were labeled A and
B on older Rugged-1 units.

- 44/348 -©2022

5.6.2 Pinout

5.6.2 Pinout
Warning
The pin numbering of the Rugged main connector does not match that of the connector manufacturer. Please refer to the drawings in
the Dimensions and Pinouts page for the correct pin numbering.

Pin

Name

I/O

Description

1

GND

-

-

2

VIN

-

4V-20V supply voltage input1

3

USB.VCC-

5V system supply input1 from USB bus. Using this pin will enable the
FTDI USB. Use the VIN pin instead to disable the FTDI USB.

4

USB.D+I/O

USB Data Positive Line5

GPS_PPSOGPS PPS time synchronization output pulse (1Hz, 10% duty cycle)

6

USB.D-I/O

USB Data Negative Line7

G3/Tx0/485Tx1-

I/O

Serial 0 output (TTL or RS232)2
Serial 1 output- (RS485/RS422)3

8

G7/Tx1/485Tx1+

I/O

Serial 1 output (TTL or RS232)2
Serial 1 output+ (RS485/RS422)39

G4/Rx0/485Rx1-

I/O

Serial 0 input (TTL or RS232)2
Serial 1 input- (RS485/RS422)3

10

G6/Rx1/485Rx1+

I/O

Serial 1 input (TTL/RS232)3
Serial 1 input+ (RS485 or RS422)3

11

G1/CANL4/Rx24

I/O

High level (CAN bus)4. Serial 2 input (TTL)4.

12

G2/CANH4/Tx24/

I/O

Low level (CAN bus)4. Serial 2 output (TTL)4. Strobe time sync input.

STROBE
1The System can be powered either by VIN or USB.VCC.
2Serial 0 is configured with SMD jumpers for TTL, RS232, or FTDI USB (default, USB.D+ and USB.D-).
3Serial 0 is configured with SMT jumpers for TTL, RS232 (default), or RS485/RS422.
4

Only available with uINS-3.2 and later.

5.6.3 Jumpers
The "MAIN" connector pinout on the Rugged product line can be configured for USB, TTL, RS232, CAN, and RS485 by setting
the dip switches for Rugged v1.1 and by setting the onboard PCB surface mount jumpers for Rugged-1.0. Jumper resistors are
470 Ω resistors. All jumpers are 0402 SMD 1/16W (5% or better tolerance) resistors.

Serial Port 0
To enable FTDI USB on pins 4 and 6, provide system supply voltage input on USB.VCC (pin 3). To disable FTDI USB and use TTLor RS232 on pins 7 and 9, provide system supply voltage input on VIN (pin 2).

- 45/348 -©2022

5.6.3 Jumpers

SER0: FTDI USB (DEFAULT)SER0: TTL

SER0: RS232- 46/348 -©2022

5.6.3 Jumpers

Serial Port 1
SER1: RS232 (DEFAULT)SER1: TTL

- 47/348 -©2022

5.6.4 USB Driver

SER1: CAN

SER1: RS485/RS422 AND SER0: FTDI USB

To enable RS485/RS422, jumper R22 must be set in the direction of the "485" silkscreen label. RS485/RS422 signals Tx- and Tx+
are on pins 7 and 8 and Rx- and Rx+ are on pins 9 and 10. In this configuration, serial port 0 can only be accessed through the
FTDI USB interface and cannot be accessed through pins 7 and 9.

5.6.4 USB Driver
The rugged unit uses the FTDI FT232R USB to UART IC to provide a serial port from the USB connection. Depending on theoperating system, it may be necessary to download and install the FTDI device driver for the FT232R to register properly as aserial port.

5.6.5 Rugged v1.1 Dipswitch Config
Version 1.1 has dip switches that replaced the jumpers of v1.0 for common configurations.

- 48/348 -©2022

5.6.5 Rugged v1.1 Dipswitch Config

Mode

Switches

Jumpers** CAN* 2,3 - ONn/a

* 1,4 - OFF
CAN Disabled

1,4 - ON

G2_Strobe on pin 12

2,3 - OFF

Ser0: RS232, Ser1: RS232* 5,6,7,8 - OFFn/a* R10/R12 - No Load
* R14/R16 - Load

Ser0: RS232, Ser1: TTL* 5,6,7,8 - OFF

R10/R12 - Load
R14/R16 - No Load

Ser0: TTL, Ser1: TTL

Ser1: RS485, Ser0: Disabled

5,6,7 - ON

R10/R12 - Load

8 - OFF

R14/R16 - No Load

8 - ON* R10/R12 - No Load

7 - OFF* R14/R16 - Load

* Factory default setting- 49/348 -©2022

5.6.6 Related Parts** CAN Bus Operation
System input voltage monitor surface mount resistors and capacitor (R2, R3, and C1) must be removed for proper high speed
CAN bus operation.

5.6.6 Related Parts
Part

Manufacturer

Manufacturer #Description

Main Connector

HarwinG125-

1.25MM F/F 12POS 26AWG 150MM

FC11205L0-0150L
GPS antenna SMA

Crystek

adapter

Corporation

CCSMX-FBM-RG178-6

6" MMCX to SMA GPS antenna adaptor

GPS antenna SMA

Crystek

CCSMX1-FBM-

6" R/A MMCX to SMA GPS antenna

adapter

Corporation

RG178-6

adaptor cable.

cable.

5.6.7 Using with Inertial Sense Software
Please return to the getting started page to get started programming, updating firmware, viewing data, and logging.

- 50/348 -©2022

5.7 Hardware Integration: IG-1-IMX-5

5.7 Hardware Integration: IG-1-IMX-5

The Inertial Sense IG-1 is a PCB module with IMX-5 and dual ublox ZED-F9P multi-frequency GNSS receivers.
• Surface mount reflowable.
• Onboard dual GNSS for simultaneous RTK positioning and GPS compassing.
• Micro USB and 14 pin I/O header for convenient evaluation.

5.7.1 Pinout
Module Pinout- 51/348 -©2022

5.7.1 Pinout

Header H1 Pinout- 52/348 -©2022

5.7.1 Pinout- 53/348 -©2022

5.7.1 Pinout

The module and header H1 have the same pinout assignment for pins 1-14. All pins 15 and above are only on the module.

- 54/348 -©2022

5.7.1 Pinout

ModuleName

I/O

Description

GND

PWR

All other pins not shown in the image are pin 0 tied to GND.

GND

PWR

-

VIN

PWR

4V-20V supply voltage input

+3.3V

PWR

Regulated 3.3V supply input/output.

& H1 Pin
0
1
2
3
4
5

Reserved
G1/Rx2/RxCAN/SCL

Not Connected
I/O

GPIO1
Serial 2 input (TTL)
Serial input pin from CAN transceiver*I2C SCL line6

6

G2/Tx/TxCAN/SDA/

I/O

STROBE

GPIO2
Serial 2 output (TTL)
Serial output pin to CAN transceiver*I2C SDA line
Strobe time sync input

7

8

9

G3/Tx0I/O

GPIO3Serial 0 output (TTL)

G4/Rx0I/O

GPIO4Serial 0 input (TTL)

G5/SCLK/STROBE

I/O

GPIO5
SPI SCLK
Strobe time sync input

10

G6/Rx1/MOSI

I/O

GPIO6
Serial 1 input (TTL)SPI MOSI11

G7/Tx1/MISO

I/O

GPIO7
Serial 1 output (TTL)SPI MISO12

G8/CS/STROBE

I/O

GPIO8
SPI CS
Strobe time sync input

13

G9/nSPI_EN/

I/O

GPIO9

STROBESPI Enable: Hold LOW during boot to enable SPI on G5-G8/STROBE_OUT/

Strobe time sync input or output. SPI data ready alternate location.

SPI_DRDY
GPS.TIMEPULSEOGPS PPS UTC time synchronization signal.

15

GND

I/O

-

16

VBAT

I/O

GPS backup supply voltage. (1.4V to 3.6V) enables GPS hardware

14

backup mode for hot or warm startup (faster GPS lock acquisition).
MUST connect GPS_VBAT to VCC if no backup battery is used.
17

G10/BOOT_MODE

I/O

Leave unconnected. BOOT MODE used in manufacturing. !!!
WARNING !!! Asserting a logic high (+3.3V) will cause the IMX toreboot into ROM bootloader (DFU) mode.

- 55/348 -©2022

5.7.2 Hardware Versions

ModuleName

I/O

Description

18

G11

I/O

GPIO11

19

G12

I/O

GPIO12& H1 Pin

GPS reset
20

G13/DRDYI/O

GPIO13
SPI data ready21

G14/SWCLKI/OGPIO1422

nRESETI

System reset on logic low. May be left unconnected if not used.

23

GND

PWR

-

24

USB_N

I/O

USB Data Negative Line

25

USB_P

I/O

USB Data Positive Line

5.7.2 Hardware Versions
The following outlines differences in the IG-1.x hardware versions.
IG-1.1• GPS1 PPS line connected to IMX TIMEPUSE G15 (pin 20).
IG-1.0• GPS1 PPS line connected to IMX G8 (pin 8).

5.7.3 Soldering
The IMX-5 can be reflow soldered. Reflow information can be found in the Reflow Information page of this manual

5.7.4 Hardware Design
Recommend PCB Footprint and Layout
The default forward direction is indicated in the PCB footprint figure and on the silkscreen as the X axis. The forward direction isreconfigurable in software as necessary.
Download PDF

5.7.5 Design Files
Open source hardware design files, libraries, and example projects for the IMX module are found at theInertial Sense Hardware Design repository hosted on GitHub. These include schematic and layout files forprinted circuit board designs, and 3D step models of the InertialSense products usable for CAD and circuitboard designs.

Reference Design Projects
The IG-1 circuit board projects serve as reference designs that illustrate implementation of the IMX PCB module.
IG-1-G2 module
IG-1-G1 module- 56/348 -©2022

5.7.6 Related Parts

5.7.6 Related Parts
Part

Manufacturer

Manufacturer #Description

H1

JST

GHR-14V-S

14 pin connector 1.25mm pitch for IMX I/O connection.

- 57/348 -©2022

5.8 Hardware Integration: IG-2 (IMX5 + GPX1)

5.8 Hardware Integration: IG-2 (IMX5 + GPX1)

The Inertial Sense IG-2 is a PCB module with IMX-5 and GPX-1 multi-frequency GNSS receiver.
• Surface mount reflowable.
• Onboard dual GNSS for simultaneous RTK positioning and GPS compassing.
• Micro USB and 14 pin I/O header for convenient evaluation.

5.8.1 Pinout
Module Pinout- 58/348 -©2022

5.8.1 Pinout

Header H1 Pinout- 59/348 -©2022

5.8.1 Pinout- 60/348 -©2022

5.8.1 Pinout

The IG-2 module and IG-2 header H1 have the same pinout assignment for pins 1-14. Because H1 only has 14 pins, pins 15 andabove listed in the following table are only on the IG-2 module.

- 61/348 -©2022

5.8.1 Pinout

IG-2

Name

I/O

Description

GND

PWR

All other pins not shown in the image are pin 0 tied to GND.

GND

PWR

-

VIN

PWR

4V-20V supply voltage input

+3.3V

PWR

Regulated 3.3V supply input/output.

Module& IG-2H1 Pin0
1
2
3
45Reserved
G1/Rx2/RxCAN/SCL

Not Connected
I/O

IMX GPIO1
Serial 2 input (TTL)
Serial input pin from CAN transceiver*I2C SCL line6

6

G2/Tx/TxCAN/SDA/

I/O

STROBEIMX GPIO2
Serial 2 output (TTL)
Serial output pin to CAN transceiver*I2C SDA line
Strobe time sync input

7

8

9

G3/Tx0I/O

IMX GPIO3
Serial 0 output (TTL)

G4/Rx0I/O

IMX GPIO4
Serial 0 input (TTL)

G5/SCLK/STROBEI/OIMX GPIO5SPI SCLK
Strobe time sync input

10

G6/Rx1/MOSII/O

IMX GPIO6
Serial 1 input (TTL)SPI MOSI11

G7/Tx1/MISO

I/O

IMX GPIO7
Serial 1 output (TTL)SPI MISO12

G8/CS/STROBEI/OIMX GPIO8SPI CS
Strobe time sync input

13

G9/nSPI_EN/

I/O

IMX GPIO9STROBESPI Enable: Hold LOW during bootup to enable SPI on G5-G8/STROBE_OUT/

Strobe time sync input or output. SPI data ready alternate location.

SPI_DRDY
GPS.TIMEPULSEOGPS PPS UTC time synchronization signal.

15

GND

I/O

-

16

VBAT

I/O

GPS backup supply voltage. (1.4V to 3.6V) enables GPS hardware

14

backup mode for hot or warm startup (faster GPS lock acquisition).
MUST connect GPS_VBAT to VCC if no backup battery is used.
17

G10/BOOT_MODE

I/O- 62/348 -©2022

5.8.2 IG-2 Schematic

IG-2

Name

I/O

Description

Module& IG-2H1 PinLeave unconnected. IMX BOOT MODE used in manufacturing. !!!
WARNING !!! Asserting a logic high (+3.3V) will cause the IMX toreboot into ROM bootloader (DFU) mode.
18

G11

I/O

IMX GPIO11

19

G12

I/O

IMX GPIO12
GPS reset

20

G13/DRDY

I/O

IMX GPIO13
SPI data ready21

G14/SWCLKI/OIMX GPIO14

22

nRESETI

System reset (IMX and GPX) on logic low. May be left unconnected
if not used.

23

GND

PWR

-

24

USB_N

I/O

IMX USB Data Negative Line

25

USB_P

I/O

IMX USB Data Positive Line

5.8.2 IG-2 Schematic
Download Schematic

5.8.3 Hardware Versions
The following outlines the differences between the IG-2 hardware versions.
IG-2.1•IG-2.0•5.8.4 Soldering
The IMX-5 can be reflow soldered. Reflow information can be found in the Reflow Information page of this manual

5.8.5 Hardware Design
Recommend PCB Footprint and Layout
The default forward direction is indicated in the PCB footprint figure and on the silkscreen as the X axis. The forward direction isreconfigurable in software as necessary.
Download PDF

5.8.6 Design Files- 63/348 -©2022

5.8.7 Related Parts

Open source hardware design files, libraries, and example projects for the IMX module are found at theInertial Sense Hardware Design repository hosted on GitHub. These include schematic and layout files forprinted circuit board designs, and 3D step models of the InertialSense products usable for CAD and circuitboard designs.

Reference Design Projects
The EVB-2, IG-1, and IG-2 circuit board projects serve as reference designs that illustrate implementation of the IMX PCB
module.
EVB-2 evaluation board
IG-1 module
IG-2 module

5.8.7 Related Parts
Part

Manufacturer

Manufacturer #Description

H1

JST

GHR-14V-S

14 pin connector 1.25mm pitch for IMX I/O connection.

- 64/348 -©2022

5.9 Hardware Integration: EVB-2

5.9 Hardware Integration: EVB-2

The Inertial Sense EVB-2 is a development board which contains the Inertial Sense µINS, µAHRS, or µIMU module. The EVB-2
builds on the foundation established by the EVB-1, but adds new features including:• 915MHz XBee radio for RTK (real-time-kinematics)• Wi-Fi and Bluetooth Low energy (BLE) for remote data viewing and logging operation• Onboard logging to micro SD card.
• Dual antenna ports for GPS compassing• Companion Microchip SAME70 processor that serves as a communication bridge between the µINS, µAHRS, or µIMU and allother interfaces.

- 65/348 -©2022

5.9.1 Configurations

5.9.1 Configurations
The EVB-2 can be configured to preform a multitude of operations. Below are diagrams of connectivity and configuration options
available. The configuration can be changed by pressing the tactile switch labeled "CONFIG" on the EVB-2 until the Config LEDshows the desired mode.
CBPreset

Config LED

Mode

ON

OFF

2

Default

RS232

WiFi/BLE Module, XBee

3

XBee

RS232, XBee

WiFi/BLE Module

4

WiFi/BLE

Wi-Fi/BLE Module,

XBee

RS422/485
5

SPI*

SPI*

Wi-Fi/BLE Module, XBee

6

USB/232

RS232, XBee

EVB2 to IMX Connection

7

USB/422/485

RS422/485

EVB2 to IMX Connection

1

Off

EVB2 to IMX Connection
WiFi/BLE Module, XBee

- 66/348 -©2022

5.9.1 Configurations*

A reset is required following selection of this CBPreset to enable SPI on the IMX, in order to assert the IMX pin 10 (G9/nSPI_EN) during bootup.

- 67/348 -©2022

5.9.1 Configurations

Default

Serial 0

TTL

uinsComPort

Serial 1 TTL
SPI

uinsAuxPort

CAN

Serial 2 TTL

RTK Filter

H7

USB
H3
H8

μINS/μAHRS/μIMU

SAME70 Comm BridgeTTL

μSD Card
H4

USB

RS232

External Radio (TTL)

WiFi/BLE Module
XBee RadioEVB2CAN XCVR

Communications Bridge Preset 2 (Default)

H2

Config LED

Default protocols shown in bold text, disabled peripherals in light gray

XBee

Serial 0

TTL

uinsComPort

Serial 1 TTL
SPI

uinsAuxPort

CAN

Serial 2 TTL

RTK Filter

H7

USB
H3
H8

μINS/μAHRS/μIMU

SAME70 Comm BridgeTTL

μSD Card
H4

USB

RS232

External Radio (TTL)

WiFi/BLE Module
XBee RadioEVB2CAN XCVR

Communications Bridge Preset 3 (XBee)

H2

Config LED

Default protocols shown in bold text, disabled peripherals in light grayWiFi/BLE

Serial 0

TTL

uinsComPort

Serial 1 TTL
SPI

uinsAuxPort

CAN

Serial 2 TTL

RTK Filter

H7
USB
μINS/μAHRS/μIMU- 68/348 SAME70 Comm Bridge

USB
H3

RS232

H8

TTL

μSD Card
H4

External Radio (TTL)

WiFi/BLE Module©2022

5.9.2 EVB-2 Connections

In the USB hub modes (6-7), the following communications bridge/forwarding exists:
DID_EVB_FLASH_CFG.uinsComPort <-> All ports except XBee, WiFi, and XRadio DID_EVB_FLASH_CFG.uinsAuxPort <-> XBee, WiFi, andXRadio. XBee and WiFi only enabled when DID_EVB_FLASH_CFG.cbPreset == EVB2_CB_PRESET_RS232_XBEE
EVB2_PORT_UINS0 is the default value for both of these.

Bit EVB2_PORT_OPTIONS_RADIO_RTK_FILTER of DID_EVB_FLASH_CFG.portOptions only allows RTK corrections to pass through theuinsAuxPort , reducing the wireless communications burden to only essential RTK base connections. This bit is enabled by default.

5.9.2 EVB-2 Connections
USB
The most commonly used user interface available on the EVB-2 is the EVB USB port. Connecting to the EVB USB port will provide
power to the device as well communications with the onboard SAME70 processor. After connecting to a PC the EVB2 will appear
as a virtual COM port and can be configured to communicate with every other communication bus on the board. This USB port
should be used when updating the EVB-2 firmware or bootloader.
The EVB-2 also has a second USB port, IMX USB . This USB port also supplies power, but it connects directly to the µINS, µAHRS,
or µIMU onboard the EVB-2. This USB port should be used when updating the µINS, µAHRS, or µIMU firmware or bootloader.

GPS Antenna(s)If using GPS with the module, connect an appropriate antenna to GPS1 (J7) . If using the board for GPS compassing, connect asecond antenna to GPS2 (J5) . More information on GPS antennas is available on the GNSS Antennas page.

XBee Antenna
If using the onboard XBee radio, ensure that the XBee radio U.FL connector (U10) is connected to the EVB-2 U.FL connector (J8).
Connect an appropriate antenna to the EVB-2 RP-SMA connector (J5).
To communicate with another XBee radio the PID and NID need to match on both radios. The PID and NID can be set using
DID_EVB_FLASH_CFG.radioPID and DID_EVB_FLASH_CFG.radioNID . After setting the PID and NID, the EVB-2 needs to be reset so theradio can be configured. The XBee LED will flash Yellow then Green if the configuration is successful. A red LED signifies a failed
radio configuration.

Wi-Fi Antenna
The XBee radio can be used along with the Wi-Fi module. In this case, a Wi-Fi antenna must be provided and connected to the
U.FL port on the Wi-Fi module (U8).
To use Wi-Fi alone, connect the U.FL connector on the Wi-Fi module (U8) to the EVB-2 U.FL connector (J8), and connect the Wi-Fi
antenna to the XBee RP-SMA connector (J5).

Header Pinouts
Use JST-PH series connectors for EVB 2.x header H1. Maximum current is 2A per pin.
Use JST-GH series connectors for all other EVB 2.x headers. Maximum current is 1A per pin.
H1 (POWER)

Pin
1
2

Name

Type

Description

VIN-

4.5–17V supply voltage

GND

-

-

- 69/348 -©2022

5.9.2 EVB-2 Connections

H2 (CAN)To enable IMX CAN interface on H2, the U5 transceiver IC (TCAN334) must be loaded and the R27 jumper removed. To enable
EVB CAN interface on H2, the U13 transceiver IC (TCAN334) must be loaded and the R51 jumper removed.
Pin
1
2
3
4

Name

Type

Description

GND

-

3.3V

-

3.3V supply

CANL

I/O

Low level CAN bus line.

CANH

I/O

High level CAN bus line.

Name

Type

Description

GND

-

-

232Tx-/485Tx-

O

Serial output (RS232 transmit-, RS485 transmit-)

485Tx+O

Serial output (RS485 transmit+)

485Rx-

I

Serial input (RS485 receive-)

232Rx/485Rx+

I

Serial input (RS232 receive, RS485 receive+)

Name

Type

Description

GND

-

-

GND

-

-

GND

-

-

3.3V

-

Separate radio 3.3V supply. Regulator can supply up to 3.5A.

3.3V

-

""

3.3V

-

""

RxD

I

Serial input from radio transmit pin (TTL) PD25.

TxD

O

Serial output to radio receive pin (TTL) PD26.

RSTO

Reset pin

H3 (RS-232/RS-485)

Pin
1
2
3
4
5
H4 (EXTERNAL RADIO)

Pin
1
2
3
4
5
6
7
8
9

- 70/348 -©2022

5.9.2 EVB-2 Connections

H7 (IMX CONNECTIONS)

Pins on H7 (IMX) are shared with the EVB-2 processor. To prevent conflict when using H7, set EVB-2 CBPreset to 6 or 7 (USBhub mode) to prevent the EVB-2 processor from asserting any I/O on the H7.
Pin

Name

Type

Default

Description

Type
1
2
3

4
5

6

7

8

9
10

11

12
13

GND

-

-

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise
can be 3.3V input.

DATA-RDY

I/O

I

Indicates data is read to be read from IMX.

G1/Rx2*/RxCAN*

I/O

I

GPIO1. Serial 2 input (TTL). Serial input pin from
CAN transceiver.

G2/Tx2*/TxCAN*/

I/O

O

G3/Tx0

GPIO2. Serial 2 output (TTL). Serial output pin to
CAN transceiver. Strobe time sync input.

STROBEI/O

O

GPIO3. Serial 0 output (TTL)(tied to IMX-Ser0 Rx)

G4/Rx0

I/O

I

GPIO4. Serial 0 input (TTL)(tied to IMX-Ser0 Tx)

G5/SCLK/STROBEI/OIGPIO5. SPI SCLK. Strobe time sync input.

G6/Rx1/MOSI

I/OI

GPIO6. Serial 1 input (TTL). SPI MOSI
(tied to IMX-Ser1 Tx)

G7/Tx1/MISO

I/OO

GPIO7. Serial 1 output (TTL). SPI MISO
(tied to IMX-Ser1 Rx)

G8/CS/STROBEI/OOGPIO8. SPI CS. Strobe time sync input.

G9/nSPI_EN/

I/O

I

GPIO9. Hold LOW during boot to enable SPI on

STROBE

G5-G8. Strobe time sync input or output.

/STROBE_OUT
14

GPS_PPSOOGPS PPS time synchronization output pulse (1Hz,
10% duty cycle)*Available on IMX-3.2 and later.

- 71/348 -©2022

5.9.3 IMX Connections

H8 (SAME70 CONNECTIONS)

Pin

Name

Type

Default

Description

Type
1
2
3

4
5

6

7

8

9

10

11
12
13
14

GND

-

-

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise
can be 3.3V input.

3.3V

-

M1/TXD1O""O

GPIO1, USART 1 Output (TTL/SPI), Inverted
Serial 1 Output (TTL)

M2/RXD1

I

I

GPIO2, USART 1 Input (TTL/SPI), Inverted Serial
1 Input (TTL)

M3/SCK1/

I/O

GPIO3, USART 1 Clock (SPI), Quadrature

QDA
M4/CS1/

Encoder Input A
I/O

GPIO4, USART 1 Chip Select (SPI), Quadrature

QDB
M5/DA0/

Encoder Input B
I/O

GPIO5, DAC 0, ADC 4

I/O

GPIO6, DAC 1, ADC 5

M7/AD10I/O

GPIO7, ADC 10

M8/AD4I/O

GPIO8, ADC 4

M9/AD1I/O

GPIO9, ADC 1

M10/AD2

I/O

GPIO10, ADC 2

AD4
M6/DA1/AD5

PWM and timer interrupt functions have been excluded from this table. Please see the MCU pin definition spreadsheet for more
info.

5.9.3 IMX Connections
The EVB-2 ATSAME70 (E70) processor interfaces with the IMX over UART (serial 0 and 1) and SPI (serial 1).

CAN Bus
To use IMX CAN bus interface on the EVB-2, U5 (TCAN334 transceiver) should be loaded and R27 should not be loaded.

- 72/348 -©2022

5.9.3 IMX Connections

SPI
The EVB-2 must be put into CBPreset mode 6 (CONFIG led color cyan) followed by a system reset to enable SPI mode interface
with the IMX. The EVB-2 (E70) project source code is available in the SDK for reference.

Serial 2
To use serial 2, the IMX CAN transciever (U5) and R27 must be depopulated to avoid contention on the data lines.

- 73/348 -©2022

5.9.4 Mechanical Dimensions

5.9.4 Mechanical Dimensions

PCB w/ SMA connectors: 70.0 x 45.0 x 12.0 mm
Enclosure: 78.0 x 48.0 x 18.0 mm

5.9.5 Using with Inertial Sense Software
Please return to the getting started page to get started programming, updating firmware, viewing data, and logging.

5.9.6 Updating Firmware
The EVB-2 and IMX firmware can be updated using the EVB-USB connector and only the IMX firmware when using the IMX-USB
connector.

5.9.7 EVB-2 Design FilesThe EVB-2 PCB assembly design files are available as open source hardware on GitHub.
In particular, full schematics for the board can be found here.

- 74/348 -©2022

5.9.8 Related Parts

5.9.8 Related Parts
Part

Manufacturer

Manufacturer

Description#
H7, H8JST

GHR-14V-S

14 pin connector 1.25mm pitch for IMX and SAME70
connection.

H1

JST

PHR-2

2 pin connectors 2.00mm pitch for input power.

5.9.9 XBee Radio Frequencies
The EVB-2 shipped standard with the XBee radio default frequency is 915MHz. An alternate frequency can be achieve by using
the European version of the XBee Pro SX module.
XBee Pro SX Part#

Frequency

Frequency BandXBP9X-DMUS-001 (default)

915 MHz

902MHz ~ 928MHz

XB8X-DMUS-001 (Europe)

868 MHz863MHz ~ 870MHz- 75/348 -©2022

5.10 Hardware Integration: EVB-1

5.10 Hardware Integration: EVB-1

The Inertial Sense EVB1.x is a development board which contains the Inertial Sense µINS, µAHRS, or µIMU module. The EVB1.x
functions as a breakout and communications board with the following features:• Access to all communications pins on the module• USB connection, either directly to the module or through an on-board FTDI chip
• RS232/RS422/RS485 transceiver

5.10.1 Connecting the board
For the purposes of basic evaluation, the easiest interface available on the EVB 1.x is the micro USB port. Connecting the micro
USB port will provide power and communications with the installed module via the on-board FTDI chip. There are a variety ofother interfaces available on the EVB 1.x.
If using GPS with the module, connect an antenna to the on-board SMA port. More information on compatible antennas isavailable on the GNSS Antennas page.

5.10.2 PowerThe EVB-1 can be powered in using the following methods:• 4-20V DC regulated supply via H1• 3.3V DC regulated supply via any +3.3V header pin• 5V USB connection

5.10.3 Pinout
Use Molex PicoBlade™ series connectors for the EVB-1 headers.

- 76/348 -©2022

5.10.3 Pinout

Warning
Please note that EVB-1 header pin 1 location and pin order is reversed from that designated by the header
manufacturer, Molex.

H1 (Power)
Pin
1
2

Name

I/O

Description

GND

-

-

VIN

-

4V – 20V supply voltage- 77/348 -©2022

5.10.3 Pinout

H2 (I2C)
Pin
1
2

3

4

Name

I/O

Description

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise can be 3.3V input tosupply IMX. Do NOT power VIN and 3.3V simultaneously!

G1/SDA/I/O

GPIO1/*I2C data (Hold HIGH during boot to enable *I2C)

I/O

GPIO2/*I2C clock/Strobe time sync input.

I2C_EN
G2/SCL/STROBE

H4 (Serial 0)
Pin
1
2

3
4

Name

I/O

Description

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise can be 3.3V input to supply
IMX. Do NOT power VIN and 3.3V simultaneously!

G4/Rx0I‡GPIO4/Serial0 Input (TTL)

G3/Tx0O‡GPIO3/Serial0 Output (TTL)

H5 (RS232/RS485)
Pin
1
2

3
4
5
6

Name

I/O

Description

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise can be 3.3V input tosupply IMX. Do NOT power VIN and 3.3V simultaneously!

232Rx1/485Rx1+

I

Serial 1 input (RS232)/Serial 1 input+ (RS485)

232Rx0/485Rx1-

I

Serial 0 input (RS232)/Serial 1 input- (RS485)

232Tx1/485Tx1+

O

Serial 1 output (RS232)/Serial 1 output+ (RS485)

232Tx0/485Tx1-

O

Serial 0 output (RS232)/Serial 1 output- (RS485)- 78/348 -©2022

5.10.3 Pinout

H6 (Serial 1/SPI)
Pin
1
2

3

4
5
6

7

Name

I/O

Description

GND

-

-

3.3V

-

3.3V supply. Output if H1 is supplied. Otherwise can be 3.3V input tosupply IMX. Do NOT power VIN and 3.3V simultaneously!

G5/SCLK/

I/O

GPIO5/SPI SCLK/Strobe time sync input.

G6/Rx1/MOSII

GPIO6/Serial1 Input (TTL)/SPI MOSI

G7/Tx1/MISOO

GPIO7/Serial1 Output (TTL)/SPI MISO

G8/CS/I/O

GPIO8/SPI CS/Strobe time sync input.

O

GPS PPS time synchronization output pulse (1Hz, 10% duty cycle)

STROBESTROBE
GPS_PPS* Feature will be available in future firmware update.
‡Tied to FTDI USB to serial converter ONLY when USB is connected.

- 79/348 -©2022

5.10.4 Mechanical5.10.4 Mechanical5.10.5 Jumpers
The jumpers identified in the following table are used to configure RS485/RS422 features and select which serial port the USB isconnected to on the evaluation board.
JumperLabel

Default*

Description

R9

RXEN

RXEN

Receiver enable for RS232 and RS485 function.

R10

232

232

Select RS232 or RS485/RS422 mode on H5. Setting jumper in the“232” position enables RS232 mode.

R8, R11,
R12

S0 S1

S0

Connects USB to either Ser0 or Ser1. All three jumpers must move
together into either the “S0” or “S1” positions.

- 80/348 -©2022

5.10.5 Jumpers

EVB Bottom View

- 81/348 -©2022

5.10.6 Schematic

5.10.6 Schematic

EVB Simplified Schematic

5.10.7 RS232 DB9 Adapter
The EVB RS232 interface for the serial port 0 is enabled by default and available through header H5. The figure to the rightillustrates how a standard DB9 connector is wired to this port.

- 82/348 -©2022

5.10.8 USB Driver

5.10.8 USB Driver
The EVB 1.x uses the FTDI FT232R USB to UART IC to provide a serial port over connection over USB. Depending on theoperating system, it may be necessary to download and install the FTDI device driver for the FT232R to register properly as aserial port.

5.10.9 Using with Inertial Sense Software
Please return to the getting started page to get started programming, updating firmware, viewing data, and logging.

- 83/348 -©2022

5.11 Hardware Design Files

5.11 Hardware Design FilesThe Inertial Sense hardware design files are available on our IS-hdw repository to facilitate product hardware development andintegration.
• PCB Libraries - Schematic and layout files for printed circuit board designs.
• Products - 3D models and resources for the IMX, Rugged, EVB, and products useful for CAD and circuit board designs.

- 84/348 -©2022

5.12 Reflow Soldering

5.12 Reflow Soldering
Use of "No Clean" soldering paste is recommended as it does not require cleaning after the soldering process. The following
examples of paste meet these criteria.
SolderDetails

Soldering Paste

OM338 SAC405 / Nr.143714 (Cookson Electronics)

Allow Specification

Sn 95.5/ Ag 4/ Cu 0.5 (95.5% Tin/ 4% Silver/ 0.5% Copper)

Melting temperatures

217 °C

5.12.1 The following reflow profile is recommended for soldering:

Phase

Name

Recommended

Details

dT/dt

3°C/sec

Preheat Temperature Rise Rate

TsMIN

150°C

Preheat Minimum Temperature

TsMAX

200°C

Preheat Maximum Temperature

tsPreheat60 - 120 sec

Time Spent Between Preheat MIN and Max temperatures

TL

217°C

Reflow Liquidus temperatures

TP

245°C

Reflow Peak temperatures

tL

40-60 sec

Time Spent above Reflow Liquidus temperatures

dT/dt

4°C/sec

Maximum Cooling Temperature Fall Rate

Preheat

Reflow

Cooling- 85/348 -©2022

5.12.1 The following reflow profile is recommended for soldering:

Important
A convection soldering oven is highly recommended over an infrared type radiation oven as it allows precision control of thetemperature and all parts will be heated evenly.

Warning
The IMX should be located on the topside of a PCB during reflow to avoid falling off.
Care should be taken to not disturb the components on the IMX during reflow as the solder on the IMX will also reflow.
The part must not be soldered with a damp heat process.

- 86/348 -©2022

6. IS Software

6. IS Software
6.1 CLTool
6.1.1 Overview
The Inertial Sense CLTool is a command line utility that can be used to read and display data, update firmware, and log data from
Inertial Sense products. Additionally, CLTool serves as example source code that demonstrates integration of the Inertial Sense
SDK into your own source code. The CLTool can be compiled in Linux, Mac, Windows and embedded platforms.

6.1.2 Help Menu
# Command line utility for communicating, logging, and updating firmware with Inertial Sense product line.
EXAMPLES
cltool -c /dev/ttyS2 -did DID_INS_1 DID_GPS1_POS DID_PIMU# stream DID messages
cltool -c /dev/ttyS2 -did 4 13 3
# stream same as line above
cltool -c /dev/ttyS2 -did 3=5# stream DID_PIMU at startupNavDtMs x 5
cltool -c /dev/ttyS2 -presetPPD# stream post processing data (PPD) with INS2
cltool -c /dev/ttyS2 -presetPPD -lon -lts=1# stream PPD + INS2 data, logging, dir timestamp
cltool -c /dev/ttyS2 -edit DID_FLASH_CFG# edit DID_FLASH_CONFIG message
cltool -c /dev/ttyS2 -baud=115200 -did 5 13=10 # stream at 115200 bps, GPS streamed at 10x startupGPSDtMs
cltool -c * -baud=921600# 921600 bps baudrate on all serial ports
cltool -rp logs/20170117_222549# replay log files from a folder
cltool -c /dev/ttyS2 -rover=RTCM3:192.168.1.100:7777:mount:user:password# Connect to RTK NTRIP base
EXAMPLES (Firmware Update)cltool -c /dev/ttyS2 -ufpkg fw/IS-firmware.fpkg
cltool -c /dev/ttyS2 -uf fw/IS_IMX-5.hex -ub fw/IS_bootloader-STM32L4.hex -uv
OPTIONS (General)-h --help
Display this help menu.
-c DEVICE_PORT Select the serial port. Set DEVICE_PORT to "*" for all ports or "*4" for only first four available.
-baud=BAUDRATE Set serial port baudrate. Options: 115200, 230400, 460800, 921600 (default)-magRecal[n]Recalibrate magnetometers: 0=multi-axis, 1=single-axis-q
Quiet mode, no display.
-resetIssue software reset.
-s
Scroll displayed messages to show history.
-stats
Display statistics of data received.
-survey=[s],[d] Survey-in and store base position to refLla: s=[2=3D, 3=float, 4=fix], d=durationSec-ufpkg FILEPATH Update firmware using firmware package file (.fpkg) at FILEPATH.
-uf FILEPATH
Update application firmware using .hex file FILEPATH. Add -baud=115200 for systems w/ baud rate limits.
-ub FILEPATH
Update bootloader using .bin file FILEPATH if version is old. Must be used along with option -uf.
-fb
Force bootloader update regardless of the version.
-uv
Run verification after application firmware update.
-sysCmd=[c]Send DID_SYS_CMD c (see eSystemCommand) preceeded by unlock command then exit the program.
-factoryReset
Reset IMX flash config to factory defaults.
-romBootloader Reboot into ROM bootloader mode. Requires power cycle and reloading bootloader and firmware.
-v
Print version information.
OPTIONS (Message Streaming)-did [DID#<=PERIODMULT> DID#<=PERIODMULT> ...] Stream 1 or more datasets and display w/ compact view.
-edit [DID#<=PERIODMULT>]
Stream and edit 1 dataset.
Each DID# can be the DID number or name and appended with <=PERIODMULT> to decrease message frequency.
Message period = source period x PERIODMULT. PERIODMULT is 1 if not specified.
Common DIDs: DID_INS_1, DID_INS_2, DID_INS_4, DID_PIMU, DID_IMU, DID_GPS1_POS,
DID_GPS2_RTK_CMP_REL, DID_BAROMETER, DID_MAGNETOMETER, DID_FLASH_CONFIG (see data_sets.h for complete list)-dids
Print list of all DID datasets-persistent
Save current streams as persistent messages enabled on startup-presetPPD
Stream preset post processing datasets (PPD)-presetINS2
Stream preset INS2 datasets
OPTIONS (Logging to file, disabled by default)-lon
Enable logging-lt=TYPE
Log type: dat (default), raw, sdat, kml or csv-lp PATH
Log data to path (default: ./IS_logs)-lms=PERCENT
Log max space in percent of free space (default: 0.5)
-lmf=BYTES
Log max file size in bytes (default: 5242880)-lts=0Log sub folder, 0 or blank for none, 1 for timestamp, else use as is-r
Replay data log from default path-rp PATH
Replay data log from PATH
-rs=SPEED
Replay data log at x SPEED. SPEED=0 runs as fast as possible.
OPTIONS (Read flash configuration from command line)-flashCfg# List all "keys" and "values""-flashCfg=[key]|[key]|[key]"# List select values
OPTIONS (Write flash configuration from command line)"-flashCfg=[key]=[value]|[key]=[value]"# Set key / value pairs in flash config.
# Surround with "quotes" when using pipe operator.
EXAMPLES
cltool -c /dev/ttyS2 -flashCfg # Read from device and print all keys and values- 87/348 -©2022

6.1.3 Compile & Run (Linux/Mac)cltool -c /dev/ttyS2 "-flashCfg=insOffset[1]=1.2|=ser2BaudRate=115200"# Set multiple values

OPTIONS (RTK Rover / Base)-rover=[type]:[IP or URL]:[port]:[mountpoint]:[username]:[password]
As a rover (client), receive RTK corrections. Examples:-rover=TCP:RTCM3:192.168.1.100:7777:mountpoint:username:password(NTRIP)-rover=TCP:RTCM3:192.168.1.100:7777-rover=TCP:UBLOX:192.168.1.100:7777-rover=SERIAL:RTCM3:/dev/ttyS2:57600(port, baud rate)-base=[IP]:[port]
As a Base (sever), send RTK corrections. Examples:-base=TCP::7777(IP is optional)-base=TCP:192.168.1.43:7777-base=SERIAL:/dev/ttyS2:921600

6.1.3 Compile & Run (Linux/Mac)
1. You must have cmake installed on your machine. To do this, download the cmake application at https://cmake.org/download/. Then,
using the command line, you will need to install cmake with either of the following commands depending on your platform:Mac:
sudo "/Applications/CMake.app/Contents.bin/cmake-gui" --installLinux:
sudo apt-get install cmake

2. Create build directory
cd cltool
mkdir build

3. Run cmake from within build directory
cd build
cmake ..

4. Compile using makemake

5. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

6. Run executable
cd build./cltool

6.1.4 Compile & Run (Windows CMake CL)
1. Install CMake for Windows
2. Create build directory ```bash cd cltool mkdir build
3. Run cmake from within build directory
cd build
cmake ..

4. Compile
cmake --build .

5. Run executable
cd Release (or Debug depending on CMake configuration you selected)
cltool.exe- 88/348 -©2022

6.1.5 Compile & Run (Windows CMake Visual Studio)

6.1.5 Compile & Run (Windows CMake Visual Studio)
Windows Visual Studio supports CMake projects. Follow the instructions provided by Microsoft: https://learn.microsoft.com/enus/cpp/build/cmake-projects-in-visual-studio?view=msvc-170

6.1.6 Updating Firmware with CLTool
Updating using Firmware Package
Updating firmware using a firmware package file provides a simple method to update multiple devices in one process. This
include the ability to update an IMX-GPX module pair in one step. The cltool only needs know the file path of the firmware
package file and the serial port of the device to be updated. The file extension for a firmware package is .fpkg .
NOTE: Updating the IMX firmware using a firmware package currently not supported and will become available in a future
update.
cltool -c DEVICE_PORT -ufpkg FILEPATH

The following is a specific example of using a firmware package file:cltool -c /dev/ttyACM0 -ufpkg IS-firmware_2.0.3_2024-03-18_213925.fpkg

Updating using Single Firmware File (Legacy Mode)
The CLTool can be used to update device firmware with the following options. This is the legacy firmware update methods thatworks only with the IMX-5.0 and earlier products (uINS-3, EVB-2, etc.).
cltool -c DEVICE_PORT -uf [FW_FILEPATH] -ub [BL_FILEPATH] -uv

Options

Description-c DEVICE_PORT

Specifies the device serial or USB port (i.e. /dev/ttyACM0 ).

-ufSpecifies the application firmware file path.

[FW_FILEPATH]-ub(Optional) Specified the bootloader firmware file. The bootloader is only updated if the version of the file

[BL_FILEPATH]

provided is newer than the bootloader version currently on the device.

-uv(Optional) Run verification after application firmware update.

The following is a specific example:
cltool -c /dev/ttyS2 -uf fw/IS_IMX-5.hex -ub fw/IS_bootloader-STM32L4.hex -uv

Note: The firmware can only be updated at the following baud rates: 300000, 921600, 460800, 230400, 115200

6.1.7 Logging with CLTool
The CLTool can be used to log data to file with the following options:cltool -c DEVICE_PORT -lon -lt=LOG_TYPE -lp DIRECTORY

Options

Description-lon

Enable logging.

-lt=LOG_TYPE

Specifies the log file type to be written. LOG_TYPE can be dat , raw , sdat , or csv .

-lp DIRECTORY(Optional) Specifies the path where log files will be written. When not specified, the default location will be
the current working directory.

- 89/348 -©2022

6.1.8 Command Line Options

Log File Types
Log

Description

Type
dat

Binary file containing InertialSense binary (ISB) DID data sets in "chunk" groups containing data in serial order as
they appear over the serial port. Default file format. Recommended for post processing.

raw

Binary file containing byte for byte data received over the serial ports. All packets remain in their native form.
Used for logging InertialSense binary (ISB), NMEA, RTCM3, uBlox UBX binary and SPARTN, and any other packet
formats. Recommended for logging all data formats and post processing.

sdat

Binary file containing InertialSense binary (ISB) DID data sets in "chunk" groups organized by DID. Each chunkcontains only one DID type, and at least one chunk allocated for each DID data set type. Not recommended for
future use.

csv

Comma-Separated Values - Plain text file that uses specific structuring to arrange tabular data. Its basic format
involves separating each data field (or cell in a table) with a comma and each record (or row) is on a new line. This
simple format allows for ease in data import and export between programs that handle tabular data, such as
databases and spreadsheets.

The following is an example of enabling the logger with type raw and specifying the output directory:./cltool -c /dev/ttyACM0 -lon -lt=raw -lp /media/usbdrive/data

6.1.8 Command Line Options
Navigate to the directory /cpp/SDK/cltool/build and run the CLTool with the help option, " -h "./cltool -hto display the command line options

6.1.9 Command Line Options in MS Visual Studio
When using MS Visual Studio IDE, command line arguments can be supplied by right clicking the project in the solution explorer
and then selecting Configuration Properties -> Debugging -> Command Arguments (see image below).

- 90/348 -©2022

6.1.9 Command Line Options in MS Visual Studio- 91/348 -©2022

6.2 EvalTool

6.2 EvalTool
6.2.1 Overview
The EvalTool (Evaluation Tool) is a desktop GUI application that allows you to explore and test functionality of the Inertial Sense
products in real-time. It has scrolling plots, 3D model representation, table views of all data, data logger, and firmware updatinginterface for the IMX, uAHRS, or uIMU. The EvalTool can simultaneously interface with multiple Inertial Sense devices.

6.2.2 Download and Install
The EvalTool Windows desktop app installer (.exe) can be downloaded from the Inertial Sense releases page.

6.2.3 Getting Started

With a device connected to your computer:1. Connect your INS to your computer using directions in the getting started section of this guide.
2. Open the Settings > Serial Ports tab.
3. Click the Find All button.
4. Open the port to your device by checking the Open checkbox.
5. The status box in the Port column will turn green and the Link status bar will turn green while data is being received from thedevice.
6. You can specify the serial port baud rate using the Baud Rate dropdown menu when using a serial interface like RS232.

- 92/348 -©2022

6.2.4 Info Bar

DATA LOGGING STEPSIn order to log data from your INS device, follow the steps listed below:
1. Connected your device to the EvalTool and open the port.
2. Go to the Data Logs tab.
3. Enable the data that you would like collected in the Data Streams area:
a. Select one of the RMC Preset menu options. This automatically enables standard messages commonly used for logging. PPD (Post
Processed Data) is the recommended default.
b. Enable any of the DID messages listed below by checking the On checkbox and setting the Period Mult.
4. Configure and enable logging in the Data Log area:
a. The Open Folder button opens the log directory in a file explorer window where logs are saved.
b. The Format dropdown menu selects the output log file format (.dat .sdat .csv .kml .raw).
c. Press Log to start recording a new log.
5. The data you are currently recording will be shown in the “Log Summary” sub-tab.
6. When you are finished recording data, press “Disable”. Your data will be saved in the location shown in “Open Folder”.

6.2.4 Info Bar
The Info Bar can be seen from any tab and shows basic connection information for the unit selected.

1. Link Status - Shows Packets being Transmitted and Received. counts to 99 then resets to 0.
2. Error Message - Shows error messages for the selected unit. The kinds of messages vary from data packets lost to system had areset.
3. RTK Base Messages - The number in this field will increment as your rover unit continues to receive RTK messages from your basestation. Use this field as the main signifier that RTK messages are coming through.
4. Currently selected unit - The unit with the serial number shown here will have its live data shown on each tab in EvalTool.

- 93/348 -©2022

6.2.5 Update Firmware

6.2.5 Update Firmware- 94/348 -©2022

6.2.5 Update Firmware

1. Go to the Settings > Serial Port tab.
2. Open the Ports of the units you would like to update. If the units don't open up, you may have to change the baud rate.
3. Click Update Firmware.
4. Select the update type using the drop down menu:
Update Type

Description

FwPkg (.fpkg)

Batch firmware update method for updating multiple devices in one
process. The .fpkg file contains multiple firmware files and instructions
for sequencing firmware updates for all available devices. NOTE: IMX-5
firmware update is not yet supported but will be in a future update.

GPX-1 (.bin)

GPX-1 firmware update.

IMX-5.0 (.hex)(Legacy mode) IMX-5.0 firmware update that used the legacy
InertialSense bootloader (ISB).

IMX-5.1 (.bin)

IMX-5.1 firmware update.

1. Select the firmware file by clicking on the ellipsis(three dots) button next to the file name andnavigating to and opening the file.
1. For the IMX-5.0 update type, you can optionallyselect the bootloader .bin file. The bootloader will
only be updated if the selected file is newer thanthe bootloader on the connected unit.
1. Click Start.
1. Wait for the progress to reach 100% and click
Done.

*Note: The firmware can only be updated at the following baud rates: 300000, 921600, 460800, 230400, 115200.

- 95/348 -©2022

6.2.6 Tab Descriptions

6.2.6 Tab Descriptions
INS Tab

1. Attitude Plot and Table - shows the Roll, Pitch, and Yaw values of the selected unit. Hover the cursor of the radio buttons to see
more descriptions.
2. Velocity Plot and Table - U,V,W velocities.
3. LLA Plot and Table - Tabular values and plot of Latitude, Longitude, and Altitude.
4. Simulation - Real-time, simulated image of the INS orientation.
5. GPS Summary - Strength of GPS signal and accuracy.
6. Mag Recal Button - Allows you to calibrate your units about either a single axis (for heavy, ground based vehicles) or multi-axes.
7. BIT (Built-In Test) Button - Runs a system of checks on your unit.
8. Link Messages - shows the performance information on connected units and displays error messages.

- 96/348 -©2022

6.2.6 Tab Descriptions

Sensors Tab

1. Gyros Plot and Table - Gyroscopic data on the selected unit. Includes standard deviation.
2. Accelerometers Plot and Table - Accelerometer data on the selected unit. Includes standard deviation.
3. Magnetometers Plot and Table - Magnetometer data on the selected unit. Includes standard deviation.
4. Barometer Plot and Table - Barometric, temperature, and humidity data on the selected unit. Includes standard deviation.

- 97/348 -©2022

6.2.6 Tab Descriptions

GPS Tab

1. GPS CNO Signal Strength - Bar graphs of each satellite being used in your solution and its strength in dBHz(CNO).
2. Position Accuracy Plot and Table - RTK mode and status. Includes number of satellites used in the RTK solution (max and mean).
3. Satellites Used Table - The GNSS ID for each satellite seen by your unit and the subsequent connection details.

- 98/348 -©2022

6.2.6 Tab Descriptions

Map Tab

1. Track Active - Tracks all units on window view.
2. Zoom to Fit - Zooms your window view around each unit being used.
3. Manual - Requires manual movement of the window view.
4. Location of Units - GPS location of each of your units. Shows RTK, GPS ublox, and INS solution.

- 99/348 -©2022

6.2.6 Tab Descriptions

Data Sets Tab

1. List of DIDs (Data IDentifiers) - The data identifiers that you might need to view for measurements. See the User Manual (Binary
Protocol Data Sets) for a detailed description of frequently used DIDs.
2. List of Variables within DIDs - shows what is recorded in each DID in real-time.

- 100/348 -©2022

6.2.6 Tab Descriptions

Data Logs

DATA STREAMSThis area allow users to enable streaming of various DIDs.
1. RMC Presets Button - Enable a group of data sets. PPD (post process data) is the preferred preset for post processing and debug
analysis.
2. Save Persistent Button - Save currently enabled data streams to automatically begin streaming after system restart. To clear
persistent streams, first stop streaming and then click Save Persistent.
3. Stop Streaming - Stops all data streams. Any streams previously saved as persistent will begin streaming at startup.
DATA LOG

1. Enable/Disable Button - Starts/stops a log of all currently streaming data and saves it to a sub-folder with the current time-stamp
within your "Logs" folder.
2. Open Folder Button - Opens the "Logs" folder where your previous logs are saved.
3. Format Dropdown - Select the file output type of the data log , such as .dat, .raw, .sdat, .csv, or .kml.

- 101/348 -©2022

6.2.6 Tab Descriptions

Log Format

Description

Serial binary

Binary file containing InertialSense binary (ISB) DID data sets in "chunk" groups containing data in serial(.dat)

order as they appear over the serial port. Default file format. Recommended for post processing.

Raw packet

Binary file containing byte for byte data received over the serial ports. All packets remain in their native form.

(.raw)

Used for logging InertialSense binary (ISB), NMEA, RTCM3, uBlox UBX binary and SPARTN, and any otherpacket formats. Recommended for logging all data formats and post processing.

Sorted binary

Binary file containing InertialSense binary (ISB) DID data sets in "chunk" groups organized by DID. Each(.sdat)chunk contains only one DID type, and at least one chunk allocated for each DID data set type. Not
recommended for future use.

Comma

Plain text file that uses specific structuring to arrange tabular data. Its basic format involves separating eachseparateddata field (or cell in a table) with a comma and each record (or row) is on a new line. This simple format allows(.csv)

for ease in data import and export between programs that handle tabular data, such as databases andspreadsheets.

4. Summary Window - Shows the log directly path, the elapsed time the data log has been running, the total size of the log file, and alist currently recording DIDs with corresponding dt (time between measurements).
5. File Conversion Utility - Enables you to convert the data log file type in a specified directory. (e.g. .dat to .csv)

Settings Tab
The Settings tab has 3 sub tabs and they are as follows:
Settings - Serial Ports Tab- 102/348 -©2022

6.2.6 Tab Descriptions

1. Open All - Opens all of the ports shown.
2. Close All - Closes all of the ports shown.
3. Find Devices - Determines which peripherals into your computer are Inertial Sense units, and opens those ports while closing theothers.
4. Baud Rate - The rate at which data will be communicated over your data channel.
5. Update Firmware - Allows you to update your unit's firmware when an update is released from Inertial Sense.
6. Port Status - Shows a list of all connected comports and basic information for each of them. Clicking the check box opens the port.
Settings - General Tab- 103/348 -©2022

6.2.6 Tab Descriptions

1. Software Reset - Allows the user to issue a reset to the unit. has options for all open comports and only the currently connectedunit.
2. Zero Motion - Allows the user to informs the EKF that the system is stationary on the ground and is used to aid in IMU bias
estimation which can reduce drift in the INS attitude.
3. DID_Flash_Config - Gives the user option to disable or enable different features normally found in the "Data Sets" tab. For more
information about the Flash Config see Data sets.
Settings - GPS Tab- 104/348 -©2022

6.2.6 Tab Descriptions

1. IMX Parameters - Shows flash config settings commonly used when setting up RTK units
2. Status - Shows information important to using RTK.
3. Rover/Base Mode - Used in setup of RTK Rovers and RTK base Stations.
4. Message Window - Shows confirmation messages and Flash Config writes.

About Tab
The about tab shows version information for the EvalTool and connected device. It also provides helpful links to online
documentation and software release information.

- 105/348 -©2022

6.2.6 Tab Descriptions- 106/348 -©2022

6.3 SDK

6.3 SDK
Overview
The Inertial Sense open source software development kit (SDK) provides quick integration for communication with the Inertial
Sense product line, including the µIMU, µAHRS, and µINS. It includes data logger, math libraries, and serial port interface forLinux and Windows environments.

6.3.1 C vs. C++ Implementation
The Inertial Sense SDK provides both C and C++ programming language implementation. The following compares differences
between these implementations.

C• Easier implementation• Light weight• Smaller code size
• Minimal subset of SDK files• Recommended for smaller projects that require lower memory usage.
• SDK files: ISComm.c

C++• Object oriented device representation• Fully integrated support for:• Commutations: single or multiple data type callback functions.
• Serial port handling included• Datalogging• Firmware update (bootloader)• Recommended for typical to advanced C++ applications and production level integration.
• SDK files: InertialSense.cpp

6.3.2 Installing and Configuring Visual Studio
The SDK example projects can be conveniently compiled using gcc with cmake or Visual Studio. The following sections outline
how to setup Visual Studio for use with the SDK example projects.

Installing
The SDK example projects can be compiled using the Community (free) version of Visual Studio. Windows SDK should beinstalled in addition to Visual Studio, as an added option in the Visual Studio installer or using the separate Windows SDK
installer.
• Visual Studio• Windows SDK - Can be installed using option in Visual Studio Installer or using separate Windows SDK installer.

- 107/348 -©2022

6.3.3 SDK Example Projects Overview

Configuring
When compiling an Inertial Sense SDK example project in Visual Studio, the currently installed version of Windows SDK must be
selected in the project properties, as illustrated below:
Project properties > General > Windows SDK Version > [Currently Installed Version]

6.3.3 SDK Example Projects Overview
Example Project

Language

Description

NMEA

C

How to use SDK for NMEA NMEA communications.

C

How to use SDK for binary communications.

Fimrware Update

C

How to use bootloader for embedded firmware update.

Data LoggerC++

How to use SDK data logging.

CLToolC++

Open source project illustrating how to use the InertialSense C++ class. It

Communications
BinaryCommunications

combines all SDK capabilities including serial communications, data logging tofile, and embedded firmware update.

6.3.4- 108/348 -©2022

6.4 Log Inspector

6.4 Log Inspector
6.4.1 Overview
Log Inspector is an open source python utility for viewing and scrubbing InertialSense data log (.dat) files.

6.4.2 Getting Started
Log Inspector can open and plot .dat PPD log files. The lower left hand corner file browser allows you to enter a "working
directory" in the directory field. The whole directory containing the desired is selected from the directory tree. Once the log is
opened, the buttons in the upper left hand corner are used to graph various data sets.

- 109/348 -©2022

6.4.3 Standard data sets

6.4.3 Standard data sets
• POS NED Map - Used to plot INS position data in NED frame.
• POS NED - INS position in NED frame.
• POS LLA - INS and GNSS position in LLA.
• GPS LLA - GNSS LLA position.
• Vel NED - Velocity in NED frame.
• Vel UVW - Velocity in body frame.
• Attitude - Euler angle attitude in degrees.
• Heading - Heading data from magnetometer, INS, and RTK.
• INS Status - Plots of status flags vs time.
• HDW Status - plots of hardware status flags vs time.

6.4.4 Building
Note - logInspector requires Python 3.

Navigate to the Inertial Sense SDK directory
pip3 install logInspector/ # (this will return an error message, but will install all the dependencies you need)
cd logInspector
python3 setup.py build_ext --inplace

Create a config file.
C:\Users\[USER]\Documents\Inertial_Sense\config.yaml

Add the following or similar contents to this file.
directory: C:\Users\<username>\Documents\Inertial_Sense\Logs\20181116_SKI\morning_run_1\back\20181116_175352
logs_directory: C:\Users\<username>\Documents\Inertial_Sense\Logsserials: ["ALL"]

6.4.5 Running
To run logInspector open a shell and navigate to the logInspector directory and enter the following commands:
python3 logInspector.py

6.4.6 Other Directory Contents
The logInspector also contains some example implementations for dealing with log files directly in python.

logReaderThis python module is responsible for loading the log file through a pybind11 interface. All the data in the log is eventually put inthe log.data array.

- 110/348 -©2022

6.4.6 Other Directory Contents

logPlotter
This python module is responsible for creating plots. Adding new plots is easy, data is directly accessed using the member
logReader object.

logInspector
A pyqt5 GUI which uses logPlotter to generate plots.

- 111/348 -©2022

7. Communication Protocols

7. Communication Protocols
7.1 Protocol Overview
The Inertial Sense products support binary and NMEA protocol for communication.

7.1.1 Binary vs. NMEA
The following table compares the differences and advantages between the binary and NMEA protocols.

Data Efficient

Human

NMEA Protocol

Binary Protocol

No. Numbers must be converted to IEEE float

Numbers are in floating point and integer binary

and integers for application. Data occupies

format used in computers. Data occupies lessmore memory.

memory.

Yes

No

Packet are easier to parse.

Packet encoding, decoding, and parsing are

ReadableComplexity

MORE complicated. Using SDK is recommended.
SDK Support

Yes, lessYes, more

Data Access

Limited to sensor and INS output.

Comprehensive access to all data andconfiguration settings.

Recommended

Rapid prototypes and simple projects. Devices

Usesupporting NMEA.

Apps andNMEA Communications Example

Moderate to advanced applications.

EvalTool, CLTool, Binary Communications
Example, Fimrware Update Example, Data

ExamplesLogger Example- 112/348 -©2022

7.2 Data Sets (DIDs)

7.2 Data Sets (DIDs)
7.2.1 Data Sets (DIDs)
Data Sets in the form of C structures are available through binary protocol and provide access to system configuration andoutput data. The data sets are defined in SDK/src/data_sets.h of the InertialSense SDK.

INS / AHRS Output
DID_INS_1

INS output: euler rotation w/ respect to NED, NED position from reference LLA.
ins_1_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

insStatus

uint32_t

INS status flags (eInsStatusFlags). Copy of DID_SYS_PARAMS.insStatus

hdwStatus

uint32_t

Hardware status flags (eHdwStatusFlags). Copy of DID_SYS_PARAMS.hdwStatus

theta

float[3]Euler angles: roll, pitch, yaw in radians with respect to NED

uvw

float[3]Velocity U, V, W in meters per second. Convert to NED velocity using"vectorBodyToReference( uvw, theta, vel_ned )".

lladouble[3]WGS84 latitude, longitude, height above ellipsoid (degrees,degrees,meters)

nedfloat[3]North, east and down (meters) offset from reference latitude, longitude, and altitude tocurrent latitude, longitude, and altitude

DID_INS_2

INS output: quaternion rotation w/ respect to NED, ellipsoid altitude
ins_2_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

insStatus

uint32_t

INS status flags (eInsStatusFlags). Copy of DID_SYS_PARAMS.insStatus

hdwStatus

uint32_t

Hardware status flags (eHdwStatusFlags). Copy of DID_SYS_PARAMS.hdwStatusqn2b

float[4]Quaternion body rotation with respect to NED: W, X, Y, Z

uvw

float[3]Velocity U, V, W in meters per second. Convert to NED velocity using"quatRot(vel_ned, qn2b, uvw)".

lladouble[3]WGS84 latitude, longitude, height above ellipsoid in meters (not MSL)

DID_INS_3

Inertial navigation data with quaternion NED to body rotation and ECEF position.

- 113/348 -©2022

7.2.1 Data Sets (DIDs)

ins_3_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

insStatus

uint32_t

INS status flags (eInsStatusFlags). Copy of DID_SYS_PARAMS.insStatus

hdwStatus

uint32_t

Hardware status flags (eHdwStatusFlags). Copy of DID_SYS_PARAMS.hdwStatusqn2b

float[4]Quaternion body rotation with respect to NED: W, X, Y, Z

uvw

float[3]Velocity U, V, W in meters per second. Convert to NED velocity using"quatRot(vel_ned, qn2b, uvw)".

lladouble[3]WGS84 latitude, longitude, height above ellipsoid in meters (not MSL)

msl

float

height above mean sea level (MSL) in meters

DID_INS_4

INS output: quaternion rotation w/ respect to ECEF, ECEF position.
ins_4_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

insStatus

uint32_t

INS status flags (eInsStatusFlags). Copy of DID_SYS_PARAMS.insStatus

hdwStatus

uint32_t

Hardware status flags (eHdwStatusFlags). Copy of DID_SYS_PARAMS.hdwStatus

qe2b

float[4]Quaternion body rotation with respect to ECEF: W, X, Y, Z

ve

float[3]Velocity in ECEF (earth-centered earth-fixed) frame in meters per second

ecef

double[3]Position in ECEF (earth-centered earth-fixed) frame in meters

Inertial Measurement Unit (IMU)
DID_IMU

Inertial measurement unit data down-sampled from IMU rate (DID_FLASH_CONFIG.startupImuDtMs (1KHz)) to navigation
update rate (DID_FLASH_CONFIG.startupNavDtMs) as an anti-aliasing filter to reduce noise and preserve accuracy. Minimum
data period is DID_FLASH_CONFIG.startupNavDtMs (1KHz max).
imu_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

statusuint32_t

IMU Status (eImuStatus)I

imus_tInertial Measurement Unit (IMU)

DID_IMU_RAW

IMU data averaged from DID_IMU3_RAW. Use this IMU data for output data rates faster than
DID_FLASH_CONFIG.startupNavDtMs. Otherwise we recommend use of DID_IMU or DID_PIMU as they are oversampled andcontain less noise.

- 114/348 -©2022

7.2.1 Data Sets (DIDs)

imu_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

statusuint32_t

IMU Status (eImuStatus)I

imus_tInertial Measurement Unit (IMU)

DID_PIMU

Preintegrated IMU (a.k.a. Coning and Sculling integral) in body/IMU frame. Updated at IMU rate. Also know as delta theta delta
velocity, or preintegrated IMU (PIMU). For clarification, the name "Preintegrated IMU" or "PIMU" throughout our User Manual.
This data is integrated from the IMU data at the IMU update rate (startupImuDtMs, default 1ms). The integration period (dt) andoutput data rate are the same as the NAV rate (startupNavDtMs) and cannot be output at any other rate. If a faster output data
rate is desired, DID_IMU_RAW can be used instead. PIMU data acts as a form of compression, adding the benefit of higher
integration rates for slower output data rates, preserving the IMU data without adding filter delay and addresses antialiasing. It
is most effective for systems that have higher dynamics and lower communications data rates. The minimum data period is
DID_FLASH_CONFIG.startupImuDtMs or 4, whichever is larger (250Hz max). The PIMU value can be converted to IMU bydividing PIMU by dt (i.e. IMU = PIMU / dt)
pimu_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding gps.towOffset

dt

float

Integral period in seconds for delta theta and delta velocity. This is configured using
DID_FLASH_CONFIG.startupNavDtMs.

statusuint32_t

IMU Status (eImuStatus)

theta

float[3]IMU delta theta (gyroscope {p,q,r} integral) in radians in sensor framevelfloat[3]IMU delta velocity (accelerometer {x,y,z} integral) in m/s in sensor frame

Sensor Output
DID_BAROMETER

Barometric pressure sensor data
barometer_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

bar

float

Barometric pressure in kilopascals

mslBarfloat

MSL altitude from barometric pressure sensor in meters

barTempfloat

Temperature of barometric pressure sensor in Celsius

humidity

float

Relative humidity as a percent (%rH). Range is 0% - 100%

DID_MAGNETOMETER

Magnetometer sensor output- 115/348 -©2022

7.2.1 Data Sets (DIDs)

magnetometer_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

mag

float[3]Magnetometers in Gauss

DID_MAG_CAL

Magnetometer calibration
mag_cal_t

Field

Type

Description

state

uint32_t

Mag recalibration state. COMMANDS: 1=multi-axis, 2=single-axis, 101=abort, STATUS:
200=running, 201=done (see eMagCalState)progressfloat

Mag recalibration progress indicator: 0-100 %declination

float

Magnetic declination estimate

DID_SYS_SENSORS

System sensor information
sys_sensors_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding gps.towOffset

temp

float

Temperature in Celsius

pqr

float[3]Gyros in radians / secondacc

float[3]Accelerometers in meters / second squaredmagfloat[3]Magnetometers in Gauss

bar

float

Barometric pressure in kilopascals

barTempfloat

Temperature of barometric pressure sensor in Celsius

mslBarfloat

MSL altitude from barometric pressure sensor in metershumidity

float

Relative humidity as a percent (%rH). Range is 0% - 100%

vin

float

EVB system input voltage in volts. uINS pin 5 (G2/AN2). Use 10K/1K resistor divider
between Vin and GND.

ana1

float

ADC analog input in volts. uINS pin 4, (G1/AN1).

ana3

float

ADC analog input in volts. uINS pin 19 (G3/AN3).

ana4

float

ADC analog input in volts. uINS pin 20 (G4/AN4).

GPS / GNSSDID_GPS1_POS

GPS 1 position data. This comes from DID_GPS1_RCVR_POS or DID_GPS1_RTK_POS, depending on whichever is more accurate.

- 116/348 -©2022

7.2.1 Data Sets (DIDs)

gps_pos_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

ecef

double[3]Position in ECEF {x,y,z} (m)lladouble[3]Position - WGS84 latitude, longitude, height above ellipsoid (not MSL) (degrees, m)

hMSL

float

Height above mean sea level (MSL) in meters

hAcc

float

Horizontal accuracy in meters

vAcc

float

Vertical accuracy in meters

pDop

float

Position dilution of precision (unitless)cnoMeanfloat

Average of all non-zero satellite carrier to noise ratios (signal strengths) in dBHz

towOffset

doubleTime sync offset between local time since boot up to GPS time of week in seconds. Add
this to IMU and sensor time to get GPS time of week in seconds.

leapS

uint8_t

GPS leap second (GPS-UTC) offset. Receiver's best knowledge of the leap seconds
offset from UTC to GPS time. Subtract from GPS time of week to get UTC time of week.
(18 seconds as of December 31, 2016)

satsUsed

uint8_t

Number of satellites used

cnoMeanSigma

uint8_t

Standard deviation of cnoMean over past 5 seconds (dBHz x10)

reserved

uint8_t

Reserved for future use

DID_GPS1_RCVR_POS

GPS 1 position data from GNSS receiver.

- 117/348 -©2022

7.2.1 Data Sets (DIDs)

gps_pos_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

ecef

double[3]Position in ECEF {x,y,z} (m)lladouble[3]Position - WGS84 latitude, longitude, height above ellipsoid (not MSL) (degrees, m)

hMSL

float

Height above mean sea level (MSL) in meters

hAcc

float

Horizontal accuracy in meters

vAcc

float

Vertical accuracy in meters

pDop

float

Position dilution of precision (unitless)cnoMeanfloat

Average of all non-zero satellite carrier to noise ratios (signal strengths) in dBHz

towOffset

doubleTime sync offset between local time since boot up to GPS time of week in seconds. Add
this to IMU and sensor time to get GPS time of week in seconds.

leapS

uint8_t

GPS leap second (GPS-UTC) offset. Receiver's best knowledge of the leap seconds
offset from UTC to GPS time. Subtract from GPS time of week to get UTC time of week.
(18 seconds as of December 31, 2016)

satsUsed

uint8_t

Number of satellites used

cnoMeanSigma

uint8_t

Standard deviation of cnoMean over past 5 seconds (dBHz x10)

reserved

uint8_t

Reserved for future use

DID_GPS1_RTK_POS

GPS RTK position data

- 118/348 -©2022

7.2.1 Data Sets (DIDs)

gps_pos_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

ecef

double[3]Position in ECEF {x,y,z} (m)lladouble[3]Position - WGS84 latitude, longitude, height above ellipsoid (not MSL) (degrees, m)

hMSL

float

Height above mean sea level (MSL) in meters

hAcc

float

Horizontal accuracy in meters

vAcc

float

Vertical accuracy in meters

pDop

float

Position dilution of precision (unitless)cnoMeanfloat

Average of all non-zero satellite carrier to noise ratios (signal strengths) in dBHz

towOffset

doubleTime sync offset between local time since boot up to GPS time of week in seconds. Add
this to IMU and sensor time to get GPS time of week in seconds.

leapS

uint8_t

GPS leap second (GPS-UTC) offset. Receiver's best knowledge of the leap seconds
offset from UTC to GPS time. Subtract from GPS time of week to get UTC time of week.
(18 seconds as of December 31, 2016)

satsUsed

uint8_t

Number of satellites used

cnoMeanSigma

uint8_t

Standard deviation of cnoMean over past 5 seconds (dBHz x10)

reserved

uint8_t

Reserved for future use

DID_GPS1_RTK_POS_MISC

RTK precision position related data.

- 119/348 -©2022

7.2.1 Data Sets (DIDs)

gps_rtk_misc_t- 120/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

accuracyPos

float[3]Accuracy - estimated standard deviations of the solution assuming apriori error model and error parameters by the positioning options. []:standard deviations {ECEF - x,y,z} or {north, east, down} (meters)

accuracyCovfloat[3]Accuracy - estimated standard deviations of the solution assuming apriori error model and error parameters by the positioning options. []:Absolute value of means square root of estimated covariance NE, EU,UN

arThresholdfloat

Ambiguity resolution threshold for validation

gDop

float

Geometric dilution of precision (meters)

hDop

float

Horizontal dilution of precision (meters)

vDop

float

Vertical dilution of precision (meters)baseLladouble[3]Base Position - latitude, longitude, height (degrees, meters)

cycleSlipCountuint32_t

Cycle slip counterroverGpsObservationCountuint32_t

Rover gps observation element counter

baseGpsObservationCountuint32_tBase station gps observation element counterroverGlonassObservationCountuint32_t

Rover glonass observation element counter

baseGlonassObservationCountuint32_tBase station glonass observation element counterroverGalileoObservationCountuint32_t

Rover galileo observation element counter

baseGalileoObservationCountuint32_tBase station galileo observation element counterroverBeidouObservationCountuint32_t

Rover beidou observation element counter

baseBeidouObservationCountuint32_tBase station beidou observation element counterroverQzsObservationCountuint32_t

Rover qzs observation element counter

baseQzsObservationCountuint32_tBase station qzs observation element counterroverGpsEphemerisCountuint32_t

Rover gps ephemeris element counter

baseGpsEphemerisCountuint32_tBase station gps ephemeris element counterroverGlonassEphemerisCountuint32_t

Rover glonass ephemeris element counter

baseGlonassEphemerisCountuint32_tBase station glonass ephemeris element counterroverGalileoEphemerisCountuint32_t

Rover galileo ephemeris element counter

baseGalileoEphemerisCountuint32_tBase station galileo ephemeris element counterroverBeidouEphemerisCountuint32_t

Rover beidou ephemeris element counter

baseBeidouEphemerisCountuint32_tBase station beidou ephemeris element counterroverQzsEphemerisCountuint32_t

Rover qzs ephemeris element counter

baseQzsEphemerisCountuint32_tBase station qzs ephemeris element counterroverSbasCountuint32_t

Rover sbas element counter

baseSbasCountuint32_tBase station sbas element counter

baseAntennaCountuint32_tBase station antenna position element counter- 121/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

ionUtcAlmCountuint32_t

Ionosphere model, utc and almanac countcorrectionChecksumFailuresuint32_t

Number of checksum failures from received corrections

timeToFirstFixMs

uint32_t

Time to first RTK fix.

DID_GPS1_RTK_POS_REL

RTK precision position base to rover relative info.
gps_rtk_rel_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

differentialAge

float

Age of differential (seconds)

arRatiofloat

Ambiguity resolution ratio factor for validation

baseToRoverVector

float[3]Vector from base to rover (m) in ECEF - If Compassing enabled, this is the 3vector from antenna 2 to antenna 1

baseToRoverDistancefloat

Distance from base to rover (m)baseToRoverHeading

float

Angle from north to baseToRoverVector in local tangent plane. (rad)baseToRoverHeadingAcc

float

Accuracy of baseToRoverHeading. (rad)statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used,[0x0000xx00] fix type, [0x00xx0000] status flags, NMEA input flag

DID_GPS1_SAT

GPS 1 GNSS satellite information: sat identifiers, carrier to noise ratio, elevation and azimuth angles, pseudo range residual.
gps_sat_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

numSats

uint32_t

Number of satellites in the skysat

gps_sat_sv_t[50]Satellite information list

DID_GPS1_VEL

GPS 1 velocity data
gps_vel_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in millisecondsvelfloat[3]GPS Velocity. Velocity is in ECEF {vx,vy,vz} (m/s) if status bit
GPS_STATUS_FLAGS_GPS_NMEA_DATA (0x00008000) is NOT set. Velocity is in local
tangent plane with no vertical velocity {vNorth, vEast, 0} (m/s) if status bit
GPS_STATUS_FLAGS_GPS_NMEA_DATA (0x00008000) is set.

sAcc

float

Speed accuracy in meters / second

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

- 122/348 -©2022

7.2.1 Data Sets (DIDs)

DID_GPS1_VERSION

GPS 1 version info
gps_version_t

Field

Type

Description

swVersion

uint8_t[30]Software version

hwVersion

uint8_t[10]Hardware version

extension

gps_extension_ver_t[6]Extension 30 bytes array description

DID_GPS2_POS

GPS 2 position data
gps_pos_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

ecef

double[3]Position in ECEF {x,y,z} (m)lladouble[3]Position - WGS84 latitude, longitude, height above ellipsoid (not MSL) (degrees, m)

hMSL

float

Height above mean sea level (MSL) in meters

hAcc

float

Horizontal accuracy in meters

vAcc

float

Vertical accuracy in meters

pDop

float

Position dilution of precision (unitless)cnoMeanfloat

Average of all non-zero satellite carrier to noise ratios (signal strengths) in dBHz

towOffset

doubleTime sync offset between local time since boot up to GPS time of week in seconds. Add
this to IMU and sensor time to get GPS time of week in seconds.

leapS

uint8_t

GPS leap second (GPS-UTC) offset. Receiver's best knowledge of the leap seconds
offset from UTC to GPS time. Subtract from GPS time of week to get UTC time of week.
(18 seconds as of December 31, 2016)

satsUsed

uint8_t

Number of satellites used

cnoMeanSigma

uint8_t

Standard deviation of cnoMean over past 5 seconds (dBHz x10)

reserved

uint8_t

Reserved for future use

DID_GPS2_RTK_CMP_MISC

RTK Dual GNSS RTK compassing related data.

- 123/348 -©2022

7.2.1 Data Sets (DIDs)

gps_rtk_misc_t- 124/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

accuracyPos

float[3]Accuracy - estimated standard deviations of the solution assuming apriori error model and error parameters by the positioning options. []:standard deviations {ECEF - x,y,z} or {north, east, down} (meters)

accuracyCovfloat[3]Accuracy - estimated standard deviations of the solution assuming apriori error model and error parameters by the positioning options. []:Absolute value of means square root of estimated covariance NE, EU,UN

arThresholdfloat

Ambiguity resolution threshold for validation

gDop

float

Geometric dilution of precision (meters)

hDop

float

Horizontal dilution of precision (meters)

vDop

float

Vertical dilution of precision (meters)baseLladouble[3]Base Position - latitude, longitude, height (degrees, meters)

cycleSlipCountuint32_t

Cycle slip counterroverGpsObservationCountuint32_t

Rover gps observation element counter

baseGpsObservationCountuint32_tBase station gps observation element counterroverGlonassObservationCountuint32_t

Rover glonass observation element counter

baseGlonassObservationCountuint32_tBase station glonass observation element counterroverGalileoObservationCountuint32_t

Rover galileo observation element counter

baseGalileoObservationCountuint32_tBase station galileo observation element counterroverBeidouObservationCountuint32_t

Rover beidou observation element counter

baseBeidouObservationCountuint32_tBase station beidou observation element counterroverQzsObservationCountuint32_t

Rover qzs observation element counter

baseQzsObservationCountuint32_tBase station qzs observation element counterroverGpsEphemerisCountuint32_t

Rover gps ephemeris element counter

baseGpsEphemerisCountuint32_tBase station gps ephemeris element counterroverGlonassEphemerisCountuint32_t

Rover glonass ephemeris element counter

baseGlonassEphemerisCountuint32_tBase station glonass ephemeris element counterroverGalileoEphemerisCountuint32_t

Rover galileo ephemeris element counter

baseGalileoEphemerisCountuint32_tBase station galileo ephemeris element counterroverBeidouEphemerisCountuint32_t

Rover beidou ephemeris element counter

baseBeidouEphemerisCountuint32_tBase station beidou ephemeris element counterroverQzsEphemerisCountuint32_t

Rover qzs ephemeris element counter

baseQzsEphemerisCountuint32_tBase station qzs ephemeris element counterroverSbasCountuint32_t

Rover sbas element counter

baseSbasCountuint32_tBase station sbas element counter

baseAntennaCountuint32_tBase station antenna position element counter- 125/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

ionUtcAlmCountuint32_t

Ionosphere model, utc and almanac countcorrectionChecksumFailuresuint32_t

Number of checksum failures from received corrections

timeToFirstFixMs

uint32_t

Time to first RTK fix.

DID_GPS2_RTK_CMP_REL

Dual GNSS RTK compassing / moving base to rover (GPS 1 to GPS 2) relative info.
gps_rtk_rel_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

differentialAge

float

Age of differential (seconds)

arRatiofloat

Ambiguity resolution ratio factor for validation

baseToRoverVector

float[3]Vector from base to rover (m) in ECEF - If Compassing enabled, this is the 3vector from antenna 2 to antenna 1

baseToRoverDistancefloat

Distance from base to rover (m)baseToRoverHeading

float

Angle from north to baseToRoverVector in local tangent plane. (rad)baseToRoverHeadingAcc

float

Accuracy of baseToRoverHeading. (rad)statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used,[0x0000xx00] fix type, [0x00xx0000] status flags, NMEA input flag

DID_GPS2_SAT

GPS 2 GNSS satellite information: sat identifiers, carrier to noise ratio, elevation and azimuth angles, pseudo range residual.
gps_sat_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

numSats

uint32_t

Number of satellites in the skysat

gps_sat_sv_t[50]Satellite information list

DID_GPS2_VEL

GPS 2 velocity data
gps_vel_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in millisecondsvelfloat[3]GPS Velocity. Velocity is in ECEF {vx,vy,vz} (m/s) if status bit
GPS_STATUS_FLAGS_GPS_NMEA_DATA (0x00008000) is NOT set. Velocity is in local
tangent plane with no vertical velocity {vNorth, vEast, 0} (m/s) if status bit
GPS_STATUS_FLAGS_GPS_NMEA_DATA (0x00008000) is set.

sAcc

float

Speed accuracy in meters / second

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags, NMEA input flag

- 126/348 -©2022

7.2.1 Data Sets (DIDs)

DID_GPS2_VERSION

GPS 2 version info
gps_version_t

Field

Type

Description

swVersion

uint8_t[30]Software version

hwVersion

uint8_t[10]Hardware version

extension

gps_extension_ver_t[6]Extension 30 bytes array description

DID_GPS_RTK_OPT

RTK options - requires little endian CPU.

- 127/348 -©2022

7.2.1 Data Sets (DIDs)

gps_rtk_opt_t- 128/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

mode

int32_t

positioning mode (PMODE_???)

soltype

int32_tsolution type (0:forward,1:backward,2:combined)nf

int32_t

number of frequencies (1:L1,2:L1+L2,3:L1+L2+L5)

navsysint32_tnavigation systems

elmin

doubleelevation mask angle (rad)snrminint32_t

Min snr to consider satellite for rtk

modearint32_t

AR mode (0:off,1:continuous,2:instantaneous,3:fix and hold,4:ppp-ar)

glomodear

int32_t

GLONASS AR mode (0:off,1:on,2:auto cal,3:ext cal)

gpsmodear

int32_t

GPS AR mode (0:off,1:on)sbsmodear

int32_t

SBAS AR mode (0:off,1:on)bdsmodear

int32_t

BeiDou AR mode (0:off,1:on)

arfilter

int32_t

AR filtering to reject bad sats (0:off,1:on)

maxoutint32_t

obs outage count to reset bias

maxrejint32_t

reject count to reset bias

minlock

int32_t

min lock count to fix ambiguity

minfixsats

int32_t

min sats to fix integer ambiguities

minholdsats

int32_t

min sats to hold integer ambiguities

mindropsats

int32_t

min sats to drop sats in AR

rcvstds

int32_t

use stdev estimates from receiver to adjust measurement variances

minfixint32_t

min fix count to hold ambiguity

armaxiter

int32_t

max iteration to resolve ambiguity

dynamics

int32_t

dynamics model (0:none,1:velociy,2:accel)

niter

int32_t

number of filter iteration

intpref

int32_tinterpolate reference obs (for post mission)

rovposint32_trover position for fixed mode

refposint32_tbase position for relative modeeratiodouble[]code/phase error ratio

err

double[5]measurement error factor

std

double[3]initial-state std [0]bias,[1]iono [2]trop

prndouble[6]process-noise std [0]bias,[1]iono [2]trop [3]acch [4]accv [5] possclkstabdoublesatellite clock stability (sec/sec)

thresardouble[8]AR validation thresholdelmaskardoubleelevation mask of AR for rising satellite (rad)elmaskhold

doubleelevation mask to hold ambiguity (rad)thresslip

doubleslip threshold of geometry-free phase (m)- 129/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

thresdop

doublevariance for fix-and-hold pseudo measurements (cycle^2)varholdamb

doublegain used for GLO and SBAS sats to adjust ambiguity

gainholdamb

doublemax difference of time (sec)maxtdiff

doublereset sat biases after this long trying to get fix if not acquired

fix_reset_base_msgs

int

reject thresholds of NIS

maxinnodouble[2]reject threshold of gdop

maxnis_lo

doublebaseline length constraint {const,sigma before fix, sigma after fix} (m)maxnis_hi

doublemaximum error wrt ubx position (triggers reset if more than this far) (m)maxgdop

doublerover position for fixed mode {x,y,z} (ecef) (m)baseline

double[3]base position for relative mode {x,y,z} (ecef) (m)max_baseline_error

doublemax averaging epochs

reset_baseline_error

doubleoutput single by dgps/float/fix/ppp outage

Raw GPS Data
Raw GPS data is contained in the DID_GPS1_RAW , DID_GPS2_RAW , and DID_GPS_BASE_RAW messages of type gps_raw_t . The actual raw
data is contained in the union member gps_raw_t.data and should be interpreted based on the value of gps_raw_t.dataType (i.e. as
observation, ephemeris, SBAS, or base station position).
DID_GPS1_RAW

GPS raw data for rover (observation, ephemeris, etc.) - requires little endian CPU. The contents of data can vary for this message
and are determined by dataType field. RTK positioning or RTK compassing must be enabled to stream this message.
gps_raw_t

Field

Type

Description

receiverIndex

uint8_t

Receiver index (1=RECEIVER_INDEX_GPS1,
2=RECEIVER_INDEX_EXTERNAL_BASE, or 3=RECEIVER_INDEX_GPS2 )dataType

uint8_t

Type of data (eRawDataType: 1=observations, 2=ephemeris, 3=glonassEphemeris,
4=SBAS, 5=baseAntenna, 6=IonosphereModel)

obsCount

uint8_t

Number of observations in data (obsd_t) when dataType==1(raw_data_type_observation).

reserved

uint8_t

Reserved

data

uGpsRawData

Interpret based on dataType (see eRawDataType)

DID_GPS2_RAW

GPS raw data for rover (observation, ephemeris, etc.) - requires little endian CPU. The contents of data can vary for this message
and are determined by dataType field. RTK positioning or RTK compassing must be enabled to stream this message.

- 130/348 -©2022

7.2.1 Data Sets (DIDs)

gps_raw_t

Field

Type

Description

receiverIndex

uint8_t

Receiver index (1=RECEIVER_INDEX_GPS1,
2=RECEIVER_INDEX_EXTERNAL_BASE, or 3=RECEIVER_INDEX_GPS2 )dataType

uint8_t

Type of data (eRawDataType: 1=observations, 2=ephemeris, 3=glonassEphemeris,
4=SBAS, 5=baseAntenna, 6=IonosphereModel)

obsCount

uint8_t

Number of observations in data (obsd_t) when dataType==1(raw_data_type_observation).

reserved

uint8_t

Reserved

data

uGpsRawData

Interpret based on dataType (see eRawDataType)

DID_GPS_BASE_RAW

GPS raw data for base station (observation, ephemeris, etc.) - requires little endian CPU. The contents of data can vary for thismessage and are determined by dataType field. RTK positioning or RTK compassing must be enabled to stream this message.
gps_raw_t

Field

Type

Description

receiverIndex

uint8_t

Receiver index (1=RECEIVER_INDEX_GPS1,
2=RECEIVER_INDEX_EXTERNAL_BASE, or 3=RECEIVER_INDEX_GPS2 )dataType

uint8_t

Type of data (eRawDataType: 1=observations, 2=ephemeris, 3=glonassEphemeris,
4=SBAS, 5=baseAntenna, 6=IonosphereModel)

obsCount

uint8_t

Number of observations in data (obsd_t) when dataType==1(raw_data_type_observation).

reserved

uint8_t

Reserved

data

uGpsRawData

Interpret based on dataType (see eRawDataType)RAW GPS DATA BUFFER UNION

uGpsRawData

Field

Type

Description

obs

obsd_t[]Satellite observation data

eph

eph_t

Satellite non-GLONASS ephemeris data (GPS, Galileo, Beidou, QZSS)

gloEphgeph_tSatellite GLONASS ephemeris datasbas

sbsmsg_t

Satellite-Based Augmentation Systems (SBAS) data

sta

sta_t

Base station information (base position, antenna position, antenna height,
etc.)

ion

ion_model_utc_alm_t

Ionosphere model and UTC parametersbuf

uint8_t[1000]

Byte buffer- 131/348 -©2022

7.2.1 Data Sets (DIDs)

GPS GALILEO QZSS EPHEMERIS

eph_t- 132/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Descriptionsat

int32_t

Satellite number in RTKlib notation. GPS: 1-32, GLONASS: 33-59, Galilleo: 60-89, SBAS:
90-95

iode

int32_t

IODE Issue of Data, Ephemeris (ephemeris version)iodc

int32_t

IODC Issue of Data, Clock (clock version)

sva

int32_t

SV accuracy (URA index) IRN-IS-200H p.97

svh

int32_t

SV health GPS/QZS (0:ok)

week

int32_t

GPS/QZS: gps week, GAL: galileo weekcode

int32_t

GPS/QZS: code on L2. (00 = Invalid, 01 = P Code ON, 11 = C/A code ON, 11 = Invalid).
GAL/CMP: data sources

flag

int32_t

GPS/QZS: L2 P data flag (indicates that the NAV data stream was commanded OFF on the Pcode of the in-phase component of the L2 channel). CMP: nav typetoe

gtime_t

Time Of Ephemeris, ephemeris reference epoch in seconds within the week (s)tocgtime_tclock data reference time (s) (20.3.4.5)

ttr

gtime_t

T_trans (s)AdoubleOrbit semi-major axis (m)edoubleOrbit eccentricity (non-dimensional)i0

doubleOrbit inclination angle at reference time (rad)OMG0doubleLongitude of ascending node of orbit plane at weekly epoch (rad)omgdoubleArgument of perigee (rad)M0doubleMean anomaly at reference time (rad)delndoubleMean Motion Difference From Computed Value (rad)OMGddoubleRate of Right Ascension (rad/s)

idot

doubleRate of Inclination Angle (rad/s)

crc

doubleAmplitude of the Cosine Harmonic Correction Term to the Orbit Radius (m)crsdoubleAmplitude of the Sine Harmonic Correction Term to the Orbit Radius (m)cucdoubleAmplitude of the Cosine Harmonic Correction Term to the Argument of Latitude (rad)cusdoubleAmplitude of the Sine Harmonic Correction Term to the Argument of Latitude (rad)cicdoubleAmplitude of the Cosine Harmonic Correction Term to the Angle of Inclination (rad)cisdoubleAmplitude of the Sine Harmonic Correction Term to the Angle of Inclination (rad)toesdoubleTime Of Ephemeris, ephemeris reference epoch in seconds within the week (s), same asabove but represented as double type. Note that toe is computed as eph->toe =gst2time(week, eph->toes)

fit

doubleFit interval (h) (0: 4 hours, 1: greater than 4 hours)

f0

doubleSV clock offset, af0 (s)f1doubleSV clock drift, af1 (s/s, non-dimensional)

f2

doubleSV clock drift rate, af2 (1/s)

tgd

double[4]Group delay parameters GPS/QZS: tgd[0] = TGD (IRN-IS-200H p.103). Galilleo: tgd[0] =BGD E5a/E1, tgd[1] = BGD E5b/E1. Beidou: tgd[0] = BGD1, tgd[1] = BGD2

- 133/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

AdotdoubleAdot for CNAV, not used

ndot

doubleFirst derivative of mean motion n (second derivative of mean anomaly M), ndot for CNAV
(rad/s/s). Not used.

GLONASS EPHEMERIS

geph_t

Field

Type

Descriptionsat

int32_t

Satellite number in RTKlib notation. GPS: 1-32, GLONASS: 33-59, Galilleo: 60-89,
SBAS: 90-95

iode

int32_t

IODE (0-6 bit of tb field)

frq

int32_tsatellite frequency number

svh

int32_tsatellite healthsva

int32_tsatellite accuracy

age

int32_tsatellite age of operation

toe

gtime_t

Ephemeris reference epoch in seconds within the week in GPS time gpst (s)tofgtime_t

message frame time in gpst (s)posdouble[3]satellite position (ecef) (m)veldouble[3]satellite velocity (ecef) (m/s)

accdouble[3]satellite acceleration (ecef) (m/s^2)

taun

doubleSV clock bias (s)gamndoublerelative frequency bias

dtaun

doubledelay between L1 and L2 (s)SBAS

sbsmsg_t

Field

Type

Description

weekint32_treceiption time - weektow

int32_t

reception time - tow

prn

int32_t

SBAS satellite PRN number

msg

uint8_t[29]SBAS message (226bit) padded by 0

reserved

uint8_t[3]reserved for alighment- 134/348 -©2022

7.2.1 Data Sets (DIDs)

STATION PARAMETERS

sta_t

Field

Type

Description

deltype

int32_tantenna delta type (0:enu,1:xyz)

posdouble[3]station position (ecef) (m)deldouble[3]antenna position delta (e/n/u or x/y/z) (m)hgt

doubleantenna height (m)stationId

int32_tstation id

Field

Type

Descriptionnuint32_t

number of observation slots used

nmax

uint32_t

number of observation slots allocateddata

obsd_tobservation data buffer

Field

Type

Description

gnssIduint8_t

GNSS identifier (see eSatSvGnssId)

svId

uint8_t

Satellite identifier

elev

int8_t(deg) Elevation (range: ±90)azim

int16_t(deg) Azimuth (range: ±180)cno

uint8_t(dBHz) Carrier to noise ratio (signal strength)

statusuint16_t(see eSatSvStatus)

SATELLITE OBSERVATION

obs_t

SATELLITE INFORMATION

gps_sat_sv_t

INERTIAL MEASUREMENT UNIT (IMU)

imus_t

Field

Type

Description

pqr

float[3]Gyroscope P, Q, R in radians / secondacc

float[3]Acceleration X, Y, Z in meters / second squared

Configuration
DID_FLASH_CONFIG

Flash memory configuration- 135/348 -©2022

7.2.1 Data Sets (DIDs)

nvm_flash_cfg_t- 136/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description

size

uint32_t

Size of group or union, which is nvm_group_x_t + padding

checksumuint32_t

Checksum, excluding size and checksum

key

uint32_t

Manufacturer method for restoring flash defaults

startupImuDtMs

uint32_t

IMU sample (system input) period in milliseconds set on startup. Cannot
be larger than startupNavDtMs. Zero disables sensor/IMU sampling.

startupNavDtMs

uint32_t

Navigation filter (system output) output period in milliseconds set on
startup. Used to initialize sysParams.navOutputPeriodMs.

ser0BaudRate

uint32_t

Serial port 0 baud rate in bits per second

ser1BaudRate

uint32_t

Serial port 1 baud rate in bits per second

insRotation

float[3]Rotation in radians about the X,Y,Z axes from Sensor Frame toIntermediate Output Frame. Order applied: Z,Y,X.

insOffset

float[3]

X,Y,Z offset in meters from Intermediate Output Frame to INS Output
Frame.

gps1AntOffset

float[3]

X,Y,Z offset in meters in Sensor Frame to GPS 1 antenna.

dynamicModel

uint8_t

INS dynamic platform model (see eDynamicModel). Options are:
0=PORTABLE, 2=STATIONARY, 3=PEDESTRIAN, 4=GROUNDVEHICLE, 5=SEA, 6=AIRBORNE_1G, 7=AIRBORNE_2G,
8=AIRBORNE_4G, 9=WRIST. Used to balance noise and performance
characteristics of the system. The dynamics selected here must be atleast as fast as your system or you experience accuracy error. This is tied
to the GPS position estimation model and intend in the future to beincorporated into the INS position model.

debug

uint8_t

Debug

gnssSatSigConst

uint16_t

Satellite system constellation used in GNSS solution. (seeeGnssSatSigConst) 0x0003=GPS, 0x000C=QZSS, 0x0030=Galileo,
0x00C0=Beidou, 0x0300=GLONASS, 0x1000=SBAS

sysCfgBits

uint32_t

System configuration bits (see eSysConfigBits).

refLladouble[3]Reference latitude, longitude and height above ellipsoid for north east
down (NED) calculations (deg, deg, m)

lastLladouble[3]Last latitude, longitude, HAE (height above ellipsoid) used to aid GPS
startup (deg, deg, m). Updated when the distance between current LLA
and lastLla exceeds lastLlaUpdateDistance.

lastLlaTimeOfWeekMs

uint32_t

Last LLA GPS time since week start (Sunday morning) in milliseconds

lastLlaWeekuint32_t

Last LLA GPS number of weeks since January 6th, 1980

lastLlaUpdateDistancefloat

Distance between current and last LLA that triggers an update of lastLla

ioConfig

uint32_t

Hardware interface configuration bits (see eIoConfig).

platformConfig

uint32_t

Hardware platform specifying the IMX carrier board type (i.e. RUG,
EVB, IG) and configuration bits (see ePlatformConfig). The platform type
is used to simplify the GPS and I/O configuration process.

gps2AntOffset

float[3]

X,Y,Z offset in meters in Sensor Frame origin to GPS 2 antenna.

zeroVelRotation

float[3]Euler (roll, pitch, yaw) rotation in radians from INS Sensor Frame toIntermediate ZeroVelocity Frame. Order applied: heading, pitch, roll.

zeroVelOffset

float[3]- 137/348 -©2022

7.2.1 Data Sets (DIDs)

Field

Type

Description
X,Y,Z offset in meters from Intermediate ZeroVelocity Frame to Zero
Velocity Frame.

gpsTimeUserDelayfloat(sec) User defined delay for GPS time. This parameter can be used toaccount for GPS antenna cable delay.

magDeclination

float

Earth magnetic field (magnetic north) declination (heading offset fromtrue north) in radians

gpsTimeSyncPeriodMs

uint32_t

Time between GPS time synchronization pulses in milliseconds. Requires
reboot to take effect.

startupGPSDtMs

uint32_t

GPS measurement (system input) update period in milliseconds set on
startup. 200ms minimum (5Hz max).

RTKCfgBits

uint32_t

RTK configuration bits (see eRTKConfigBits).

sensorConfig

uint32_t

Sensor config to specify the full-scale sensing ranges and output rotation
for the IMU and magnetometer (see eSensorConfig in data_sets.h)

gpsMinimumElevation

float

Minimum elevation of a satellite above the horizon to be used in thesolution (radians). Low elevation satellites may provide degradedaccuracy, due to the long signal path through the atmosphere.

ser2BaudRate

uint32_t

Serial port 2 baud rate in bits per second

wheelConfig

wheel_config_t

Wheel encoder: euler angles describing the rotation from imu to left
wheel

magInterferenceThreshold

float

Magnetometer interference sensitivity threshold. Typical range is 2-10
(3 default) and 1000 to disable mag interference detection.

DID_NMEA_BCAST_PERIOD

Set broadcast periods for NMEA messages
nmea_msgs_t

Field

Type

Description

options

uint32_t

Options: Port selection[0x0=current, 0x1=ser0, 0x2=ser1, 0x4=ser2, 0x8=USB,
0x100=preserve, 0x200=Persistant] (see RMC_OPTIONS_...)

msgCount

uint8_t

The number of messages being set in this message

DID_RMC

Realtime Message Controller (RMC). The data sets available through RMC are driven by the availability of the data. The RMC
provides updates from various data sources (i.e. sensors) as soon as possible with minimal latency. Several of the data sources(sensors) output data at different data rates that do not all correspond. The RMC is provided so that broadcast of sensor data isdone as soon as it becomes available. All RMC messages can be enabled using the standard Get Data packet format.
rmc_t

Field

Type

Description

bits

uint64_t

Data stream enable bits for the specified ports. (see RMC_BITS_...)

options

uint32_t

Options to select alternate ports to output data, etc. (see RMC_OPTIONS_...)

Command
DID_SYS_CMD

System commands. Both the command and invCommand fields must be set at the same time for a command to take effect.

- 138/348 -©2022

7.2.1 Data Sets (DIDs)

system_command_t

Field

Type

Descriptioncommanduint32_t

System commands (see eSystemCommand) 1=save current persistent messages, 5=zeromotion, 97=save flash, 99=software reset. "invCommand" (following variable) must be set
to bitwise inverse of this value for this command to be processed.

invCommand

uint32_t

Error checking field that must be set to bitwise inverse of command field for the commandto take effect.

EVB-2
DID_EVB_FLASH_CFG

EVB configuration.

- 139/348 -©2022

7.2.1 Data Sets (DIDs)

evb_flash_cfg_t

Field

Type

Description

size

uint32_t

Size of this struct

checksumuint32_t

Checksum, excluding size and checksum

key

uint32_t

Manufacturer method for restoring flash defaults

cbPresetuint8_t

Communications bridge preset. (seeeEvb2ComBridgePreset)

reserved1

uint8_t[3]Communications bridge forwardingcbf

uint32_t[EVB2_PORT_COUNT]

Communications bridge options (seeeEvb2ComBridgeOptions)cbOptions

uint32_t

Config bits (see eEvbFlashCfgBits)

bits

uint32_t

Radio preamble ID (PID) - 0x0 to 0x9. Only radios withmatching PIDs can communicate together. Different PIDs
minimize interference between multiple sets of networks.
Checked before the network ID.

radioPID

uint32_t

Radio network ID (NID) - 0x0 to 0x7FFF. Only radios withmatching NID can communicate together. Checked after
the preamble ID.

radioNID

uint32_t

Radio power level - Transmitter output power level. (XBee
PRO SX 0=20dBm, 1=27dBm, 2=30dBm)

radioPowerLevel

uint32_t

WiFi SSID and PSK

wifi

evb_wifi_t[3]Server IP and port

serverevb_server_t[3]Encoder tick to wheel rotation conversion factor (inradians). Encoder tick count per revolution on 1 channel x
gear ratio x 2pi.

encoderTickToWheelRadfloat

CAN baudrate

CANbaud_kbps

uint32_t

CAN receive address

can_receive_address

uint32_t

EVB port for uINS communications and SD card logging.
0=uINS-Ser0 (default), 1=uINS-Ser1, SP330=5,
6=GPIO_H8 (use eEvb2CommPorts)

uinsComPort

uint8_t

EVB port for uINS aux com and RTK corrections. 0=uINSSer0, 1=uINS-Ser1 (default), 5=SP330, 6=GPIO_H8 (useeEvb2CommPorts)

uinsAuxPort

uint8_t

Enable radio RTK filtering, etc. (see eEvb2PortOptions)reserved2

uint8_t[2]Baud rate for EVB serial port H3 (SP330 RS233 andRS485/422).

portOptions

uint32_t

Baud rate for EVB serial port H4 (TLL to external radio).

h3sp330BaudRate

uint32_t

Baud rate for EVB serial port H8 (TLL).

h4xRadioBaudRate

uint32_t

Wheel encoder configuration (see eWheelCfgBits)

h8gpioBaudRate

uint32_t

Wheel update period. Sets the wheel encoder and control
update period. (ms)- 140/348 -©2022

7.2.1 Data Sets (DIDs)

DID_EVB_STATUS

EVB monitor and log control interface.
evb_status_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

firmwareVer

uint8_t[4]Firmware (software) version

evbStatus

uint32_t

Status (eEvbStatus)

loggerModeuint32_t

Data logger control state. (see eEvb2LoggerMode)loggerElapsedTimeMs

uint32_tloggerwifiIpAddr

uint32_t

WiFi IP address

sysCommand

uint32_t

System command (see eSystemCommand). 99 = software reset

towOffset

doubleTime sync offset between local time since boot up to GPS time of week inseconds. Add this to IMU and sensor time to get GPS time of week in seconds.

GeneralDID_BIT

System built-in self-test
bit_t

Field

Type

Description

state

uint32_t

Built-in self-test state (see eBitState)

hdwBitStatus

uint32_t

Hardware BIT status (see eHdwBitStatusFlags)

calBitStatus

uint32_t

Calibration BIT status (see eCalBitStatusFlags)

tcPqrBias

float

Temperature calibration bias

tcAccBias

float

Temperature calibration slope

tcPqrSlope

float

Temperature calibration linearity

tcAccSlope

float

Gyro error (rad/s)

tcPqrLinearity

float

Accelerometer error (m/s^2)

tcAccLinearity

float

Angular rate standard deviation

pqr

float

Acceleration standard deviation

acc

float

Self-test mode (see eBitTestMode)

DID_CAN_CONFIG

Addresses for CAN messages- 141/348 -©2022

7.2.1 Data Sets (DIDs)

can_config_t

Field

Type

Description

can_period_mult

uint16_t[]

Broadcast period multiple - CAN time message. 0 to disable.

can_transmit_address

uint32_t[]Transmit address.

can_baudrate_kbps

uint16_t

Baud rate (kbps) (See can_baudrate_t for valid baud rates)

can_receive_address

uint32_t

Receive address.

DID_DEV_INFODevice information
dev_info_t

Field

Type

Description

reserved

uint16_t

Reserved bits

hardwareuint16_t

Hardware: 1=uINS, 2=EVB, 3=IMX, 4=GPX (see eDevInfoHardware)

serialNumber

uint32_t

Serial number

hardwareVer

uint8_t[4]Hardware version

firmwareVer

uint8_t[4]Firmware (software) version

buildNumber

uint32_t

Build number

protocolVer

uint8_t[4]Communications protocol version

repoRevisionuint32_t

Repository revision number

manufacturer

char[24]

Manufacturer namebuildTypeuint8_t

Build type (Release: 'a'=ALPHA, 'b'=BETA, 'c'=RELEASE CANDIDATE,'r'=PRODUCTION RELEASE, 'd'=debug)buildYearuint8_t

Build date year - 2000

buildMonthuint8_t

Build date monthbuildDay

uint8_t

Build date day

buildHouruint8_t

Build time hourbuildMinuteuint8_t

Build time minutebuildSecond

uint8_t

Build time secondbuildMillisecond

uint8_t

Build time millisecond

addInfochar[24]

Additional info

firmwareMD5Hashuint32_t[4]Firmware MD5 hash

DID_DIAGNOSTIC_MESSAGE

Diagnostic message- 142/348 -©2022

7.2.1 Data Sets (DIDs)

diag_msg_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

messageLength

uint32_t

Message length, including null terminatormessagechar[256]

Message data, max size of message is 256

Type

Description

DID_EVB_DEBUG_ARRAY

debug_array_t

Field

DID_EVB_DEV_INFO

EVB device information
dev_info_t

Field

Type

Description

reserved

uint16_t

Reserved bits

hardwareuint16_t

Hardware: 1=uINS, 2=EVB, 3=IMX, 4=GPX (see eDevInfoHardware)

serialNumber

uint32_t

Serial number

hardwareVer

uint8_t[4]Hardware version

firmwareVer

uint8_t[4]Firmware (software) version

buildNumber

uint32_t

Build number

protocolVer

uint8_t[4]Communications protocol version

repoRevisionuint32_t

Repository revision number

manufacturer

char[24]

Manufacturer namebuildTypeuint8_t

Build type (Release: 'a'=ALPHA, 'b'=BETA, 'c'=RELEASE CANDIDATE,'r'=PRODUCTION RELEASE, 'd'=debug)buildYearuint8_t

Build date year - 2000

buildMonthuint8_t

Build date monthbuildDay

uint8_t

Build date day

buildHouruint8_t

Build time hourbuildMinuteuint8_t

Build time minutebuildSecond

uint8_t

Build time secondbuildMillisecond

uint8_t

Build time millisecond

addInfochar[24]

Additional info

firmwareMD5Hashuint32_t[4]Firmware MD5 hash

DID_EVB_RTOS_INFO

EVB-2 RTOS information.

- 143/348 -©2022

7.2.1 Data Sets (DIDs)

evb_rtos_info_t

Field

Type

Description

freeHeapSize

uint32_t

Heap high water mark bytes

mallocSize

uint32_t

Total memory allocated using RTOS pvPortMalloc()

freeSizeuint32_t

Total memory freed using RTOS vPortFree()task

rtos_task_t[]

Tasks

DID_GPS1_SIG

GPS 1 GNSS signal information.
gps_sig_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

numSigs

uint32_t

Number of satellite signals in the following satelliate signal list

sig

gps_sig_sv_t[100]Satellite signal list

DID_GPS1_TIMEPULSE

gps_timepulse_t

Field

Type

Description

DID_GPS2_SIG

GPS 2 GNSS signal information.
gps_sig_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

numSigs

uint32_t

Number of satellite signals in the following satelliate signal list

sig

gps_sig_sv_t[100]Satellite signal list

DID_GPX_BIT

GPX BIT test
GPX_bit_t

Field

Type

Description

results

uint32_t

Calibration BIT status (see eCalBitStatusFlags)commanduint8_t

Commandport

uint8_t

Built-in self-test state

DID_GPX_DEBUG_ARRAYGPX debug- 144/348 -©2022

7.2.1 Data Sets (DIDs)

debug_array_t

Field

Type

Description

DID_GPX_DEV_INFO

GPX device information
dev_info_t

Field

Type

Description

reserved

uint16_t

Reserved bits

hardwareuint16_t

Hardware: 1=uINS, 2=EVB, 3=IMX, 4=GPX (see eDevInfoHardware)

serialNumber

uint32_t

Serial number

hardwareVer

uint8_t[4]Hardware version

firmwareVer

uint8_t[4]Firmware (software) version

buildNumber

uint32_t

Build number

protocolVer

uint8_t[4]Communications protocol version

repoRevisionuint32_t

Repository revision number

manufacturer

char[24]

Manufacturer namebuildTypeuint8_t

Build type (Release: 'a'=ALPHA, 'b'=BETA, 'c'=RELEASE CANDIDATE,'r'=PRODUCTION RELEASE, 'd'=debug)buildYearuint8_t

Build date year - 2000

buildMonthuint8_t

Build date monthbuildDay

uint8_t

Build date day

buildHouruint8_t

Build time hourbuildMinuteuint8_t

Build time minutebuildSecond

uint8_t

Build time secondbuildMillisecond

uint8_t

Build time millisecond

addInfochar[24]

Additional info

firmwareMD5Hashuint32_t[4]Firmware MD5 hash

DID_GPX_FLASH_CFG

GPX flash configuration- 145/348 -©2022

7.2.1 Data Sets (DIDs)

gpx_flash_cfg_t

Field

Type

Description

size

uint32_t

Size of this struct

checksumuint32_t

Checksum, excluding size and checksum

key

uint32_t

Manufacturer method for restoring flash defaults

ser0BaudRate

uint32_t

Serial port 0 baud rate in bits per second

ser1BaudRate

uint32_t

Serial port 1 baud rate in bits per second

ser2BaudRate

uint32_t

Serial port 2 baud rate in bits per second

startupGPSDtMs

uint32_t

GPS measurement (system input data) update period in milliseconds set on
startup. 200ms minimum (5Hz max).

gps1AntOffset

float[3]

X,Y,Z offset in meters in Sensor Frame to GPS 1 antenna.

gps2AntOffset

float[3]

X,Y,Z offset in meters in Sensor Frame to GPS 2 antenna.

gnssSatSigConst

uint16_t

Satellite system constellation used in GNSS solution. (see eGnssSatSigConst)
0x0003=GPS, 0x000C=QZSS, 0x0030=Galileo, 0x00C0=Beidou,
0x0300=GLONASS, 0x1000=SBAS

dynamicModel

uint8_t

Dynamic platform model (see eDynamicModel). Options are: 0=PORTABLE,
2=STATIONARY, 3=PEDESTRIAN, 4=GROUND VEHICLE, 5=SEA,
6=AIRBORNE_1G, 7=AIRBORNE_2G, 8=AIRBORNE_4G, 9=WRIST. Used tobalance noise and performance characteristics of the system. The dynamics
selected here must be at least as fast as your system or you experience accuracy
error. This is tied to the GPS position estimation model and intend in the future to
be incorporated into the INS position model.

debug

uint8_t

Debug

gpsTimeSyncPeriodMs

uint32_t

Time between GPS time synchronization pulses in milliseconds. Requires reboot totake effect.

gpsTimeUserDelayfloat(sec) User defined delay for GPS time. This parameter can be used to account for
GPS antenna cable delay.

gpsMinimumElevation

float

Minimum elevation of a satellite above the horizon to be used in the solution(radians). Low elevation satellites may provide degraded accuracy, due to the longsignal path through the atmosphere.

RTKCfgBits

uint32_t

RTK configuration bits (see eRTKConfigBits).

DID_GPX_RMC

GPX rmc
rmc_t

Field

Type

Description

bits

uint64_t

Data stream enable bits for the specified ports. (see RMC_BITS_...)

options

uint32_t

Options to select alternate ports to output data, etc. (see RMC_OPTIONS_...)

DID_GPX_RTOS_INFOGPX RTOs info

- 146/348 -©2022

7.2.1 Data Sets (DIDs)

gpx_rtos_info_t

Field

Type

Description

freeHeapSize

uint32_t

Heap high water mark bytes

mallocSize

uint32_t

Total memory allocated using RTOS pvPortMalloc()

freeSizeuint32_t

Total memory freed using RTOS vPortFree()task

rtos_task_t[]

Tasks

DID_GPX_STATUS

GPX status
gpx_status_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t

Status (eGpxStatus)

grmcBitsSer0

uint64_t

GRMC BITS

grmcBitsSer1

uint64_t

Hardware status flags (eHdwStatusFlags)

grmcBitsSer2

uint64_t

MCU temperature (not available yet)grmcBitsUSB

uint64_t

Nav output period (ms).

grmcNMEABitsSer0

uint64_t

Flash config checksum used with host SDK synchronization

grmcNMEABitsSer1

uint64_t

RTK Mode bits (see eRTKConfigBits)

grmcNMEABitsSer2

uint64_t

GNSS status (see RunState)

DID_GROUND_VEHICLE

Static configuration for wheel transform measurements.
ground_vehicle_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

statusuint32_t

Ground vehicle status flags (eGroundVehicleStatus)

mode

uint32_t

Current mode of the ground vehicle. Use this field to apply commands. (seeeGroundVehicleMode)

wheelConfig

wheel_config_t

Wheel transform, track width, and wheel radius.

DID_IMU3_RAW

Triple IMU data calibrated from DID_IMU3_UNCAL. We recommend use of DID_IMU or DID_PIMU as they are oversampled andcontain less noise.

- 147/348 -©2022

7.2.1 Data Sets (DIDs)

imu3_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

statusuint32_t

IMU Status (eImuStatus)I

imus_t[3]Inertial Measurement Units (IMUs)

DID_IMU3_UNCAL

Uncalibrated triple IMU data. We recommend use of DID_IMU or DID_PIMU as they are calibrated and oversampled and containless noise. Minimum data period is DID_FLASH_CONFIG.startupImuDtMs or 4, whichever is larger (250Hz max).
imu3_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

statusuint32_t

IMU Status (eImuStatus)I

imus_t[3]Inertial Measurement Units (IMUs)

DID_IMU_MAG

DID_IMU + DID_MAGNETOMETER. Only one of DID_IMU_MAG or DID_PIMU_MAG should be streamed simultaneously.
imu_mag_t

Field

Type

Description

imu

imu_t

imu - raw or pre-integrated depending on data id

magmagnetometer_t

mag

DID_INFIELD_CAL

Measure and correct IMU calibration error. Estimate INS rotation to align INS with vehicle.
infield_cal_t

Field

Type

Description

state

uint32_t

Used to set and monitor the state of the infield calibration system. (seeeInfieldCalState)statusuint32_t

Infield calibration status. (see eInfieldCalStatus)

sampleTimeMs

uint32_t

Number of samples used in IMU average. sampleTimeMs = 0 means "imu"
member contains the IMU bias from flash.

imu

imus_t[3]Dual purpose variable. 1.) This is the averaged IMU sample whensampleTimeMs != 0. 2.) This is a mirror of the motion calibration IMU bias
from flash when sampleTimeMs = 0.

calDatainfield_cal_vaxis_t[3]Collected data used to solve for the bias error and INS rotation. Vertical axis:
0 = X, 1 = Y, 2 = Z

DID_INL2_MAG_OBS_INFO

INL2 magnetometer calibration information.

- 148/348 -©2022

7.2.1 Data Sets (DIDs)

inl2_mag_obs_info_t

Field

Type

Description

timeOfWeekMs

uint32_t

Timestamp in milliseconds

Ncal_samples

uint32_t

Number of calibration samples

readyuint32_t

Data ready to be processedcalibrated

uint32_t

Calibration data present. Set to -1 to force mag recalibration.

auto_recal

uint32_t

Allow mag to auto-recalibrate

outlieruint32_t

Bad sample data

magHdgfloat

Heading from magnetometer

insHdgfloat

Heading from INS

magInsHdgDelta

float

Difference between mag heading and (INS heading plus mag declination)

nis

float

Normalized innovation squared (likelihood metric)

nis_threshold

float

Threshold for maximum NIS

Wcal

float[9]Magnetometer calibration matrix. Must be initialized with a unit matrix, not zeros!

activeCalSet

uint32_t

Active calibration set (0 or 1)

magHdgOffset

float

Offset between magnetometer heading and estimate heading

Tcal

float

Scaled computed variance between calibrated magnetometer samples.

bias_calfloat[3]Calibrated magnetometer output can be produced using: Bcal = Wcal * (Braw bias_cal)

DID_INL2_NED_SIGMA

Standard deviation of INL2 EKF estimates in the NED frame.
inl2_ned_sigma_t

Field

Type

Description

timeOfWeekMs

unsigned

Timestamp in milliseconds

StdPosNed

float[3]NED position error sigma

StdVelNed

float[3]NED velocity error sigma

StdAttNed

float[3]NED attitude error sigma

StdAccBias

float[3]Acceleration bias error sigma

StdGyrBias

float[3]Angular rate bias error sigma

StdBarBias

float

Barometric altitude bias error sigma

StdMagDeclinationfloat

Mag declination error sigma

DID_INL2_STATESINS Extended Kalman Filter (EKF) states- 149/348 -©2022

7.2.1 Data Sets (DIDs)

inl2_states_t

Field

Type

Description

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

qe2b

float[4]Quaternion body rotation with respect to ECEF

vefloat[3](m/s) Velocity in ECEF frame

ecef

double[3](m) Position in ECEF frame

biasPqrfloat[3](rad/s) Gyro bias

biasAcc

float[3](m/s^2) Accelerometer bias

biasBaro

float(m) Barometer bias

magDecfloat(rad) Magnetic declination

magIncfloat(rad) Magnetic inclination

Type

Description

DID_INL2_STATUS

inl2_status_t

Field

DID_INTERNAL_DIAGNOSTIC

Internal diagnostic info
internal_diagnostic_t

Field

Type

Description

gapCountSerialDriveruint32_t[6]Count of gap of more than 0.5 seconds receiving serial data, driver level, one
entry for each com port

gapCountSerialParser

uint32_t[6]Count of gap of more than 0.5 seconds receiving serial data, class / parser
level, one entry for each com port

rxOverflowCountuint32_t[6]Count of rx overflow, one entry for each com port

txOverflowCountuint32_t[6]Count of tx overflow, one entry for each com port

checksumFailCountuint32_t[6]Count of checksum failures, one entry for each com port

DID_IO

I/O
io_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

gpioStatus

uint32_t

General purpose I/O status

DID_MANUFACTURING_INFOManufacturing info

- 150/348 -©2022

7.2.1 Data Sets (DIDs)

manufacturing_info_t

Field

Type

Description

serialNumber

uint32_t

Inertial Sense serial number

hardwareId

uint16_t

Hardware ID: This is a packed identifier, which includes the Hardware Type,hardwareVer Major, and hardwareVer Minor

lotNumberuint16_t

Inertial Sense lot number

datechar[16]

Inertial Sense manufacturing date (YYYYMMDDHHMMSS)

key

uint32_t

Key - write: unlock manufacturing info, read: number of times OTP has been set, 15
max

platformType

int32_t

Platform / carrier board (ePlatformConfig::PLATFORM_CFG_TYPE_MASK). Only valid ifgreater than zero.

reserved

int32_t

Microcontroller unique identifier, 128 bits for SAM / 96 for STM32

DID_PIMU_MAG

DID_PIMU + DID_MAGNETOMETER. Only one of DID_IMU_MAG or DID_PIMU_MAG should be streamed simultaneously.
pimu_mag_t

Field

Type

Description

pimu

pimu_tPreintegrated IMU

mag

magnetometer_t

Magnetometer

DID_PORT_MONITOR

Data rate and status monitoring for each communications port.
port_monitor_t

Field

Type

Description

port

port_monitor_set_t[6]Port monitor set

DID_POSITION_MEASUREMENT

External position estimate
pos_measurement_t

Field

Type

Description

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

ecef

double[3]Position in ECEF (earth-centered earth-fixed) frame in meters

psi

float

Heading with respect to NED frame (radDID_REFERENCE_IMU

Raw reference or truth IMU used for manufacturing calibration and testing. Input from testbed.

- 151/348 -©2022

7.2.1 Data Sets (DIDs)

imu_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

statusuint32_t

IMU Status (eImuStatus)I

imus_tInertial Measurement Unit (IMU)

DID_REFERENCE_MAGNETOMETER

Reference or truth magnetometer used for manufacturing calibration and testing
magnetometer_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding
gps.towOffset

mag

float[3]Magnetometers in Gauss

DID_REFERENCE_PIMU

Reference or truth IMU used for manufacturing calibration and testing
pimu_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding gps.towOffset

dt

float

Integral period in seconds for delta theta and delta velocity. This is configured using
DID_FLASH_CONFIG.startupNavDtMs.

statusuint32_t

IMU Status (eImuStatus)

theta

float[3]IMU delta theta (gyroscope {p,q,r} integral) in radians in sensor framevelfloat[3]IMU delta velocity (accelerometer {x,y,z} integral) in m/s in sensor frame

DID_ROS_COVARIANCE_POSE_TWISTINL2 EKF covariances matrix lower diagonals
ros_covariance_pose_twist_t

Field

Type

Description

timeOfWeek

doubleGPS time of week (since Sunday morning) in seconds

covPoseLD

float[21](rad^2, m^2) EKF attitude and position error covariance matrix lower diagonal in body
(attitude) and ECEF (position) frames

covTwistLD

float[21]((m/s)^2, (rad/s)^2) EKF velocity and angular rate error covariance matrix lower
diagonal in ECEF (velocity) and body (attitude) frames

DID_RTOS_INFORTOS information.

- 152/348 -©2022

7.2.1 Data Sets (DIDs)

rtos_info_t

Field

Type

Description

freeHeapSize

uint32_t

Heap high water mark bytes

mallocSize

uint32_t

Total memory allocated using RTOS pvPortMalloc()

freeSizeuint32_t

Total memory freed using RTOS vPortFree()task

rtos_task_t[]

Tasks

Type

Description

Type

Description

Type

Description

Type

Description

DID_RUNTIME_PROFILER

System runtime profiler
runtime_profiler_t

Field

DID_SCOMP

sensor_compensation_t

Field

DID_SENSORS_ADC

sys_sensors_adc_t

Field

DID_SENSORS_ADC_SIGMA

sys_sensors_adc_t

Field

DID_SENSORS_MCAL

Temperature compensated and motion calibrated IMU output.
sensors_w_temp_t

Field

Type

Description

imu3

imu3_t(°C) Temperature of IMU. Units only apply for calibrated data.

temp

f_t[3](uT) Magnetometers. Units only apply for calibrated data.

DID_SENSORS_TCAL

Temperature compensated IMU output.
sensors_w_temp_t

Field

Type

Description

imu3

imu3_t(°C) Temperature of IMU. Units only apply for calibrated data.

temp

f_t[3](uT) Magnetometers. Units only apply for calibrated data.

- 153/348 -©2022

7.2.1 Data Sets (DIDs)

DID_SENSORS_TC_BIAS

sensors_t

Field

Type

Description

time

doubleTime since boot up in seconds. Convert to GPS time of week by adding gps.towOffset

temp

float

Temperature in Celsius

pqr

float[3]Gyros in radians / secondacc

float[3]Accelerometers in meters / second squaredmagfloat[3]Magnetometers in Gauss

bar

float

Barometric pressure in kilopascals

barTempfloat

Temperature of barometric pressure sensor in Celsius

mslBarfloat

MSL altitude from barometric pressure sensor in metershumidity

float

Relative humidity as a percent (%rH). Range is 0% - 100%

vin

float

EVB system input voltage in volts. uINS pin 5 (G2/AN2). Use 10K/1K resistor divider
between Vin and GND.

ana1

float

ADC analog input in volts. uINS pin 4, (G1/AN1).

ana3

float

ADC analog input in volts. uINS pin 19 (G3/AN3).

ana4

float

ADC analog input in volts. uINS pin 20 (G4/AN4).

DID_SENSORS_UCAL

Uncalibrated IMU output.
sensors_w_temp_t

Field

Type

Description

imu3

imu3_t(°C) Temperature of IMU. Units only apply for calibrated data.

temp

f_t[3](uT) Magnetometers. Units only apply for calibrated data.

DID_STROBE_IN_TIME

Timestamp for input strobe.
strobe_in_time_t

Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

pin

uint16_t

Strobe input pin (i.e. G1, G2, G5, or G9)

count

uint16_t

Strobe serial index number

DID_SURVEY_IN

Survey in, used to determine position for RTK base station. Base correction output cannot run during a survey and will be
automatically disabled if a survey is started.

- 154/348 -©2022

7.2.1 Data Sets (DIDs)

survey_in_t

Field

Type

Description

state

uint32_t

State of current survey, eSurveyInStatus

maxDurationSec

uint32_t

Maximum time (milliseconds) survey will run if minAccuracy is not first achieved.
(ignored if 0).

minAccuracy

float

Required horizontal accuracy (m) for survey to complete before maxDuration.
(ignored if 0)

elapsedTimeSec

uint32_t

Elapsed time (seconds) of the survey.

hAccuracy

float

Approximate horizontal accuracy of the survey (m).

lladouble[3]The current surveyed latitude, longitude, altitude (deg, deg, m)

Field

Type

Description

statusuint32_t

System fault status

g1Taskuint32_t

Fault Type at HardFault

g2FileNum

uint32_t

Multipurpose register - Line number of fault

g3LineNum

uint32_t

Multipurpose register - File number at fault

g4

uint32_t

Multipurpose register - at time of fault.

g5Lr

uint32_t

Multipurpose register - link register value at time of fault.

pc

uint32_t

Program Counter value at time of fault

psr

uint32_t

Program Status Register value at time of fault

DID_SYS_FAULT

System fault information
system_fault_t

DID_SYS_PARAMS

System parameters / info

- 155/348 -©2022

7.2.2 Enumerations and Defines

sys_params_t

Field

Type

Description

timeOfWeekMs

uint32_t

GPS time of week (since Sunday morning) in milliseconds

insStatus

uint32_t

INS status flags (eInsStatusFlags)

hdwStatus

uint32_t

Hardware status flags (eHdwStatusFlags)

imuTempfloat

IMU temperaturebaroTemp

float

Baro temperature

mcuTempfloat

MCU temperature (not available yet)sysStatus

uint32_t

System status flags (eSysStatusFlags)

imuSamplePeriodMs

uint32_t

IMU sample period (ms). Zero disables sampling.

navOutputPeriodMs

uint32_t

Preintegrated IMU (PIMU) integration period and navigation/AHRS filter
output period (ms).

sensorTruePeriod

doubleActual sample period relative to GPS PPS (sec)flashCfgChecksum

uint32_t

Flash config checksum used with host SDK synchronization

navUpdatePeriodMs

uint32_t

Navigation/AHRS filter update period (ms)genFaultCode

uint32_t

General fault code descriptor (eGenFaultCodes). Set to zero to reset fault code.

DID_WHEEL_ENCODER

Wheel encoder data to be fused with GPS-INS measurements, set DID_GROUND_VEHICLE for configuration before sending thismessagewheel_encoder_t

Field

Type

Description

timeOfWeek

doubleTime of measurement wrt current weekstatusuint32_t

Status Word

theta_l

float

Left wheel angle (rad)theta_r

float

Right wheel angle (rad)omega_l

float

Left wheel angular rate (rad/s)

omega_r

float

Right wheel angular rate (rad/s)

wrap_count_l

uint32_t

Left wheel revolution countwrap_count_r

uint32_t

Right wheel revolution count

7.2.2 Enumerations and Defines
System status and configuration is made available through various enumeration and #defines.

- 156/348 -©2022

7.2.2 Enumerations and Defines

General
DID_EVB_FLASH_CFG.CBPRESET(eEvb2ComBridgePreset)
Field

Value

EVB2_CB_PRESET_NA

0

EVB2_CB_PRESET_ALL_OFF

1

EVB2_CB_PRESET_RS232

2

EVB2_CB_PRESET_RS232_XBEE

3

EVB2_CB_PRESET_RS422_WIFI

4

EVB2_CB_PRESET_SPI_RS232

5

EVB2_CB_PRESET_USB_HUB_RS232

6

EVB2_CB_PRESET_USB_HUB_RS422

7

EVB2_CB_PRESET_COUNT8

DID_EVB_FLASH_CFG.PORTOPTIONS(eEvb2PortOptions)
Field

Value

EVB2_PORT_OPTIONS_RADIO_RTK_FILTER

0x00000001

EVB2_PORT_OPTIONS_DEFAULT

EVB2_PORT_OPTIONS_RADIO_RTK_FILTERDID_EVB_STATUS.LOGGERMODE(eEvb2LoggerMode)
Field

Value

EVB2_LOG_NA

0

EVB2_LOG_CMD_START2

EVB2_LOG_CMD_STOP

4

EVB2_LOG_CMD_PURGE

1002- 157/348 -©2022

7.2.2 Enumerations and Defines

DID_FLASH_CONFIG.GNSSSATSIGCONST(eGnssSatSigConst)
Field

Value

GNSS_SAT_SIG_CONST_GPS

0x0003

GNSS_SAT_SIG_CONST_QZS

0x000C

GNSS_SAT_SIG_CONST_GAL

0x0030

GNSS_SAT_SIG_CONST_BDS

0x00C0

GNSS_SAT_SIG_CONST_GLO

0x0300

GNSS_SAT_SIG_CONST_SBS

0x1000

GNSS_SAT_SIG_CONST_IRN

0x2000

GNSS_SAT_SIG_CONST_IME

0x4000- 158/348 -©2022

7.2.2 Enumerations and Defines

DID_FLASH_CONFIG.SENSORCONFIG(eSensorConfig)- 159/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

SENSOR_CFG_GYR_FS_250

0x00000000

SENSOR_CFG_GYR_FS_500

0x00000001

SENSOR_CFG_GYR_FS_1000

0x00000002

SENSOR_CFG_GYR_FS_2000

0x00000003

SENSOR_CFG_GYR_FS_4000

0x00000004

SENSOR_CFG_GYR_FS_MASK

0x00000007

SENSOR_CFG_GYR_FS_OFFSET(int)0SENSOR_CFG_ACC_FS_2G

0x00000000

SENSOR_CFG_ACC_FS_4G

0x00000001

SENSOR_CFG_ACC_FS_8G

0x00000002

SENSOR_CFG_ACC_FS_16G

0x00000003

SENSOR_CFG_ACC_FS_MASK

0x00000030

SENSOR_CFG_ACC_FS_OFFSET(int)4SENSOR_CFG_GYR_DLPF_250HZ

0x00000000

SENSOR_CFG_GYR_DLPF_184HZ

0x00000001

SENSOR_CFG_GYR_DLPF_92HZ0x00000002

SENSOR_CFG_GYR_DLPF_41HZ0x00000003

SENSOR_CFG_GYR_DLPF_20HZ0x00000004

SENSOR_CFG_GYR_DLPF_10HZ0x00000005

SENSOR_CFG_GYR_DLPF_5HZ

0x00000006

SENSOR_CFG_GYR_DLPF_MASK

0x00000F00

SENSOR_CFG_GYR_DLPF_OFFSET(int)8SENSOR_CFG_ACC_DLPF_218HZ

0x00000000

SENSOR_CFG_ACC_DLPF_218HZb

0x00000001

SENSOR_CFG_ACC_DLPF_99HZ0x00000002

SENSOR_CFG_ACC_DLPF_45HZ0x00000003

SENSOR_CFG_ACC_DLPF_21HZ0x00000004

SENSOR_CFG_ACC_DLPF_10HZ0x00000005

SENSOR_CFG_ACC_DLPF_5HZ

0x00000006

SENSOR_CFG_ACC_DLPF_MASK

0x0000F000

SENSOR_CFG_ACC_DLPF_OFFSET(int)12SENSOR_CFG_SENSOR_ROTATION_MASK

0x00FF0000

SENSOR_CFG_SENSOR_ROTATION_OFFSET(int)16

SENSOR_CFG_SENSOR_ROTATION_0_0_0(int)0SENSOR_CFG_SENSOR_ROTATION_0_0_90(int)1- 160/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

SENSOR_CFG_SENSOR_ROTATION_0_0_180(int)2SENSOR_CFG_SENSOR_ROTATION_0_0_N90(int)3SENSOR_CFG_SENSOR_ROTATION_90_0_0(int)4SENSOR_CFG_SENSOR_ROTATION_90_0_90(int)5SENSOR_CFG_SENSOR_ROTATION_90_0_180(int)6SENSOR_CFG_SENSOR_ROTATION_90_0_N90(int)7SENSOR_CFG_SENSOR_ROTATION_180_0_0(int)8SENSOR_CFG_SENSOR_ROTATION_180_0_90(int)9SENSOR_CFG_SENSOR_ROTATION_180_0_180(int)10SENSOR_CFG_SENSOR_ROTATION_180_0_N90(int)11

SENSOR_CFG_SENSOR_ROTATION_N90_0_0(int)12SENSOR_CFG_SENSOR_ROTATION_N90_0_90(int)13SENSOR_CFG_SENSOR_ROTATION_N90_0_180(int)14SENSOR_CFG_SENSOR_ROTATION_N90_0_N90(int)15

SENSOR_CFG_SENSOR_ROTATION_0_90_0(int)16

SENSOR_CFG_SENSOR_ROTATION_0_90_90(int)17

SENSOR_CFG_SENSOR_ROTATION_0_90_180(int)18

SENSOR_CFG_SENSOR_ROTATION_0_90_N90(int)19

SENSOR_CFG_SENSOR_ROTATION_0_N90_0(int)20

SENSOR_CFG_SENSOR_ROTATION_0_N90_90(int)21

SENSOR_CFG_SENSOR_ROTATION_0_N90_180(int)22

SENSOR_CFG_SENSOR_ROTATION_0_N90_N90(int)23

SENSOR_CFG_IMU_FAULT_DETECT_MASK

0x0F000000

SENSOR_CFG_IMU_FAULT_DETECT_OFFSET(int)24

SENSOR_CFG_IMU_FAULT_DETECT_NONE(int)0SENSOR_CFG_IMU_FAULT_DETECT_OFFLINE(int)1SENSOR_CFG_IMU_FAULT_DETECT_LARGE_BIAS(int)2SENSOR_CFG_IMU_FAULT_DETECT_BIAS_JUMPS(int)3SENSOR_CFG_IMU_FAULT_DETECT_SENSOR_NOISE(int)4- 161/348 -©2022

7.2.2 Enumerations and Defines

DID_SYS_CMD.COMMAND(eSystemCommand)- 162/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

SYS_CMD_NONE

0

SYS_CMD_SAVE_PERSISTENT_MESSAGES

1

SYS_CMD_ENABLE_BOOTLOADER_AND_RESET

2

SYS_CMD_ENABLE_SENSOR_STATS

3

SYS_CMD_ENABLE_RTOS_STATS

4

SYS_CMD_ZERO_MOTION

5

SYS_CMD_REF_POINT_STATIONARY

6

SYS_CMD_REF_POINT_MOVING

7

SYS_CMD_RESET_RTOS_STATS

8SYS_CMD_ENABLE_GPS_LOW_LEVEL_CONFIG

10

SYS_CMD_DISABLE_SERIAL_PORT_BRIDGE

11

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_GPS1

12

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_GPS2

13

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_SER0

14

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_SER1

15

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_SER2

16

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_SER0_TO_GPS1

17

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_GPS1

18

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_GPS2

19

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_USB

20

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_SER0

21

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_SER1

22

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_TO_SER2

23

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_LOOPBACK24

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_SER0_LOOPBACK25

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_SER1_LOOPBACK26

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_SER2_LOOPBACK27

SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_CUR_PORT_LOOPBACK28

SYS_CMD_GPX_ENABLE_BOOTLOADER_MODE

30

SYS_CMD_GPX_ENABLE_GNSS1_CHIPSET_BOOTLOADER

31

SYS_CMD_GPX_ENABLE_GNSS2_CHIPSET_BOOTLOADER32

SYS_CMD_GPX_ENABLE_GNSS1_PASS_THROUGH

33

SYS_CMD_GPX_ENABLE_GNSS2_PASS_THROUGH

34

SYS_CMD_GPX_ENABLE_SERIAL_BRIDGE_CUR_PORT_LOOPBACK35

SYS_CMD_TEST_GPIO

64- 163/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

SYS_CMD_SAVE_FLASH97

SYS_CMD_SAVE_GPS_ASSIST_TO_FLASH_RESET98

SYS_CMD_SOFTWARE_RESET99

SYS_CMD_MANF_UNLOCK

1122334455

SYS_CMD_MANF_FACTORY_RESET

1357924680

SYS_CMD_MANF_CHIP_ERASE

1357924681

SYS_CMD_MANF_DOWNGRADE_CALIBRATION

1357924682

SYS_CMD_MANF_ENABLE_ROM_BOOTLOADER

1357924683

DID_SYS_PARAMS.GENFAULTCODE(eGenFaultCodes)
Field

Value

GFC_INS_STATE_ORUN_UVW

0x00000001

GFC_INS_STATE_ORUN_LAT

0x00000002

GFC_INS_STATE_ORUN_ALT

0x00000004

GFC_UNHANDLED_INTERRUPT

0x00000010

GFC_INIT_SENSORS

0x00000100

GFC_INIT_SPI

0x00000200

GFC_CONFIG_SPI

0x00000400

GFC_INIT_GPS1

0x00000800

GFC_INIT_GPS2

0x00001000

GFC_FLASH_INVALID_VALUES

0x00002000

GFC_FLASH_CHECKSUM_FAILURE

0x00004000

GFC_FLASH_WRITE_FAILURE

0x00008000

GFC_SYS_FAULT_GENERAL

0x00010000

GFC_SYS_FAULT_CRITICAL

0x00020000

GFC_SENSOR_SATURATION

0x00040000

GFC_INIT_IMU

0x00100000

GFC_INIT_MAGNETOMETER

0x00400000

GFC_INIT_BAROMETER

0x00200000

GFC_INIT_I2C

0x00800000

GFC_CHIP_ERASE_INVALID

0x01000000- 164/348 -©2022

7.2.2 Enumerations and Defines

GPS NAVIGATION FIX TYPE

(eGpsNavFixStatus)
Field

Value

GPS_NAV_FIX_NONE

0x00000000

GPS_NAV_FIX_POSITIONING_3D

0x00000001

GPS_NAV_FIX_POSITIONING_RTK_FLOAT

0x00000002

GPS_NAV_FIX_POSITIONING_RTK_FIX

0x00000003- 165/348 -©2022

7.2.2 Enumerations and Defines

GPS STATUS(eGpsStatus)- 166/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

GPS_STATUS_NUM_SATS_USED_MASK

0x000000FF

GPS_STATUS_FIX_NONE

0x00000000

GPS_STATUS_FIX_DEAD_RECKONING_ONLY

0x00000100

GPS_STATUS_FIX_2D

0x00000200

GPS_STATUS_FIX_3D

0x00000300

GPS_STATUS_FIX_GPS_PLUS_DEAD_RECK

0x00000400

GPS_STATUS_FIX_TIME_ONLY

0x00000500

GPS_STATUS_FIX_UNUSED1

0x00000600

GPS_STATUS_FIX_UNUSED2

0x00000700

GPS_STATUS_FIX_DGPS

0x00000800

GPS_STATUS_FIX_SBAS

0x00000900

GPS_STATUS_FIX_RTK_SINGLE

0x00000A00

GPS_STATUS_FIX_RTK_FLOAT

0x00000B00

GPS_STATUS_FIX_RTK_FIX

0x00000C00

GPS_STATUS_FIX_MASK

0x00001F00

GPS_STATUS_FIX_BIT_OFFSET(int)8

GPS_STATUS_FLAGS_FIX_OK

0x00010000

GPS_STATUS_FLAGS_DGPS_USED

0x00020000

GPS_STATUS_FLAGS_RTK_FIX_AND_HOLD

0x00040000

GPS_STATUS_FLAGS_WEEK_VALID

0x00040000

GPS_STATUS_FLAGS_TOW_VALID

0x00080000

GPS_STATUS_FLAGS_GPS1_RTK_POSITION_ENABLED

0x00100000

GPS_STATUS_FLAGS_STATIC_MODE

0x00200000

GPS_STATUS_FLAGS_GPS2_RTK_COMPASS_ENABLED

0x00400000

GPS_STATUS_FLAGS_GPS1_RTK_RAW_GPS_DATA_ERROR

0x00800000

GPS_STATUS_FLAGS_GPS1_RTK_BASE_DATA_MISSING

0x01000000

GPS_STATUS_FLAGS_GPS1_RTK_BASE_POSITION_MOVING

0x02000000

GPS_STATUS_FLAGS_GPS1_RTK_BASE_POSITION_INVALID

0x03000000

GPS_STATUS_FLAGS_GPS1_RTK_BASE_POSITION_MASK

0x03000000

GPS_STATUS_FLAGS_GPS1_RTK_POSITION_VALID

0x04000000

GPS_STATUS_FLAGS_GPS2_RTK_COMPASS_VALID

0x08000000

GPS_STATUS_FLAGS_GPS2_RTK_COMPASS_BASELINE_BAD

0x00002000

GPS_STATUS_FLAGS_GPS_NMEA_DATA

0x00008000

GPS_STATUS_FLAGS_GPS_PPS_TIMESYNC

0x10000000

GPS_STATUS_FLAGS_MASK

0xFFFFE000- 167/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

GPS_STATUS_FLAGS_BIT_OFFSET(int)16- 168/348 -©2022

7.2.2 Enumerations and Defines

HARDWARE STATUS FLAGS(eHdwStatusFlags)- 169/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

HDW_STATUS_MOTION_GYR_SIG

0x00000001

HDW_STATUS_MOTION_ACC_SIG

0x00000002

HDW_STATUS_MOTION_SIG_MASK

0x00000003

HDW_STATUS_MOTION_GYR_DEV

0x00000004

HDW_STATUS_MOTION_ACC_DEV

0x00000008

HDW_STATUS_MOTION_MASK

0x0000000F

HDW_STATUS_GPS_SATELLITE_RX

0x00000010

HDW_STATUS_STROBE_IN_EVENT

0x00000020

HDW_STATUS_GPS_TIME_OF_WEEK_VALID

0x00000040

HDW_STATUS_REFERENCE_IMU_RX

0x00000080

HDW_STATUS_SATURATION_GYR

0x00000100

HDW_STATUS_SATURATION_ACC

0x00000200

HDW_STATUS_SATURATION_MAG

0x00000400

HDW_STATUS_SATURATION_BARO

0x00000800

HDW_STATUS_SATURATION_MASK

0x00000F00

HDW_STATUS_SATURATION_OFFSET

8HDW_STATUS_SYSTEM_RESET_REQUIRED

0x00001000

HDW_STATUS_EKF_USING_REFERENCE_IMU

0x00002000

HDW_STATUS_MAG_RECAL_COMPLETE

0x00004000

HDW_STATUS_FLASH_WRITE_PENDING

0x00008000

HDW_STATUS_ERR_COM_TX_LIMITED

0x00010000

HDW_STATUS_ERR_COM_RX_OVERRUN

0x00020000

HDW_STATUS_ERR_NO_GPS_PPS

0x00040000

HDW_STATUS_GPS_PPS_TIMESYNC

0x00080000

HDW_STATUS_COM_PARSE_ERR_COUNT_MASK

0x00F00000

HDW_STATUS_COM_PARSE_ERR_COUNT_OFFSET

20

HDW_STATUS_BIT_RUNNING

0x01000000

HDW_STATUS_BIT_PASSED

0x02000000

HDW_STATUS_BIT_FAULT

0x03000000

HDW_STATUS_BIT_MASK

0x03000000

HDW_STATUS_ERR_TEMPERATURE

0x04000000

HDW_STATUS_SPI_INTERFACE_ENABLED

0x08000000

HDW_STATUS_FAULT_RESET_MASK

0x70000000

HDW_STATUS_FAULT_RESET_BACKUP_MODE

0x10000000

HDW_STATUS_FAULT_RESET_WATCHDOG

0x20000000- 170/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

HDW_STATUS_FAULT_RESET_SOFT

0x30000000

HDW_STATUS_FAULT_RESET_HDW

0x40000000

HDW_STATUS_FAULT_SYS_CRITICAL

0x80000000

IMU STATUS(eImuStatus)
Field

Value

IMU_STATUS_SATURATION_IMU1_GYR

0x00000001

IMU_STATUS_SATURATION_IMU2_GYR

0x00000002

IMU_STATUS_SATURATION_IMU3_GYR

0x00000004

IMU_STATUS_SATURATION_IMU1_ACC

0x00000008

IMU_STATUS_SATURATION_IMU2_ACC

0x00000010

IMU_STATUS_SATURATION_IMU3_ACC

0x00000020

IMU_STATUS_SATURATION_MASK

0x0000003F

IMU_STATUS_MAG_UPDATE

0x00000100

IMU_STATUS_RESERVED2

0x00000400

IMU_STATUS_SATURATION_HISTORY

0x00000100

IMU_STATUS_SAMPLE_RATE_FAULT_HISTORY

0x00000200

IMU_STATUS_GYR1_OK

0x00010000

IMU_STATUS_GYR2_OK

0x00020000

IMU_STATUS_GYR3_OK

0x00040000

IMU_STATUS_ACC1_OK

0x00080000

IMU_STATUS_ACC2_OK

0x00100000

IMU_STATUS_ACC3_OK

0x00200000

IMU_STATUS_IMU1_OK(int)(IMU_STATUS_GYR1_OK|IMU_STATUS_ACC1_OK)

IMU_STATUS_IMU2_OK(int)(IMU_STATUS_GYR2_OK|IMU_STATUS_ACC2_OK)

IMU_STATUS_IMU3_OK(int)(IMU_STATUS_GYR3_OK|IMU_STATUS_ACC3_OK)

IMU_STATUS_IMU_OK_MASK

0x003F0000- 171/348 -©2022

7.2.2 Enumerations and Defines

INS STATUS FLAGS(eInsStatusFlags)- 172/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

INS_STATUS_HDG_ALIGN_COARSE

0x00000001

INS_STATUS_VEL_ALIGN_COARSE

0x00000002

INS_STATUS_POS_ALIGN_COARSE

0x00000004

INS_STATUS_ALIGN_COARSE_MASK

0x00000007

INS_STATUS_WHEEL_AIDING_VEL

0x00000008

INS_STATUS_HDG_ALIGN_FINE

0x00000010

INS_STATUS_VEL_ALIGN_FINE

0x00000020

INS_STATUS_POS_ALIGN_FINE

0x00000040

INS_STATUS_ALIGN_FINE_MASK

0x00000070

INS_STATUS_GPS_AIDING_HEADING

0x00000080

INS_STATUS_GPS_AIDING_POS

0x00000100

INS_STATUS_GPS_UPDATE_IN_SOLUTION

0x00000200

INS_STATUS_MAG_ACTIVE_CAL_SET

0x00000400

INS_STATUS_MAG_AIDING_HEADING

0x00000800

INS_STATUS_NAV_MODE

0x00001000

INS_STATUS_STATIONARY_MODE

0x00002000

INS_STATUS_GPS_AIDING_VEL

0x00004000

INS_STATUS_KINEMATIC_CAL_GOOD

0x00008000

INS_STATUS_SOLUTION_MASK

0x000F0000

INS_STATUS_SOLUTION_OFFSET

16

INS_STATUS_SOLUTION_OFF

0

INS_STATUS_SOLUTION_ALIGNING

1

INS_STATUS_SOLUTION_NAV

3

INS_STATUS_SOLUTION_NAV_HIGH_VARIANCE

4

INS_STATUS_SOLUTION_AHRS

5

INS_STATUS_SOLUTION_AHRS_HIGH_VARIANCE

6

INS_STATUS_SOLUTION_VRS

7

INS_STATUS_SOLUTION_VRS_HIGH_VARIANCE

8

INS_STATUS_RTK_COMPASSING_BASELINE_UNSET

0x00100000

INS_STATUS_RTK_COMPASSING_BASELINE_BAD

0x00200000

INS_STATUS_RTK_COMPASSING_MASK(INS_STATUS_RTK_COMPASSING_BASELINE_UNSET|
INS_STATUS_RTK_COMPASSING_BASELINE_BAD)

INS_STATUS_MAG_RECALIBRATING

0x00400000

INS_STATUS_MAG_INTERFERENCE_OR_BAD_CAL

0x00800000

INS_STATUS_GPS_NAV_FIX_MASK

0x03000000

INS_STATUS_GPS_NAV_FIX_OFFSET

24- 173/348 -©2022

7.2.2 Enumerations and Defines

Field

Value

INS_STATUS_RTK_COMPASSING_VALID

0x04000000

INS_STATUS_RTK_RAW_GPS_DATA_ERROR

0x08000000

INS_STATUS_RTK_ERR_BASE_DATA_MISSING

0x10000000

INS_STATUS_RTK_ERR_BASE_POSITION_MOVING

0x20000000

INS_STATUS_RTK_ERR_BASE_POSITION_INVALID

0x30000000

INS_STATUS_RTK_ERR_BASE_MASK

0x30000000

INS_STATUS_RTK_ERROR_MASK(INS_STATUS_RTK_RAW_GPS_DATA_ERROR|
INS_STATUS_RTK_ERR_BASE_MASK)

INS_STATUS_RTOS_TASK_PERIOD_OVERRUN

0x40000000

INS_STATUS_GENERAL_FAULT

0x80000000

MAGNETOMETER RECALIBRATION MODE(eMagCalState)
Field

Value

MAG_CAL_STATE_DO_NOTHING(int)0

MAG_CAL_STATE_MULTI_AXIS(int)1

MAG_CAL_STATE_SINGLE_AXIS(int)2

MAG_CAL_STATE_ABORT(int)101

MAG_CAL_STATE_RECAL_RUNNING(int)200

MAG_CAL_STATE_RECAL_COMPLETE(int)201- 174/348 -©2022

7.2.2 Enumerations and Defines

RTK CONFIGURATION(eRTKConfigBits)
Field

Value

RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING

0x00000001

RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING_EXTERNAL

0x00000002

RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING_F9P

0x00000004

RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING

0x00000008

RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING_MASK(RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING|
RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING_EXTERNAL)

RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING_MASK(RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING|
RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING_F9P)

RTK_CFG_BITS_ROVER_MODE_MASK

0x0000000F

RTK_CFG_BITS_BASE_OUTPUT_GPS1_UBLOX_SER0

0x00000010

RTK_CFG_BITS_BASE_OUTPUT_GPS1_UBLOX_SER1

0x00000020

RTK_CFG_BITS_BASE_OUTPUT_GPS1_UBLOX_SER2

0x00000040

RTK_CFG_BITS_BASE_OUTPUT_GPS1_UBLOX_USB

0x00000080

RTK_CFG_BITS_BASE_OUTPUT_GPS1_RTCM3_SER0

0x00000100

RTK_CFG_BITS_BASE_OUTPUT_GPS1_RTCM3_SER1

0x00000200

RTK_CFG_BITS_BASE_OUTPUT_GPS1_RTCM3_SER2

0x00000400

RTK_CFG_BITS_BASE_OUTPUT_GPS1_RTCM3_USB

0x00000800

RTK_CFG_BITS_BASE_OUTPUT_GPS2_UBLOX_SER0

0x00001000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_UBLOX_SER1

0x00002000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_UBLOX_SER2

0x00004000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_UBLOX_USB

0x00008000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_RTCM3_SER0

0x00010000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_RTCM3_SER1

0x00020000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_RTCM3_SER2

0x00040000

RTK_CFG_BITS_BASE_OUTPUT_GPS2_RTCM3_USB

0x00080000

RTK_CFG_BITS_BASE_POS_MOVING

0x00100000

RTK_CFG_BITS_RESERVED1

0x00200000

RTK_CFG_BITS_RTK_BASE_IS_IDENTICAL_TO_ROVER

0x00400000

RTK_CFG_BITS_GPS_PORT_PASS_THROUGH

0x00800000

RTK_CFG_BITS_ROVER_MODE_ONBOARD_MASK(RTK_CFG_BITS_ROVER_MODE_RTK_POSITIONING|
RTK_CFG_BITS_ROVER_MODE_RTK_COMPASSING)

RTK_CFG_BITS_ALL_MODES_MASK(RTK_CFG_BITS_ROVER_MODE_MASK|RTK_CFG_BITS_BASE_MODE)- 175/348 -©2022

7.2.2 Enumerations and Defines

SYSTEM CONFIGURATION(eSysConfigBits)
Field

Value

UNUSED1

0x00000001

SYS_CFG_BITS_ENABLE_MAG_CONTINUOUS_CAL

0x00000002

SYS_CFG_BITS_AUTO_MAG_RECAL

0x00000004

SYS_CFG_BITS_DISABLE_MAG_DECL_ESTIMATION

0x00000008

SYS_CFG_BITS_DISABLE_LEDS

0x00000010

Magnetometer

multi-axis

SYS_CFG_BITS_MAG_RECAL_MODE_MASK

0x00000700

SYS_CFG_BITS_MAG_RECAL_MODE_OFFSET

8

SYS_CFG_BITS_MAG_ENABLE_WMM_DECLINATION

0x00000800

SYS_CFG_BITS_DISABLE_MAGNETOMETER_FUSION

0x00001000

SYS_CFG_BITS_DISABLE_BAROMETER_FUSION

0x00002000

SYS_CFG_BITS_DISABLE_GPS1_FUSION

0x00004000

SYS_CFG_BITS_DISABLE_GPS2_FUSION

0x00008000

SYS_CFG_BITS_DISABLE_AUTO_ZERO_VELOCITY_UPDATES

0x00010000

SYS_CFG_BITS_DISABLE_AUTO_ZERO_ANGULAR_RATE_UPDATES

0x00020000

SYS_CFG_BITS_DISABLE_INS_EKF

0x00040000

SYS_CFG_BITS_DISABLE_AUTO_BIT_ON_STARTUP

0x00080000

SYS_CFG_BITS_DISABLE_WHEEL_ENCODER_FUSION

0x00100000

SYS_CFG_BITS_UNUSED30x00200000

SYS_CFG_BITS_UNUSED40x00400000

SYS_CFG_BITS_UNUSED50x00800000

SYS_CFG_USE_REFERENCE_IMU_IN_EKF

0x01000000

SYS_CFG_EKF_REF_POINT_STATIONARY_ON_STROBE_INPUT

0x02000000- 176/348 -©2022

7.3 Inertial Sense Binary (ISB) Protocol

7.3 Inertial Sense Binary (ISB) Protocol
The Inertial Sense binary protocol provides the most efficient way to communicate with the µINS, µAHRS, and µIMU because it
preserved the native floating point and integer binary format used in computers. Binary protocol is not human readable like
NMEA Protocol. Binary protocol uses Data Set (DID) C structures defined in SDK/src/data_sets.h of the InertialSense SDK.

7.3.1 Communication
Writing to and reading from InertialSense products is done using "Set" and "Get" commands. The following helper function
portWrite() which assists with writing data to the serial port is used throughout this document.
static int portWrite(int port, const unsigned char* buf, int len){return serialPortWrite(&serialPort, buf, len);}

Setting Data
The is_comm_set_data() function will encode a message used to set data or configurations.
// Set INS output Euler rotation in radians to 90 degrees roll for mounting
void setInsOutputRotation(){
float rotation[3] = { 90.0f*C_DEG2RAD_F, 0.0f, 0.0f };int messageSize = is_comm_set_data(portWrite, 0, comm, DID_FLASH_CONFIG, sizeof(float) * 3, offsetof(nvm_flash_cfg_t, insRotation), rotation);}

Getting Data
Data broadcasting or streaming is enabled by using the Realtime Message Controller (RMC) or the get data command.
GET DATA COMMAND

The is_comm_get_data() function will encode a PKT_TYPE_GET_DATA message that enables broadcast of a given message at a
multiple of the Data Source Update Rates. Set the data rate (period multiple) to zero disable message broadcast and pull a single
packet of data. Set the data size and offset to zero to request the entire data set.
// Ask for INS message w/ update 40ms period (4ms source period x 10).
is_comm_get_data(portWrite, 0, comm, DID_INS_1, 0, 0, 10);

Set data rate to zero to disable broadcast and pull a single packet.

DATA SOURCE UPDATE RATESDIDUpdate Rate (Period)

DID_INS_[1-4](4ms default) Configured with DID_FLASH_CONFIG.startupNavDtMs

DID_IMU,(4ms default) Configured with DID_FLASH_CONFIG.startupImuDtMs

DID_PIMU*DID_BAROMETER~8ms

DID_MAGNETOMETER_[1-2]~10ms

DID_GPS[1-2]_[X](200ms default) Configured with DID_FLASH_CONFIG. startupGPSDtMs(Any DID beginning with DID_GPS)
All other DIDs

1ms

*DID_PIMU integration period (dt) and output data rate are the same as DID_FLASH_CONFIG.startupNavDtMs and cannot be output at
any other rate. If a different output data rate is desired, DID_IMU which is derived from DID_PIMU can be used instead.

- 177/348 -©2022

7.3.1 Communication

REALTIME MESSAGE CONTROLLER (RMC)

The RMC is used to enable message broadcasting and provides updates from onboard data as soon as it becomes available withminimal latency. All RMC messages can be enabled using the Get Data Command, which is the preferred method, or by directly
setting the RMC bits. The RMC bits are listed below. Message data rates are listed in the Data Source Update Rates table.
RMC Message
RMC_BITS_INS[1-4]
RMC_BITS_DUAL_IMU, RMC_BITS_PIMU
RMC_BITS_BAROMETER
RMC_BITS_MAGNETOMETER[1-2]
RMC_BITS_GPS[1-2]_NAV
RMC_BITS_GPS_RTK_NAV, RMC_BITS_GPS_RTK_MISC
RMC_BITS_STROBE_IN_TIME

The following is an example of how to use the RMC. The rmc.options field controls whether RMC commands are applied to otherserial ports. rmc.options = 0 will apply the command to the current serial port.
rmc_t rmc;// Enable broadcasts of DID_INS_1 and DID_GPS_NAV
rmc.bits = RMC_BITS_INS1 | RMC_BITS_GPS1_POS;// Remember configuration following reboot for automatic data streaming.
rmc.options = RMC_OPTIONS_PERSISTENT;
is_comm_set_data(portWrite, 0, comm, DID_RMC, 0, 0, &rmc);

The update rate of the EKF is set by DID_FLASH_CONFIG.startupNavDtMs (reboot is required to apply the change).
Independently, the DID_INS_x broadcast period multiple can be used to set the output data rate down to 1ms.
PERSISTENT MESSAGESThe persistent messages option saves the current data stream configuration to flash memory for use following reboot,eliminating the need to re-enable messages following a reset or power cycle.
• To save persistent messages - (to flash memory), bitwise OR RMC_OPTIONS_PERSISTENT (0x200) with the RMC option field or set
DID_CONFIG.system = 0x00000001 and DID_CONFIG.system = 0xFFFFFFFE. See the save persistent messages example in
the Binary Communications example project.
• To disable persistent messages - a stop all broadcasts packet followed by a save persistent messages command.
NMEA persistent messages are also available.
Enabling Persistent Messages - EvalTool• Enable the desired messages in the EvalTool "Data Sets" tab.
• Press the "Save Persistent" button in the EvalTool "Data Logs" tab to store the current message configuration to flash memory
for use following reboot.
• Reset the system and verify the messages are automatically streaming. You can use the EvalTool->Data Logs dialog to view thestreaming messages.
To disable all persistent messages using the EvalTool, click the "Stop Streaming" button and then "Save Persistent" button.
Enabling Persistent Messages - CLTool

Persistent messages are enabled using the CLTool by including the -persistent option along with the options for the desired
messages in the command line.
cltool -c /dev/ttyS3 -persistent -msgINS2 -msgGPS- 178/348 -©2022

7.3.2 ISB Packet Overview

EXAMPLE PROJECTS

Examples on how to use the Inertial Sense SDK for binary communications are found in the Binary Communications Example
Project and cltool project. NMEA communications examples are found in the NMEA Example Project.

Parsing Data
The ISComm library in the InertialSenseSDK provides a communications parser that can parse InertialSense binary protocol aswell as other protocols.
ONE BYTE (SIMPLE METHOD)

The following parser code is simpler to implement. This method uses the is_comm_parse_byte() function to parse one byte at atime of a data stream. The return value is a non-zero protocol_type_t when valid data is found.
uint8_t c;
protocol_type_t ptype;// Read from serial buffer until empty
while (serialPortReadChar(&s_serialPort, &c) > 0){// timeMs = current_timeMs();
switch (is_comm_parse_byte(&comm, inByte)){case _PTYPE_INERTIAL_SENSE_DATA:
break;
case _PTYPE_UBLOX:
break;
case _PTYPE_RTCM3:
break;
case _PTYPE_NMEA:
break;}}SET OF BYTES (FAST METHOD)

The following parser code uses less processor time to parse data by copying multiple bytes at a time. This method uses
is_comm_free() and is_comm_parse() along with a serial port read or buffer copy. The return value is a non-zero protocol_type_t

when valid data is found.
// Read a set of bytes (fast method)
protocol_type_t ptype;// Get available size of comm buffer
int n = is_comm_free(comm);// Read data directly into comm bufferif ((n = serialPortRead(comm->buf.tail, n))){// Update comm buffer tail pointercomm->buf.tail += n;// Search comm buffer for valid packets
while ((ptype = is_comm_parse(comm)) != _PTYPE_NONE){
switch (ptype){case _PTYPE_INERTIAL_SENSE_DATA:
case _PTYPE_IS_V1_CMD:
break;
case _PTYPE_UBLOX:
break;
case _PTYPE_RTCM3:
break;
case _PTYPE_NMEA:
break;}}}

7.3.2 ISB Packet Overview
The IMX and GPX communicate using the Inertial Sense Binary (ISB) protocol. This section details the ISB protocol packet
structure specific for protocol 2.x (software releases 2.x). Refer to the release 1.x ISB protocol document for a description of
protocol 1.x (software releases 1.x). The Inertial-Sense-SDK ISComm provides functions to encode and decode ISB packets.

- 179/348 -©2022

7.3.2 ISB Packet Overview

ISB Packet

The ISB packet structure is defined in the typedef packet_t found in ISComm.h.
HEADER TYPE AND FLAGS

The packet type and flags are found in the byte at offset 2 in the ISB packet. The Type is the lower nibble and the Flags are theupper nibble. The packet and is defined in ISComm.h.
typedef enum{
PKT_TYPE_INVALID
PKT_TYPE_ACK
PKT_TYPE_NACK
PKT_TYPE_GET_DATA
broadcast data.
PKT_TYPE_DATA
PKT_TYPE_SET_DATA
PKT_TYPE_STOP_BROADCASTS_ALL_PORTS
PKT_TYPE_STOP_DID_BROADCAST
PKT_TYPE_STOP_BROADCASTS_CURRENT_PORT
PKT_TYPE_COUNTPKT_TYPE_MAX_COUNTPKT_TYPE_MASKISB_FLAGS_MASKISB_FLAGS_EXTENDED_PAYLOAD
ISB_FLAGS_PAYLOAD_W_OFFSET} eISBPacketFlags;

= 0,
= 1,
= 2,
= 3,

// Invalid packet id// (ACK) received valid packet// (NACK) received invalid packet// Request for data to be broadcast, response is PKT_TYPE_DATA. See data structures for list of possible= 4,// Data sent in response to PKT_TYPE_GET_DATA (no PKT_TYPE_ACK is sent)= 5,// Data sent, such as configuration options. PKT_TYPE_ACK is sent in response.
= 6,// Stop all data broadcasts on all ports. Responds with an ACK= 7,// Stop a specific broadcast= 8,// Stop all data broadcasts on current port. Responds with an ACK= 9,// The number of packet identifiers, keep this at the end!
= 16,// The maximum count of packet identifiers, 0x1F (PACKET_INFO_ID_MASK)= 0x0F, // ISB packet type bitmask= 0xF0, // ISB packet flags bitmask (4 bits upper nibble)= 0x10, // Payload is larger than 2048 bytes and extends into next packet.
= 0x20, // The first two bytes of the payload are the byte offset of the payload data into the data set.

HEADER DID

The data ID (DID) values are defined at the top of data_sets.h and identify which data set is requested or contained in the ISB
packet.
HEADER PAYLOAD SIZEThe ISB packet payload size is a uint16 that will
FOOTER CHECKSUM

The ISB packet footer contains a Fletcher-16 (16-bit integer). The following algorithm is used for this checksum and is found in
ISComm.h.
uint16_t is_comm_fletcher16(uint16_t cksum_init, const void* data, uint32_t size){
checksum16_u cksum;
cksum.ck = cksum_init;
for (uint32_t i=0; i<size; i++){cksum.a += ((uint8_t*)data)[i];cksum.b += cksum.a;}
return cksum.ck;}

The ISB packet footer checksum is computed using the Fletcher-16 algorithm starting with an initial value of zero andsequencing over the entire packet (excluding the two footer checksum bytes).

- 180/348 -©2022

7.3.3 Stop Broadcasts Packets

ISB Packet with Data Offset*The first two bytes of the payload may be a uint16 offset for the data offset in the target data set when the
ISB_FLAGS_PAYLOAD_W_OFFSET flag is set in the header flags.

ISB Packet with No Payload

Packet types PKT_TYPE_STOP_BROADCASTS_ALL_PORTS , PKT_TYPE_STOP_DID_BROADCAST , PKT_TYPE_STOP_BROADCASTS_CURRENT_PORT havepayload size zero and no payload.

ISB Get Data Packet

The Get Data packet of type PKT_TYPE_GET_DATA is used to query specific data according to data set ID, size, offset, and streaming
period multiple. The payload size is 8. Setting the payload period to zero will result in a single response and a continuous streamof data for a non-zero period.

7.3.3 Stop Broadcasts Packets
Note
The NEMA $STPB stop broadcasts command is recommended as the protocol version-independent method for disabling data
streaming.

Two stop all broadcasts packets are special packet types that will disable all binary and NMEA data streams. The following
functions calls are provided in the SDK to generate the stop all broadcasts packets.

All Ports- 181/348 -©2022

7.3.4 RMC Presets

is_comm_stop_broadcasts_all_ports(portWrite, 0, &comm);

The hexadecimal string to stop all broadcasts on all ports is:
0xef 0x49 0x06 0x00 0x00 0x00 0x3e 0x1f

Current Port Only
is_comm_stop_broadcasts_current_port(portWrite, 0, &comm);

The hexadecimal string to stop all broadcasts on the current port is:
0xef 0x49 0x08 0x00 0x00 0x00 0x40 0x27

7.3.4 RMC Presets
RMC Preset Stream PPD
The hexadecimal string for the RMC Preset enable PPD is:
0xef 0x49 0x05 0x09 0x0c 0x00 0xe2 0x3c 0x35 0x01 0x90 0x00 0x00 0xc0 0x00 0x01 0x00 0x00 0xf7 0xb0

- 182/348 -©2022

7.4 NMEA 0183 (ASCII) Protocol

7.4 NMEA 0183 (ASCII) Protocol
For simple use, the Inertial Sense device supports a human-readable NMEA communications protocol based on NMEA 0183. The
NMEA protocol is human readable from in a command line terminal but is less optimal than the binary protocol in terms of
message length for the same amount of data.

7.4.1 Communications Examples
The NMEA Communications Example Project demonstrates how to implement the protocol.

7.4.2 Packet Structure
The Inertial Sense NMEA protocol follows the standard NMEA 0183 message structure:• 1 byte – Start packet, $ ( 0x24 )• n bytes – packet identifier• 1 byte – comma ( 0x2C )• n bytes – comma separated list of data, can include decimals and text
• 1 byte – checksum marker, * ( 0x2A )• 2 bytes – checksum in hex format (i.e. f5 or 0a ), 0 padded and lowercase• 2 bytes – End packet, \r\n ( 0x0D , 0x0A )The packet checksum is an 8 bit integer and is calculated by calculating the exclusive OR of all bytes in between and notincluding the $ and * bytes. The packet checksum byte is converted to a 2 byte NMEA hex code, and left padded with 0 if
necessary to ensure that it is always 2 bytes. The checksum is always lowercase hexadecimal characters. See NMEA 0183
message structure for more details. The NMEA string checksum is automatically computed and appended to string when using
the InertialSense SDK serialPortWriteAscii function or can be generated using an online checksum calculator. For example: MTKNMEA checksum calculator

7.4.3 Persistent Messages
The persistent messages option saves the current data stream configuration to flash memory for use following reboot,eliminating the need to re-enable messages following a reset or power cycle.
• To save current NMEA persistent messages - send the $PERS command.
• To disable persistent messages - send the STPB](#stpb) followed by [PERS.
Binary persistent messages are also available.

Enabling Persistent Messages - EvalTool
To enable persistent NMEA messages using the EvalTool:• Enable the desired NMEA messages in the EvalTool "Data Sets" tab. Select DID_NMEA_BCAST_PERIOD in the DID menu andset the desired NMEA messages period to a non-zero value.
• Press the "Save Persistent" button in the EvalTool "Data Logs" tab to store the current message configuration to flash memory.
• Reset the IMX and verify the messages are automatically streaming. You can use a generic serial port program like putty or the
EvalTool->Data Logs->Data Log->Messages dialog to view the NMEA messages.
To disable all persistent messages using the EvalTool, click the "Stop Streaming" button and then "Save Persistent" button.

- 183/348 -©2022

7.4.4 NMEA Input Messages

7.4.4 NMEA Input Messages
The following NMEA messages can be received by the IMX.
Message

Description$ASCE*14\r\nQuery the broadcast rate of NMEA output messages.

ASCE

Set the broadcast period of selected NMEA output messages.

$INFO*0E\r\nQuery device information.

$SRST*06\r\nSoftware reset.

$PERS*14\r\nSave persistent messages to flash.

$STPB*15\r\nStop broadcast of all messages (NMEA and binary) on all ports.

$STPC*14\r\nStop broadcast of all messages (NMEA and binary) on current port.

ASCE
Enable NMEA message output streaming by specifying the NMEA message identifier or ID and broadcast period. The period is
the multiple of the data source period (i.e. a GNSS message with period multiple of 2 and data source period of 200 ms (5 Hz)
will broadcast every 400 ms). “xx” is the two-character checksum. A period of 0 will disable message streaming. The broadcast
period for each message is configurable as a period multiple of the Data Source Update Rates. Up to 20 different NMEA
messages can be enabled by repeating the message ID and period sequence within an ASCE message.
$ASCE,OPTIONS,(ID,PERIOD)*xx\r\n

The following examples will enable the same NMEA message output:$ASCE,0,PPIMU,1,PINS2,10,GxGGA,1*10\r\n$ASCE,0,2,1,5,10,7,1*39\r\n

Index

Field

Description

1

OPTIONSPort selection. Combine by adding options together:0=current, 1=ser0, 2=ser1, 4=ser2, 8=USB,
512=persistent (remember after reset)
Start of repeated group (1...20 times)

2+n*2

ID

Either 1.) message identifier string (i.e. PPIMU, PINS1, GxGGA) excluding packet start
character $ or 2.) message ID (eNmeaAsciiMsgId) of the NMEA message to be streamed.
See the message ID in the NMEA output messages table.

3+n*2

PERIOD

Broadcast period multiple for specified message. Zero disables streaming.
End of repeated group (1...20 times)- 184/348 -©2022

7.4.4 NMEA Input Messages

EXAMPLE MESSAGESThe following examples NMEA messages enable IMX data streaming output. The data period is 1, full data source rates, for thosethat do not specify the output rate.
Message

Data (Output Rate)**$ASCE,0,6,1,7,1,8,1,10,1,14,1*04\r\nGGA, GLL, GSA, ZDA, GSV (all at 5Hz)

$ASCE,0,5,2,2,1,7,1*0A\r\n

PINS2 (31.25 Hz), PPIMU (62.5Hz), GGA (5Hz)$ASCE,0,0,1*09\r\n

PIMU$ASCE,0,1,1*08\r\n

PPIMU$ASCE,0,2,1*0B\r\n

PRIMU$ASCE,0,3,1*0A\r\n

PINS1$ASCE,0,4,1*0D\r\n

PINS2$ASCE,0,5,1*0C\r\nPGPSP$ASCE,0,6,1*0F\r\n

GGA$ASCE,0,7,1*0E\r\n

GLL$ASCE,0,8,1*01\r\n

GSA$ASCE,0,9,1*00\r\n

RMC$ASCE,0,10,1*38\r\n

ZDA$ASCE,0,11,1*39\r\n

PASHR$ASCE,0,12,1*3A\r\nPSTRB$ASCE,0,13,1*3B\r\n

INFO$ASCE,0,14,1*3C\r\n

GSV$ASCE,0,15,1*3D\r\n

VTG** These rates assume the default settings for data source rates.

PERS
Send this command to save current persistent messages to flash memory for use following reboot. This eliminates the need to reenable messages following a reset or power cycle. In order to disable persistent messages, all messages must be disabled andthen the 'save persistent messages' command should be sent.
$PERS*14\r\n

STPB
Stop all broadcasts (both binary and NMEA) on all ports by sending the following packet:$STPB*15\r\n

The hexadecimal equivalent is:
24 53 54 50 42 2A 31 35 0D 0A- 185/348 -©2022

7.4.5 NMEA Output Messages

STPC
Stop all broadcasts (both binary and NMEA) on the current port by sending the following packet:$STPC*14\r\n

The hexadecimal equivalent is:
24 53 54 50 43 2A 31 34 0D 0A

7.4.5 NMEA Output Messages
The following NMEA messages can be sent by the IMX. The message ID ( eNmeaAsciiMsgId ) is used with the $ASCE message toenable message streaming.
Identifier

ID

ASCB

Description
Broadcast period of NMEA output messages.

PIMU

1

IMU data (3-axis gyros and accelerometers) in the body frame.

PPIMU

2

Preintegrated IMU: delta theta (rad) and delta velocity (m/s).

PRIMU

3

Raw IMU data (3-axis gyros and accelerometers) in the body frame.

PINS1

4

INS output: euler rotation w/ respect to NED, NED position from reference LLA.

PINS2

5

INS output: quaternion rotation w/ respect to NED, ellipsoid altitude.

PGPSP

6

GPS position data.

GGA

7Standard NMEA GGA GPS 3D location, fix, and accuracy.

GLL

8Standard NMEA GLL GPS 2D location and time.

GSA

9Standard NMEA GSA GPS DOP and active satellites.

RMC

10

Standard NMEA RMC Recommended minimum specific GPS/Transit data.

ZDA

11

Standard NMEA ZDA UTC Time/Date message.

PASHR

12

Standard NMEA PASHR (euler) message.

PSTRB

13

Strobe event input time.

INFO

14

Device information.

GSV

15

Standard NMEA GSV satellite info (all active constellations sent with corresponding
talker IDs).

VTG

16

Standard NMEA VTG track made good and speed over ground.

The field codes used in the message descriptions are: lf = double, f = float, d = int.

PIMU
IMU sensor data (3-axis gyros and accelerometers) in the body frame.

- 186/348 -©2022

7.4.5 NMEA Output Messages$PIMU,lf,f,f,f,f,f,f*xx\r\n
1 2 3 4 5 6 7

Index

Field

Units

Description

1

time

sec

Time since system power up

3

IMU pqr[0]rad/sec

IMU angular rate gyro – X

2IMU pqr[1]rad/sec

IMU angular rate gyro – Y

4

IMU pqr[2]rad/sec

IMU angular rate gyro – Z

5

IMU acc[0]m/s2IMU linear acceleration – X

6

IMU acc[1]m/s2

IMU linear acceleration – Y

7

IMU acc[2]m/s2

IMU linear acceleration – Z

PPIMUPreintegrated inertial measurement unit (IMU) sensor data, delta theta in radians and delta velocity in m/s in the body frame.
Also known as coning and sculling integrals.
$PPIMU,lf,f,f,f,f,f,f,f*xx\r\n
1 2 3 4 5 6 7 8

Index

Field

Units

Description

1

time

sec

Time since system power up

2theta[0]rad

IMU delta theta integral – X

3theta[1]rad

IMU delta theta integral – Y4theta[2]rad

IMU delta theta integral – Z

8

vel[0]m/s

IMU delta velocity integral – X

9vel[1]m/s

IMU delta velocity integral – Y

10

vel[2]m/s

IMU delta velocity integral – Z

14

dt

s

Integration period for delta theta vel

PRIMU
Raw IMU sensor data (3-axis gyros and accelerometers) in the body frame (up to 1KHz). Use this IMU data for output data rates
faster than DID_FLASH_CONFIG.startupNavDtMs. Otherwise we recommend use of PIMU or PPIMU as they are oversampled
and contain less noise. 0 to disable.

- 187/348 -©2022

7.4.5 NMEA Output Messages$PRIMU,lf,f,f,f,f,f,f*xx\r\n
1 2 3 4 5 6 7

Index

Field

Units

Description

1

time

sec

Time since system power up

3

Raw IMU pqr[0]rad/sec

Raw IMU angular rate gyro – X

2

Raw IMU pqr[1]rad/sec

Raw IMU angular rate gyro – Y

4

Raw IMU pqr[2]rad/sec

Raw IMU angular rate gyro – Z

5

Raw IMU acc[0]m/s2

Raw IMU linear acceleration – X

6

Raw IMU acc[1]m/s2

Raw IMU linear acceleration – Y

7

Raw IMU acc[2]m/s2

Raw IMU linear acceleration – Z

PINS1
INS output with Euler angles and NED offset from the reference LLA.
$PINS1,lf,d,d,d,f,f,f,f,f,f,lf,lf,lf,f,f,f*xx\r\n
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6

Index

Field

Units

Description

1

timeOfWeek

sec

Seconds since Sunday morning in GMT

2

GPS week

weeks

Number of weeks since January 1st of 1980 in GMT

3

insStatus

INS Status Flags

4

hdwStatus

Hardware Status Flags

5

theta[0]radEuler angle – roll6

theta[1]radEuler angle – pitch

7

theta[2]radEuler angle – yaw

8

UVW[0]

m/s

Velocity in body frame – X

9UVW[1]

m/s

Velocity in body frame – Y

10UVW[2]

m/s

Velocity in body frame – Z

11Latitudedeg

WGS84 Latitude

12

Longitudedeg

WGS84 Longitude13

HAE Altitudem

Height above ellipsoid (vertical elevation)

14

NED[0]m

Offset from reference LLA – North

15

NED[1]m

Offset from reference LLA – East16

NED[2]m

Offset from reference LLA – Down

PINS2
INS output with quaternion attitude.

- 188/348 -©2022

7.4.5 NMEA Output Messages$PINS2,lf,d,d,d,f,f,f,f,f,f,f,lf,lf,lf*xx\r\n
1 2 3 4 5 6 7 8 9 0 1 2 3 4

Index

Field

Units

Description

1

timeOfWeek

sec

Seconds since Sunday morning in GMT

2

GPS week

weeks

Number of weeks since January 1st of 1980 in GMT

3

insStatus

INS Status Flags

4

hdwStatus

Hardware Status Flags

5qn2b[0]Quaternion rotation (NED to body) – W

6

qn2b[1]

Quaternion rotation (NED to body) – X

7

qn2b[2]

Quaternion rotation (NED to body) – Y

8

qn2b[3]

Quaternion rotation (NED to body) – Z

9UVW[0]

m/s

Velocity in body frame – X

10UVW[1]

m/s

Velocity in body frame – Y

11

UVW[2]

m/s

Velocity in body frame – Z

12Latitudedeg

WGS84 Latitude

13

Longitudedeg

WGS84 Longitude

14

HAE altitudem

Height above ellipsoid (vertical elevation)

PGPSP
GPS navigation data.
$PGPSP,d,d,d,lf,lf,lf,f,f,f,f,f,f,f,f,f,f*xx\r\n
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6- 189/348 -©2022

7.4.5 NMEA Output Messages$PGPSP,337272200,2031,1075643160,40.33057800,-111.72581630,1406.39,1425.18,0.95,0.37,0.55,-0.02,0.02,-0.03,0.17,39.5,337182.4521*4d\r\n

Index

Field

Units

Description

1

timeOfWeekMs

ms

GPS time of week in milliseconds since Sunday morning in GMT

2

GPS weekweeks

GPS number of weeks since January 1st of 1980 in GMT

3status(see eGpsStatus) GPS status: [0x000000xx] number of satellites used,[0x0000xx00] fix type, [0x00xx0000] status flags

4

Latitudedeg

WGS84 Latitude

5

Longitudedeg

WGS84 Longitude

6

HAE altitudem

Height above WGS84 ellipsoid

7

MSL altitudemElevation above mean sea level

8

pDOP

m

Position dilution of precision

9

hAcc

m

Horizontal accuracy

10

vAcc

m

Vertical accuracy

11

Velocity X

m/s

ECEF X velocity

12

Velocity Y

m/s

ECEF Y velocity

13

Velocity Z

m/s

ECEF Z velocity

14

sAcc

m/s

Speed accuracy

15

cnoMeandBHz

Average of all satellite carrier to noise ratios (signal strengths) that nonzero

16

towOffsetsTime sync offset between local time since boot up to GPS time of week
in seconds. Add this to IMU and sensor time to get GPS time of week inseconds.

17

leapS

s

GPS leap second (GPS-UTC) offset. Receiver's best knowledge of theleap seconds offset from UTC to GPS time. Subtract from GPS time ofweek to get UTC time of week.

GGA
NMEA GPS fix, 3D location and accuracy data.

- 190/348 -©2022

7.4.5 NMEA Output Messages$GPGGA,204153.200,4003.34331,N,11139.51872,W,1,25,0.93,1433.997,M,18.82,M,,*6d\r\n
1
2 3
4 5 6 78
90
1 2 3 4

Index

Field

Units

1

HHMMSS.sss

2,3

Latitude4,5Longitude6

Fix quality

Description

ExampleUTC time (fix taken at 20:41:53.200 UTC)

204153.200

deg,min

WGS84 latitude (DDmm.mmmmm,N)

4003.34331,N

deg,min

WGS84 longitude (DDDmm.mmmmm,E)

11139.51872,W

0 = invalid, 1 = GPS fix (SPS), 2 = DGPS fix, 3 =1

PPS fix, 4 = RTK Fix, 5 = RTK Float, 6 = estimated(dead reckoning), 7 = Manual input mode, 8 =Simulation mode
7

# Satellites

Number of satellites in use

15

8

hDop

m

Horizontal dilution of precision

0.9

9,10

MSL_altitudemElevation above mean sea level (MSL)

545.4,M

11,12

Undulationm

Undulation of geoid. Height of the geoid above the46.9,M

WGS84 ellipsoid.
13

empty

14

empty

s

Time since last DGPS update
DGPS station ID number

GLL
NMEA geographic position, latitude / longitude and time.
$GPGLL,4916.45123,N,12311.12324,W,225444.800,A*33\r\n
1 2
3 4
5 6

Index

Field

Units

Description

Example1,2

Latitudedeg,min

WGS84 latitude (DDmm.mmmmm,N)

4916.45123,N

3,4

Longitudedeg,min

WGS84 longitude12311.12324,W(DDDmm.mmmmm,E)
5

HHMMSS.sss

UTC time (fix taken at 22:54:44.8

225444.800

UTC)
6

Valid

Data valid (A=active, V=void)A

GSA
NMEA GPS DOP and active satellites.

- 191/348 -©2022

7.4.5 NMEA Output Messages$GPGSA,A,3,04,05,,09,12,,,24,,,,,2.5,1.3,2.1*39\r\n
1 2 3 4 ...
15 16 17

Index

Field

Units

1

Description

ExampleAuto selection of 2D or 3D fix (M =A

manual)2

Fix quality

Fix quality (1 = none, 2 = 2D, 3 = 3D)

3

3-14

Sat ID

Satellite ID (PRNs)

04,05,,09,12,,,24,,,,,

15

pDop

m

Dilution of precision

2.5

16

hDop

m

Horizontal dilution of precision

1.3

17

vDop

m

Vertical dilution of precision

2.1

RMC
NMEA GPS recommended minimum specific GPS/Transit data.
eg1. $GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62\r\neg2. $GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68\r\n225446
A
4916.45,N
12311.12,W
000.5
054.7
191194020.3,E*68

Time of fix 22:54:46 UTC
Navigation receiver warning A = OK, V = warning
Latitude 49 deg. 16.45 min North
Longitude 123 deg. 11.12 min West
Speed over ground, Knots
Course Made Good, True
Date of fix 19 November 1994
Magnetic variation 20.3 deg East
mandatory checksum

eg3. $GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694,004.2,W*70\r\n
1
2
3
4
5
6
7
8
9
10 11 12
1
2
3
4
5
6
7
8
9
10
11
12

220516
A
5133.82N
00042.24
W
173.8
231.8
130694004.2
W*70Time Stampvalidity - A-ok, V-invalid
current Latitude
North/Southcurrent Longitude
East/West
Speed in knots
True course
Date Stamp
Variation
East/Westchecksumeg4. $GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh\r\n1= UTC of position fix
2= Data status (V=navigation receiver warning)3= Latitude of fix
4= N or S
5= Longitude of fix
6= E or W
7= Speed over ground in knots
8= Track made good in degrees True
9
= UT date10= Magnetic variation degrees (Easterly var. subtracts from true course)
11= E or W
12= Checksum

VTG
NMEA GPS track made good and speed over ground.
eg1. $GPVTG,140.88,T,,M,8.04,N,14.89,K,D*05\r\n
0
1
2
3
4
5
6
7
8
9

Message ID $GPVTG
Track made good (degrees true)
T: track made good is relative to true north
Track made good (degrees magnetic)
M: track made good is relative to magnetic north
Speed, in knots
N: speed is measured in knots
Speed over ground in kilometers/hour (kph)
K: speed over ground is measured in kph
Mode indicator:- 192/348 -©2022

7.4.5 NMEA Output Messages

10

A: Autonomous mode
D: Differential mode
E: Estimated (dead reckoning) mode
M: Manual Input mode
S: Simulator mode
N: Data not valid
The checksum data, always begins with *ZDA
NMEA GPS UTC Time and Date specification.
$GPZDA,213301.200,31,08,2023,00,00*41\r\n
1 2 3
4 5 6

Index

Field

1

Units

Description

ExampleHHMMSS.sss

UTC Time

213301.200

2

Day

Day

31

3

Month

Month

08

4

Year

Year

2023

5

localHrs

Local time zone hours

00

6

localMin

Local time zone minutes

00

GSV
NMEA GNSS satellites in view. xx corresponds to a constellation talker ID, shown in the table below.
Contains the number of sats in view, PRN numbers, elevation, azimuth and SNR value. Each message includes up to four
satellites. When there are more than 4 sats for a constellation, multiple messages are sent. The total number of messages and themessage number are included in each message.
Example:$GPGSV,6,1,23,02,40,310,43,08,07,324,31,10,48,267,45,15,37,053,45*7C\r\n$GPGSV,6,2,23,16,12,268,35,18,69,078,41,23,74,336,40,24,15,111,37*79\r\n$GPGSV,6,3,23,26,02,239,31,27,35,307,38,29,12,162,37,32,14,199,39*7B\r\n$GPGSV,6,4,23,44,43,188,43,46,40,206,43,522,48,267,45,527,37,053,26*73\r\n$GPGSV,6,5,23,530,69,078,34,535,74,336,34,536,15,111,25,538,02,239,18*74\r\n$GPGSV,6,6,23,539,35,307,27,541,12,162,21,544,14,199,25*73\r\n$GAGSV,2,1,08,05,65,144,41,09,39,052,43,34,71,341,42,36,46,105,39*6A\r\n$GAGSV,2,2,08,517,65,144,30,521,39,052,30,546,71,341,27,548,46,105,30*64\r\n$GBGSV,3,1,10,11,09,141,34,14,52,047,44,27,32,313,43,28,80,263,44*64\r\n$GBGSV,3,2,10,33,81,039,43,41,43,230,42,43,33,148,42,58,,,44*5B\r\n$GBGSV,3,3,10,11,09,141,16,14,52,047,32*60\r\n$GQGSV,1,1,01,02,45,101,30*49\r\n$GLGSV,2,1,07,65,85,260,33,66,28,217,30,72,36,034,35,81,20,324,33*69\r\n$GLGSV,2,2,07,87,47,127,35,88,73,350,34,87,47,127,20*53\r\nExample NMEA version 4.11:$GPGSV,4,1,14,02,40,310,43,08,07,324,31,10,48,267,45,15,37,053,45,1*67\r\n$GPGSV,4,2,14,16,12,268,35,18,69,078,41,23,74,336,40,24,15,111,37,1*62\r\n$GPGSV,4,3,14,26,02,239,31,27,35,307,38,29,12,162,37,32,14,199,39,1*60\r\n$GPGSV,4,4,14,44,43,188,43,46,40,206,43,1*65\r\n$GPGSV,3,1,09,10,48,267,45,15,37,053,26,18,69,078,34,23,74,336,34,6*68\r\n$GPGSV,3,2,09,24,15,111,25,26,02,239,18,27,35,307,27,29,12,162,21,6*64\r\n$GPGSV,3,3,09,32,14,199,25,6*58\r\n$GAGSV,1,1,04,05,65,144,41,09,39,052,43,34,71,341,42,36,46,105,39,7*7E\r\n$GAGSV,1,1,04,05,65,144,30,09,39,052,30,34,71,341,27,36,46,105,30,2*73\r\n$GBGSV,2,1,08,11,09,141,34,14,52,047,44,27,32,313,43,28,80,263,44,1*71\r\n$GBGSV,2,2,08,33,81,039,43,41,43,230,42,43,33,148,42,58,,,44,1*4E\r\n$GBGSV,1,1,02,11,09,141,16,14,52,047,32,B*0D\r\n$GQGSV,1,1,01,02,45,101,30,1*54\r\n$GLGSV,2,1,06,65,85,260,33,66,28,217,30,72,36,034,35,81,20,324,33,1*75\r\n$GLGSV,2,2,06,87,47,127,35,88,73,350,34,1*75\r\n$GLGSV,1,1,01,87,47,127,20,3*41\r\n- 193/348 -©2022

7.4.5 NMEA Output Messages

Talker ID

Constellation

GP

GPS

GQ

QZSS

GA

GalileoGL

Glonass

GB

BeiDouGN

Combination of active constellations

Index

Field

Units

Description

1

numMsgs

Total number of messages for this constellation and epoch2

msgNumMessage number

3

numSats

Total number of known satellites for the talker ID and signal ID

4+(n*5)prn

Satellite PRN number

5+(n*5)elev

deg

Elevation (0-90)

6+(n*5)azim

deg

Azimuth (000 to 359)

7+(n*5)snrdB

SNR (00-99, empty when not tracking)variablesystem ID

GNSS system ID (distinguishes frequency band). This field is only
output if the NMEA version is 4.11.

Where n is 0-3, for the four satellites supported by this message.

VTG
NMEA GPS track made good and speed over ground.
$GPVTG,140.88,T,,M,8.04,N,14.89,K,D*05\r\n
1 2 3 45 6
7 8 9

| Index | Field | Units | Description | Example | |-------|--------|-------|----------------------------------------------------|---------| | 1 | track true | deg |Ground track heading (true north) | 140.88 | | 2 | T | | Ground track heading is relative to true north | T | | 3 | track mag | deg |Ground track heading (magnetic north) | | | 4 | M | | Ground track heading is relative to magnetic north (track mag = track true +magVarCorrection) | M | | 5 | speed Kn | knots | Speed | 8.04 | | 6 | N | | Speed is measured in knots | N | | 7 | speed Km | kph |Speed over ground in kilometers/hour | 14.89 | | 8 | K | | Speed over ground is measured in kph | K | | 9 | mode ind | | Mode
indicator: | D | | | | | A: Autonomous mode | | | | | | D: Differential mode | | | | | | E: Estimated (dead reckoning) mode | | | | | | M:
Manual Input mode | | | | | | S: Simulator mode | | | | | | N: Data not valid | |PASHRNMEA GPS DOP and active satellites.

- 194/348 -©2022

7.4.5 NMEA Output Messages$PASHR,001924.600,95.81,T,+0.60,+1.05,+0.00,0.038,0.035,0.526,0,0*08\r\n
1
2
3
4
5
6
7
8
9 10 11

Index

Field

1

Units

Description

ExampleTime

UTC Time

001924.600

2

HeadingHeading value in decimal degrees

95.81

3

True Heading

T displayed if heading is relative to trueTnorth.
4Roll

mRoll in decimal degrees.

+0.60

5

Pitch

m

Pitch in decimal degrees.

+1.05

6

Heave

m

Instantaneous heave in meters.

+0.00

7

Roll Accuracy

Roll standard deviation in decimal+0.038degrees.
8

Pitch Accuracy

Pitch standard deviation in decimal

0.035

degrees.
9

HeadingHeading standard deviation in decimal

Accuracy

degrees.

0.526

10

GPS Status

GPS Status

0

11

INS Status

INS Status

0

PSTRB
Strobe input time. This message is sent when an assert event occurs on a strobe input pin.
$PSTRB,d,d,d,d*xx\r\n
1 2 3 4

Index

Field

Units

Description

1

GPS week

weeks

Number of weeks since January 1st of 1980 in GMT

2

timeMsOfWeek

ms

Milliseconds since Sunday morning in GMT

3pin

Strobe event input pin number

4

count

Strobe event serial index number

INFO
Device version information. Query this message by sending $INFO*0E\r\n .

- 195/348 -©2022

7.4.6 NMEA Examples$INFO,d,d.d.d.d,d.d.d.d,d,d.d.d.d,d,s,YYYY-MM-DD,hh:mm:ss.ms,s*xx\r\n
1 2
3
4 5
6 7 8
9
10

Index

Field

Units

Description

1

Serial number

Manufacturer serial number

2

HardwareHardware version

version3

FirmwareFirmware version

version4

Build number

Firmware build number

5

Protocol version

Communications protocol version

6

Repo revision

Repository revision number

7

Manufacturer

Manufacturer name8

Build date

Build date:[1] = year, [2] = month, [3] = day

9

Build time

Build date: [0] = hour, [1] = minute,[2] = second, [3] = millisecond

10

Add Info

Additional information

11

HardwareHardware: 1=uINS, 2=EVB, 3=IMX, 4=GPX

12Reserved

Reserved for internal purpose.

13

Build type

Build type: 'a'=ALPHA, 'b'=BETA, 'c'=RELEASE CANDIDATE,'r'=PRODUCTION RELEASE, 'd'=debug

7.4.6 NMEA Examples
Note
If the command strings below are altered, their checksum must be recalculated.

Note
All NMEA command strings must be followed with a carriage return and new line character ( \r\n or 0x0D , 0x0A ).

The NMEA string checksum is automatically computed and appended to string when using the InertialSense SDK
serialPortWriteAscii function or can be generated using an online NMEA checksum calculator. For example: MTK NMEA
checksum calculator
Stop streams on CURRENT port
$STPB*15

Stop all streams on ALL ports$STPC*14

Query device version information$INFO*0E- 196/348 -©2022

7.4.6 NMEA Examples

Response:$INFO,30612,3.1.2.0,1.7.0.0,3522,1.2.74.7,6275,Inertial Sense INC,0018-10-16,23:20:38.41,INL2*58

Stream INS1 @5Hz on port 0$ASCE,1,3,1*0B

Stream INS1 @400ms on current port
$ASCE,0,3,2*09

Response:$PINS1,244272.398,2021,427888998,805306448,0.0468,-0.3830,-0.0909,0.232,-0.083,-0.089,40.05574940,-111.65861580,1438.451,-1.678,-5.086,-9.697*11$PINS1,244272.498,2021,427888998,805306448,0.0469,-0.3830,-0.0902,0.232,-0.081,-0.089,40.05575000,-111.65861550,1438.451,-1.611,-5.060,-9.697*18$PINS1,244272.598,2021,427888998,805306448,0.0469,-0.3830,-0.0902,0.232,-0.081,-0.089,40.05575022,-111.65861562,1438.449,-1.587,-5.070,-9.695*1e

Stream INS1 @600ms on serial port 1$ASCE,2,3,3*0A

Response:$PINS1,256270.627,2021,427888998,1073741912,0.1153,-0.1473,-0.1628,0.001,0.001,0.003,40.05569486,-111.65864500,1416.218,-7.738,-7.570,12.536*3d$PINS1,256270.647,2021,427888998,1073741912,0.1153,-0.1473,-0.1632,0.001,0.001,0.003,40.05569486,-111.65864500,1416.219,-7.738,-7.570,12.535*32$PINS1,256270.667,2021,427888998,1073741912,0.1153,-0.1473,-0.1631,0.001,0.001,0.003,40.05569486,-111.65864500,1416.220,-7.738,-7.570,12.534*38

Stream PIMU @400ms and GGA @5Hz on current port
$ASCE,0,6,1,0,2*0D

Response:$PIMU,3218.543,0.0017,-0.0059,-0.0077,-1.417,-1.106,-9.524,0.0047,0.0031,-0.0069,-1.433,-1.072,-9.585*1f$GPGGA,231841,4003.3425,N,11139.5188,W,1,29,0.89,1434.16,M,18.82,M,,*59$GPGGA,231841,4003.3425,N,11139.5188,W,1,29,0.89,1434.19,M,18.82,M,,*56$PIMU,3218.763,0.0019,-0.0062,-0.0086,-1.426,-1.114,-9.509,0.0054,0.0029,-0.0070,-1.431,-1.085,-9.579*13$GPGGA,231841,4003.3425,N,11139.5188,W,1,29,0.89,1434.16,M,18.82,M,,*59$GPGGA,231841,4003.3425,N,11139.5188,W,1,29,0.89,1434.19,M,18.82,M,,*56$PIMU,3218.543,0.0017,-0.0059,-0.0077,-1.417,-1.106,-9.524,0.0047,0.0031,-0.0069,-1.433,-1.072,-9.585*1f- 197/348 -©2022

7.5 SPI Protocol

7.5 SPI Protocol
The SPI interface provides an alternative method of communications with the µINS, µAHRS, and µIMU. The SPI protocol uses
much of the same structure and format as the serial communication binary protocol which is outlined in the Binary Protocol
section of the users manual.

7.5.1 Enable SPITo Enable SPI, hold pin G9 (nSPI_EN) low at startup.
Note: When external GPS PPS timepulse signal is enabled on G9, the module will ignore the nSPI_EN signal and SPI mode will bedisabled regardless of G9 pin state.

7.5.2 Hardware
Inertial Sense SPI interface uses 5 lines to interface with other devices.
Line

FunctionCS

SPI Chip SelectSCLK

SPI Clock Synchronization Pin

MISO

SPI Master In Slave Out

MOSI

SPI Master Out Slave InDR

SPI Data Ready Pin (optional)

Hardware Configuration
The IMX and GPX modules operate as a SPI slave device using SPI Mode 3:
SPI Settings
SPI Mode

3

CPOL (Clock Polarity)

1

CPHA (Clock Phase)

1

Clock Polarity in Idle State

Logic highClock Phase Used to Sample and/or Shift Data

Data sampled on the rising edge and shifted out on the falling edge.

Chip SelectActive low

Data Ready

Active highData Transfer
To ensure correct behavior of the receiver in SPI Slave mode, the master device sending the frame must ensure a minimum delayof one tbit (tbit being the nominal time required to transmit a bit) between each character transmission. Inertial Sense devices do
not require a falling edge of the [Chip Select (CS)] to initiate a character reception but only a low level. However, this low levelmust be present on the [Chip Select (CS)] at least one tbit before the first serial clock cycle corresponding to the MSB bit. (1)- 198/348 -©2022

7.5.2 Hardware

When reading the IMX and there is no data ready it will send zeros for the data.
Keeping CS low should not cause any issues. However, if the clocking between the master and slave processors gets out of sync
there is nothing to get them back into sync. Ground bounce or noise during a transition could cause the IMX to see two clock
edges when there should have only been one (due to an ESD or a fast transient event). Raising and lowering the CS line resets
the shift register will resynchronize the clocks.

Data Ready Pin Option
There is a data ready pin option. This signal will be raised when data becomes ready. Depending on when this happens there canbe 1-4 bytes of zeros that will come out before the packet starts. Also this line will go inactive a byte or two before the end of thepacket gets sent. There is not a "not in a data packet" character to send. It is strictly done by data ready pin and parsing.
If the chip select line is lowered during a data packet, the byte being transmitted (or that would be transmitted) can be lost. It is
recommended to only lower the chip select when outside of a data packet and the data ready pin is inactive.
The internal SPI buffer is 4096 bytes. If there is a buffer overflow, the buffer gets dropped. This is indicated by a data ready pinthat is high without data being there. When an overflow happens, it clears the buffer, so the system could be in the middle of apacket and the IMX would just send zeros. If a request is sent to the IMX or the IMX sends a packet periodically it will resolve
the situation.
The SPI interface supports up to 3 Mbs data rate. (5 Mbs works if the data ready pin is used to receive the data - see B below.)

Reading Data
There are two strategies that can be used to read the data:
A. Read a fixed data size out every set time interval. More data will be read than the uINx will produce on a regular interval, forinstance, reading 512 bytes every 4 ms.

Packet will be 0x00 padded if bytes read exceeds packet size.
B. Read while the data ready pin is active or we are inside a data packet. One anomaly is the data ready pin will drop a byte or
two before the end gets clocked out, hence needing to watch for the end of the packet.

- 199/348 -©2022

7.5.3 EVB-2 SPI Dev Kit

Pseudo Code for reading data:
1. Check data ready pin. If pin is low, delay and check pin again.
2. Lower CS line and read a block of data. Read sizes are arbitrary, but it tends to work better if the read count is long enough tocontain most data packets.
3. After read completes, check data ready pin. If it is high, read more data. DO NOT raise the CS line while the data ready pin is high,it will cause data loss. If data ready is low, raise CS line. On a busy system (and depending on baud rate) this would need to happen
along with the data read as the data ready pin might not go low in between packets.
4. Parse data looking for start of packet (0xFF) discarding data until found. Once found start saving the data.
5. Save and parse data looking for end of packet (0xFE). Once found send packet off for use. If a start of packet character is seen
while looking for the end, discard previous data and start the packet saving over.

7.5.3 EVB-2 SPI Dev Kit
The EVB-2 demonstrates SPI interface with the IMX. The EVB-2 ATSAM-E70 (E70) processor provides the example SPI interface
with the IMX. The EVB-2 must be put into CBPreset mode 6 (CONFIG led color cyan) followed by a system reset to enable SPI
mode. The EVB-2 (E70) project source code is available in the SDK for reference.

7.5.4 Troubleshooting
If every other character from a packet is lost it might be that the CS line is being toggled after every byte.
The uINS-3.1 uses a USART SPI peripherial which requires a minimum delay of one tbit (tbit being the nominal time required totransmit a bit) spacing between characters sent. Reading bytes one by one may cause signifacnt time delays when streaming
data. Depending on the ammount of data streaming, the uINS mable to keep up and the buffer could be overflow. Single message
requests should work properly, but streaming probably will not work well. If the master hardware can't handle the delay, theuINS 3.2 hardware should be used.

7.5.5 Resources(1) SAM E70/S70/V70/V71 Family. Microchip Technology Inc., https://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70S70-V70-V71-Family-Data-Sheet-DS60001527E.pdf- 200/348 -©2022

7.6 CAN Protocol

7.6 CAN Protocol
The CAN interface allows the output of the the µINS, µAHRS, and µIMU to be published on a CAN bus. The Inertial Sense CAN
implementation is based on CAN2.0b specification and follows a specific structure and format which is outlined below. All of the
CAN configuration is done using the data set DID_CAN_CONFIG.

7.6.1 Enable CAN
To enable the CAN bus interface on the IMX, set bit IO_CONFIG_G1G2_CAN_BUS in DID_FLASH_CONFIG.ioConfig . This bit can be set
using the EvalTool >> Settings >> General >> DID_FLASH_CONFIG >> ioConfig >> Enable CAN Bus on G1,G2 option.
A CAN message is enabled by entering a non-zero value in the DID_CAN_CONFIG.can_period_mult field of the desired message.
The can_period_mult field is an integer which is multiplied by the Data Source Update Rate to determine the message broadcast
period. Set can_period_mult to zero disable message broadcasting.
In the image below the CID_INS_TIME message is set to broadcast data at 10 times the data source rate.

- 201/348 -©2022

7.6.2 Hardware

The baud rate is configurable by setting the field DID_CAN_CONFIG.can_baudrate_kbps. The following standard baud rates aresupported:• 20 kbps• 33 kbps• 50 kbps• 83 kbps• 100 kbps
• 125 kbps
• 200 kbps
• 250 kbps
• 500 kbps
• 1000 kbps
The message ID for each message can be entered into the can_transmit_address field corresponding to the desired message.
*Note: Any message ID greater than 0x7FF will be transmitted in the extended ID format.
The values set in any field of DID_CAN_CONFIG are saved to flash when a 'Save Persistent' command is received by the module.
For example, this can be done in the EvalTool by clicking the Save Persistent button in the Data Logs tab. When the module isturned on, all the fields will be repopulated with the saved values.
All messages are disabled when a Stop Streaming message is received by the module. However, the values in each field will be
repopulated to the values present when a 'Save Persistent' command was last received.

7.6.2 Hardware
Inertial Sense module exposes the RxCAN and TxCAN pins. The selection and implementation of a CAN transceiver is left to the
user.
Line

Function

G1

RxCAN

G2

TxCAN

The Inertial Sense evaluation boards and Rugged unit have a built in transceiver.

7.6.3 CAN Data Sets (CIDs)
The CAN Data Sets, in the form of C structures, define the format of the output data. The data sets are defined in
SDK\src\data_sets_canbus.h of the InertialSense SDK. The CID data is selected data from the standard Inertial Sense DIDs. The
data types generally have been changed and scaled to fit the CAN2.0 8 byte payload restrictions.
CID_INS_TIME

INS time output
is_can_time

GMT information
Field

Type

Description

week

uint32_t

GPS number of weeks since January 6th, 1980

timeOfWeek

float

GPS time of week (since Sunday morning) in seconds- 202/348 -©2022

7.6.3 CAN Data Sets (CIDs)

CID_INS_STATUS

is_can_ins_status

INS status flags
Field

Type

Description

insStatus

uint32_t

INS status flags (see eInsStatusFlags)

hdwStatus

uint32_t

Hardware status flags (see eHdwStatusFlags)

CID_INS_EULER

is_can_ins_euler

Euler angles: roll, pitch, yaw in radians with respect to NED (scaled by 10000)
Field

Type

Description

theta1

int16_tRoll (4 decimal places precision)theta2

int16_t

Pitch (4 decimal places precision)theta3

int16_t

Yaw (4 decimal places precision)

CID_INS_QUATN2B

is_can_ins_quatn2b

Quaternion body rotation with respect to NED: W, X, Y, Z (scaled by 10000)
Field

Type

Description

qn2b1

int16_t

W (4 decimal places precision)

qn2b2

int16_t

X (4 decimal places precision)

qn2b3

int16_t

Y (4 decimal places precision)

qn2b4

int16_t

Z (4 decimal places precision)

CID_INS_QUATE2B

is_can_ins_quate2b

Quaternion body rotation with respect to ECEF: W, X, Y, Z (scaled by 10000)
Field

Type

Description

qe2b1

int16_t

W (4 decimal places precision)

qe2b2

int16_t

X (4 decimal places precision)

qe2b3

int16_t

Y (4 decimal places precision)

qe2b4

int16_t

Z (4 decimal places precision)

CID_INS_UVW

is_can_uvw- 203/348 -©2022

7.6.3 CAN Data Sets (CIDs)

Velocity U, V, W in body frame in meters per second (scaled by 100).
Field

Type

Description

uvw1

int16_t

U (2 decimal places precision)

uvw2

int16_t

V (2 decimal places precision)

uvw3

int16_t

W (2 decimal places precision)

CID_INS_VE

is_can_ve

Velocity in ECEF (earth-centered earth-fixed) frame in meters per second (scaled by 100).
Field

Type

Description

ve1

int16_tve1 (2 decimal places precision)ve2

int16_t

ve2 (2 decimal places precision)

ve3

int16_t

ve3 (2 decimal places precision)

Field

Type

Description

latdoubleLatitude (degrees) (more than 8 decimal places precision)

Field

Type

Description

londoubleLongitude (degrees) (more than 8 decimal places precision)

CID_INS_LAT

is_can_ins_lat

WGS84 latitude.

CID_INS_LON

is_can_ins_lon

WGS84 longitude.

CID_INS_ALT

is_can_ins_alt

WGS84 height above ellipsoid and GPS status flags
Field

Type

Description

alt

float

Altitude (meters) (more than 8 decimal places precision)

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags

CID_INS_NORTH_EAST

is_can_north_east- 204/348 -©2022

7.6.3 CAN Data Sets (CIDs)

Offset from reference latitude, longitude, and altitude to current latitude, longitude, and altitude.
Type

Field

Description

float

ned1

North (meters)

float

ned2

East (meters)

CID_INS_DOWN

is_can_down

Down offset from reference LLA and INS status flags
Type

Field

Description

float

ned3

Down (meters)

float

insStatus

INS status flags

CID_INS_ECEF_X

is_can_ecef_x

X Position in ECEF (earth-centered earth-fixed) frame.
Type

Field

Description

ecef1

doubleX (meters)

CID_INS_ECEF_Y

is_can_ecef_y

Y Position in ECEF (earth-centered earth-fixed) frame.
Type

Field

Description

ecef2

doubleY (meters)

CID_INS_ECEF_Z

is_can_ecef_z

Z Position in ECEF (earth-centered earth-fixed) frame.
Type

Field

Description

ecef2

doubleZ (meters)

CID_INS_MSL

ins_can_msl

Height above Mean Sea Level
Type

Field

Description

msl

float

MSL (meters)

CID_PREINT_PX

is_can_preint_imu_px- 205/348 -©2022

7.6.3 CAN Data Sets (CIDs)

Preintegrated IMU values delta theta and delta velocity (X axis), and Integral period in body/IMU frame of accelerometer 0.
Type

Field

Description

theta0int16_t

Delta theta (rad, scaled by 1000, 3 decimal places precision)

vel0

int16_t

Delta velocity (m/s, scaled by 100, 2 decimal places precision)

dt

uints16_t

Integral Period (meters, scaled by 1000)

CID_PREINT_QY

is_can_preint_imu_qy

Preintegrated IMU values delta theta and delta velocity (Y axis), and Integral period in body/IMU frame of accelerometer 0.
Type

Field

Description

theta1

int16_t

Delta theta (rad, scaled by 1000, 3 decimal places precision)

vel1

int16_t

Delta velocity (m/s, scaled by 100, 2 decimal places precision)

dt

uints16_t

Integral Period (meters, scaled by 1000)

CID_PREINT_RZ

is_can_preint_imu_rz

Preintegrated IMU values delta theta and delta velocity (Z axis), and Integral period in body/IMU frame of accelerometer 0.
Type

Field

Description

theta2

int16_t

Delta theta (rad, scaled by 1000, 3 decimal places precision)

vel2

int16_t

Delta velocity (m/s, scaled by 100, 2 decimal places precision)

dt

uints16_t

Integral Period (meters, scaled by 1000)

CID_DUAL_PX

is_can_dual_imu_px

Dual IMU gyro and accelerometer values from accelerometer 0
Type

Field

Description

theta0int16_t

Theta (rad/s, scaled by 1000, 3 decimal places precision)

vel0

int16_t

Acceleration (m/s2, scaled by 100, 2 decimal places precision)

statusuints32_t

IMU status (see eImuStatus)

CID_DUAL_QY

is_can_dual_imu_qy

Dual IMU gyro and accelerometer values from accelerometer 0
Type

Field

Description

theta1

int16_t

Theta (rad/s, scaled by 1000, 3 decimal places precision)

vel1

int16_t

Acceleration (m/s2, scaled by 100, 2 decimal places precision)

statusuints32_t

IMU status (see eImuStatus)- 206/348 -©2022

7.6.3 CAN Data Sets (CIDs)

CID_DUAL_RZ

is_can_dual_imu_rz

Dual IMU gyro and accelerometer values from accelerometer 0
Type

Field

Description

theta2

int16_t

Theta (rad/s, scaled by 1000, 3 decimal places precision)

vel2

int16_t

Acceleration (m/s2, scaled by 100, 2 decimal places precision)

statusuints32_t

IMU status (see eImuStatus)

CID_GPS1_POS

is_can_gps_pos_status

GPS CNO Mean and GPS status flags
Type

Field

Description

statusuint32_t(see eGpsStatus) GPS status: [0x000000xx] number of satellites used, [0x0000xx00] fix
type, [0x00xx0000] status flags

cnoMeanuint32_t(dBHz) Average of all satellite carrier to noise ratios (signal strengths) that are nonzero

CID_GPS1_RTK_POS_REL

is_can_gps_rtk_rel

RTK-GPS positioning performance metrics
Type

Field

Description

arRatio

uint8_t

Ambiguity resolution ratio factor for validationdifferentialAge

uint8_t

Age of differential (seconds)

distanceToBase

float

Distance to Base (m)headingToBase

int16_t

Angle from north to vectorToBase in local tangent plane. (rad, scaled by 1000)

CID_GPS2_RTK_CMP_REL

is_can_gps_rtk_rel

RTK-GPS compassing performance metrics
Type

Field

Description

arRatio

uint8_t

Ambiguity resolution ratio factor for validationdifferentialAge

uint8_t

Age of differential (seconds)

distanceToBase

float

Distance to Base (m)headingToBase

int16_t

Angle from north to vectorToBase in local tangent plane. (rad, scaled by 1000)

CID_ROLL_ROLLRATE

is_can_roll_rollRate- 207/348 -©2022

7.6.3 CAN Data Sets (CIDs)

Combination or INS roll estimation and preintegrated IMU of both accelerometers
Type

Field

Description

insRoll

int16_t

INS Roll (scaled by 10000, 4 decimal places precision)

pImu1

int16_t

Delta theta (rad, scaled by 1000, 3 decimal places precision)

pImu2

int16_t

Delta theta (rad, scaled by 1000, 3 decimal places precision)- 208/348 -©2022

8. GNSS - RTK

8. GNSS - RTK
8.1 Multi-band GNSS
8.1.1 Advantages
The advent of multi-band GNSS (multiple frequency global navigation satellite systems) improves accuracy by reducing theimpact of errors caused by multi-path and atmospheric distortion. When compared to traditional single-band GNSS, dual-band
technology provides about a 2x reduction in average position error (circular error probable - CEP). Benefits of multi-band GNSS
systems like the uBlox ZED-F9P receiver include:• Concurrent reception of GPS, GLONASS, Galileo and BeiDou for better coverage.
• Faster convergence time (GPS time to fix).
• More reliable / robust performance.
• ~2x reduction in average position error (CEP).
• Centimeter-level RTK position accuracy.
• Small and energy efficient module.
• Easy integration of RTK for fast time-to-market.

8.1.2 Overview
The IMX (GPS-INS) can be interfaced with external multi-band (multi-frequency) GNSS receiver(s) connected via serial port(s) toimprove precision the EKF solution. The supported message protocols are uBlox binary and NMEA. The following are the GPS
settings (accessible in the EvalTool GPS Settings tab and IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits ):Setting

Value

GPS Source

Serial port of the GNSS (serial 0 or 1)

GPS Type

GNSS model or protocol (ublox M8, ublox F9, or NMEA)GPS RTK

Position for L1 RTK precision positioning
Compass for L1 RTK Dual GNSS heading
F9 Position for ZED-F9P mult-frequency RTK precision positioning
F9 Compass for ZED-F9P multi-frequency Dual GNSS heading

GPS1 Timepulse

Source of the GNSS PPS time synchronization, uBlox GPS type only.

Refer to the Hardware section of this manual for serial port pinout information.

- 209/348 -©2022

8.1.3 uBlox ZED-F9P GNSS

8.1.3 uBlox ZED-F9P GNSSThe IMX (GPS-INS) can be configured for use with uBlox ZED-F9P multi-band GNSS receivers. This can be done using either the
EvalTool GPS Setting tab or the IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits fields.
GPS Ports

Value

GPS Source

serial 0, serial 1, or serial 2

GPS Type

ublox F9P

GPS1 Timepulse

Disable or IMX pin connected to ZED-F9P PPSRTK Rover

Value

GPS RTK ModeF9P Position or F9P Compass

RTK Base

Value

Serial Port 0 (Single GNSS only)

GPS1 - RTCM3

USB Port

GPS1 - RTCM3

The following sections detail how to interface and configure the IMX for operation using the ZED-F9P. See RTK precision
positioning and RTK compassing for RTK operation principles.
DUAL ZED-F9 HEADING ACCURACY

When using two multi-band ZED-F9 GNSS receivers in moving baseline mode (RTK compassing) such as the EVB-2 Dual ZED-F9,
the baseline error is composed of the measurement error plus the RTK solution error. The heading accuracy with ideal conditions
is shown in the following plot.

- 210/348 -©2022

8.1.3 uBlox ZED-F9P GNSS

Typical Interface
The IMX will automatically configure the ZED-F9P for communications.
SINGLE GNSS RTK POSITIONING W/ LIDAR

RTK base messages (RTMC3) supplied to any of the IMX serial ports are forwarded to GPS1 for RTK positioning. The RTK
precision position from GPS 1 is used in the IMX EKF solution. The IMX can be configured to output NMEA messages such as
GPGGA or GPRMC on any serial port.

UART2
GPS1...

PPS

USB
UART1

PPS
ublox Binary...

Serial1
StrobeLiDAR

μINS
Serial2
USB

GPRMC

Serial0

INS Data...

Point Cloud

Vehicle Data Interface

Viewer does not support full SVG 1.1
DUAL GNSS RTK POSITIONING AND RTK COMPASSING

RTK base messages (RTMC3) supplied to any of the IMX serial ports are forwarded to GPS1 for RTK positioning. RTK movingbase messages from GPS1 are forwarded to GPS2 for RTK compassing. The RTK precision position from GPS 1 and the RTK
compassing heading from GPS2 are used in the IMX EKF solution. Note that typically the Rugged-2 uses Serial 0 and the EVB-2
uses Serial 2 to communicate with the GPS2 F9P receiver.

- 211/348 -©2022

8.1.3 uBlox ZED-F9P GNSS

UART2
GPS2...

UART2

PPS

PPS

GPS1...

USB

USB
UART1

UART1

ublox Bina...

ublox Binary...

Serial2

Serial1

μINS

USB

StrobeSerial0

INS Data...

Vehicle Data Interface

Viewer does not support full SVG 1.1

Rugged-2- 212/348 -©2022

8.1.3 uBlox ZED-F9P GNSSThe Rugged-2 INS contains the either single or dual ZED-F9P onboard supporting RTK positioning and compassing. GPS 1 andGPS 2 are connected to serial ports 1 and 0 respectively on the IMX.
SINGLE GNSS SETTINGS

Use the following IMX settings with the Rugged-2-G1 (single GNSS receiver). These settings can be applied either using the
EvalTool GPS Settings tab or the IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits fields.
GPS Ports

Set the GPS1 source to Serial 1 and type to ublox F9P.

DID_FLASH_CONFIG

Value

ioConfig (firmware >=1.8.5)0x0244a040

RTK Rover

Enable RTK rover mode by selecting F9P Precision Position.

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000002

RTK Base

To configuring a system as an RTK base, disable the RTK Rover by setting the GPS1 and GPS2 RTK Mode to OFF, and select theappropriate correction output port on the IMX.

- 213/348 -©2022

8.1.3 uBlox ZED-F9P GNSSDID_FLASH_CONFIG

Value

RTKCfgBits

0x00000900

DUAL GNSS SETTINGS

Use the following IMX settings with the Rugged-2-G2 (dual GNSS receivers). These settings can be applied either using the
EvalTool GPS Settings tab or the IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits fields.
GPS Ports

Set GPS 1 and 2 to source Serial 1 and Serial 0. the serial port that the ZED-F9P is connected to and type to ublox F9P.

DID_FLASH_CONFIG

Value

ioConfig (firmware >=1.8.5)0x025ca040

RTK Rover

Enable RTK rover mode by selecting Precision Position External. GPS1 is designated for Precision Position External andGPS2 for F9P Compass settings. Either or both can be enabled at the same time.

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000006

RTK Base

To configuring a system as an RTK base, skip the RTK rover settings, and select the appropriate correction output port on the
IMX. Notice that IMX serial port 0 and 1 may be unavailable and occupied by the dual ZED-F9P receivers.

- 214/348 -©2022

8.1.3 uBlox ZED-F9P GNSSDID_FLASH_CONFIG

Value

RTKCfgBits

0x00000900

EVB-2 to ZED-F9P

The ZED-F9P can be powered using the EVB-2 +3.3V output. Either serial 0 or serial 1 can be used to communicate with the
ZED-F9P. See the EVB-2 H7 pinout for details.

- 215/348 -©2022

8.1.3 uBlox ZED-F9P GNSSSINGLE GNSS PINOUT

EVB-2
H7-1
H7-3
H7-11
H7-10
H7-12

IMX

ZED-F9P

GND

GND

+3.3V

3V3

Ser1 Tx

GPS RxD

Ser1 Rx

GPS TxD

G8 TIMEPULSEPPSSINGLE GNSS SETTINGS

Use the following settings when only one GPS receiver is connected to the IMX. These settings can be applied either using the
EvalTool GPS Settings tab or the IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits fields.
GPS Ports

Set the serial port that the ZED-F9P is connected to and type to ublox F9P.

DID_FLASH_CONFIG

Value

ioConfig (firmware >=1.8.5)0x0244a040

RTK Rover

Enable RTK rover mode by selecting Precision Position External.

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000002

RTK Base

To configuring a system as an RTK base, disable the RTK Rover by setting the RTK Mode for GPS1 and GPS2 to off, and select theappropriate correction output port on the IMX.

- 216/348 -©2022

8.1.3 uBlox ZED-F9P GNSSDID_FLASH_CONFIG

Value

RTKCfgBits

0x00000900

Rugged-1 to ZED-F9P

A +3.3V or +5V supply is needed to power the ZED-F9P when using the Rugged-1 IMX. A USB +5V supply can be used if
available. The Rugged-1 must be configured for Serial Port 1 TTL voltage. See hardware configuration for Rugged v1.0 or
Rugged v1.1 for details.
SETTINGS

See the single GNSS settings.

- 217/348 -©2022

8.1.3 uBlox ZED-F9P GNSS

EVB-2 to Dual ZED-F9

Two ZED-F9 units can be used to provide either or both multi-band RTK compassing and RTK positioning for the INS solution.
The ZED-F9Ps can be powered using the EVB-2 +3.3V output. Serial port 0 and 1 must both be used to communicate with the
ZED-F9P.
DUAL GNSS PINOUT

EVB-2
H7-1
H7-3
H7-11
H7-10
H7-12

EVB-2
H7-2
H7-3
H7-6
H7-5

IMX

GPS1 ZED-F9P

GND

GND

+3.3V

3V3

Ser1 Tx

RxD

Ser1 Rx

TxD

G8 TIMEPULSE

PPS

IMX

GPS2 ZED-F9P

GND

GND

+3.3V

3V3

Ser2 Tx*

RxD

Ser2 Rx*

TxD*R17 and R18 on the EVB-2 must be loaded with a zero ohm jumpers to connect Ser2 to H7 and U5 must be removed from the
EVB-2.

- 218/348 -©2022

8.1.3 uBlox ZED-F9P GNSSDUAL GNSS SETTINGS

The following settings are used when two GPS receivers are connected to the IMX. These settings can be applied either using the
EvalTool GPS Settings tab or the IMX DID_FLASH_CONFIG.ioConfig and DID_FLASH_CONFIG.RTKCfgBits fields.
GPS Ports

Set the serial port that the ZED-F9P is connected to and type to ublox F9P.

DID_FLASH_CONFIG

Value

ioConfig (firmware >=1.8.5)0x026ca040

RTK Rover

Enable RTK rover mode by selecting Precision Position External. GPS1 is designated for Precision Position External andGPS2 for F9P Compass settings. Either or both can be enabled at the same time.

- 219/348 -©2022

8.1.4 RTK Base Messages

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000006

RTK Base

To configuring a system as an RTK base, skip the RTK rover settings, and select the appropriate correction output port on the
IMX. Notice that IMX serial port 0 and 1 may be unavailable and occupied by the dual ZED-F9P receivers.

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000900

8.1.4 RTK Base Messages
In RTK mode, the ZED-F9P requires RTCM version 3 messages supporting DGNSS according to RTCM 10403.3.

- 220/348 -©2022

8.1.4 RTK Base Messages

ZED-F9 Rover Messages
The ZED-F9P operating in RTK rover mode can decode the following RTCM 3.3 messages.
Message type

Description

RTCM 1001

L1-only GPS RTK observables

RTCM 1002

Extended L1-only GPS RTK observables

RTCM 1003

L1/L2 GPS RTK observables

RTCM 1004

Extended L1/L2 GPS RTK observables

RTCM 1005

Stationary RTK reference station ARP

RTCM 1006

Stationary RTK reference station ARP with antenna height

RTCM 1007

Antenna descriptor

RTCM 1009

L1-only GLONASS RTK observables

RTCM 1010

Extended L1-only GLONASS RTK observables

RTCM 1011

L1/L2 GLONASS RTK observables

RTCM 1012

Extended L1/L2 GLONASS RTK observables

RTCM 1033

Receiver and antenna description

RTCM 1074

GPS MSM4

RTCM 1075

GPS MSM5

RTCM 1077

GPS MSM7

RTCM 1084

GLONASS MSM4

RTCM 1085

GLONASS MSM5

RTCM 1087

GLONASS MSM7

RTCM 1094

Galileo MSM4

RTCM 1095

Galileo MSM5

RTCM 1097

Galileo MSM7

RTCM 1124

BeiDou MSM4

RTCM 1125

BeiDou MSM5

RTCM 1127

BeiDou MSM7

RTCM 1230

GLONASS code-phase biases

RTCM 4072.0

Reference station PVT (u-blox proprietary RTCM Message)- 221/348 -©2022

8.1.5 ZED-F9P Firmware Update

ZED-F9 Base Output Messages
The ZED-F9P operating in RTK base mode will generate the following RTCM 3.3 output messages depending on whether thesatellite constellation have been enabled. See the Constellation Selection for information on enabling and disabling satellite
constellations.
Message Type

Period (sec)

Description

RTCM 1005

2

Stationary RTK reference station ARP

RTCM 1074

0.4

GPS MSM4

RTCM 1077

0.4

GPS MSM7

RTCM 1084

0.4

GLONASS MSM4

RTCM 1087

0.4

GLONASS MSM7

RTCM 1094

0.4

Galileo MSM4

RTCM 1097

0.4

Galileo MSM7

RTCM 1124

0.4

BeiDou MSM4

RTCM 1127

0.4

BeiDou MSM7

RTCM 1230

2

GLONASS code-phase biases

NTRIP Messages
The NTRIP server must provide the necessary subset of RTCM3 messages supported by the IMX-RTK. See the NTRIP page for an
overview of NTRIP.

8.1.5 ZED-F9P Firmware Update
The following section describes how to view the current GPS firmware version and how to update the firmware on the uBlox
ZED-F9P GNSS receiver through the IMX.

GPS Firmware Version
The current GPS firmware version can be read through the DID_GPS1_VERSION and DID_GPS2_VERSION messages.

- 222/348 -©2022

8.1.5 ZED-F9P Firmware Update

Firmware Update
The following steps describe how to update the uBlox ZED-F9P firmware. The uBlox U-Center application software and firmware
binary can be downloaded from the uBlox ZED-F9P documentation and resources webpage.

- 223/348 -©2022

8.1.5 ZED-F9P Firmware Update

1. Enable IMX Serial Bypass - Send the system command ( DID_SYS_CMD ) SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_GPS1 or
SYS_CMD_ENABLE_SERIAL_PORT_BRIDGE_USB_TO_GPS2 to enable serial bypass on the IMX. This will create a direct connection between thecurrent IMX serial port and the GPS. This is done in the EvalTool using the Factory Options dialog in the Settings -> General tab.

- 224/348 -©2022

8.1.5 ZED-F9P Firmware Update

2. Update Using U-Center - With the IMX serial bypass enabled, the uBlox U-Center software can connect directly to the ZED-F9P
GPS. Use the following steps in the ublox U-Center app:• Open the serial port with baudrate 921600.
• Select Tool -> Firmware Update and specify the uBlox F9P firmware file (i.e. UBX_F9_100_HPG132...bin ).
• Enable "Use this baudrate for update" as 921600.
• Disable "Enter safeboot before update".
• Enable "Send training sequence".
• Start the firmware update by pressing the small green "GO" circle in the bottom left corner of the Firmware Update Utility dialog.

• Power cycle the IMX.

- 225/348 -©2022

8.1.6 Multi-Band GNSS Components

8.1.6 Multi-Band GNSS Components
The following is a list of the ZED-F9P GNSS receivers and compatible antenna(s).

- 226/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 227/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 228/348 -©2022

8.1.6 Multi-Band GNSS Components- 229/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 230/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 231/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 232/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 233/348 -©2022

8.1.6 Multi-Band GNSS Components- 234/348 -©2022

8.1.6 Multi-Band GNSS Components

Item- 235/348 -©2022

8.2 External NMEA GNSS

8.2 External NMEA GNSS
GNSS receivers that output NMEA ascii protocol can be used to aid the IMX EKF.

8.2.1 Configure IMX for NMEA GNSS Input
1. Set serial port baudrate, matching DID_FLASH_CONFIG.serXBaudRate.
2. Configure GPS1 using EvalTool GPS Setting tab or the DID_FLASH_CONFIG.ioConfig.

DID_FLASH_CONFIG

Value

ioConfig (firmware >=1.8.5)

0x00840040

3. Enable the NMEA messages on the external GNSS:
Message

Description

GNS

GNSS Fix data (preferred) or GGA - Global positioning System Fix Data.

ZDA

UTC time and date.

RMC

Recommended Minimum Specific GNSS Data.

GSA

GNSS DOP and Active Satellites.

4. If RTK positioning is supported by the NMEA receiver, Enable RTK rover mode by selecting Precision Position External. This will
run the INS kalman filter in high accuracy mode and forward any RTK base station corrections to the external GNSS receiver.

DID_FLASH_CONFIG

Value

RTKCfgBits

0x00000002

8.2.2 Electrical Interface
The external NMEA GNSS receiver can be connected to Serial 0, Serial 1, and Serial 2 ports (3.3V TTL UART) on the IMX. See
the PCB Module hardware page for a description of the IMX pinout. Serial 0 and 2 can be accessed on the main connector of
Rugged-1 and Rugged-2 and all serial ports can be accessed on header H7 of the EVB-2.

- 236/348 -©2022

8.2.3 Enabling NMEA on ZED-F9P

8.2.3 Enabling NMEA on ZED-F9P
The recommended procotol with the IMX and ZED-F9P receiver is the uBlox binary protocol. However, the ZED-F9 can operateusing NMEA protocol if necessary. The following steps can be used to enable NMEA protocol output on the ublox ZED-F9P
receiver.
1. Enable NMEA output using the u-blox u-center application.
• Set the configuration: (ublox u-center menu -> View -> Configuration View) change the following. You must press the "Send"
button to apply each change.
• PRT (Ports) - Set Baudrate to match the GPS port baudrate (i.e. ser1BaudRate 921600)• PRT (Ports) - Enable NMEA on the connected port/UART• PRT (Ports) - Enable RTCM3 on the connected port/UART if using RTK• RATE (Rates) - Measurement Period: 200ms• RATE (Rates) - Navigation Rate: 1cyc
• MSG (Messages) - Enable NMEA messages listed above for the connected port/UART (i.e. UART1 On)• F0-0D NMEA GxGNS• F0-08 NMEA GxZDA• F0-04 NMEA GxRMC• F0-03 NMEA GxGSV• Save the configuration: Send the CFG (Configuration) to 1 - FLASH or press the "Save Config" button with the small gear saveicon (or menu Receiver -> Action -> Save Config).

- 237/348 -©2022

8.3 GNSS Antennas

8.3 GNSS Antennas
8.3.1 Selecting a GNSS Antenna• Using a passive GNSS antenna is possible but not recommended. This requires a high RHCP antenna gain, good view of thesky, and a short matched/tuned 50 Ω input impedance line. This option may be appropriate to minimize BOM costs.
• Best performance is achieved by using an active antenna with integrated LNA. The LNA gain must be >17dB for standard
GPS-INS use.
• For RTK and dual antenna (GPS compassing) use, the following characteristics are recommended: gain >26dB, multipath
signal rejection, better signal to noise ratio, and improved carrier phase linearity.
• Antennas with integrated SAW filter may be necessary to reject interference from near frequencies or harmonic signals, suchas wireless and LTE.
• For RTK and dual antenna applications we recommend dual feed (dual element) GNSS antennas

8.3.2 GNSS Antenna Integration Considerations
GNSS Antenna Ground PlaneA GNSS antenna ground plane blocks multipath signals, creating a shadow area for the antenna to hide in. The ground plane isacting as an RF blocking device. It is made of any material that attenuates (or totally blocks or reflects) RF signals. It creates a
shadow area for the antenna to hide in. That shadow is a cone above the ground plane. Any signals that come down from thesatellites and are bouncing back upward from the earth can’t get to the antenna. Only signals coming directly from above can getto the antenna. The distance of the physical antenna above the ground plane changes the shape of the RF blocked shadow area.
The signal gain on some antennas can be improved by increasing the ground plane size up to a given size. Beyond that given size
the antenna gain is not affected much.
A ground plane width of 8 to 12 cm is typically large enough for most applications.
HELPFUL LINKS:

u-Blox: RF design considerations for GNSS receivers Application Note
Taoglas: GPS Patch Integration Application Noteelectronics.stackexchange.com: How big a ground plane does a GPS antenna need?

8.3.3 Recommended GNSS Components
The following components are optional components that may be used with the μINS, μAHRS, and μIMU.
Frequencies: GPS (L1), GLONASS (G1), Beidou (B1), and Galileo (E1).
Recommended for RTK indicates the GNSS antenna will have better performance for applications using RTK and dual GNSS
antenna (GNSS compassing).
For multi-frequency GNSS antennas, see Purchasing the ZED-F9.

- 238/348 -©2022

8.3.3 Recommended GNSS Components

Enclosed GNSS Antennas
The following GNSS antennas have an environmental case rated at IP67 or better.

- 239/348 -©2022

8.3.3 Recommended GNSS Components

Manufacturer

Description

Part Number
Tallysman

Magnet Mount, L1/G1/B1/E1 freq.,

TW4722Dual-feed, 26dB LNA, SAW filter, SMA
3m cable, Recommended for RTK

TallysmanThrough-Hole Mount, L1/G1/B1/E1

TW2712

freq., Dual-feed, 26dB LNA, SAW filter,
SMA 3m cable, Recommended for
RTK

TallysmanThrough-Hole Mount, L1/G1/E1/B1

TW3712

freq., Dual-feed, 26dB LNA, SAW filter,
SMA 3m cable, Recommended for
RTK

TaoglasMagnet Mount, L1/G1 freq., 29dB

Limited

LNA, SAW Filter, SMA 3m cable.

AA.162.301111

TaoglasMagnet Mount, L1/G1/E1/B1 freq.,

Limited

29dB LNA, SAW Filter, SMA 3m cable.

AA.171.301111

Abracon LLC

Magnet Mount, L1/G1 freq., 30dB

APAMPG-130

LNA, SAW Filter, SMA 3m cable.

- 240/348 -©2022

8.3.3 Recommended GNSS Components

Manufacturer

Description

Part Number

OEM GNSS Antennas
These non-enclosed embedded antennas have exposed PCA with no environmental protection. OEM antennas are easily detunedby the local environment (caused by mounting inside enclosures). We recommend contacting the manufacturer for custom tuning
services for optimized integration into OEM end-user modules.
Manufacturer

Description

Part Number
Tallysman

Dual-feed, L1/G1/B1/E1 freq., 1-3 dB

TW2708axial ratio, 28dB LNA and SAW Filter,
56mm dia. x 7.6mm, RG174 cable,
Recommended for RTK

Tallysman

Dual-feed, L1/G1/B1/E1 freq., 28dB

TW1722

LNA and SAW Filter, 35mm dia. x6mm, RG174 cable, Recommended
for RTK

Taoglas Limited

L1/G1/B1/E1 freq.. 28dB LNA and

AGGBP.25A.

SAW Filter, 25x25mm, U.FL 6cm cable

07.0060A- 241/348 -©2022

8.3.3 Recommended GNSS Components

Related GNSS Parts
Manufacturer

Description

Part Number
GNSS Backup Battery

Seiko Instruments

Coin, 6.8mm 3V Lithium Battery Rechargeable (Secondary) 3mAh

MS621T-FL11E
GNSS Backup Battery

Panasonic

Coin, 6.8mm 3V Lithium Battery Rechargeable (Secondary) 3.4mAh

ML-614S/FN- 242/348 -©2022

8.4 GNSS Satellite Constellations

8.4 GNSS Satellite Constellations
The uINS supports onboard M8 and external (off-board) uBlox GNSS receivers. These receivers use multiple GNSS constellationsin the global positioning solution.
The M8 receiver supports use of 3 concurrent constellations and the ZED-F9 receivers support 4 concurrent constellations (i.e.
GPS, GLONASS, Galileo, and BeiDou).

8.4.1 Constellation Selection
The satellite constellations can be enabled or disabled by setting the corresponding enable bits in
DID_FLASH_CONFIG.gnssSatSigConst as defined by eGnssSatSigConst in data_sets.h. The following are commonly used andrecommended configuration groups.
// 3 constellations is supported by uINS onboard M8 reciever.
// (SBAS is not considered a constellation)
DID_FLASH_CONFIG.gnssSatSigConst = 0x133F// GPS/QZSS, Galileo, GLONASS, SBAS
DID_FLASH_CONFIG.gnssSatSigConst = 0x10FF// GPS/QZSS, Galileo, BeiDou, SBAS
DID_FLASH_CONFIG.gnssSatSigConst = 0x130F// GPS/QZSS, GLONASS, SBAS// 4 constellations is supported by ZED-F9 receiver (not uINS onboard M8 receiver).
DID_FLASH_CONFIG.gnssSatSigConst = 0x13FF// GPS/QZSS, Galileo, GLONASS, BeiDou, SBAS

- 243/348 -©2022

8.5 RTK Positioning

8.5 RTK Positioning
8.5.1 RTK Precision Positioning
Overview
Real Time Kinematic (RTK) is a precision satellite positioning technique which utilizes a base station to transmit position
corrections to a receiver. The Inertial Sense RTK solution provides centimeter level position accuracy.
To use RTK, a base station, arover (receiver), and a method to send corrections from the base to the rover are required.

See the multi-band GNSS section for details on using our multi-frequency ZED-F9 GNSS system.

- 244/348 -©2022

8.5.1 RTK Precision Positioning

RTK Hardware Setup
BASE STATION OPTIONS

Any of the following devices can be used as a RTK base station. All Inertial Sense base station options require a GPS antenna.
• Inertial Sense EVB 2 - Sends corrections using the onboard 915 MHz radio, the onboard WiFi module, either serial port, orUSB.
• Inertial Sense µINS module, EVB 1 or Rugged - Sends corrections on either serial port or USB that can then be forwarded
to a rover using a communication method of choice.
• 3rd Party Base Station - e.g. Emlid Reach Receiver.
• Public NTRIP Caster - e.g. CORS Network.
ROVER OPTIONS

The following configurations can be used for the RTK rover:• Inertial Sense EVB 2 - Can receive corrections via the onboard 915 MHz radio, onboard WiFi module, serial ports, or USB.
• Inertial Sense µINS module, EVB 1 or Rugged - Can receive corrections via either serial port or USB.
BASE TO ROVER COMMUNICATION

1. Direct Serial - Using USB, RS232, RS422/485, or TTL to pass corrections from Base to Rover.
2. Radio Link - Inertial Sense EVB 2 uses the Digi Xbee Pro SX module to send RTK corrections. Other communication methods suchas Bluetooth may also work for the chosen application.
3. NTRIP - Transmits RTK correction data over the Internet. To receive messages with NTRIP, the user must supply a URL, port
number, and mount point . Often a username and password are also required.
4. TCP/IP - A protocol for communicating directly between computers. In order to receive messages using TCP/IP, an address (IPAddress or DNS) must be suppled to the Base where the corrections will be transmitted.

How to Know RTK is Working
USING THE EVALTOOL

1. Connect the µINS Rover to a computer with the EvalTool running. Open the comport for the unit in the Settings > Serial Ports.
2. Navigate to Settings > RTK.
3. Under the Status section, RTK functionality can be verified in 3 ways:• Status field will show Single. Over the course of several minutes this status will change to Float then Fix.
• The Differential Age will show a timestamp that increments and resets back to zero about every second. This shows that the Roveris receiving Base messages.
• The Accuracy: H, V will show a large number at first. This number will decrease over time as the system acquires RTK Fix. Once in
Fix, this number will average at +- 0.08, 0.14 m.

- 245/348 -©2022

8.5.1 RTK Precision Positioning

USING THE CLTOOL

1. Connect the µINS Rover to a computer with the CLTool running.
2. Include the argument -msgPresetPPD in the CLTool command.
3. Observe the DID_GPS_RTK_NAV message, Status: 0x******** (Single) over the course of several minutes this will change to (Float)then (Fix).

RTK Fix Status
LED INDICATORSThe LEDs on the IMX will indicate RTK fix status.
LED Behavior

StatusDescription

3D Fix, RTK Float

Allows improved accuracy up to ~1m

RTK Fix

Allows increased accuracy up to ~3cm

RTK POSITIONING VALID FLAGSThe RTK precision positioning fix status can be identified using the valid bit in the INS and GPS status flags.
// INS status
INS_STATUS_NAV_FIX_STATUS(DID_INS_1.insStatus) == GPS_NAV_FIX_POSITIONING_RTK_FIX// GPS status
DID_GPS1_POS.status & GPS_STATUS_FLAGS_GPS1_RTK_POSITION_VALID

RTK precision positioning fix is indicated is indicated when the RTK-Pos radio button turns purple in the EvalTool INS tab.

- 246/348 -©2022

8.5.1 RTK Precision Positioning

PROGRESS AND ACCURACY

The ambiguity resolution ratio, arRatio , is a metric that indicates progress of the solution that ranges from 0 to 999. Typicallyvalues above 3 indicate RTK fix progress.
DID_GPS1_RTK_POS_REL.arRatio// Ambiguity resolution ratio

The DID_GPS1_RTK_POS_REL status can be monitored in the EvalTool GPS tab.

RTK Base Messages
The IMX RTK solution accepts both RTCM3 and uBlox raw GNSS base correction messages. See the RTK Base or NTRIP pages
for details on using base stations.

- 247/348 -©2022

8.5.2 Rover Setup

8.5.2 Rover Setup
System Configuration
A µINS must be configured as a Rover to receive RTK Base messages. This can be done through the EvalTool or the CLTool byenabling "Rover Mode".
EvalTool

1. Navigate to Settings > GPS > Rover > RTK.
2. Change the first drop-down menu to "Positioning (GPS1)", or one of the F9P options depending on the hardware setup.
3. Press Accept.
4. Verify the RTKCfgBits was automatically set correctly to any one of the rover modes listed in our binary communications protocol
page.
CLToolUse the -flashConfig=rtkCfgBits=0x01 argument to configure the unit as rover where 0x01 can be any one of the rover modes
listed in our binary communications protocol page.

Communications Setup
The IMX automatically parses data that arrives at any of the ports and recognizes base corrections data. Any communications
method that sends the base corrections to one of the ports is suitable. Several common methods are described below.
EVB2 RADIO
EvalTool

The EVB-2 radio can be configured by pressing the "CONFIG" tactile switch until the light next to it is blue. This enables theradio and configures the radio settings. See the Configurations and EVB-2 Connections sections of the EVB-2 documentation.
1. Under "IMX Parameters" section verify the following:• Check the Baud Rate for the serial port of the radio ( ser0BaudRate or ser1BaudRate ). This should match the Baud Rate of the radio.
The Digi Xbee Pro SX module on the EVB2 runs at 115200 baud.
2. Navigate to Data Sets > DID_EVB_FLASH_CFG• Change cbPreset - This should be set to 0x3 to enable the Digi Xbee Pro SX module.
• Change radioPID - Radio Preamble ID. Should be the same number used as the Base radio. ( 0x0 to 0x9 )• Change radioNID - Radio Network ID. Should be the same number used as the Base radio. ( 0x0 to 0x7FFF )• Change radioPowerLevel - Used to adjust the radio output power level. (0=20dbm, 1=27dbm, and 2=30dbm)
3. Reset the EVB2 and Rover radio setup is complete.
For more information on DID_EVB_FLASH_CFG see DID-descriptions.
NTRIP CLIENT

For the Rover to receive messages from an NTRIP Caster, it must be connected to an interface with internet access (e.g.
computer).

- 248/348 -©2022

8.5.2 Rover Setup

EvalTool

Follow the proceeding steps in order to set up the Rover to receive messages through NTRIP:
1. Navigate to Settings > RTK > Rover Mode.
2. Change the first drop-down menu to "RTK - GPS1"
3. Under Correction Input:• Type = NTRIP• Address:Port = : Ex: rtgpsout.unavco.org:2101• Username/Password = Enter the Username and Password to the account used as the NTRIP Caster. Some Casters do not require
this field.
• Format = RTCM3 or UBLOX• Mount Point = Specify the mount point of the caster. Ex: P016_RTCM3 4. Press Apply.
CLToolWith the Rover µINS connected to the computer, use the -rover argument when running the CLTool executable:• -rover=TCP: Set the type to "TCP".
• PROTOCOL: Set the protocol to "RTCM3" or "UBLOX". UBLOX requires more bandwidth and is not available from NTRIP casters.
• URL: The URL for the NTRIP Caster.
• Port: The port number will be provided by the NTRIP Caster.
• MountPoint: The mount point specifies which base station the corrections come from. This number will be provided by the
NTRIP Caster.
• Username:Password The username and password for the account at the given URL (Not required by some public NTRIP casters).
Example:cltool.exe -c COM10 -flashConfig=rtkCfgBits=0x01 -baud=57600 -rover=TCP:RTCM3:rtgpsout.unavco.org:2101:P016_RTCM3:username:password

TCP/IPFor the Rover to receive messages from a Base Station on a local network, it must be connected to an interface with network
access (e.g. computer).
EvalTool

Follow these steps:
1. Navigate to Settings > GPS1
2. Under Correction Input:• Type = TCP• Address:Port = : e.g. 192.168.1.145:2001• Change Format to "ublox" or "RTCM3". Ublox requires more bandwidth but will result in better performance.
3. Press Accept.

Hint
For serial ports, view available comport numbers in the Settings tab of the EvalTool.

- 249/348 -©2022

8.5.2 Rover Setup

CLToolWith the µINS Rover connected to the computer, enter the -rover argument when running the CLTool executable:• -rover=TCP: Set the type to "TCP".
• RTCM3 Set the message type to "RTCM3" or "UBLOX". UBLOX requires more bandwidth and may be unavailable from some
NTRIP Casters.
• IP_Address The IP Address of the Base Station to receive messages from.
• Port You may choose any number here. This should match the port number used for the Base Station.
Example: cltool.exe -c COM10 -flashConfig=rtkCfgBits=0x01 -baud=57600 -rover=RTCM3:100.100.1.100:7777
EVB2 WIFI

Using the EVB2 WiFi module to connect to the TCP/IP Base. EVB2 can save up to 3 Networks information. (Wifi[0], Wifi[1],Wifi[2]) Follow these steps using the EvalTool:
1. Under "IMX Parameters" section verify the following:• Verify the RTKCfgBits was automatically set to 0x00000001
2. Navigate to Data Sets > DID_EVB_FLASH_CFG• Change cbPreset - This should be set to 0x4 to enable the WiFi module.
• Change wifi[0].ssid - WiFi [0] Service Set Identifier or network name.
• Change wifi[0].psk - WiFi [0] Pre-Shared Key authentication or network password.
• Change server[0].ipAddr - server [0] IP address.
• Change server[0].port - server [0] port.
3. Reset the EVB2 and Rover WiFi setup is complete.

- 250/348 -©2022

8.5.3 Base Setup

8.5.3 Base Setup
RTK Base Configuration

Note
If using an NTRIP service or 3rd Party Base Station instead of your own base station, please skip this page and see the NTRIP
page or reference the setup instructions for the 3rd Party Base Station. NTRIP services do not require additional setup.

An essential part of an RTK system is the Base Station which supplies correction messages from a known, surveyed location to
the RTK Rover. The µINS Rover supports receiving RTCM3 and UBLOX correction messages.

Surveying In Base Position

Important- 251/348 -©2022

8.5.3 Base Setup

Accuracy of the base position directly effects the rover absolute position accuracy. It is critical that the base position be surveyed
in for rover absolute position accuracy.
The base survey cannot happen at the same time as base correction output messages are enabled. If a survey is started the basecorrection output will automatically be disabled.
The base position is stored in DID_FLASH_CONFIG.reflla and transmitted to the rover during RTK operation. The following steps
outline how to survey in the base position.
1. Mount base station in fixed location - The location should not change during or following a survey.
2. Set survey-in parameters - This step can either be done using the EvalTool or programmatically using the data set( DID_SURVEY_IN ).
EvalTool

1. Navigate to Settings > RTK > Base Mode.
2. In the "Survey In" section select one of the States:• Manual: Direct entry of base position.
• Average GPS 3D - Requires standard GPS 3D lock (non-RTK mode) for survey.*• Average RTK Float - Requires RTK float state for survey.*• Average RTK Fix - Requires RTK fix for survey.
*The average methods will not run if the minimum requirements are not met. The system will wait until the requirements are met
and then begin the survey.
3. Use the slider to select the Survey In runtime. Generally the longer the survey runs the more accurate the results will be.
4. Press the Start button.

Note
The current estimate of the survey is listed in the Position area above the Survey In section. If the survey completes successfully the
results stored in flash memory ( DID_FLASH_CONFIG.reflla ) which will only change if the survey is re-run.

Using DID_SURVEY_IN

1. The location of the base can be manually entered using ( DID_FLASH_CONFIG.RefLLA ) if location is known.
2. Set DID_SURVEY_IN.maxDurationSec - Maximum time in milliseconds the survey will run. This is ignored if it is set to 0.
3. Set DID_SURVEY_IN.minAccuracy - Minimum horizontal accuracy in meters for survey to complete before maxDuration. This is ignored
if it is set to 0.
4. Set ( DID_SURVEY_IN.state ) to begin the survey according to the desired survey State:• 2 = Average GPS 3D - Requires standard GPS 3D lock (non-RTK mode) or better for survey.*• 3 = Average RTK Float - Requires RTK float fix or better for survey.*• 4 = Average RTK Fix - Requires RTK fix for survey.
*The average methods will not run if the minimum requirements are not met. The system will wait until the requirements are met
and then begin the survey.

Communications Setup
RADIO

The Base IMX must be configured to stream base corrections to the radio so it can be broadcast to the rover.
EvalTool

1. Open the COM port for the µINS under Settings > Serial Ports.

- 252/348 -©2022

8.5.3 Base Setup

2. Navigate to Settings > RTK > Base Mode.
3. Under "Correction Output", find the fields for serial ports 0, 1, or USB. Select the serial port from which the corrections will betransmitted. This port must also be connected to the radio. Choose one of the options listed below. Leave the unused serial port off.
• "GPS1 - RTCM3": Output standard RTCM3 messages.
• "GPS1 - uBlox": Output uBlox messages. This will provide more accuracy but requires significantly more bandwidth.
4. Change the "Data Rate(ms)" field. This determines how many milliseconds pass between message outputs (e.g. Data Rate(ms) =1,000 means one message/second). It is usually best to match the startupGPSDtMs value found in DID_FLASH_CONFIG.
5. In the "Position" section, a the Base Station position is required so that it can transmit accurate corrections. Please refer toSurveying In Base Position if the base station location is unknown.
6. Click Apply, and reset the µINS. The unit will now start up in Base Station mode. Verify the base station is working by looking inthe section labeled "Status". It will display the serial port of the radio and the message type. e.g. "SER1:UBX"
7. Navigate to Data Sets > DID_EVB_FLASH_CFG• Change cbPreset - This should be set to 0x3 to enable the Digi Xbee Pro SX module.
• Change radioPID - Radio Preamble ID. Should be the same number used as the Rover radio. ( 0x0 to 0x9 )• Change radioNID - Radio Network ID. Should be the same number used as the Rover radio. ( 0x0 to 0x7FFF )• Change radioPowerLevel - Used to adjust the radio output power level. (0 = 20dbm, 1 = 27dbm, and 2 = 30dbm)
8. Reset the EVB2 and Base radio setup is complete.
For more information on DID_EVB_FLASH_CFG see DID-descriptions.
CLToolThe RTK config bit must be set manually when using the CLTool. Use the following command line arguments when executing the
CLTool from a prompt/terminal.
• -c # Open the COM port of the µINS. Windows users will use the name of the COM port, e.g. COM7. Linux users must enter
the path to the correct COM port, e.g. /dev/ttyUSB0.
• -baud=# Set the baud rate for communications output (Replace # with baud rate number). This number will vary depending on
setup. For lower quality radios it maybe necessary to use a lower baud rate (ex: 57600).
• -flashConfig=rtkCfgBits=0x00 Configure the unit to cast Base corrections. For more configuration options see eRTKConfigBits
Example:cltool.exe -c COM29 -baud=57600 -flashConfig=rtkCfgBits=0x80

Warning
If the Base Station is not communicating properly, it maybe necessary to verify that the baud rate is set to match that of the radios
used. This rate varies depending on radio type.

TCP/IP SETUP
CLTool

It is required to manually set the RTK config bits in the CLTool. Passed these to the CLTool when run from the command prompt/
terminal.
• -c # Open the COM port of the µINS. Windows users will use the name of the COM port, e.g. COM7. Linux users must enter
the path to the correct COM port, e.g. /dev/ttyUSB0.
• -baud=# Set the baud rate for communications output (Replace # with baud rate number).
• `-flashConfig=rtkCfgBits=0x00 Configure the unit to cast Base corrections. For more configuration options see eRTKConfigBits• -base=:# Create the port over which corrections will be transmitted. Choose any unused port number.

- 253/348 -©2022

8.5.3 Base Setup

Example:cltool.exe -c COM29 -baud=921600 -flashConfig=rtkCfgBits=0x10 -base=:7777

Important
If the console displays the error "Failed to open port at COMx", reset the device immediately after attempting to change the baudrate in the CLTool.

- 254/348 -©2022

8.5.4 NTRIP

8.5.4 NTRIP
Networked Transport of RTCM via internet protocol, or NTRIP, is an open standard protocol for streaming differential data overthe internet in accordance with specifications published by RTCM. There are three major parts to the NTRIP system: The NTRIP
client, the NTRIP server, and the NTRIP caster:
1. The NTRIP server is a PC or on-board computer running NTRIP server software communicating directly with a GNSS reference
station.
2. The NTRIP caster is an HTTP server which receives streaming RTCM data from one or more NTRIP servers and in turn streams the
RTCM data to one or more NTRIP clients via the internet.
3. The NTRIP client receives streaming RTCM data from the NTRIP caster to apply as real-time corrections to a GNSS receiver.

The EvalTool/CLTool software applications provide NTRIP client functionality to be used with the IMX RTK rover. Typically an
EvalTool NTRIP client connects over the internet to an NTRIP service provider. The EvalTool/CLTool NTRIP client then provides
the RTCM 3.3 corrections to the IMX and ZED-F9P rover connected over USB or serial. Virtual reference service (VRS) is also
supported by the EvalTool/CLTool NTRIP client.

Important
If using a virtual reference service (VRS), the rover must output the NMEA GGA message to return to the NTRIP caster. Without
this, the NTRIP caster will not provide correction information.

NTRIP RTCM3 Messages
The NTRIP server must provide the necessary subset of RTCM3 messages supported by the IMX-RTK. The following is an
example of compatible RTCM3 base output messages provided from a Trimble NTRIP RTK base station.

- 255/348 -©2022

8.5.4 NTRIPREQUIRED RTCM MESSAGES FOR RTK POSITIONING

Message Type

Description

RTCM 1005

Stationary RTK reference station ARP

RTCM 1074, 1075, or 1077

GPS MSM4, MSM5, or MSM7

RTCM 1084, 1085, or 1087

GLONASS MSM4, MSM5, or MSM7

RTCM 1094, 1095, or 1097

Galileo MSM4, MSM5, or MSM7

RTCM 1230

GLONASS code-phase biases- 256/348 -©2022

8.5.5 Using uBlox PointPerfect L-band Corrections

8.5.5 Using uBlox PointPerfect L-band Corrections
The IMX-5 can receive corrections from the uBlox D9S device, which provides L-band corrections through the uBlox PointPerfectsolution. PointPerfect IP-based corrections are currently not supported (L-band only)

Firmware update
L-band corrections requires a later version of F9P firmware. Use FW version HPG 1.32 from the F9P downloads page on theuBlox site.
To check your firmware version, follow these steps:
1. Open the Inertial Sense EvalTool
2. Navigate to the Data Sets tab.
3. Select DID_GPSx_VERSION
4. The firmware version is displayed in extension[1]. For Example, FWVER=HPG 1.12
To update the firmware on the F9P, follow these steps:
1. Open the Inertial Sense EvalTool
2. Navigate to the Data Sets tab. Select DID_SYS_CMD from the sidebar (see the image below)
3. Set command to 11 and invCommand to -12 to enable passthrough to GNSS1 (set 12 and -13 for GNSS2)
4. Close the serial port (Settings tab)
5. Open the device in uBlox u-center (we currently use u-center 22.07)
6. Update the firmware in u-center per u-blox instructions. Baudrate should be set to 921600.

Configuration of the F9P
By default, the IMX-5 module updates settings on the F9P at bootup. Currently the IMX:
• Configures frequencies and constellations to use in the solution• Changes the CFG-SPARTN setting to use L-band corrections. IP corrections are not currently supported through the IMX-5 due
to a difference in the protocol.
The IMX acts as a transparent pipe for some UBX messages. In the mode shown below, the IMX passes the following messages:• RXM-SPARTN (from F9P)
• RXM-SPARTNKEY (to/from F9P)
• RXM-PMP (to F9P)
• CFG-* (bidirectional)- 257/348 -©2022

8.5.5 Using uBlox PointPerfect L-band Corrections

For L-band, the messages are sent as UBX-RXM-PMP messages. No additional configuration on the IMX is needed to switch
between these messages and RTCM3, either will work. We have not tested using them together, contact uBlox if you areconsidering this.
To set the SPARTNKEY message, use the u-center tool or send the proper message as specified in the HPG 1.32 manual to the
IMX. SPARTNKEY messages are passed through the IMX.
If you need to access additional settings on the F9P, you can use the serial passthrough mode used for firmware update, or there
are settings under the RTK Base tab that allow passthrough of all uBlox messages.
Corrections can be forwarded through the EvalTool using the Correction Input section of the tool. See the above screenshot foran example configuration.

- 258/348 -©2022

8.5.6 Using uBlox SBAS corrections

8.5.6 Using uBlox SBAS corrections
The uBlox F9P receivers can be configured to enable the SBAS corrections constelations

Firmware update
SBAS corrections require a later version of F9P firmware. Use FW version HPG 1.32 from the F9P downloads page on the uBlox
site. To update the firmware on the F9P, follow these steps:
1. Open the Inertial Sense EvalTool
2. Navigate to the Data Sets tab. Open DID_SYS_CMD from the sidebar (see the image below)
3. Set command to 11 and invCommand to -12 to enable passthrough to GNSS1 (set 12 and -13 for GNSS2)
4. Close the serial port (Settings tab)
5. Open the device in uBlox u-center (u-center 22.07)
6. Update the firmware in u-center per u-blox instructions. Baudrate should be set to 921600.

Configuration of the F9P
With the uBlox 1.32 firmware installed on the F9P SBAS can be enabled using the standard constelation selection methods
described in the GNSS Constelations page.

- 259/348 -©2022

8.6 Dual GNSS RTK Compassing

8.6 Dual GNSS RTK Compassing
8.6.1 Overview
RTK Compassing (Dual GNSS) is a system that determines heading by use of two GNSS receivers and antennas. It replaces theneed for magnetometers which can be problematic in the presence of ferrous materials (e.g. steel) and EMI generating circuits(e.g. electric motors and drivers).
See the multi-band dual GNSS section for details on using our multi-frequency dual ZED-F9 GNSS system.

8.6.2 Heading Accuracy
The generalized heading accuracy for both the single-band (L1) and the dual GNSS multi-band systems under ideal conditions isshown in the following plot.

Recommenced Minimum Baseline
The recommended minimum baseline (distance between dual GNSS antennas) is 0.3 meters for single-band (L1) GNSS
compassing and 0.25 meters for multi-band ZED-F9 GNSS compassing. The solution can operate at shorter baseline distances
but is less robust and more susceptible to getting caught in a local minimum which may not converge to the correct heading.

- 260/348 -©2022

8.6.3 Antenna Orientation

8.6.3 Antenna Orientation
Important
It is recommended that both GNSS antennas be identical and have the same physical orientation relative to each other (i.e. theantenna cable should exit in the same direction on both antennas). This will ensure best RF phase center alignment and heading
accuracy. The actual RF phase center is often offset from the physical center of the antenna case.

Mismatch- 261/348 -©2022

8.6.4 Rugged GNSS Antenna Ports

8.6.4 Rugged GNSS Antenna Ports

On the Rugged IMX, the MMCX port A is for GPS1 and MMXC port B is GPS2. These port labels are changed to 1 and 2 onnewer Rugged units.

8.6.5 Dual Antenna Locations
The location for both GPS antennae must be correctly specified by the user in the DID_FLASH_CONFIG variables within 1 cm
accuracy:
DID_FLASH_CONFIG.gps1AntOffset[X,Y,Z]
DID_FLASH_CONFIG.gps2AntOffset[X,Y,Z]

These values describe the distance of each GPS antenna from the IMX Sensor Frame origin in the direction of the Sensor Frameaxes. The Sensor Frame is defined using DID_FLASH_CONFIG.sensorConfig.

Example Antennae Configurations
The following are examples that illustrate what the GPS antenna offsets should be for two different antenna configurations.

- 262/348 -©2022

8.6.5 Dual Antenna Locations

DRONE

µINS
GPS 1
AntennaX

Y1

DID_FLASH_CONFIG.gps1AntOffset[0] = 0.0
DID_FLASH_CONFIG.gps2AntOffset[1] = -0.3
DID_FLASH_CONFIG.gps2AntOffset[2] = 0.0
DID_FLASH_CONFIG.gps2AntOffset[0] =DID_FLASH_CONFIG.gps2AntOffset[1] =DID_FLASH_CONFIG.gps2AntOffset[2] =

Y
Y2

GPS 2
Antenna(negative direction of Y axis)

0.0
0.3
0.0

- 263/348 -©2022

8.6.5 Dual Antenna Locations

AUTOMOBILE

µINS
X

Y
X1
Y1
GPS 1
Antenna

Y2

X2

GPS 2
Antenna

DID_FLASH_CONFIG.gps1AntOffsetX = -0.5
DID_FLASH_CONFIG.gps1AntOffsetY = 0.5
DID_FLASH_CONFIG.gps1AntOffsetZ = -0.5

(negative direction of X axis)

DID_FLASH_CONFIG.gps2AntOffsetX = -1.5
DID_FLASH_CONFIG.gps2AntOffsetY = 0.5
DID_FLASH_CONFIG.gps2AntOffsetZ = -0.5

(negative direction of X axis)(negative direction of Z axis, above IMX)

(negative direction of Z axis, above IMX)

- 264/348 -©2022

8.6.6 Setup

GPS Antenna Ports
The following table explains how ports A and B on the Rugged IMX map to GPS antennas 1 and 2.
Ports

Rugged IMX

IMX Module and EVB-2

GPS 1 antenna port

A1

GPS 2 antenna port

B2

8.6.6 Setup
Step 1 - Specify Offsets for Both Antennae
Refer to the Dual Antenna Locations section for a description of the GPS antenna offset.
DID_FLASH_CONFIG.gps1AntOffsetX = ?
DID_FLASH_CONFIG.gps1AntOffsetY = ?
DID_FLASH_CONFIG.gps1AntOffsetZ = ?
DID_FLASH_CONFIG.gps2AntOffsetX = ?
DID_FLASH_CONFIG.gps2AntOffsetY = ?
DID_FLASH_CONFIG.gps2AntOffsetZ = ?

Using EvalTool - select Data Sets -> DID_FLASH_CONFIG and set gps1AntOffset[X,Y,Z] and gps2AntOffset[X,Y,Z] with the GPS
antenna offsets.
Using CLTool - run the CLTool using the following options replacing the [OFFSET] with the GPS antenna offsets.
-flashconfig=gps1AntOffsetX=[OFFSET]-flashconfig=gps1AntOffsetY=[OFFSET]-flashconfig=gps1AntOffsetZ=[OFFSET]-flashconfig=gps2AntOffsetX=[OFFSET]-flashconfig=gps2AntOffsetY=[OFFSET]-flashconfig=gps2AntOffsetZ=[OFFSET]

Step 2 - Enable GPS Dual Antenna
Set the RTK_CFG_BITS_COMPASSING (0x00000008) bit of RTKCfgBits.
DID_FLASH_CONFIG.RTKCfgBits |= RTK_CFG_BITS_COMPASSING// |= 0x00000008

Using EvalTool - go to Settings -> RTK -> Rover Mode , set the dropdown menu to GPS Compassing , and press the Apply button.
Using CLTool - run the CLTool using the -flashconfig=RTKCfgBits=0x8 option to enable GPS Dual Antenna.

8.6.7 RTK Compassing Fix Status
INS and GPS Status Flags
The RTK compassing fix status can be identified using the valid bit in the INS and GPS status flags.
DID_INS_1.insStatus & INS_STATUS_RTK_COMPASSING_VALID
DID_GPS1_POS.status & GPS_STATUS_FLAGS_GPS2_RTK_COMPASS_VALID// INS status// GPS status

RTK compassing fix is indicated when the RTK-Cmp radio button turns purple in the EvalTool INS tab.

- 265/348 -©2022

8.6.8 Stationary Application

Progress and Accuracy
The ambiguity resolution ratio, arRatio , is a metric that indicates progress of the solution that ranges from 0 to 999. Typicallyvalues above 3 indicate RTK fix progress. The base to rover heading accuracy indicates how much error is in the base to roverheading (RTK compassing heading).
DID_GPS1_RTK_CMP_REL.arRatio
DID_GPS1_RTK_CMP_REL.baseToRoverHeadingAcc// Ambiguity resolution ratio// (rad) RTK compassing accuracy

The DID_GPS1_RTK_CMP_REL status can be monitored in the EvalTool GPS tab.

8.6.8 Stationary Application
For RTK compassing stationary application, enabling the STATIONARY INS dynamic model (DID_FLASH_CONFIG.dynamicModel= 2) is recommended to reduce heading noise and drift. This will reduce heading error during RTK compassing fix or loss of fix.
See INS-GNSS Dynamic Model and Zero Motion Command for details.

- 266/348 -©2022

9. Dead Reckoning

9. Dead Reckoning
9.1 Ground Vehicle Dead Reckoning
9.1.1 Overview
The IMX inertial navigation integrates IMU data to dead reckon (estimate position and velocity) when GPS position fix is notavailable. The amount of position error during dead reckoning can vary based on several factors including system runtime,
motion experienced, and sensor bias stability.
Knowledge about the vehicle's kinematic constraints is applied to reduce drift and improve position estimation.

9.1.2 Installation
Important
It is critical to ensure the IMX remains fixed relative to the vehicle. Any shift or change in the IMX location relative to the vehicle will
result in degraded or inaccurate dead reckoning solution.

Important
Heavy vibrations can degrade the IMX measurements and dead reckoning solution.

1. Mount the IMX and GNSS antenna at fixed locations on the vehicle.
2. Set the GPS antenna offsets relative to the IMX origin in meters. EvalTool > Data Sets > DID_FLASH_CONFIG > gps1AntOffsetX/Y/Z.

Enabling
Dead reckoning is enabled by setting the DID_FLASH_CONFIG.dynamicModel to 4 for ground vehicles. This is done automaticallyduring Learning Mode and stored to flash memory.

Learning Mode
Learning mode is be used following installation or any change in the IMX position relative to the vehicle. Learning is used toestimate the vehicle kinematic calibration which is used during normal operation.
LEARNING MODE INSTRUCTIONS

1. Start learning mode.
2. Drive with sufficient motion for learning. This is identified with the EvalTool GV: Cal indicator in the INS tab turns GREEN( DID_GROUND_VEHICLE.status & GV_STATUS_LEARNING_CONVERGED is not zero). Either of the following patterns is typically adequate.
• At least 200 meters straight, 5 left turns (+90 degrees) and 5 right turns• Three figure eight patterns.
3. Stop learning and save kinematic calibration to flash memory.

- 267/348 -©2022

9.1.3 Examples

Using the EvalTool

From the EvalTool INS tab:
1. Press the GV: button to reveal the ground vehicle options.
2. Press the Start button to clear and start learning.
3. Press the Stop button to stop learning and save kinematic calibration to flash memory.
Using the DID_GROUND_VEHICLE Message

1. Enable learning mode by setting the DID_GROUND_VEHICLE.mode to any of the following commands. The DID_GROUND_VEHICLE.mode value
will toggle to 1 indicating the system is in learning mode and 0 to indicate learning mode is off.
2 "Start" - Start with user supplied values in the DID_GROUND_VEHICLE.transform and enable learning mode.
3 "Resume" - Start with the existing calibration and enable learning mode.
4 "Clear & Start" - Set transform to zero and start with aggressive learning mode. This is the same as the "Start" button in the
EvalTool INS tab.
5 "Stop & Save" - End learning mode and save kinematic calibration to flash memory.
2. Disable learning and save kinematic calibration to flash memory by setting DID_GROUND_VEHICLE.mode to 5.

9.1.3 Examples
Dead reckoning examples can be found here.

- 268/348 -©2022

9.1.3 Examples- 269/348 -©2022

9.2 IMX Dead Reckoning Examples

9.2 IMX Dead Reckoning Examples
Dead Reckoning is the process of calculating the current position of a moving object by using a previously determined position,or fix, and then incorporating estimations of speed, heading direction, and course over elapsed time. Knowledge about thevehicle's kinematic constraints (i.e. wheels on the ground) is applied to reduce drift and improve position estimation.
Inertial Sense has added dead reckoning capability to IMX to estimate position for extended periods of time during GNSS
outages. In this report RTK-GNSS is used.
The following are examples dead reckoning of a car test vehicle. No wheel sensors were used in these examples. The deadreckoning position is shown in the yellow "INS" line and GNSS position in the red "GNSS" line.

9.2.1 Parking Lot Simulated GNSS Outage
In this example GNSS outage was simulated by disabling GNSS fusion into the INS Kalman filter (EKF). This was done by setting
the Disable Fusion - GPS1 option found in the General settings of the EvalTool app. By disabling GPS fusion and keeping fix, we
can use the GNSS position as truth and compare it to the dead reckoning solution.
Dead reckoning duration: 30 seconds, 605 meters
Max position error: 2.5 meters, 0.4% drift- 270/348 -©2022

9.2.1 Parking Lot Simulated GNSS Outage

INS
GNSS
GNSS
FusionDisabled

5
4
3
2

1
8
7
6

Start
GNSS Fusion
Re-enabledEnd

In the drive the car starts and ends the drive at the bottom right corner of the image. The numbered path segments show theorder of travel. GPS fusion was disabled in the middle of path segment 5.

- 271/348 -©2022

9.2.2 Multi-Level Parking Garage

INS
GNSS
1

8

2.5 m Error
Start

GNSS Fusion
Re-enabledEnd

When GNSS fusion is re-enabled, error in the INS solution is removed and the INS position estimate jumps back onto the GNSS
position. There is 2.5m of error between the dead reckoning position and the GNSS position.

9.2.2 Multi-Level Parking Garage
In this example our test vehicle drove in and out of a parking garage. The drive consisted of starting outside with GNSS fix,
entering the garage (losing GNSS fix), driving up one level, parking, and then following the path back down and out of the
garage where GNSS fix was regained.
Dead reckoning duration: 105 seconds, 349 meters
Exit position error: ~2 meters, 0.6% drift- 272/348 -©2022

9.2.2 Multi-Level Parking Garage

INS
GNSS

Here we see outside parking lot where the test vehicle started and ended. GNSS fix was lost upon entry of the garage andregained several seconds after exiting the garage.

- 273/348 -©2022

9.2.2 Multi-Level Parking Garage

INS
GNSS

Enter Garage
GNSS Lost

End

Start

Exit Garage

Above is the top view of the parking garage. When inside the garage, the GNSS fix is lost shown by the red line erratic deviation.
The dead reckoning (INS) position shown by the yellow line matches the actual driven path.

- 274/348 -©2022

9.2.3 Conclusion

INS
GNSS
TRUTH

End

Enter Garage
GNSS Lost

GNSS Fix

Start

Exit Garage~2 m Error

GNSS fix was not regained until about 20 meters after exiting the garage, just prior to parking at the top right corner of theoutside parking lot. The actual position is shown by the orange truth dotted line. GNSS position is shown by the red line anddead reckoning by the yellow INS line. GNSS fix occurs when the red GNSS line jumps and joins the orange truth dotted line.
When exiting the garage, the position error was approximately 2 meters following 105 seconds of dead reckoning from GNSS
outage.

9.2.3 Conclusion
The IMX with dead reckoning and without wheel sensor can estimate position to within ~3m over 100 seconds of typical
automotive parking lot driving.

- 275/348 -©2022

10. General Configuration

10. General Configuration
10.1 Infield Calibration
The Infield Calibration provides a method to 1.) zero IMU biases and 2.) zero INS attitude to align the INS output frame with thevehicle frame. These steps can be run together or independently.

10.1.1 Zeroing IMU Bias
Zeroing IMU bias is a way to remove permanent offsets in the sensor output that may have occurred as a result of manufacturing
or high shock. The system must be completely stationary for accurate bias measurement. The current value for IMU biases
stored in flash memory is viewable in DID_INFIELD_CAL.imu when infield calibration is inactive and DID_INFIELD_CAL.sampleCount iszero.

Accelerometer Bias
In order to correct accelerometer bias on a given axis, that axis must be sampled while measuring full gravity. Thus, only theaccelerometer axes that are sampled while in the vertical direction can be corrected. In order to correct all accelerometer axes,
all three axes must be sampled while oriented vertically. The sample can be done while the axis is pointed up, down, or both up
and down for averaging.

Gyro Bias
All three axes of the gyros are sampled simultaneously, and the bias is stored in flash memory. The system must be completely
stationary for accurate bias measurement. The system does not need to be level to zero the gyro biases.

10.1.2 Zeroing INS Attitude
The Infield Calibration process can be used to align or level the INS output frame with the vehicle frame. This is done byobserving the X,Y,Z axes rotations necessary to level the orientation(s) sampled. Zeroing the INS attitude as part of the Infield
Calibration routine provides a optimal and highly accurate method for measuring the attitude while stationary by averaging raw
bias corrected accelerations.
Rotations cannot be computed for axes that are pointed vertically. For example, a single orientation sample with X and Y in thehorizontal plane and Z pointed down will only be able to produce an X,Y rotation, and the Z rotation will remain zero. To computeall three rotations for the X,Y,Z axes, the system must be sampled at least twice, once while level and once while on its side.
The infield calibration process is generally useful for only small angle INS rotations and is not intended for those larger than 15°
per axis. The user must set the INS rotation manually for larger rotations. The INS rotation is stored and accessed in
DID_FLASH_CONFIG.insRotation in flash memory.

Because the sampled orientations are averaged together, it is recommended to only sample orientations that are at true 90°
multiples of the vehicle frame.
The zero INS attitude feature assumes there are flat rigid surface(s) attached to the IMX about which the system can be leveled.
If the working surface is not level or additional precision is desired, each orientation sampled can have an additional sample
taken with ~180° yaw offset to cancel out tilt of the working surface.
If Infield Calibration is not adequate, the INS may be leveled or aligned manually.

- 276/348 -©2022

10.1.3 Infield Calibration Process

10.1.3 Infield Calibration Process
The following process can be used to used to improve the IMU calibration accuracy and also align or level the INS to the vehicle
frame.
1. Prepare Leveling Surface - Ensure the system is stable and stationary on a near-level surface with one of three axes in thevertical direction.
2. Initialize the Mode - Clear any prior samples and set the calibration mode by setting DID_INFIELD_CAL.state to one of thefollowing:
INFIELD_CAL_STATE_CMD_INIT_ZERO_IMU= 1, // Zero accel and gyro biases.
INFIELD_CAL_STATE_CMD_INIT_ZERO_GYRO= 2, // Zero only gyro biases.
INFIELD_CAL_STATE_CMD_INIT_ZERO_ACCEL= 3, // Zero only accel biases.
INFIELD_CAL_STATE_CMD_INIT_ZERO_ATTITUDE= 4, // Zero (level) INS attitude by adjusting INS rotation.
INFIELD_CAL_STATE_CMD_INIT_ZERO_ATTITUDE_IMU= 5, // Zero gyro and accel biases. Zero (level) INS attitude by adjusting INS rotation.
INFIELD_CAL_STATE_CMD_INIT_ZERO_ATTITUDE_GYRO = 6, // Zero only gyro biases. Zero (level) INS attitude by adjusting INS rotation.
INFIELD_CAL_STATE_CMD_INIT_ZERO_ATTITUDE_ACCEL = 7, // Zero only accel biases. Zero (level) INS attitude by adjusting INS rotation.
INFIELD_CAL_STATE_CMD_INIT_OPTION_DISABLE_MOTION_DETECT= 0x00010000, // Bitwise AND this with the above init commands to disable motion detection during
sampling (allow for more tolerant sampling).
INFIELD_CAL_STATE_CMD_INIT_OPTION_DISABLE_REQUIRE_VERTIAL = 0x00020000, // Bitwise AND this with the above init commands to disable vertical alignment
requirement for accelerometer bias calibration (allow for more tolerant sampling).

Zeroing accelerometer biases requires that any of the X,Y,Z axes be vertically aligned with gravity during sampling. This isindicated by bit INFIELD_CAL_STATUS_AXIS_NOT_VERTICAL = 0x01000000 in DID_INFIELD_CAL.status .
By default, the system must also be stationary without any movement during sampling. This is indicated by bit
INFIELD_CAL_STATUS_MOTION_DETECTED = 0x02000000 is set in DID_INFIELD_CAL.status . Motion detection can be disabled to make thesystem more tolerant during sampling. To do this, bitwise and INFIELD_CAL_STATE_CMD_INIT_OPTION_DISABLE_MOTION_DETECT = 0x00010000with the initialization command. As an example, the command to initialize INS alignment with zero IMU bias with motion detection
disabled is as follows:(INFIELD_CAL_STATE_CMD_INIT_ZERO_ATTITUDE_IMU | INFIELD_CAL_STATE_CMD_INIT_OPTION_DISABLE_MOTION_DETECT);
0x00010101 = (0x00000101 | 0x00010000);

3. Sample Orientation(s) - Initiate sampling of one or more orientations by setting DID_INFIELD_CAL.state to
INFIELD_CAL_STATE_CMD_START_SAMPLE = 8 . Sampling per orientation will take 5 seconds and completion is indicated when
DID_INFIELD_CAL.state switches to INFIELD_CAL_STATE_SAMPLING_WAITING_FOR_USER_INPUT = 50 .

• Sample Same Orientation w/ +180° Yaw - If the working surface is not level, two samples per orientation can be taken to cancelout the tilt of the working surface. Rotate the system approximately 180° in yaw (heading) and initiate the sampling a second time
for a given orientation.
• Sample Up to Six Orientations - The sampling process can be done for up to six orientations (X,Y,Z pointed up and down). Eachsample will be automatically associated with the corresponding vertical axis and direction. All orientations will be averaged
together for both the zero IMU bias and zero INS attitude.
4. Store IMU Bias and/or Align INS - Following sampling of the orientations, set DID_INFIELD_CAL.state to
INFIELD_CAL_STATE_CMD_SAVE_AND_FINISH = 9 to process and save the infield calibration to flash memory. The built-in test (BIT) will

run once following this to verify the newly adjusted calibration and DID_INFIELD_CAL.state will be set to
INFIELD_CAL_STATE_SAVED_AND_FINISHED .

EvalTool or CLTool for Infield Cal
The EvalTool IMU Settings tab provides a user interface to read and write the DID_INFIELD_CAL message.

- 277/348 -©2022

10.1.3 Infield Calibration Process

CLTOOL INFIELD CAL

The following options can be used with the CLTool to edit the infield calibration (DID_INFIELD_CAL).
cltool -c /dev/ttyS2 -edit DID_INFIELD_CAL

Below is an example of the CLTool edit view of the DID_INFIELD_CAL message.
$ Inertial Sense.

Connected.

Press CTRL-C to terminate.

Rx 13657(94) DID_INFIELD_CAL:
W up, S down0
calData[2].down.dev[1].acc[1]0calData[2].down.dev[1].acc[2]0calData[2].down.yaw
0calData[2].up.dev[0].acc[0]0calData[2].up.dev[0].acc[1]0calData[2].up.dev[0].acc[2]0calData[2].up.dev[1].acc[0]0calData[2].up.dev[1].acc[1]0calData[2].up.dev[1].acc[2]0calData[2].up.yaw
0.0398919582
imu[0].acc[0]0.000717461109
imu[0].acc[1]9.67872334
imu[0].acc[2]0.00583727891
imu[0].pqr[0]0.0135380113
imu[0].pqr[1]-0.00342554389
imu[0].pqr[2]0.0874974579
imu[1].acc[0]-0.167159081
imu[1].acc[1]9.67817783
imu[1].acc[2]-0.00111889921
imu[1].pqr[0]-0.00523020467
imu[1].pqr[1]0.00455262465
imu[1].pqr[2]0sampleTimeMs
50
state
0x00B01000 * status- 278/348 -©2022

10.2 Platform Configuration

10.2 Platform Configuration
The DID_FLASH_CONFIG.platformConfig allows for specification of the IMX carrier board type and configuration settings. This isimportant and helpful for configuring I/O specific to the platform (carrier board). Values for the Platform Config are specified in
the enum ePlatformConfig in the SDK data_sets.h.

10.2.1 Platform TypeThe platform config type can be set through the EvalTool General Settings and GPS Settings tabs. Setting the Platform Config
type through the EvalTool acts as a convenience preset that automatically sets the GPS source, type, and timepulse pin selection
for the selected platform.

10.2.2 I/O Presets
The pin assignments on the RUG-3 are software configurable using the PLATFORM_CFG_PRESET_MASK bits of the
DID_FLASH_CONFIG.platformConfig . The PLATFORM_CFG_TYPE must be set to one of the RUG-3 types to enable the I/O Presets

configuration on the RUG-3. The RUG-3 main connector pin numbers are listed in parenthesis in the I/O Preset.

- 279/348 -©2022

10.3 IMU INS GNSS Configuration

10.3 IMU INS GNSS Configuration
10.3.1 Translation
The IMX can be mounted and operated in any arbitrary orientation. It is often desirable and conventional to translate the IMX
output so that it is translated into the vehicle frame located at certain point for control and navigation of the vehicle. This is doneusing the Sensor Rotation, INS Rotation, and INS Offset parameters.
In most common applications, output is translated to the vehicle frame (X to the front, Y to the right, and Z down):• Sensor Rotation provides gross rotation of the IMU output in multiples of 90°.
• INS Rotation provides small angle alignment of the INS output.
• INS Offset shifts the location from the INS output.

Coordinate Frame RelationshipThe relationship between the Hardware Frame, Sensor Frame, and INS Output Frame are as follows.

The Hardware Frame and Sensor Frame are equivalent when the Sensor Rotation in DID_FLASH_CONFIG.sensorConfig is zero.
The Hardware Frame origin and Sensor Frame origin are always at the same location and may differ in direction according
to the Sensor Rotation in DID_FLASH_CONFIG.sensorConfig . The Sensor Frame and INS output Frame are equivalent when the
DID_FLASH_CONFIG.insRotation and DID_FLASH_CONFIG.insOffset are zero.

Sensor Rotation (Hardware Frame to Sensor Frame)
The Sensor Rotation is used to rotate the IMU and magnetometer output from the hardware frame to the sensor frame bymultiples of 90°. This is done using the SENSOR_CFG_SENSOR_ROTATION_MASK bits of the DID_FLASH_CONFIG.sensorConfig as defined inenum eSensorConfig . The Sensor Rotation is defined in X,Y,Z rotations about the corresponding axes and applied in the order of

Z,Y,X. This rotation is recommended for gross rotations.

- 280/348 -©2022

10.3.2 Infield Calibration

INS Rotation
The INS rotation is used to convert the INS output from the sensor frame to the vehicle frame. This is useful if the sensor frameand vehicle frame are not aligned. The actual INS rotation parameters are DID_FLASH_CONFIG.insRotation[3] (X, Y, Z) in radians.
The INS rotation values describes the rotation from the INS sensor frame to the intermediate frame in order of Z, Y, X.

INS Offset
The INS offset is used to shift the location of the INS output and is applied following the INS Rotation. This offset can be used tomove the IMX location from the origin of the sensor frame to any arbitrary location, often a control navigation point on thevehicle.

Manually Aligning the INS After Mounting
NOTE for use:
• The Infield Calibration process can be used instead of this process to automatically measure and align the INS with the vehicle
frame for INS rotations less than 15°.
• If using software release 1.8.4 or newer, we recommend using the DID_FLASH_CONFIG.sensorConfig to rotate the sensor frame by
90° to near level before following the steps below.
The following process uses the IMX to measure and correct for the IMX mounting angle.
1. Set DID_FLASH_CONFIG.insRotation to zero.
2. Set the sensor on the ground at various known orientations and record the INS quaternion output (DID_INS_2). Using the Euler
output (DID_INS_1) can be used if the pitch is less than 15°. It is recommended to use the EKF Zero Motion Command to ensure
the EKF bias estimation and attitude have stabilized quickly before measuring the INS attitude.
3. Find the difference between the known orientations and the measured INS orientations and average these differences together.
4. Negate this average difference and enter that into the DID_FLASH_CONFIG.insRotation . This value is in Euler, however it is OK for thisstep as this rotation should have just been converted from quaternion to Euler and will be converted back to quaternion on-board
for the runtime rotation.

10.3.2 Infield Calibration
The Infield Calibration provides a method to 1.) zero IMU biases and 2.) zero INS attitude to align the INS output frame with thevehicle frame. These steps can be run together or independently.

10.3.3 GNSS Antenna Offset
If the setup includes a significant distance (40cm or more) between the GPS antenna and the IMX central unit, enter a non-zerovalue for the GPS lever arm, DID_FLASH_CONFIG.gps1AntOffset (or DID_FLASH_CONFIG.gpsAnt2Offset ) X,Y,Z offset in meters from
Sensor Frame origin to GPS antenna. The Sensor Frame origin and Hardware Frame origin are always at the same location but
may differ in direction according to the Sensor Rotation.

10.3.4 IMU Sample and Navigation Periods
The IMU sample period is configured by setting DID_FLASH_CONFIG.startupImuDtMs in milliseconds. This parameter determines how
frequently the IMU is measured and data integrated into the DID_PIMU data. DID_FLASH_CONFIG.startupImuDtMs also automaticallysets the bandwidth of the IMU anti-aliasing filter to less than one half the Nyquist frequency (i.e. < 250 / startupImuDtMs).

- 281/348 -©2022

10.3.4 IMU Sample and Navigation Periods

IMU
The anti-aliasing filter
Low-Pass
bandwidth is automaticallyAnti-Aliasing Filter
set to less than half the
Nyquist frequency:

Parameter:
DID_FLASH_CONFIG.
startupImuDtMs
This parameter sets the
IMU sample period,
default of 1ms (1KHz).

< 250/
startupImuDtMs

Angular Rate
Linear Accel(@startupImuDtMs)

Coning andSculling Integrals
1𝑠

Derivative over Delta Theta
Integral period Delta Velocity(@startupNavDtMs
)

∆𝑢
∆𝑡

DID_IMU_RAW

DID_IMU

Parameter:
DID_FLASH_CONFIG.
startupNavDtMs
This parameter sets theConing and Sculling
integration period and
NAV filter update period.
Default is 4ms (250KHz)

DID_PIMU

Direct from IMU Low-Pass Filter
Anti-aliased moving average over(@startupNavDtMs)(@startupImuDtMs)
integration period with- nonoverlapping intervals.
(@startupNavDtMs)

The preintegrated IMU (PIMU) a.k.a. Coning and Sculling (delta theta, delta velocity) integrals serve as an anti-aliased moving
average of the IMU value. The DID_IMU is the derivative of the DID_PIMU value over a single integration period.

Navigation Update and Output Periods
The navigation filter output period should be set using the flash parameter DID_FLASH_CONFIG.startupNavDtMs . This value sets the
DID_SYS_PARAMS.navOutputDtMs and DID_SYS_PARAMS.navUpdateDtMs during startup of the IMX.

The navigation filter output period ( DID_SYS_PARAMS.navOutputDtMs ) determines the EKF output data rate, the maximum rate formessages DID_INS_1, DID_INS_2, and DID_INS_3.
The navigation filter update period ( DID_SYS_PARAMS.navUpdateDtMs ) controls the EKF update rate and sets the standard
integration period for the preintegrated IMU (PIMU) output. This parameter is automatically adjusted based on the value of
DID_SYS_PARAMS.navOutputDtMs and the amount of CPU available.

The following table lists the output and update period minimum limits for the IMX.
Operation Mode

IMX-5.0 Minimum

IMX-5.1, uINS-3 Minimum

Output Period / Update Period

Output Period / Update Period

INS (GPS enabled)

7 ms (142 Hz) / 14 ms

2 ms (500 Hz) / 4 ms

AHRS (GPS disabled)

5 ms (200 Hz) / 10 ms

2 ms (500 Hz) / 4 ms

VRS (GPS and4 ms (250 Hz) / 8 ms

2 ms (500 Hz) / 4 ms

magnetometer disabled)- 282/348 -©2022

10.3.5 INS-GNSS Dynamic Model

10.3.5 INS-GNSS Dynamic Model
The DID_FLASH_CONFIG.dynamicModel setting allows the user to adjust how the EKF behaves in different dynamic environments. All
values except for 2 (STATIONARY) and 8 (AIR <4g) are experimental. The user is encouraged to attempt to use different settings
to improve performance, however in most applications the default setting, 8: airborne <4g, will yield best performance.
The STATIONARY configuration (dynamicModel = 2) can be used to configure the EKF for static applications. It is a permanent
implementation of the Zero Motion Command which will reduce EKF drift under stationary conditions.

10.3.6 Disable Magnetometer and Barometer Updates
Magnetometer and barometer updates (fusion) into the INS and AHRS filter (Kalman filter) can be disabled by setting thefollowing bits in DID_FLASH_CONFIG.sysCfgBits .
Bit Name

Bit Value

Description

SYS_CFG_BITS_DISABLE_MAGNETOMETER_FUSION

0x00001000

Disable magnetometer fusion into EKF

SYS_CFG_BITS_DISABLE_BAROMETER_FUSION

0x00002000

Disable barometer fusion into EKF

These settings can be disabled using the General Settings tab of the EvalTool.

- 283/348 -©2022

10.3.7 Disable Zero Velocity Updates

10.3.7 Disable Zero Velocity Updates
Zero velocity updates (ZUPT) rely on GPS and/or wheel encoder data. In some cases there can be a slight lag/deviation whenstarting motion while simultaneously rotating. This is because GPS data is updated at 5 Hz and it takes a few samples to detectmotion after a period of no motion. When ZUPT is enabled, it acts as a virtual velocity sensor telling the system that its velocity is
zero. It may conflict briefly with GPS velocity observation when starting motion. If a slight lag at the beginning of motion is an
issue, ZUPT may be disabled. Generally it should be enabled (Default). It can be disabled using DID_FLASH_CONFIG.sysCfgBits orusing the General Settings tab of the EvalTool.

10.3.8 Disable Zero Angular Rate Updates
Zero angular rate updates (ZARU) rely on analysis of either IMU (gyro) data or wheel encoders when available. When angularmotion is very slow and no wheel encoders are available a zero angular rate may be mistakenly detected, which will lead to gyrobias estimation errors. In these cases it can be beneficial to disable ZARU if the applications has slow rotation rates(approximately below 3 deg/s). It is not encouraged to disable ZARU if there is no rotation or faster rotation. It can be disabledusing DID_FLASH_CONFIG.sysCfgBits or using the General Settings tab of the EvalTool.

- 284/348 -©2022

10.4 System Configuration

10.4 System Configuration
See the Binary Protocol page for descriptions of each flash configuration value and enumeration bit values.

10.4.1 Serial Port Baud Rates
UART standard baud rates available on the IMX are: 921600, 460800, 230400, 115200, 57600, 38400, 19200. When operating
within the standard baud rate range (<= 921600 bps), only these specific baud rates can be used. Non-standard high speed baudrates (>921600) listed in the following section allow for arbitary custom baud rates.

High Speed Baud Rates
Non-standard high speed UART baud rates (>921600 bps) can be set to arbitrary values up to 10 Mbps. Due to hardware
limitations, the applied baud rate will be rounded to the closest available baud rate and reported back via the
DID_FLASH_CONFIG.serXBaudRate parameter.

Baud Rate Configuration
The IMX baud rate can be manually set by changing the following flash configuration parameters:
Configuration

Description

DID_FLASH_CONFIG.ser0BaudRate

baud rate for IMX serial port 0

DID_FLASH_CONFIG.ser1BaudRate

baud rate for IMX serial port 1

DID_FLASH_CONFIG.ser2BaudRate

baud rate for IMX serial port 2

These parameters can be changed using the EvalTool or the CLTool. The following examples show how the EvalTool and CLtool
can be used to set the IMX serial port 1 baud rate to 460,800 bps.
EvalTool -> Data Sets -> DATA_FLASH_CONFIG.ser1BaudRate = 460800
cltool -c COM# -flashConfig=ser0BaudRate=460800- 285/348 -©2022

10.5 Time Synchronization

10.5 Time Synchronization
10.5.1 INS & GPS Timestamps
The IMX output messages are timestamped using GPS time-base because this time is known immediately following GPS signal
reception. Conversion from GPS time to UTC time requires knowledge of the number of leap seconds (GPS-UTC) offset. Thisvalue is received periodically (every 12.5 minutes) and is available in the DID_GPS1_POS and DID_GPS1_RTK_POS (gps_pos_t)
messages. GPS leap seconds is 18 seconds as of December 31, 2016 and will change in the future.
The original designers of GPS chose to express time and date as an integer week number (starting with the first full week inJanuary 1980) and a time of week (often abbreviated to TOW) expressed in seconds. Working with time/date in this form is easierfor digital systems than the more "conventional" year/month/day, hour/minute/second representation. Most GNSS receivers use
this representation internally and converting to a more "conventional form" externally.

GPS to UTC Time Conversion
UTC time is found by subtracting GPS leap seconds from the GPS time.

10.5.2 GPS Time Synchronization
Systems connected to the IMX can be time synchronized using the GPS PPS timepulse signal and any message containing GPS
time. The actual time of the GPS PPS timepulse signal is the same as any message with GPS time rounded down to the second.
The following pseudo code illustrates how this is done.
// GPS Time Synchronization - Find the difference between local time and GPS time:// 1. Sample your local time on the rising edge of the GPS PPS timepulse signal.
double ppsLocalTime = localTime();// 2. Read the GPS time from any message WITHIN ONE SECOND FOLLOWING the GPS PPS timepulse signal.
double gpsTime = readGpsMessageTime();// within one second after GPS PPS// 3. Find the difference between the GPS PPS local time and the GPS time rounded down to the//nearest second (443178.800 s down to 443178 s, or 443178800 ms down to 443178 s).
double localToGpsTimeTemp = ppsLocalTime - floor(gpsTime);// 4. Error check to ensure you have a consistent solution
static double localToGpsTimeLast;
double localToGpsTime;if (fabs(localToGpsTimeLast - localToGpsTimeTemp) < 0.002){
localToGpsTime = localToGpsTimeTemp;}
localToGpsTimeLast = localToGpsTimeTemp; // Update history// within 2ms// Local time can now be converted at anytime to GPS time using 'localToGpsTime' difference.
double currentGpsTime = localTime() + localToGpsTime;10.5.3 Using the Strobe Input Pins
The IMX has several strobe input pins which can be configured to cause the IMX to report both its internal time and fullnavigation solution at the moment when triggered.

Strobe I/O Events
Strobe input and output (I/O) events are used for time and data synchronization.

- 286/348 -©2022

10.5.3 Using the Strobe Input Pins

STROBE pins on the μIMU, μAHRS, and μINS Module - Top View

Strobe Input (Time Sync Input)
Strobe inputs are used to timestamp digital events observed on any of the pins labeled STROBE, e.g. camera shutter signals. A
STROBE input event occurs when the logic level of any STROBE pin is toggled. The transition direction can be set so that the
STROBE event triggers on a rising edge, or a falling edge. An internal 100K pull-up or pull-down resistor is enabled, dependingon the assertion direction. External pull-up or pull-down resistors are not necessary.
The STROBE input will trigger on the edge type specified. However, the minimum period between STROBE input pulses is 1 ms.
The measurement and timestamp resolution are both 1 ms.
The following pins can be used for STROBE input.
SignalModule Pin

EVB-1 Pin

Rugged Pin

EVB-2

G2

5

H2-4

12

H7-6

G5

9

H6-3

H7-9

G8

8

H6-6

H7-12

G9

10

Button "B"

H7-13

To use a pin as a Strobe Input pin, the I/O must be configured as a strobe input. Additionally, the triggering edge must be set
using the following bits in DID_FLASH_CONFIG.ioConfig .
Bit Name

Bit Value

Description

IO_CONFIG_STROBE_TRIGGER_LOW

0x00000000

Trigger strobe on falling edge

IO_CONFIG_STROBE_TRIGGER_HIGH

0x00000001

Trigger strobe on rising edge

Pushbutton “B” on the EVB asserts a logic low to G9 (pin 10) of the IMX and can be used to test the STROBE input functionality.
**Note: Holding pin 9 low at startup enables SPI which uses pins 5 and 8 making them unavailable to be used as Strobe Inputs. If
pin 9 is not held low, the internal pullup resistor holds it high at startup. This sets pins 5 and 8 as inputs which can be used as
Strobe Inputs.

- 287/348 -©2022

10.5.3 Using the Strobe Input Pins

A STROBE input event causes a timestamp message and INS2 message to be transmitted. The ASCII messages $PSTRB and$PINS2 messages are sent by default but can be disabled and replaced by the binary messages DID_STROBE_IN_TIME and DID_INS_2

if the RMC bit RMC_BITS_STROBE_IN_TIME is set for the given serial port.
Example:rmc_t rmc;
rmc.bits = RMC_BITS_STROBE_IN_TIME;
int messageSize = is_comm_set_data(comm, DID_RMC, sizeof(uint64_t), offsetof(rmc_t, bits), &rmc);
if (messageSize != serialPortWrite(serialPort, comm->buffer, messageSize)){printf("Failed to write save persistent message\r\n");}Table 2 - DID_STROBE_IN_TIME message transmitted following a SYNC input event.
Field

Type

Description

week

uint32_t

Weeks since January 6th, 1980

timeOfWeekMs

uint32_t

Time of week (since Sunday morning) in milliseconds, GMT.

pin

uint32_t

STROBE input pin

count

uint32_t

STROBE serial index number

The STROBE input event also causes the HDW_STATUS_STROBE_IN_EVENT (0x00000020) bit of the hdwStatus field in INS
output (DID_INS_1, DID_INS_2, DID_INS_3, and DID_INS_4) to be set, allowing users to identify strobe input events using the
INS output.
TROUBLESHOOTING INPUT STROBE

If the STOBE input does not appear to be functioning properly, an oscilloscope or fast multi-meter can be used to probe theactual STROBE line to ensure the proper 0V to 3.3V voltage swing is present. The following two tests can be used to evaluate theproper function of the strobe source and the IMX strobe input.
TEST 1: Identify if the IMX strobe input is configured properly and has a low input impedance:
1. Disconnect your strobe source from the IMX. Use a 1K ohm resistor as a pull-up resistor between 3.3V and the IMX strobe input
and measure the strong input line.
2. Repeat using the resistor as a pull-down resistor between ground and the strobe input and measure the strobe input line.
This will tell if the IMX strobe input is somehow being driven internally or not configured correctly. If it is functioning correctly,
the line will toggle from 0V to +3.3V following the resistor pull-down and pull-up.
TEST 2: Identify if your strobe source is driving correctly:
1. With the IMX strobe input disconnected from your strobe driving circuit, probe the output of the strobe driving circuit and observe
what levels it toggles between.
2. Attach a 1M ohm pull-down resistor from ground to the strobe output and observe the strobe voltage swing.
If the circuit is working correctly, it should drive the strobe output from 0V to +3.3V despite the 1M ohm pull-down resistor.
INPUT VOLTAGE LEVEL SHIFTER

The maximum input voltage for strobe lines (any pin on the IMX) is 3.6V. A level shifter may be used to convert any strobe signalthat is larger than 3.3V. The following figure shows two passive level shifter circuits, a zener diode voltage clamp and a resistor
voltage divider.

- 288/348 -©2022

10.5.3 Using the Strobe Input Pins

These circuits are beneficial because of their simplicity. An active, powered level shifter may also be used and necessary.

Strobe Output (Preintegrated IMU Period)
The STROBE output feature is used to indicate start and end of the preintegrated IMU period (and navigation filter IMU updates)by toggling G9. STROBE output is enabled on by setting bit IO_CONFIG_G9_STROBE_OUTPUT_NAV (0x00000020) of
DID_FLASH_CONFIG.ioConfig.

Configuring Message Output
By default, triggering a strobe input event will cause the IMX to produce an NMEA PINS2 message as well as a PSTRB message
which contains the time stamp of the strobe event.
To instead send a binary DID_INS_2 and DID_STROBE_IN_TIME message, set the RMC_BITS_STROBE_IN_TIME flag of DID_RMC/
bits field.

- 289/348 -©2022

10.6 Zero Motion Command

10.6 Zero Motion Command
The Zero Motion Command is user initiated and informs the EKF that the system is stationary on the ground. It is used to aid in
IMU bias estimation which can reduce drift in the INS attitude. It works as a virtual velocity and angular rate sensor to provide
velocity and angular rate observations when the INS is stationary (zero velocity and zero angular rate). This is done for a periodof two seconds after the Zero Motion Command is received. The Zero Motion Command is beneficial for the following reasons:• Overriding incorrect GPS motion caused by weak GPS signal.
• Speeding up gyro biases convergence time when there is no GPS signal.
In normal AHRS mode (stationary with or without GPS), only the IMU gyro biases are estimated by the EKF. Setting
DID_FLASH_CONFIG.dynamicModel = DYNAMIC_MODEL_STATIONARY (2) is equivalent to continually issuing the zero motion command.

To use the Zero Motion Command:
1. Ensure the system is stationary on the ground.
2. Send the Zero Motion Command either once or continuously while the system is stationary. This can be done either by using theZero Motion button in the EvalTool General Settings tab or by sending the DID_SYS_CMD binary message.
3. After sending the Zero Motion Command, wait for the INS_STATUS_STATIONARY_MODE status bit to clear in DID_INS_x.insStatus
before moving the system. This flag takes about 2 seconds to clear following the last Zero Motion Command.
Applying this command more than one time can further improve the IMU bias estimation.

Warning

Issuing the Zero Motion Command while the system is moving can cause incorrect IMU bias estimates and lead to poor INS
performance. It is important to make sure that the system is stationary when using the Zero Motion Command.

- 290/348 -©2022

10.7 UART Interface

10.7 UART Interface
The IMX has different UART TTL serial ports. These serial ports can be converted from TTL to RS232 or RS422 using a level
converter, such as found on the Rugged-3, EVB-1, and EVB-2 carrier boards.

10.7.1 Actual UART Baud Rates
The serial ports use different peripherals so the actual baud rates of the ports differ.
Due to UART limitations, the actual baud rate that the hardware is capable of generating differs from the target or desiredbaud rate. This difference is more pronounced at higher baud rates (>921600 bps). The following table outlines thesedifferences.
Target Baud Rate (bps)

IMX-5

uINS-3

Actual Baud Rate (bps)Actual Baud Rate (bps)

19,20019,19819,191

38,40038,40638,42257,60057,59557,515

115,200

115,273

115,030

230,400

230,547

231,481460,800

459,770

457,317921,600

919,540

937,500

3,200,000

3,125,000

4,000,000

3,750,000

5,000,000

4,687,500

8,000,000

6,250,000

10,000,000

9,375,000

IMX-5 UART Baud Rate Equation
The actual baud rate that the IMX-5 hardware is capable of generating is described in the following equation.
Baud rates <= 5 Mbps:
Divisor = floor( (80e6 + ((Target Baud Rate)/2)) / (Target Baud Rate) )Actual Baud Rate = floor( 80e6 / Divisor )Baud rates > 5 Mbps:
Divisor = floor( (160e6 + ((Target Baud Rate)/2)) / (Target Baud Rate) )Actual Baud Rate = floor( 160e6 / Divisor )uINS-3 UART Baud Rate Equation
The actual baud rate that the IMX-5 hardware is capable of generating is described in the following equations.
Divisor = floor( (18750000 + ((Target Baud Rate)/2)) / (Target Baud Rate) )Actual Baud Rate = floor( 18750000 / Divisor )- 291/348 -©2022

11. SDK

11. SDK11.1 Inertial Sense SDK
The Inertial Sense software development kit (SDK) is hosted on GitHub.
SDK - The Inertial Sense open source software development kit provides quick integration for communication with the Inertial
Sense product line, including the IMX, uAHRS, and IMX. It includes data logger, math libraries, and serial port interface forLinux and Windows environments.
EvalTool executable - Graphical Windows-based desktop program that allows you to explore and test functionality of theInertial Sense products in real-time. It has scrolling plots, 3D model representation, table views of all data, data logger, andfirmware updating interface for the IMX, uAHRS, or uIMU. The EvalTool can simultaneously interface with multiple Inertial
Sense devices.
CLTool - Command line utility that can be used to communicate, log data, and update firmware for Inertial Sense products.
Additionally, InertialSenseCLTool serves as example source code to demonstrate how to integrate the Inertial Sense SDK into
your own source code. The InertialSenseCLTool can be compiled in Linux and Windows.
EVB-2 - Multi-purpose hardware evaluation and development kit for the IMX. The EVB-2 includes the IMX-G2 with Dual GNSS,RTK heading / positioning, onboard logging to micro SD card, 915MHz XBee radio for RTK base corrections, WiFi and BLEinterface, serial and SPI communications to IMX interface, and Microchip SAME70 processor as communications bridge and user
project development environment.
ROS - The inertial-sense-sdk/ros directory contains the ROS wrapper node implementation for the Inertial Sense IMX productline.

Documents• User Manual, Datasheet, and Dimensions• Inertial Sense ROS Instructions

Downloads• SDK Example Projects - Source code projects that demonstrations of how to use the SDK.
• Software Releases - IMX, uAHRS, uIMU, and EVB-2 firmware and application installers.
• SDK & CLTool Source Code - Open source SDK repository with command line tool and example C/C++ source code.

Hardware Design Files• IS-hdw repository - CAD models of our products and PCB design assets for integration.

Support• Email - support@inertialsense.com- 292/348 -©2022

11.1 Inertial Sense SDK

Open Source License
MIT LICENSE
Copyright 2014-2024 Inertial Sense, Inc. - http://inertialsense.com
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files(the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions :The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

© 2014-2024 Inertial Sense, Inc.

- 293/348 -©2022

11.2 Example Projects

11.2 Example Projects
11.2.1 Binary Communications Example ProjectThis IS Communications Example project demonstrates binary communications with theInertial Sense Products (IMX, uAHRS, and uIMU) using the Inertial Sense SDK.

Files
Project Files• ISCommunicationsExample.c
SDK Files• data_sets.c• data_sets.h• ISComm.c• ISComm.h• serialPort.c• serialPort.h• serialPortPlatform.c• serialPortPlatform.h

Implementation
STEP 1: ADD INCLUDES// Change these include paths to the correct paths for your project#include "../../src/ISComm.h"#include "../../src/serialPortPlatform.h"#include "../../src/ISPose.h"

STEP 2: INIT COMM INSTANCE
is_comm_instance_t comm;uint8_t buffer[2048];// Initialize the comm instance, sets up state tracking, packet parsing, etc.
is_comm_init(&comm, buffer, sizeof(buffer));

STEP 3: INITIALIZE AND OPEN SERIAL PORT
serial_port_t serialPort;// Initialize the serial port (Windows, MAC or Linux) - if using an embedded system like Arduino,// you will need to handle the serial port creation, open and reads yourself. In this// case, you do not need to include serialPort.h/.c and serialPortPlatform.h/.c in your project.
serialPortPlatformInit(&serialPort);// Open serial, last parameter is a 1 which means a blocking read, you can set as 0 for non-blocking// you can change the baudrate to a supported baud rate (IS_BAUDRATE_*), make sure to reboot the IMX// if you are changing baud rates, you only need to do this when you are changing baud rates.
if (!serialPortOpen(&serialPort, argv[1], IS_BAUDRATE_921600, 1)){
printf("Failed to open serial port on com port %s\r\n", argv[1]);return -2;}

STEP 4: STOP ANY MESSAGE BROADCASTING
int messageSize = is_comm_stop_broadcasts_all_ports(comm);
if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to encode and write stop broadcasts message\r\n");}- 294/348 -©2022

11.2.1 Binary Communications Example Project

STEP 5: SET CONFIGURATION (OPTIONAL)// Set INS output Euler rotation in radians to 90 degrees roll for mounting
float rotation[3] = { 90.0f*C_DEG2RAD_F, 0.0f, 0.0f };int messageSize = is_comm_set_data(comm, DID_FLASH_CONFIG, sizeof(float) * 3, offsetof(nvm_flash_cfg_t, insRotation), rotation);
if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to encode and write set INS rotation\r\n");}STEP 6: ENABLE MESSAGE BROADCASTING// Ask for INS message w/ update 40ms period (4ms source period x 10). Set data rate to zero to disable broadcast and pull a single packet.
int messageSize = is_comm_get_data(comm, DID_INS_1, 0, 0, 10);if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to encode and write get INS message\r\n");}// Ask for GPS message at period of 200ms (200ms source period x 1). Offset and size can be left at 0 unless you want to just pull a specific field froma data set.
messageSize = is_comm_get_data(comm, DID_GPS1_POS, 0, 0, 1);
if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to encode and write get GPS message\r\n");}// Ask for IMU message at period of 96ms (DID_FLASH_CONFIG.startupNavDtMs source period x 6).
multiple of 1)
messageSize = is_comm_get_data(comm, DID_IMU, 0, 0, 6);
if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to encode and write get IMU message\r\n");}This could be as high as 1000 times a second (period

STEP 7: SAVE PERSISTENT MESSAGES(OPTIONAL) Save currently enabled streams as persistent messages enabled after reboot.
system_command_t cfg;
cfg.command = SYS_CMD_SAVE_PERSISTENT_MESSAGES;
cfg.invCommand = ~cfg.command;int messageSize = is_comm_set_data(comm, DID_SYS_CMD, 0, 0, &cfg);
if (messageSize != serialPortWrite(serialPort, comm->buf.start, messageSize)){printf("Failed to write save persistent message\r\n");}STEP 8: HANDLE RECEIVED DATA
uint8_t inByte;// You can set running to false with some other piece of code to break out of the loop and end the program
while (running){// Read one byte with a 20 millisecond timeout
while (serialPortReadCharTimeout(&serialPort, &inByte, 20) > 0){
switch (is_comm_parse_byte(&comm, inByte)){case _PTYPE_INERTIAL_SENSE_DATA:
switch (comm.dataHdr.id){
case DID_INS_1:
handleIns1Message((ins_1_t*)comm.pkt.data.ptr);
break;
case _DID_INS_LLA_QN2B:
handleIns2Message((ins_2_t*)comm.pkt.data.ptr);
break;
case DID_GPS1_POS:
handleGpsMessage((gps_pos_t*)comm.pkt.data.ptr);
break;
case _DID_PIMU:
handleImuMessage((dual_imu_t*)comm.pkt.data.ptr);
break;// TODO: add other cases for other data ids that you care about}
break;
default:
break;}- 295/348 -©2022

11.2.1 Binary Communications Example Project}}

Compile & Run (Linux/Mac)
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Communications
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using makemake

4. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

5. Run executable./ISCommunicationsExample /dev/ttyUSB0

Compile & Run (Windows Powershell)*Note - Install CMake for Windows natively, or install the CMake for Windows extension for Visual Studio
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Communications
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using make
cmake --build .

4. Run executable
C:\InertialSenseSDK\ExampleProjects\Communications\build\Release\ISCommunicationsExample.exe COM3

SummaryThis section has covered the basic functionality you need to set up and communicate with Inertial Sense products. If this doesn'tcover everything you need, feel free to reach out to us on the Inertial Sense SDK GitHub repository, and we will be happy to help.

- 296/348 -©2022

11.2.2 ASCII Communications Example Project

11.2.2 ASCII Communications Example ProjectThis IS Communications Example project demonstrates binary communications with theInertial Sense Products (IMX, uAHRS, and uIMU) using the Inertial Sense SDK. See the
ASCII protocol section for details on the ASCII packet structures.

Files
Project Files• ISAsciiExample.c
SDK Files• data_sets.c• data_sets.h• ISComm.c• ISComm.h• ISConstants.h• serialPort.c• serialPort.h• serialPortPlatform.c• serialPortPlatform.h

Implementation
STEP 1: ADD INCLUDES// Change these include paths to the correct paths for the project#include "../../src/ISComm.h"#include "../../src/serialPortPlatform.h"

STEP 2: INITIALIZE AND OPEN SERIAL PORT
serial_port_t serialPort;// Initialize the serial port (Windows, MAC or Linux) - if using an embedded system like Arduino,// you will need to handle the serial port creation, open and reads yourself. In this// case, you do not need to include serialPort.h/.c and serialPortPlatform.h/.c in your project.
serialPortPlatformInit(&serialPort);// Open serial, last parameter is a 1 which means a blocking read, you can set as 0 for non-blocking// you can change the baudrate to a supported baud rate (IS_BAUDRATE_*), make sure to reboot the IMX// if you are changing baud rates, you only need to do this when you are changing baud rates.
if (!serialPortOpen(&serialPort, argv[1], IS_BAUDRATE_921600, 1)){
printf("Failed to open serial port on com port %s\r\n", argv[1]);}STEP 3: DISABLE PRIOR MESSAGE BROADCASTING// Stop all broadcasts on the device on all ports. We don't want binary message coming through while we are doing ASCII
if (!serialPortWriteAscii(&serialPort, "STPB", 4)){printf("Failed to encode stop broadcasts message\r\n");}STEP 4: ENABLE MESSAGE BROADCASTING// ASCII protocol is based on NMEA protocol https://en.wikipedia.org/wiki/NMEA_0183// turn on the INS message at a period of 100 milliseconds (10 hz)// serialPortWriteAscii takes care of the leading $ character, checksum and ending \r\n newline// ASCE message enables ASCII broadcasts// ASCE fields: 1:options, ID0, Period0, ID1, Period1, ........ ID19, Period19// IDs:// NMEA_MSG_ID_PIMU= 0,// NMEA_MSG_ID_PPIMU= 1,// NMEA_MSG_ID_PRIMU= 2,- 297/348 -©2022

11.2.2 ASCII Communications Example Project// NMEA_MSG_ID_PINS1// NMEA_MSG_ID_PINS2// NMEA_MSG_ID_PGPSP// NMEA_MSG_ID_GxGGA// NMEA_MSG_ID_GxGLL// NMEA_MSG_ID_GxGSA// NMEA_MSG_ID_GxRMC// NMEA_MSG_ID_GxZDA// NMEA_MSG_ID_PASHR// NMEA_MSG_ID_PSTRB// NMEA_MSG_ID_INFO// NMEA_MSG_ID_GxGSV// NMEA_MSG_ID_GxVTG// NMEA_MSG_ID_INTEL

= 3,
= 4,
= 5,
= 6,
= 7,
= 8,
= 9,
= 10,
= 11,
= 12,
= 13,
= 14,
= 15,
= 16,

// options can be 0 for current serial port, 1 for serial 0, 2 for serial 1 or 3 for both serial ports// Instead of a 0 for a message, it can be left blank (,,) to not modify the period for that message// please see the user manual for additional updates and notes// Get PINS1 @ 5Hz on the connected serial port, leave all other broadcasts the same, and save persistent messages.
const char* asciiMessage = "ASCE,0,3,1";// Get PINS1 @ 1Hz and PGPSP @ 1Hz on the connected serial port, leave all other broadcasts the same// const char* asciiMessage = "ASCE,0,5,5";// Get PIMU @ 50Hz, GGA @ 5Hz, serial0 and serial1 ports, set all other periods to 0// const char* asciiMessage = "ASCE,3,6,1";
if (!serialPortWriteAscii(&serialPort, asciiMessage, (int)strnlen(asciiMessage, 128))){
printf("Failed to encode ASCII get INS message\r\n");}STEP 5: SAVE PERSISTENT MESSAGES(OPTIONAL) This remembers the current communications and automatically streams data following reboot.
if (!serialPortWriteAscii(&serialPort, "PERS", 4)){printf("Failed to encode ASCII save persistent message\r\n");}STEP 6: HANDLE RECEIVED DATA// STEP 4: Handle received data
unsigned char* asciiData;
unsigned char asciiLine[512];// you can set running to false with some other piece of code to break out of the loop and end the program
while (running){
if (serialPortReadAscii(&serialPort, asciiLine, sizeof(asciiLine), &asciiData) > 0){
printf("%s\n", asciiData);}}

Compile & Run (Linux/Mac)
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Ascii
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using makemake

4. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

5. Run executable- 298/348 -©2022

11.2.2 ASCII Communications Example Project./ISAsciiExample /dev/ttyUSB0

Compile & Run (Windows Powershell)*Note - Install CMake for Windows natively, or install the CMake for Windows extension for Visual Studio
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Ascii
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using make
cmake --build .

4. Run executable
C:\InertialSenseSDK\ExampleProjects\Ascii\build\Release\ISAsciiExample.exe COM3

SummaryThis section has covered the basic functionality you need to set up and communicate with Inertial Sense products. If this doesn'tcover everything you need, feel free to reach out to us on the Inertial Sense SDK GitHub repository, and we will be happy to help.

- 299/348 -©2022

11.2.3 Basic Arduino Communications Example Project

11.2.3 Basic Arduino Communications Example ProjectInterfacing with the IMX over serial
This example shows how to communicate with the IMX using the Inertial Sense Binary Communications Protocol. The example
code can be found in the Inertial Sense SDK/ExampleProjects/Arduino.

Important
Update the IMX to the latest firmware

This example demonstrates how to use the Inertial Sense EVB with an Arduino Due. The Due was selected because it has two
serial ports. This way the Arduino can communicate with the IMX using one of the ports, and write the output over the Serial
Monitor to the computer using the other.

Warning
The InertialSense SDK requires 64-bit double support. 32-bit processors (Arduino Due, Zero, and M0) are supported. 8-bit processors(i.e. Arduino Mega and Uno) are NOT supported. The ASCII protocol (not covered in this example) may be used on an 8-bit Arduino.

Note
A Raspberry PI (similar in price to the Arduino) is a good alternative to the Arduino. Either the Binary Communications and ASCII
Communications example projects can be run on a Raspberry PI.

- 300/348 -©2022

11.2.3 Basic Arduino Communications Example Project

Wiring Guide

After downloading the Inertial Sense SDK, Navigate to ExampleProjects/Arduino/ReadIS. Use the ImportSdkFiles.bat (Windows)
or ImportSdkFiles.sh (Linux) to copy the required files from the SDK into src/ISsdk directory. The resulting file structure for the
ReadIS Arduino sketch should look like the following:|-ReadIS| - ImportSdkFiles.bat| - ImportSdkFiles.sh| - ReadIS.ino| - src| - ISsdk| - data_sets.c| - data_sets.h| - ISComm.c| - ISComm.h| - ISConstants.h

What is an ino file?
An .ino file is the arduino extension for a sketch. It is actually C++ code.

Note
Note that there are two .c files in the tree. You'll need to make sure that these files are compiled by the toolchain, otherwisexxxx is not defined errors can occur.

- 301/348 -©2022

11.2.3 Basic Arduino Communications Example Project

SDK Implementation
ReadIS.ino file explained:
STEP 1: ADD INCLUDES

The "ISComm.h" header file includes all the other required code. stddef.h file from the standard library is required for theoffsetof function.
#include "src/ISsdk/ISComm.h"#include <stddef.h>

STEP 2: CREATE BUFFERS

Next, define a buffer to hold data. As the IMX sends data, this buffer is used to hold the data until a full message arrives. Thisbuffer only needs to be as big as the largest message expected, multiplied by two + 32 (worst case scenario if there is a badtransmission). For this example a 1KB buffer is used.
// This buffer is going to be used to hold messages as they come in.
// You can make this 512 size if memory is tight.
static uint8_t s_buffer[1024];// create an instance to hold communications statestatic is_comm_instance_t comm;

STEP 3: SERIAL PORT INITIALIZATION
void setup(){// Initialize both serial ports:
Serial.begin(115200);
Serial1.begin(115200);
if (sizeof(double) != 8){
Serial.println("Inertial Sense SDK requires 64 bit double support");while (true){};}
Serial.println("initializing");// Initialize comm interface - call this before doing any comm functions
is_comm_init(&comm, s_buffer, sizeof(s_buffer));// Stop all the broadcasts on the device
int messageSize = is_comm_stop_broadcasts_all_ports(&comm);
Serial1.write(comm.rxBuf.start, messageSize); // Transmit the message to the inertialsense device// Ask for ins_1 message 20 times per second. Ask for the whole thing, so// set 0's for the offset and size
messageSize = is_comm_get_data(&comm, DID_INS_1, 0, sizeof(ins_1_t), 1000);
Serial1.write(comm.rxBuf.start, messageSize); // Transmit the message to the inertialsense device}

Initialize the communication using the following steps as shown above:
1. Initialize the serial ports
2. Tell the communication interface where to find the buffer to use to hold messages, and how big that buffer is.
3. Reset communications on the device
4. Perform configuration of the IMX
5. Tell the IMX what data to stream, and how often
Whenever sending a command to the IMX, the command is put into the buffer, and the length of the message is returned by oneof the configuration functions. That buffer needs to be written out to the IMX for the command to be received.

Tip

It is recommended to use the enumerations in data_sets.h such as SYS_CFG_BITS_RTK_ROVER to configure the device. This aids
code readability and reduces the chance for errors.

- 302/348 -©2022

11.2.3 Basic Arduino Communications Example ProjectIn this example, the DID_INS_1 message is streamed. All available messages can be found in the data_sets.h file, defined as Cstyle structs.
STEP 4: HANDLE RECEIVED DATA
void loop(){// Read from port 1, and see if we have a complete inertialsense packet
if (Serial1.available()){
uint8_t inByte = Serial1.read();// This function returns the DID of the message that was just parsed, we can then point the buffer to// the right function to handle the message. We can use a cast to interpret the s_buffer as the// kind of message that we received.
uint32_t message_type = is_comm_parse_byte(&comm, inByte);
switch (message_type){case _PTYPE_INERTIAL_SENSE_DATA:
switch (comm.dataHdr.id){
case DID_NULL:
break;
case DID_INS_1:
handleINSMessage((ins_1_t *)(comm.pkt.data.ptr));break;
default:
Serial.print("Got an unexpected message DID: ");Serial.println(message_type, DEC);}}}}In this code, every byte that we receive from the IMX is passed to the is_comm_parse function. For each byte received, this function
waits for a complete message in the buffer and decodes it. Once a full message is received, it identifies what kind of message is in
the buffer so it can be handled correctly. The easiest way to deal with this is to us a case structure as shown above, with separate"callback" functions for each message type.
The INS message handler is just printing the position in lla, velocity and euler angle attitude to the screen. Other
parameterizations of position and attitude are available in other DID_INS_x messages.
static void handleINSMessage(ins_1_t *ins){
Serial.print("Lat: ");Serial.print((float)ins->lla[0], 6);
Serial.print("\t");Serial.print(", Lon: ");Serial.print((float)ins->lla[1], 6);
Serial.print("\t");Serial.print(", Alt: ");Serial.print((float)ins->lla[2], 2);
Serial.print("\t");Serial.print(", roll: ");Serial.print(ins->theta[0] * C_RAD2DEG_F);
Serial.print("\t");Serial.print(", pitch: ");Serial.print(ins->theta[1] * C_RAD2DEG_F);
Serial.print("\t");Serial.print(", yaw: ");Serial.print("\t");Serial.println(ins->theta[2] * C_RAD2DEG_F);}- 303/348 -©2022

11.2.4 Firmware Update (Bootloader) Example Project

11.2.4 Firmware Update (Bootloader) Example ProjectThis ISBootloaderExample project demonstrates firmware update with the InertialSense products (IMX, uAHRS, and uIMU)
using the Inertial Sense SDK.

Files
Project Files• ISBootloaderExample.cpp
SDK Files• data_sets.c• data_sets.h• inertialSenseBootLoader.c• inertialSenseBootLoader.h• ISComm.c• ISComm.h• serialPort.c• serialPort.h• serialPortPlatform.c• serialPortPlatform.h

Implementation
STEP 1: ADD INCLUDES// Change these include paths to the correct paths for your project#include "../../src/ISComm.h"#include "../../src/serialPortPlatform.h"#include "../../src/ISBootloaderThread.h"#include "../../src/ISBootloaderBase.h"#include "../../src/ISSerialPort.h"

STEP 2: INITIALIZE AND OPEN SERIAL PORT
serial_port_t serialPort;// initialize the serial port (Windows, MAC or Linux) - if using an embedded system like Arduino,// you will need to either bootload from Windows, MAC or Linux, or implement your own code that// implements all the function pointers on the serial_port_t struct.
serialPortPlatformInit(&serialPort);// set the port - the bootloader uses this to open the port and enable bootload mode, etc.
serialPortSetPort(&serialPort, argv[1]);STEP 3: SET BOOTLOADER PARAMETERS// bootloader parameters
bootload_params_t param;// very important - initialize the bootloader params to zeros
memset(&param, 0, sizeof(param));// the serial port
param.port = &serialPort;param.baudRate = atoi(argv[2]);// the file to bootload, *.hex
param.fileName = argv[3];// optional - bootloader file, *.bin
param.forceBootloaderUpdate = 0;//do not force update of bootloader
if (argc == 5)
param.bootName = argv[4];elseparam.bootName = 0;

- 304/348 -©2022

11.2.4 Firmware Update (Bootloader) Example Project

STEP 4: RUN BOOTLOADER
if (bootloadFileEx(&param)==0){
printf("Bootloader success on port %s with file %s\n", serialPort.port, param.fileName);
return 0;}
else{
printf("Bootloader failed! Error: %s\n", errorBuffer);
return -1;}

Compile & Run (Linux/Mac)
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Bootloader
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using makemake

4. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

5. Run executable./ISBootloaderExample /dev/ttyUSB0 IS_uINS-3.hex bootloader-SAMx70.bin

Compile & Run (Windows Powershell)*Note - Install CMake for Windows natively, or install the CMake for Windows extension for Visual Studio
1. Create build directory
cd InertialSenseSDK/ExampleProjects/IS_firmwareUpdate_v2
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using make
cmake --build .

4. Run executable
C:\InertialSenseSDK\ExampleProjects\IS_firmwareUpdate_v2\build\Release\ISBootloaderExample.exe COM3 IS_uINS-3.hex bootloader-SAMx70.bin

SummaryThis section has covered the basic functionality you need to set up and communicate with Inertial Sense products. If this doesn'tcover everything you need, feel free to reach out to us on the Inertial Sense SDK GitHub repository, and we will be happy to help.

- 305/348 -©2022

11.2.5 C++ API - Inertial Sense Class and CLTool Example Project

11.2.5 C++ API - Inertial Sense Class and CLTool Example Project
The InertialSense C++ class, defined in InertialSense.h/.cpp, provides all SDK capabilities including serial communications, data
logging to file, and embedded firmware update for InertialSense products.

CLTool Example
The Command Line Tool (CLTool) is an open source project designed to illustrate InertialSense C++ class implementation. The
CLTool project can be compiled on most operating systems using cmake and gcc and can be used to communicate, log data, andupdate firmware for Inertial Sense products. A Visual Studio project for Windows is also included. See Using CLTool for details
on compiling and running the CLTool.
IMPLEMENTATION KEYWORDS

The following keywords are found in the CLTool soure code identify the steps for InertialSense class implementation.
/* SDK Implementation Keywords:* [C++ COMM INSTRUCTION] - C++ binding API, InertialSense class with binary* communication protocol and serial port support for Linux and Windows.
* [LOGGER INSTRUCTION] - Data logger.
* [BOOTLOADER INSTRUCTION] - Firmware update feature.
*/

Serial Communications
STEP 1: INSTANTIATE INERTIALSENSE CLASS

Include the InertialSense header file. Create InertialSense object.
#include "InertialSense.h"// [C++ COMM INSTRUCTION] 1.) Create InertialSense object, passing in data callback function pointer.
InertialSense inertialSenseInterface(cltool_dataCallback);

STEP 2: OPEN SERIAL PORTOpen the serial by specifying the com port number, buadrate, and and The serial port used for communications
if (!inertialSenseInterface.Open(g_commandLineOptions.comPort.c_str(),g_commandLineOptions.baudRate,g_commandLineOptions.disableBroadcastsOnClose)){cout << "Failed to open serial port at " << g_commandLineOptions.comPort.c_str() << endl;
return -1; // Failed to open serial port}

STEP 3: ENABLE DATA BROADCASTING

The following enables data broadcasting from the IMX at a specified data rate or period in milliseconds.
cltool_setupCommunications(inertialSenseInterface)

STEP 4: READ DATA

Call the Update() method at regular intervals to send and receive data.
// Main loop. Could be in separate thread if desired.
while (!g_inertialSenseDisplay.ControlCWasPressed()){
if (!inertialSenseInterface.Update()){// device disconnected, exit
break;}}STEP 5: HANDLE RECEIVED DATA

New data is available in the data callback function.

- 306/348 -©2022

11.2.5 C++ API - Inertial Sense Class and CLTool Example Project

static void cltool_dataCallback(InertialSense* i, p_data_t* data, int pHandle){// Print data to terminal
g_inertialSenseDisplay.ProcessData(data);// uDatasets is a union of all datasets that we can receive. See data_sets.h for a full list of all available datasets.
uDatasets d = {};copyDataPToStructP(&d, data, sizeof(uDatasets));// Example of how to access dataset fields.
switch (data->hdr.id){
case DID_INS_2:
d.ins2.qn2b; // quaternion attituded.ins2.uvw; // body velocities
d.ins2.lla; // latitude, longitude, altitude
break;
case DID_INS_1:
d.ins1.theta; // euler attituded.ins1.lla; // latitude, longitude, altitude
break;
case DID_IMU: d.dualImu; break;case DID_PIMU: d.dThetaVel; break;case DID_GPS1_POS: d.gpsPos; break;case DID_MAGNETOMETER: d.mag; break;case DID_BAROMETER: d.baro; break;case DID_SYS_SENSORS: d.sysSensors; break;}}

STEP 6: CLOSE INTERFACE

Close the interface when your application finishes.
// Close cleanly to ensure serial port and logging are shutdown properly. (optional)
inertialSenseInterface.Close();Data Logging
STEP 1: CONFIGURE AND START LOGGING// [LOGGER INSTRUCTION] Setup and start data logger
if (!cltool_setupLogger(inertialSenseInterface)){cout << "Failed to setup logger!" << endl;
return -1;}

Compile & Run (Linux/Mac)
1. Create build directory
cd cltool
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using makemake

4. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

5. Run executable./cltool- 307/348 -©2022

11.2.5 C++ API - Inertial Sense Class and CLTool Example Project

Compile & Run (Windows Powershell)*Note - Install CMake for Windows natively, or install the CMake for Windows extension for Visual Studio
1. Create build directory
cd InertialSenseSDK/cltool
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using make
cmake --build .

4. Run executable
C:\InertialSenseSDK\cltool\build\Release\cltool.exe

SummaryThis section has covered the basic functionality you need to set up and communicate with Inertial Sense products. If this doesn'tcover everything you need, feel free to reach out to us on the Inertial Sense SDK GitHub repository, and we will be happy to help.

- 308/348 -©2022

11.2.6 Data Logging Example Project

11.2.6 Data Logging Example ProjectThis ISLoggerExample project demonstrates data logging with the InertialSense products (IMX, uAHRS, and uIMU) using theInertial Sense SDK.

Files
Project Files• ISLoggerExample.cpp
SDK Files• SDK

Implementation
STEP 1: ADD INCLUDES// Change these include paths to the correct paths for your project#include "../../src/InertialSense.h"

STEP 2: INSTANTIATE INERTIALSENSE CLASS// InertialSense class wraps communications and logging in a convenient, easy to use class
InertialSense inertialSense(dataCallback);
if (!inertialSense.Open(argv[1])){std::cout << "Failed to open com port at " << argv[1] << std::endl;}

STEP 3: ENABLE DATA LOGGER// get log type from command line
cISLogger::eLogType logType = (argc < 3 ? cISLogger::eLogType::LOGTYPE_DAT : cISLogger::ParseLogType(argv[2]));
inertialSense.SetLoggerEnabled(true, "", logType);

STEP 4: ENABLE DATA BROADCASTING// broadcast the standard set of post processing messages (ins, imu, etc.)
inertialSense.BroadcastBinaryDataRmcPreset();// instead of the rmc preset (real-time message controller) you can request individual messages...
// inertialSense.BroadcastBinaryData(DID_IMU, 6); // (startupNavDtMs default)

By default, data logs will be stored in the "IS_logs" directory in the current directory.
build/IS_logs/LOG_SN30664_20180323_112822_0001.dat

Compile & Run (Linux/Mac)
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Logger
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using makemake

4. If necessary, add current user to the "dialout" group in order to read and write to the USB serial communication ports:- 309/348 -©2022

11.2.6 Data Logging Example Projectsudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER(reboot computer)

5. Run executable./ISLoggerExample /dev/ttyUSB0

Compile & Run (Windows Powershell)*Note - Install CMake for Windows natively, or install the CMake for Windows extension for Visual Studio
1. Create build directory
cd InertialSenseSDK/ExampleProjects/Logger
mkdir build

2. Run cmake from within build directory
cd build
cmake ..

3. Compile using make
cmake --build .

4. Run executable
C:\InertialSenseSDK\ExampleProjects\Logger\build\Release\ISLoggerExample.exe COM3

SummaryThis section has covered the basic functionality you need to set up and communicate with Inertial Sense products. If this doesn'tcover everything you need, feel free to reach out to us on the Inertial Sense SDK GitHub repository, and we will be happy to help.

- 310/348 -©2022

12. Data Logging/Plotting

12. Data Logging/Plotting
12.1 Data Logging/Plotting
Inertial Sense provides data a logging capability in the EvalTool, CLTool, and SDK (C++) that can record data in binary, comma
separated (.CSV), and KML file formats. This logging capability is useful for storing, replaying, and analyzing data.

12.1.1 Data Log Types
Comma Seperated Values ( *.csv )The comma separated value (.csv) file format can be imported into many software packages, including Excel, Matlab, and Python.

KML ( *.kml )KML is a file format used to display geographic data in an Earth browser such as Google Earth.

Binary Data Log Types ( *.dat and *.sdat )Description

Advantages

Serial Logger (*.dat)

Sorted Logger (*.sdat)

Stores data to file in the same serial order it was

Sorts data of similar types into separate

passed into the logger. This is the default logger usedchunks, allowing for faster load times into

in the CLTool and EvalTool.

analysis tools.

Optimized for real-time data logging.

Optimized for loading data into analysis tools(i.e. Matlab, Python).

Source File

DeviceLogSerial.h / .cpp

DeviceLogSorted.h / .cpp

File

.dat

.sdat

extension

12.1.2 Binary Data Log Format
This section outlines the Inertial Sense binary data log types known as serial data and sorted data ( .dat and .sdat fileextensions). Both data log file types are composed of several data containers know as chunks. Each chunk contains a header, subheader, and data.

File
The data log file name has the format LOG_SNXXXXX_YYYYMMDD_HHMMSS_CNT.dat which contains the device serial number,date, time, and log file count. The two primary log file formats are .dat and .sdat . These log files consist of a series of data
Chunks.

Standard data types are stored in the log files and are defined as:
U32

unsigned int

U16

unsigned short

S8

char

U8

unsigned char- 311/348 -©2022

12.1.2 Binary Data Log Format

Chunk
The data log file is composed of Chunks. A Chunk is a data container that provides an efficient method for organizing, handling,
and parsing data in a file. A Chunk starts with a header which has a unique identifiable marker and ends with the data to be
stored.

Chunk Header
The header, found at the start of each Chunk, is as follows:

The C structure implementation of the Chunk header is://!< Chunk Header#pragma pack(push,1)
struct sChunkHeader{
uint32_t marker; //!< Chunk marker (0xFC05EA32)
uint16_t version; //!< Chunk Version
uint16_t classification; //!< Chunk classification
char name[4]; //!< Chunk namechar invName[4]; //!< Bitwise inverse of chunk nameuint32_t dataSize; //!< Chunk data length in bytes
uint32_t invDataSize; //!< Bitwise inverse of chunk data length
uint32_t grpNum; //!< Chunk Group Number: 0 = serial data, 1 = sorted data...
uint32_t devSerialNum; //!< Device serial number
uint32_t pHandle; //!< Device port handle
uint32_t reserved; //!< Unused};#pragma pack(pop)Chunk Data
The Chunk data is defined for both the .dat and .sdat file types.

Chunk Sub-Header
The Chunk sub-header is used for .sdat file types.

- 312/348 -©2022

12.1.2 Binary Data Log Format

Data Set Header
The Data set header is used for both the .dat and .sdat file types.

- 313/348 -©2022

12.2 Logging

12.2 Logging
The SDK logging interface is defined in SDK/src/ISLogger.h. Data logs can be converted between file formats using the Inertial
Sense data logger. The logging interface is used in the Inertial Sense software described below.

12.2.1 Logging using Inertial Sense software
EvalTool
1. Go to “Data Logs” tab in EvalTool.
2. Select the “Format” file type from the drop-down menu.
3. Select the data to record within the Data Streams section of the "Data Logs" tab:a. Manual Selection – Allows the user to select the specific datasets to stream and their update rates by setting the checkbox andperiod multiple in Manual Selection table.
b. INS – Log INS output (attitude, velocity, position) at 100 Hz by selecting "INS" from the RMC Presets dropdown.
c. Post Process – Used for beta testing and internal testing. Includes IMU, GPS, INS and other messages. Log by selecting "PPD"from the RMC Presets dropdown.
4. Press “Enable” to begin logging data.
5. Press “Disable” to stop logging data.
6. The “Open Folder” button opens the File Explorer location to the data logs, i.e. C:\Users\[username]\Documents\Inertial_Sense\logs .
7. To change the root log folder in the Eval Tool, edit Documents/Inertial Sense/settings.json , and add or change the logger key:
"Directory": "FOLDER_FOR_LOGS".

CLToolThe CLTool, provided in the SDK, is a command line application that can record post process data. The CLTool help menu isdisplayed using the option -h . See the CLTool section for more information on using the CLTool.

12.2.2 Post Process Data (PPD) Logging Instructions
Post process data (PPD) logs include both the input to and output from the navigation filter. The data is used for analyzing,troubleshooting, and improving system performance. PPD logs can be recorded using the EvalTool, CLTool, or SDK.

PPD RMC bits Preset
PPD logs are created by enabling PPD data streaming by setting the RMC bits to RMC_PRESET_PPD_BITS and logging this stream toa .dat binary file. RMC_PRESET_PPD_BITS is defined in data_sets.h.

Logging PPD in EvalTool
The following steps outline how to record post process data in the EvalTool
1. Go to the "Data Logs" tab in the EvalTool.
2. Press the "Data Log: PPD Log" button to start logging.
3. Toggle the "Data Log: Disable" button to stop logging.
4. The "Open Folder" button will open the directory where the data logs are stored.

Logging PPD in CLTool
Streaming and logging a PPD log using the CLTool is done using the -presetPPD -lon options:- 314/348 -©2022

12.2.2 Post Process Data (PPD) Logging Instructions

cltool -c /dev/ttyS2 -presetPPD -lon

See the CLTool section for more information on using the CLTool.

- 315/348 -©2022

12.3 Plotting

12.3 Plotting
12.3.1 Log Inspector
Log Inspector is a convenient way to quickly plot Inertial Sense PPD logs that of of the .dat format. The source code is in the SDK
and can be modified and expanded.

12.3.2 CLTool
The CLTool can be used to load and replay .dat log files. The source code for the CLTool is located in the SDK and can be
expanded by a user to analyze log data.
• -rp PATH replay data log from specified path• -rs=SPEED replay data log at x SPEED
The following example replays data at 1x speed from the specified directory.
cltool -rp IS_logs/20180801_222310

The following example will replay data as fast a possible in quiet mode (without printing to the screen). This is useful to quickly
reprocess the data.
cltool -rp IS_logs/20180801_222310 -rs=0 -q

12.3.3 3rd Party Software
The various file types described in the overview section can be analyzed using various software packages. Matlab, Python, andExcel are popular choices and are well suited for Inertial Sense data logs.

- 316/348 -©2022

13. Reference

13. Reference
13.1 Bootloader
The bootloader is embedded firmware stored on the IMX and is used to update the IMX application firmware. Updating thebootloader firmware is required occasionally when new functionality is required.

13.1.1 Bootloader Update
The bootloader is now checked and updated at the same time as loading new firmware. The following steps outline how to update
the IMX bootloader and firmware.
1. Ensure IMX Firmware is Running - (This step is not necessary if the IMX firmware is running and the EvalTool iscommunicating with the IMX). If the bootloader is running but the firmware is not, version information will not appear in the
EvalTool. The LED will also be a fading cyan.
2. Select Baud Rate - Select a slower baud rate (i.e. 115,200 or 230,400) for systems with known baud rate limits.
3. Update the Bootloader and Firmware - Use the EvalTool "Update Firmware" button in the Settings tab to upload the latest
bootloader and the latest firmware. The bootloader can only be updated using serial0 or the native USB ports.

- 317/348 -©2022

13.2 Coordinate Frames

13.2 Coordinate Frames
In this manual, coordinate frame systems are simply referred to as frames. This page is to assist the developer in choosing andimplementing the appropriate coordinate frames for their respective application. It should be noted that the following frames are
in relation to the IMX itself.

13.2.1 Coordinate Frame RelationshipThe relationship between the Hardware Frame, Sensor Frame, and INS Output Frame are as follows.

NOTE: The Hardware Frame and Sensor Frame are equivalent when the sensor rotation in DID_FLASH_CONFIG.sensorConfig iszero. The Sensor Frame and INS output Frame are equivalent when the DID_FLASH_CONFIG.insRotation and
DID_FLASH_CONFIG.insOffset are zero.

13.2.2 Hardware Frame
The Hardware Frame is labeled "X" and "Y" on the hardware indicating the direction of the sensing elements in the IMX.

- 318/348 -©2022

13.2.2 Hardware FrameThe IMX follows the right right rule for XYZ axis relative direction and angular rotation.

- 319/348 -©2022

13.2.3 Sensor Frame

13.2.3 Sensor FrameThe IMU and magnetometer data (i.e. messages DID_IMU and DID_MAGNETOMETER) are in the Sensor Frame. The Hardware
Frame is rotated into the Sensor Frame in multiples of 90° using the SENSOR_CFG_SENSOR_ROTATION_MASK bits of the
DID_FLASH_CONFIG.sensorConfig as defined in enum eSensorConfig .

13.2.4 INS Output FrameThe INS output data (DID_INS_1, DID_INS_2, DID_INS_3) is in the INS Output Frame. Translation from Sensor Frame to INS
Output Frame is defined as:
1. Sensor Frame → Intermediate Output Frame by rotation of DID_FLASH_CONFIG.insRotation euler angles (in order of heading, pitch,roll angle) In radians.
2. Intermediate Output Frame → INS Output Frame: Offset by DID_FLASH_CONFIG.insOffset in meters.
If DID_FLASH_CONFIG.insRotation and DID_FLASH_CONFIG.insOffset are zero, the Sensor Frame and the INS Output Frame are thesame.

13.2.5 North-East-Down (NED) Frame
Position estimates can be output in the North-East-Down (NED) coordinate frame defined as follows:* Right-handed, Cartesian, non-inertial, geodetic frame with origin located at the surface of Earth (WGS84 ellipsoid). * Positive Xaxis points towards North, tangent to WGS84 ellipsoid. * Positive Y-axis points towards East, tangent to WGS84 ellipsoid. *Positive Z-axis points down into the ground completing the right-handed system.

13.2.6 Earth-Centered Earth-Fixed (ECEF) Frame
The Earth-Centered Earth-Fixed (ECEF) frame is defined as follows:* Right-handed, Cartesian, non-inertial frame with origin located at the center of Earth. * Fixed to and rotates with Earth. *Positive X-axis aligns with the WGS84 X-axis, which aligns with the International Earth Rotation and Reference Systems Service(IERS) Prime Meridian. * Positive Z-axis aligns with the WGS84 Z-axis, which aligns with the IERS Reference Pole (IRP) thatpoints towards the North Pole. * Positive Y-axis aligns with the WGS84 Y-axis, completing the right-handed system.

- 320/348 -©2022

13.2.7 Coordinate Frames Transformation Functions

13.2.7 Coordinate Frames Transformation Functions
This section is intended to be an example of how to rotate between frames using utility functions defined in theInertialSenseSDK.

Body frame to NED frame
The following example converts body velocity DID_INS_2.uvw to NED velocity vel_ned .
#include "SDK/src/ISPose.h"quatRot( vel_ned, DID_INS_2.qn2b, DID_INS_2.uvw );This following example removes gravity from the IMU measured acceleration.
#include "SDK/src/ISPose.h"
Vector gravityNED = { 0, 0, -9.80665 }; // m/s^2Vector gravityBody;
Vector accMinusGravity;// Rotate gravity into body frame
quatConjRot( gravityBody, DID_INS_2.qn2b, gravityNED );// Subtract gravity from IMU acceleration output
sub_Vec3_Vec3( accMinusGravity, DID_IMU.I[0].acc, gravityBody );ECEF frame to NED frameThis example converts ECEF velocity vel_ecef to NED velocity vel_ned .
#include "SDC/src/ISPose.h"quat_ecef2ned( lla[0], lla[1], qe2n );quatConj( qn2e, qe2n );quatRot( vel_ned, qn2e, vel_ecef );- 321/348 -©2022

13.3 Definitions

13.3 Definitions
13.3.1 GPS Time To Fix
The time it takes for the GPS receiver to get “fix” or produce a navigation solution from the visible satellites is affected by thefollowing GPS startup conditions:• Cold start - In cold start mode, the receiver has no information from the last position (e.g. time, velocity, frequency etc.) atstartup. Therefore, the receiver must search the full time and frequency space, and all possible satellite numbers. If a satellite
signal is found, it is tracked to decode the ephemeris (18-36 seconds under strong signal conditions), whereas the otherchannels continue to search satellites. Once there are enough satellites with valid ephemeris, the receiver can calculate
position and velocity data. Other GNSS receiver manufacturers call this startup mode Factory Startup.
• Warm start - In warm start mode, the receiver has approximate information for time, position, and coarse satellite position
data (Almanac). In this mode, after power-up, the receiver normally needs to download ephemeris before it can calculate
position and velocity data. As the ephemeris data usually is outdated after 4 hours, the receiver will typically start with a Warm
start if it has been powered down for more than 4 hours.
• Hot start - In hot start mode, the receiver was powered down only for a short time (4 hours or less), so that its ephemeris is
still valid. Since the receiver doesn't need to download ephemeris again, this is the fastest startup method.
Battery backed-up power supplied to the IMX preserves the GPS time, position, and coarse satellite position (almanac) while off.
GPS almanac data is typically valid for several weeks while the GPS is off.

13.3.2 Preintegrated IMU
Also known as Coning and Sculling Integrals, Δ Theta Δ Velocity, or Integrated IMU. For clarification, we will use the name
"Preintegrated IMU" through the User Manual. They are integrated by the IMU at IMU update rates (1KHz). These integrals arereset each time they are output. Preintegrated IMU data acts as a form of compression, adding the benefit of higher integration
rates for slower output data rates, preserving the IMU data without adding filter delay. It is most effective for systems that havehigher dynamics and lower communications data rates.

13.3.3 IMU Bias Repeatability (Turn-on to Turn-on Bias)
The initial bias will be different for each power up of the IMU due to signal processing initial conditions and physical properties.
A more repeatable bias allows for better tuning of INS parameters and faster estimate of the bias, whereas a more variable initialturn-on bias causes more difficult and longer INS convergence startup time.

13.3.4 IMU Bias Stability (In-Run Bias)
Describes the amount of bias change during any one run-time following poweron. This change is caused by temperature, time,and mechanical stress. The INS navigation filter estimates the IMU biases in order to improve the state estimate. The IMU bias
stability directly impacts the accuracy of the INS output.

13.3.5 Random Walk
The IMU sensors measure a signal as well as noise or error, described as a stochastic process. During IMU integration in theINS, sensor noise is accumulated and produces a random walk or drift on the final solution. Random walk has a direct effect on
the accuracy of the INS output.

13.3.6 Sensor Orthogonality (Cross-Axis Alignment Error)
The three axis gyro and accelerometer sensors found in an IMU have measurement axes at 90 degrees from each other,maximizing the observability of the system. In practice, these sensing axes in a three axis sensor are not perfectly at 90 degrees
of each other, or misaligned slightly due to manufacturing imperfection. This misalignment results in integration error in the INS- 322/348 -©2022

13.3.6 Sensor Orthogonality (Cross-Axis Alignment Error)

and impacts accuracy. To correct for cross-axis alignment error, the IMU is calibrated during manufacturing in a controlled
motion environment.

- 323/348 -©2022

13.4 Interference Considerations

13.4 Interference Considerations
Electrical interference or noise can be coupled into the Inertial Sense module in the form of electromagnetic interference (EMI)through the air or electrically conducted through wiring. Sources for interference include:• EMI at the GPS antenna.
• EMI at the IMX module.
• EMI conducted through the power supply or I/O lines.
Common sources for noise and interference are digital lines, USB 3.x, noisy power supplies, etc.

13.4.1 Detecting Interference
To detect if interference is being coupled into the Inertial Sense sensor module, it can be compared with a stock EVB demo unit
to compare noise figures. This is done by using the following steps. If both steps pass, there is no noise being coupled into themodule. Optionally connect multiple sensor modules can be connected to the EvalTool in parallel to compare noise.
1. Evaluate the IMU sensor - Make sure the unit is stationary (on a table or non-moving surface) and not seeing any vibrations.
Watch the standard deviation columns labeled "σ" in the Sensors tab of the EvalTool. This shows the noise level over the past 5
seconds, which means the device needs to be completely stable for 5 seconds to be accurate. Compare this figure between the
integrated sensor module and EVB demo unit.
2. Evaluate GPS sensitivity – In clear view of the sky, monitor the satellite signal strength through the DID_GPS_NAV.cnoMax and
DID_GPS_NAV.cnoMean fields in the EvalTool "Data Sets" tab or in the EvalTool "GPS" tab. See that the strongest (largest) CNO values

are roughly the same between the integrated sensor module and the EVB demo unit.

13.4.2 Interference Mitigation
The best solution is to stop the EMI (emitted) or conducted noise at its source. If it is not possible to completely eliminate thesource, the following methods should be considered depending on the cause of interference:• GPS antenna location - Position the GPS antenna at the top of the vehicle, clear of obstructions and away from noise sources
such as motors, processors, USB cables, digital devices, etc. USB 3.x typically generates quite a bit of EMI and interferes with
the GPS. Added shielding and/or signal inline USB filters can be added USB 3.x to reduce EMI and mitigate GPS interference.
Symptoms of GPS interference are poor GPS CNO signal strength, long times to lock, slip out of lock, etc.
• GPS antenna ground plane - Adding a 2"-3" diameter metallic ground plane below the GPS antenna will improve CNO noise
ratio and improve sensitivity. This can help in noisy environments. You can use any scrap metal or PCB to test the concept bysimply placing it below the GPS antenna (no electrical grounding required). The ground plane can have holes to reduce theweight and aerodynamic effects.

- 324/348 -©2022

13.4.3 Magnetic Interference• Shielding around the Inertial Sense module - This can further prevent EMI from being absorbed by potentially GPS
sensitive circuitry on the module.
• Digital signals - Making sure best practices for electrical current return paths for both common mode and differential mode
signals can be key for this. Customers have seen GPS interference caused by USB 3.x and have have resolved the issues using
shielding and inline USB filters.
• Power supply filtering - This may be necessary on systems with significant digital noise. LC filters or similar filters can be
added inline between the power supply and the IMX supply input (Vcc). Common switching mode/buck voltage regulators
should be fine for use with the IMX module and not require additional filtering.
Please contact us at support@inertialsense.com if further support is needed.

13.4.3 Magnetic Interference
Magnetic interference may impact IMX magnetometer performance if surrounded by steel or ferrous material or near motors,
motor drivers, or other electronics that cause EMI. This interference can be observed in the magnetometer output,
magnetometer status, and INS heading. Make sure all components are fixed in location during this test. While powering andactuating the various interference sources, observe the following:• Magnetometer Output should remain constant and not deviate. (EvalTool Sensors tab)
• Magnetometer Status should remain good and not indicate interference. (EvalTool INS tab, "Mag used" green = good,yellow = interference)• INS Heading (yaw) estimate should not drift or change direction. (EvalTool INS tab, "Yaw")
If any of these items are affected during the test, the system may result in incorrect magnetometer and heading values.

13.4.4 Mechanical Vibration
The system accuracy may degrade in the presence of mechanical vibrations that exceed 3 g of acceleration. Empirical data showsdegradation at approximately 100 - 150 Hz. Adding vibration isolation to the mount may be necessary to reduce the vibrations
seen by the product and to improve accuracy.

13.4.5 Temperature Sensitivity
The system is designed to compensate for the effects of temperature drift, which can be found in typical operation. However,rapid hardware temperature changes can result in degraded accuracy of the IMU calibration, GPS position, and INS estimate.
Rapid temperature change can be caused by direct exposure to wind, sun, and other elements.

- 325/348 -©2022

13.5 Magnetometer

13.5 Magnetometer
The magnetometer is used to estimate heading when the system is in any of the following conditions:
1. is in AHRS mode
2. has no GPS fix
3. has GPS fix and constant velocity (non-accelerating motion)
To have accurate heading under these conditions, the magnetometer must be calibrated. The system allows for two types ofmodes for recalibration, external initiated and automatically initiated re-calibration. Regardless of the recalibration mode, aslower online background calibration runs that continuously improves the magnetometer calibration to handle local magnetic
environment changes. All magnetometer calibration is stored in flash memory and available on bootup.

13.5.1 Disable Magnetometer Updates
Magnetometer fusion into the INS and AHRS filter can be disabled by setting bit SYS_CFG_BITS_DISABLE_MAGNETOMETER_FUSION(0x00001000) of DID_FLASH_CONFIG.sysCfgBits .

13.5.2 Magnetometer Recalibration
Occasionally the magnetometer will require a complete recalibration, replacing the old calibration with an entirely new
calibration. This is accomplished either through external or automatic initiated recalibration. Use of the different modes isgenerally governed by the particular use case for the end customer and is intended to allow for the most flexibility in an
integrated product design.

External Recalibration
External magnetometer recalibration allows the most flexibility in determining when an end user will need to recalibrate thesystem. This control over the timing of the recalibration is critical for many use cases and allows product designers to implement
their desired workflows for customers. Further there are use cases where automatic recalibration is not possible because thequality of the magnetometer calibration is not observable. Such use cases would include AHRS operation, extended periods
without motion or no GNSS fix. External magnetometer recalibration, as the name suggests is triggered by an external commandfrom the application managing the IMX hardware. The IMX provides a set of status messages indicating the quality of themagnetometer calibration and leaves the timing and implementation of a recalibration up to the product designer. Specifically,
INS_STATUS_MAG_INTERFERENCE_OR_BAD_CAL is an indication of the quality of the magnetometer calibration (see system status flags fordetails).
During the calibration process, the system should be clear of steel, iron, magnets, or other ferrous materials (i.e. steel desks,
tables, building structures). The IMX should be attached to the system in which it is operating and rotated together during thecalibration process. The following is theForce magnetometer recalibration procedure:
1. Set DID_MAG_CAL.recalCmd to either: * MAG_CAL_STATE_MULTI_AXIS (0) for Multi-Axis which is more accurate and requires 360⁰ rotation
about two different axes. * MAG_CAL_STATE_SINGLE_AXIS (1) for Single-Axis which is less accurate and requires 360⁰ rotation about
one axis.
2. Rotate the system accordingly.
Recalibration completion is indicated by either:
1. INS_STATUS_MAG_RECALIBRATING bit of the insStatus word set to zero. The insStatus word is found in standard INS output messages( DID_INS_1 , DID_INS_2 , DID_INS_3 , and DID_INS_4 ).
2. DID_MAG_CAL.progress is 100.

- 326/348 -©2022

13.5.3 Magnetometer Continuous Calibration

Recalibration progress is indicated as a percentage (0-100%) is indicated can be observed from variable DID_MAG_CAL.progress .
The recalibration process can be canceled and the prior calibration restored anytime by setting DID_MAG_CAL.enMagRecal =MAG_RECAL_MODE_ABORT (101).

The “Mag used” indicator in the EvalTool INS tab will be green when magnetometer data is being fused into the solution, blackwhen not being fused into the solution, and red during recalibrating.
Example code:#include "com_manager.h"// Set DID_MAG_CAL.enMagRecal = 0 for multi-axis recalibration
int32_t value = MAG_RECAL_MODE_MULTI_AXIS;
sendDataComManager(0, DID_MAG_CAL, &value, 4, offsetof(mag_cal_t, enMagRecal));// Enable broadcast of DID_MAG_CAL.progress every 100ms to observe the percent complete
sendDataComManager(0, DID_MAG_CAL, 0, sizeof(mag_cal_t), 100);

Automatic Recalibration
Automatic magnetometer recalibration is useful for systems where user intervention to start external calibration is notconvenient or practical. In this mode, the solution will determine that the system needs to be recalibrated and will attempt to doso while in normal operation. In the period while the system is recalibrating, the uncalibrated magnetometer data is used toprevent the INS heading from drifting but it does not provide heading measurements to the state estimator. This feature isenabled by setting bit SYS_CFG_BITS_AUTO_MAG_RECAL (0x00000004) of DID_FLASH_CONFIG.sysCfgBits non-volatile word.
// Enable automatic magnetometer calibration.
DID_FLASH_CONFIG.sysCfgBits |= SYS_CFG_BITS_AUTO_MAG_RECAL;// Disable automatic magnetometer calibration.
DID_FLASH_CONFIG.sysCfgBits &= ~SYS_CFG_BITS_AUTO_MAG_RECAL;

13.5.3 Magnetometer Continuous Calibration
To mitigate the need for recalibration (completely replace calibration data), continuous calibration improves the magnetometer
calibration slowly over time. Continuous calibration always runs in the background.

13.5.4 Magnetometer Calibration Settings
The magnetometer calibration algorithm can produce higher quality calibrations when data more data is collected acrossmultiple axes of rotation. However, there are use cases where data collection beyond a single axis is impractical if not impossible.
To address this issue there is a setting in the flash to configure the data requirement threshold for magnetometer calibration.
The available settings include:• Single Axis Calibration – This setting requires a full rotation in the yaw axis (relative to earth) to determine the calibration.
Additional data that is collected via motion on other axes is used but not required. Once a full rotation is completed thecalibration is calculated and the online continuous calibration is started.
• Multi Axis Calibration – This setting requires data to be collected across at least two axes, where one is the yaw axis. Thiscalibration mode does not have any specific angular rotational requirements in any given axes, but it does require that data
has been collected across a sufficient angular span. There is an indicator (mag_cal_threshold_complete) in the
DID_SYS_PARAMS message that relates the total percent of the required threshold that has been collected. As more data iscollected this value will increment to 100% at which point the calibration will be calculated and the online continuous
calibration will continue to run/*! Magnetometer recalibration. 0 = multi-axis, 1 = single-axis */SYS_CFG_BITS_MAG_RECAL_MODE_MASK = (int)0x00000700,
SYS_CFG_BITS_MAG_RECAL_MODE_OFFSET = 8,

- 327/348 -©2022

13.6 System Status13.6 System Status
13.6.1 Solution Status
Solution Alignment
Solution alignment occurs when aiding sensor and state estimation are in agreement and indicates that solution output can betrusted.
HEADING ALIGNMENT

Heading alignment varies based on available sensors and conditions of motion.
Stationary INS and AHRS (no GPS) use the magnetometer for heading alignment. The INS solution will start and remain in
INS_ALIGNING status (1) until the magnetometer calibration is validated. The magnetometer requires +- 45 degrees of rotation
to validate calibration and ensure accurate heading.
Moving INS (under accelerated conditions) or Dual GNSS (two GPS antennas using RTK compassing) can align the heading
without use of the magnetometer. The INS solution will start in INS_ALIGNING status (1) and immediately proceed to
INS_NAV_IS_GOOD status (3) with GPS lock for Dual GNSS and accelerated horizontal movement for single GNSS INS use.

- 328/348 -©2022

13.6.1 Solution Status

LED Status
System status including GPS lock, INS alignment, and time synchronization are reported via the top tri-color LED. This LED canbe disabled (turned off) by setting bit 0x4 of DID_FLASH_CONFIG.sysCfgBits.
LED Behavior

Solution

StatusDescription

Status #
White
Cyan

1

Solution Aligning The solution is aligning on startup

2

Solution

The solution has aligned but insufficient dynamics have been

Alignmentcompleted for the variance to reach nominal conditions.

CompleteGreen

3

Solution Good –The solution is in Navigation mode and state estimate is good.

NAV
Blue

5

Solution Good –The solution is in AHRS mode and state estimate is good. There is no

AHRS

valid position or velocity data from GPS or other aiding sensor. Only
the attitude states are estimatedOrange4,6Solution HighThe solution is in Navigation or AHRS mode but variance (uncertainty)

Variance

is high. This may be caused by excessive sensor noise such as
vibration, magnetic interference, or poor GPS visibility or multipath
errors. See DID_INL2_VARIANCE.

PurpleCyan Fading

Magnetometer

The system is collecting new magnetometer calibration data and

Recalibration

requires rotation.

Bootloader

The bootloader has started and is waiting for communications.

Waiting
Purple Fast Blink

Firmware Upload The bootloader is uploading the embedded firmware.

Orange Fast Blink

Firmware

The bootloader is verifying the embedded firmware.

Verification
Bootloader

Red

The bootloader has experienced a failure on startup.

FailureCan combine with behaviors above
Red pulse every 1s

Red/purple pulse every 1s

GPS PPSThe system has received and synchronized local time to UTC time

Syncusing the GPS PPS signal.

RTK Base

The system is receiving RTK base station data.

Data
Received
Purple pulse every 1s

RTK Fix

The GPS has valid RTK fix and high precision positioning

StatusStatus flags described in this section that can be observed by bitwise ANDing any of the status flag bitmasks with thecorresponding status flags variable.

Status Flags
This section lists the commonly used status flags. A complete listing of status flags is available in data_sets.h.

- 329/348 -©2022

13.6.1 Solution Status

INSSTATUS – INS STATUS FLAGSThe INS status flags, insStatus, are found in the DID_INS1, DID_INS2, DID_INS3, and DID_SYS_PARAMS messages. Bitmasks
for the insStatus flags are defined in eInsStatusFlags in data_sets.h.
Field

Description

INS_STATUS_ALIGN_COARSE_MASK

Position, Velocity & Attitude are usable. Variance of the state estimate areoutside spec.

INS_STATUS_ALIGN_GOOD_MASK

Position, Velocity & Attitude are good. Variance of state estimate are within
spec.

INS_STATUS_GPS_AIDING_HEADING

INS heading are being corrected by GPS.

INS_STATUS_GPS_AIDING_POS

INS position and velocity are being corrected by GPS.

INS_STATUS_GPS_UPDATE_IN_SOLUTION

GPS update event occurred in INS, potentially causing discontinuity inposition path.

INS_STATUS_MAG_AIDING_HEADING

INS heading are being corrected by magnetometer.

INS_STATUS_NAV_MODE

AHRS = 0 (no position or velocity), NAV = 1

INS_STATUS_MAG_RECALIBRATING

Magnetometer is recalibrating.

INS_STATUS_MAG_NOT_GOOD

Magnetometer is experiencing interference.

INS_STATUS_SOLUTION_MASK

0=INS_INACTIVE – The INS is not runnning
1=INS_STATUS_SOLUTION_ALIGNING – The INS is aligning on startup
2=INS_STATUS_SOLUTION_ALIGNMENT_COMPLETE – The INS hasaligned but insufficient dynamics have been completed for the variance toreach nominal conditions.
3=INS_STATUS_SOLUTION_NAV – The INS is in NAV mode and the state
estimate is good.
4=INS_STATUS_SOLUTION_NAV_HIGH_VARIANCE – The INS is in NAV
mode and the state estimate is experiencing high variance. This may becaused by excessive noise on one or more sensors, such as vibration, magnetic
interference, poor GPS sky visibility and/or GPS multipath errors. See
DID_INL2_VARIANCE.
5=INS_STATUS_SOLUTION_AHRS – INS is in AHRS mode and the solution
is good. There is no valid position correction data from GPS or other aiding
sensor. Only the attitude states are estimated.
6=INS_STATUS_SOLUTION_AHRS_HIGH_VARIANCE – INS is in AHRS
mode and the state estimate has high variance. See DID_INL2_VARIANCE.

- 330/348 -©2022

13.6.2 Built-in Test (BIT)HDWSTATUS – HARDWARE STATUS FLAGS

The hardware status flags, hdwStatus, are found in the DID_INS1 , DID_INS2 , DID_INS3 , and DID_SYS_PARAMS messages. Bitmasks
for the hdwStatus flags are defined in eHdwStatusFlags in data_sets.h.
Field

Description

HDW_STATUS_MOTION_MASK

Accelerometers and Gyros are operational

HDW_STATUS_GPS_SATELLITE_RX

Antenna is connected to the GPS receiver and signal is received

HDW_STATUS_STROBE_IN_EVENT

Event occurred on strobe input pin

HDW_STATUS_SATURATION_MASK

Acc., Gyro, Mag or Baro is saturated

HDW_STATUS_SELF_TEST_FAULT

BIT has failed

HDW_STATUS_ERR_TEMPERATURE

Outside of operational range

HDW_STATUS_FAULT_BOD_RESET

Low Power Reset

HDW_STATUS_FAULT_POR_RESET

Software or Triggered Reset

13.6.2 Built-in Test (BIT)
Built-in test (BIT) is enabled by setting DID_BIT.state to any of the following values.
BIT_STATE_CMD_FULL_STATIONARY= (int)2, // (FULL) Comprehensive test. Requires system be completely stationary without vibrations.
BIT_STATE_CMD_BASIC_MOVING= (int)3, // (BASIC) Ignores sensor output. Can be run while moving. This mode is automatically run after
bootup.
BIT_STATE_CMD_FULL_STATIONARY_HIGH_ACCURACY = (int)4, // Same as BIT_STATE_CMD_FULL_STATIONARY but with higher requirements for accuracy.

BIT takes about 5 seconds to run, and is completed when DID_BIT.state == BIT_STATE_DONE (1) . All BIT tests except those related
to GPS require the system to be stationary to be accurate.

hdwBitStatus – Hardware BIT Flags
Hardware BIT flags are contained in hdwBitStatus, found in the DID_BIT message. Bitmasks for the hdwBitStatus flags aredefined in eHdwBitStatusFlags in data_sets.h.
Field

Description

HDW_BIT_PASSED_ALL

All HBIT are passed

HDW_BIT_PASSED_AHRS

All Self Tests passed without GPS signal

HDW_BIT_FAILED_MASKOne of the built-in tests failed

HDW_BIT_FAULT_GPS_NO_COM

No GPS Signal

HDW_BIT_FAULT_GPS_POOR_CNO

Poor GPS signal. Check Antenna

HDW_BIT_FAULT_GPS_ACCURACY

Poor GPS Accuracy or Low number of satellites

calBitStatus – Calibration BIT Flags
Calibration BIT flags are contained in calBitStatus, found in the DID_BIT message. Bitmasks for the calBitStatus flags aredefined in eCalBitStatusFlags in data_sets.h.
Field

Description

CAL_BIT_PASSED_ALL

Passed all calibration checks

CAL_BIT_FAILED_MASKOne of the calibration checks failed- 331/348 -©2022

13.6.3 Health Monitoring

13.6.3 Health Monitoring
This section illustrates tests used for system health monitoring in common application.
1. Communication Check
To check that cabling between the unit and the application is working after initialization, expect that the initial expected packets
are received within 3 seconds.
2. Sensor Test (Must be Stationary)
These tests are ideal for manufacturing and periodic in-field testing. Initiate by setting DID_BIT.state = 2 .
Test

Description

hdwBitStatus & HDW_BIT_PASSED_ALL

Hardware is good

calBitStatus & CAL_BIT_PASSED_ALL

Sensor calibration is good

1. GPS Hardware Test
Initiate by setting DID_BIT.state = 2 .
Test

Description

hdwBitStatus & HDW_BIT_FAULT_GPS_NO_COM

No GPS serial communications.

hdwBitStatus & HDW_BIT_FAULT_GPS_POOR_CNO

Poor GPS signal strength. Check antenna.

1. GPS Lock Test
Test

Description

hdwStatus & INS_STATUS_USING_GPS_IN_SOLUTION

GPS is being fused into INS solution

1. INS Output Valid
Test

Description

insStatus & INS_STATUS_ATT_ALIGN_GOOD

Attitude estimates are valid

insStatus & INS_STATUS_VEL_ALIGN_GOOD

Velocity estimates are valid

insStatus & INS_STATUS_POS_ALIGN_GOOD

Position estimates are valid

1. System Temperature
System temperature is available at DID_SYS_SENSORS.temp.
2. Communications Errors
HDW_STATUS_COM_PARSE_ERROR_COUNT(DID_SYS_SENSORS.hStatus) is the number of parsed packet errors encountered.

- 332/348 -©2022

14. User Manual PDF

14. User Manual PDF
This document is provided to allow users to capture a snapshot of our current documentation. The PDF is an automaticallygenerated printout of the current online documents so there are known link and image sizing issues. We encourage
use the online documentation which is maintained for customer accessibility.
Download PDF- 333/348 -©2022

15. Frequently Asked Questions

15. Frequently Asked Questions
15.1 What is a Tactical Grade IMU?
An Inertial Measurement Unit (IMU) is industry qualified as "Tactical Grade" when the In Run Bias Stability (IRBS) of thegyroscopes is between 0.5 deg/hour and 5 deg/hour. The IRBS represents the IMU stability during benign conditions (i.e. ideal
integration time, stable temperature, and no inertial motion).
IEEE-STD-952-1997 defines IRBS as the minima on the Allan Variance curve. The following plots identify the Allan Variance
representation of four IMX-5 tactical grade IMUs (serial numbers 60071, 60079, 60112, and 60114).

- 334/348 -©2022

15.2 Why the name change from uINS to IMX?

15.2 Why the name change from uINS to IMX?
The name IMX means inertial measurement device with extensible capabilities. IMX is a derivative of the acronym IMU. Our
flagship product was named the uINS which means miniature Inertial Navigation System (INS). This name has helped others to- 335/348 -©2022

15.3 What is Inertial Navigation?

recognize the inertial navigation functionality. However, we felt that a more generic name would better cover all of the various
functionality and capabilities contained in the IMX, namely:• Tactical grade Inertial Measurement Unit (IMU)• Barometer and magnetometer sensors• Vertical Reference Unit (VRU)• Attitude Heading Reference System (AHRS)• GNSS aided Inertial Navigation System (GNSS-INS or GPS-INS)• RTK-GNSS aided INS• Dual-GNSS (GPS compassing) aided INS• Ground vehicle Dead Reckoning system

15.3 What is Inertial Navigation?
Inertial navigation is a technique of estimating position, velocity, and orientation (roll, pitch, heading) by integrating IMU inertial
motion data from gyros and accelerometers to continuously calculate the dead reckoning position. The inertial sensors aresupplemented with other sensors such as GPS, altimeter, and magnetometer. Inertial navigation is commonly used on moving
vehicles such as mobile robots, ships, aircraft, submarines, guided missiles, and spacecraft.

15.4 What does an Inertial Navigation System (INS) offer over GPS alone?
Dead Reckoning - An inertial navigation system (INS) integrates the IMU data to dead reckon (estimate position and velocity)
between GPS updates and during GPS outage.
Higher Data Rates - Typical GPS receivers data rates vary from 1Hz to 20Hz whereas INS systems like the IMX have data rates
up to 1KHz.
Signal Conditioning - An INS filters out noise in the GPS data and provides a smoother, more continuous data stream.
Orientation Data - An INS is capable of observing the orientation (roll, pitch, and heading) of the system regardless of the
motion or direction of travel. This is because of how an INS fuses inertial data with GPS data. A GPS with one antenna canmeasure direction of travel (ground track heading) but cannot estimate vehicle roll, pitch, or heading.

15.5 Our Sensors - IMU vs AHRS vs INS
Inertial Measurement Unit (IMU) - Uses gyros and accelerometers to measure angular rate and linear acceleration.
Attitude Heading Reference System (AHRS) - Adds sensor fusion to IMU and magnetometer output to estimate orientation orroll, pitch, and heading.
Inertial Navigation System (INS) - Adds sensor fusion to IMU, GPS, magnetometer, and barometer data to estimate
orientation, velocity, and position.

15.5.1 I have my own GPS system and just need raw motion data, which sensor is for me?
If you have your own filters in place and need raw data for measuring motion, then the IMU is the best option. The IMU provides
raw, calibrated data for temperature, 3D acceleration (accelerometer), 3D magnetic field (magnetometer), and 3D rate of turn.

15.5.2 Which sensor will also provide attitude (roll/pitch/yaw) and heading data?
The AHRS sensor has all the capabilities of the IMU plus data on roll, pitch, and yaw. This sensor uses algorithms to fuse raw
data from the IMU with the Earth’s gravity to provide orientation and is perfect for a robotic arm or indoor floor cleaner.
I need geographic positional data. Which sensor contains a GPS?

- 336/348 -©2022

15.6 How long can the IMX dead reckoning estimate position without GPS?

If the AHRS doesn’t get you what you need, packaging this with one or more GPS sensors will give you the geographic positional
data you need. Like the AHRS, your sensor or should provide some sort of “sensor fusion” by combining all the data from each ofthese sensors to give a more accurate and holistic view of your rover’s state.
What do I need to get started?
We recommend beginning with some sort of Development Kit. Ours comes with all of the necessary components to simplify
testing and integration: the sensor you selected, the needed cable and antennas for connectivity, the firmware & software, and3-5 hrs of complementary engineering support from a team of Inertial Sense engineers.
Additionally, Inertial Sense provides customers with a custom datalogger, called the EvalTool. An easy to use data logging
software to test and troubleshoot your new sensor is essential to your sensor integration experience.

15.6 How long can the IMX dead reckoning estimate position without GPS?
The IMX inertial navigation integrates the IMU data to dead reckoning position and velocity estimation between GPS updates
and for a short period of time during GPS outages. This dead reckoning is designed to filter out GPS noise and provide cleaner
faster updates than are available via GPS alone. The IMX dead-reckons, or estimates position and velocity, between GPS updates
and through brief GPS outages. However, it is not designed for extended position navigation without GPS aiding. Dead reckoning
is disabled after 7 seconds of GPS outage in order to constrain position and velocity drift. The amount of position drift during
dead reckoning can vary based on several factors, including system runtime, motion experienced, and bias stability.

15.7 Can the IMX estimate position without GPS?
IMX can estimate the position for extended periods of time without GPS for ground vehicle dead reckoning applications only (seeGround Vehicle Dead Reckoning). When in standard mode (not ground vehicle dead reckoning) GPS is required to provide initial
position estimation and to aid in IMU bias estimation. The IMX can dead reckon (estimate position without GPS) for brief periodsof time. However, the quality of dead reckoning is a function of IMU bias estimation, which improves while the GPS is aiding theINS.

15.8 How does the IMX estimate roll/pitch during airborne coordinate turns (acceleration only in
the Z axis and not in the X and Y axes)?
Using acceleration alone will incorrectly indicate the platform is level. GPS informs the IMX extended Kalman filter (EKF) about
any motion the system experiences and as a result the EKF can distinguish between acceleration due to motion and gravity.
Without a GPS (in AHRS mode) the IMX EKF can only assume the direction of gravity equals the average direction ofacceleration measured slowly over time. The IMX can estimate roll/pitch under accelerated conditions during a coordinated turnbecause gyro integration prevents attitude drift over short term and level coordinate turns are cyclical allowing the averagegravity for an entire heading rotation to be observed. However, the IMX AHRS solution under accelerated conditions (moving)
will have degraded attitude accuracy. The IMX solution is more accurate when aided by GPS.

15.9 How does vibration affect navigation accuracy?
The IMX accuracy may degrade in the presence of mechanical vibrations that exceed 3g of acceleration. Empirical data showsdegradation at approximately 100 - 150 Hz. Adding vibration isolation to the mount may be necessary to reduce the vibrations
seen by the product and to improve accuracy.

15.10 Can the IMX operate underwater?
The IMX can only dead reckon for short periods of time and in general requires GPS to provide position and velocity data. The
GPS antenna must be above the water surface in order for the GPS to function properly. It is ideal that the GPS antenna be fixed
relative to the IMX (IMU) module in order to maintain precision when moving faster than 2 m/s or 0.8 m/s^2. However, the GPS
antenna may be tethered above the IMX, where the GPS antenna is floating on the water surface and the IMX is below the water- 337/348 -©2022

15.11 Can the IMX operate at >4g acceleration?

surface. System position will reflect the GPS antenna position and attitude (roll, pitch, heading) will reflect the IMX module
orientation.

15.11 Can the IMX operate at >4g acceleration?
Typical L1 GPS receivers lose fix above 4g acceleration because the doppler variation starts to get too large and the receiver may
become unstable or not be able to get/keep a fix. Additionally, the acceleration begins to affect the stability of the GPS XTAL
oscillator.
On the IMX, the GPS will regain fix within seconds after acceleration drops below 4g. The IMX will track the velocity and position
using inertial navigation for up to 5 seconds of GPS outage. As long as GPS outage is below 5 seconds, the IMX should be able to
track position through a launch.

15.12 Customer Support
Have other questions or needs? Please email us at support@inertialsense.com.

- 338/348 -©2022

16. Troubleshooting

16. Troubleshooting
16.1 Firmware Troubleshooting
Please email support@inertialsense.com for assistance or to provide feedback on this user guide.

16.1.1 Data doesn't look rightIf the EvalTool or SDK are from a different release from the firmware on the unit, there may be communication protocol related
issues. It's best to keep both the software and firmware in sync with each other. The EvalTool should flag a protocol mismatch inthe settings tab.

16.1.2 Bootloader Not Responding
Check the following:• The input supply is at 3.3V and clean without noise.
• The serial connection is grounded (no floating grounds).
• The serial wires between the uINS module and the next active device (buffer, converter, or processor) are not longer than 1
meter when bootloading firmware.

16.1.3 Bootloader Update fails first time
If updating the bootloader firmware and using the USB direct connection on the IMX module (pins 1 and 2) or the EVB-2 (EVB
USB connector), the serial port number will change when the device switches from application mode to Bootloader Update mode.
This is expected and requires reselecting the new serial port and running the Bootloader Update process a second time.

16.1.4 System in AHRS mode despite GPS messages being received
If attempting to enter NAV mode but the system reports AHRS despite GPS data beig received, then assure your units are not set
to Rover RTK mode. This will override your ability to lock in GPS Nav mode.

16.1.5 "Bricked" System Recovery
There are different reasons a system may appear unresponsive and not communicate. The following sections describe how torecover a system from these states.

Attention
The ONLY indicator that the bootloader is running is the fading cyan module LED. NO communications will appear in the EvalTool or
CLTool. Attempt to update the firmware before performing a chip erase.

Attention
Hardware v3.1.3 and firmware IS_uINS-3_v1.2.1.0_b287_2017-09-17_103826.hex and older will not communicate and require
following these instructions to be recovered. Do NOT use the chip erase procedure for this scenario.

Stuck in Bootloader ModeIn some cases, the bootloader may fail to completely update firmware. This is indicated by the fading cyan status LED on the IMX
module. This can happen if older bootloader firmware is on the uINS and firmware version 1.7.1 is uploaded. If this happens, the- 339/348 -©2022

16.1.6 Troubleshooting with EvalTool

system will appear to be unresponsive in the EvalTool. The following process can be used to recover the system to a working
state:
If the bootloader is running, identified with the fading cyan color LED on the uINS module, following these steps:
1. Ensure uINS Firmware is Running - (This step is not necessary if the uINS firmware is running and the EvalTool iscommunicating with the uINS). Select the device serial port and update the firmware using 1.6.4 or earlier. If the bootloader isrunning, version information will not appear in the EvalTool. The following bootloader update step will not work unless the
EvalTool is communicating with the uINS firmware.
2. Update the Bootloader - Use the EvalTool "Update Bootloader" button in the Settings tab to upload the latest bootloader
firmware. If it has a fading cyan color on the uINS module, the bootloader is running and ready for new firmware to be loaded. The
bootloader can only be updated using serial0 or the native USB connection.
3. Update the Firmware - Use the EvalTool "Update Firmware" button to upload the latest uINS firmware.
If neither the bootloader or the uINS firmware are running, identified with the solid or no LED status on the uINS module, pleasecontacts us.

Recovery for Firmware v1.2.1.0
Hardware v3.1.3 and newer and firmware IS_uINS-3_v1.2.1.0_b287_2017-09-17_103826.hex and older result in a system thatruns but will not communicate properly. This older firmware was not designed for the newer hardware and consequently runs theprocessor at a slower speed, which alters all of the predefined baud rates to non-standard irregular baud rates. A symptom of
this problem is the LED flashing to indicate the processor activity and the module never communicates properly.
The following steps are provided to recover communications with the system.
1. Install and run the hotfix release 1.1.3 EvalTool.
2. Select the special baud rate 560,000 in the EvalTool and open the serial port.
3. Update the firmware using any version newer than IS_uINS-3_v1.2.1.0_b287_2017-09-17_103826.hex.
The latest EvalTool, CLTool, SDK, and firmware can be used once the firmware has been updated on the module.

16.1.6 Troubleshooting with EvalTool
Units Not Connecting
In the case that your units do not connect properly to the EvalTool, verify:
1. The baud rate is the same that you previously had when the Com Ports last opened correctly.
2. The LED on the unit is not showing solid white, flashing white, or solid red. These mean a failure occured in loading the bootloader(see User Guide for full LED descriptions).
3. If you are using a USB3.0 connection, the com port might take longer to show up than with USB2.0
4. Check your computer's Device Manager to see if your unit shows up there. If it doesn't show up, you may have an FTDI driverissue.
a. If you suspect you don't have the FTDI driver installed on your Windows computer, use the following links to download the driver: Executable for the FTDI USB driver: - https://ftdichip.com/wp-content/uploads/2023/09/CDM-v2.12.36.4-WHQL-Certified.zip Drives without executable. - http://www.ftdichip.com/Drivers/D2XX.htm- 340/348 -©2022

16.1.7 Downgrading uINS to 1.8.x Firmware

16.1.7 Downgrading uINS to 1.8.x Firmware
The following steps can be used to downgrade the uINS firmware to version 1.8.x (or older):1. Ensure the uINS is running 1.9.x (or newer) firmware.
2. Send the system commands SYS_CMD_MANF_UNLOCK and SYS_CMD_MANF_DOWNGRADE_CALIBRATION to the uINS to downgrade the IMU
calibration and put the system into bootloader update mode. This can be done using the EvalTool, cltool, or SDK .
a. EvalTool (version 1.9.1 or later): Use the firmware "Downgrade" button (EvalTool -> Settings -> General -> Factory ->Downgrade).
b. cltool (version 1.10 or later): Use option -sysCmd=1357924682 to send the downgrade command:./cltool -c /dev/ttyACM0 -sysCmd=1357924682

cltool alternate method: use option -edit 7 to edit the DID_SYS_CMD and send the downgrade command:./cltool -c /dev/ttyACM0 -edit 7

Use w and s to move the cursor up or down (arrow keys do not work) and enter to submit the new value. The invCommand value isthe bitwise inverse of the command and is required to validate the command. The command value will change to zero when the IMX
accepts the command and invCommand values.
Send manufacture unlock command:command = 1122334455
invCommand = 3172632840

Send downgrade command:command = 1357924682
invCommand = 2937042613

3. Verify the uINS has reboot into bootloader update mode. The host serial port will disappear and reappear. The uINS will NOT
support normal DID binary or NMEA communications in this mode, but will be ready to update the bootloader.
4. Update the bootloader and firmware using the 1.8.x EvalTool, cltool, or SDK. Be sure to use the bootloader v5d (or older) with the
1.8.x firmware.

Chip Erase Downgrade
The above process using the SYS_CMD_MANF_DOWNGRADE_CALIBRATION command is recommended as it prevents the need to reload the
IMU calibration onto the uINS. However, an alternative method to downgrade uINS to 1.8.x firmware is as follows:
1. Chip erase the uINS.
2. Load v5b (or older) bootloader and 1.8.x (or older) firmware using the 1.8.x EvalTool, cltool, or SDK.
3. Restore the IMU calibration.

16.1.8 1.7.6 Bug RTK Base GPS Raw work aroundIf you are having base raw errors on your Rover, in the bottom right of the Evaltool, or a climbing Diffrential Age, in Data Sets
DID_GPS1_RTK_REL, you maybe having this bug. Try this workaround.
1. Go-to settings tab, open the Base serial COM port.
2. Go-to Data Logs tab, under RCM Presets dropdown select PPD.
3. NOTE: You must leave the comport open on the Base.
4. Check your Rover to see if its still getting raw errors messages.

- 341/348 -©2022

16.2 Chip Erase16.2 Chip Erase
Please email support@inertialsense.com for assistance or to provide feedback on this user guide.

Steps for Chip-Erase Recovery

Warning
The CHIP ERASE (Reserved (CE) pin 17) erases all flash memory including firmware, settings and calibration. CHIP ERASE should
only be used as a last resort. This step should ONLY be used if the steps for Stuck in Bootloader Mode fail and there is NO othermethod to recover communications.

ImportantPlease notify support@inertialsense.com if this step is necessary so that we can keep track of cause of failures and provide you any
necessary support.

IMX CHIP ERASE PAD

On the IMX-5, CHIP ERASE is enabled if +3.3V (available on pin 22) is applied to the chip erase (CE) pin 17 during boot up frompower cycle or reset.

Connect +3.3V to pin 17 (CE) while power cycling the IMX to chip erase IMX.

- 342/348 -©2022

16.2 Chip Erase

EVB-2 CHIP ERASE PADS

Short R25 pads together to chip erase uINS.
Short R53 pads together to chip erase EVB-2.
RUGGED CHIP ERASE PADS

The chip erase pads on the Rugged-3 are a set of 0402 SMT pads with the label "ERASE". Shorting these pads together will apply+3.3V to the IMX chip erase pin 17. The power must be cycled while shorting these pads in order to apply chip erase to the
IMX-5.

- 343/348 -©2022

16.2 Chip Erase

Short "ERASE" pads together and reset to chip erase.

- 344/348 -©2022

16.2 Chip Erase

RESTORE FIRMWARE

1. Power on system
2. Record your IMX Serial Number - If you can read the serial number, record it for reference. On older firmware versions theserial number will be erased. New firmware versions store the serial number in a location that chip erase won't touch.
3. Chip Erase IMX - Assert Chip Erase (Reserved (CE) pin 17) on the IMX longer than 100ms by connecting to +3.3V. +3.3V isavailable on pin 2 of all EVB headers. Warning!!! - CHIP ERASE erases all flash memory (including firmware, settings, andcalibration) and should only be used as a last resort. This step should ONLY be used if there is NO other method to recovercommunications.
4. Reset the system
5. Enable EvalTool Internal Mode - This exposes the "Manufacturing" tab used to upload calibration data.
6. Restore the application and bootloader firmware - Use the "Update Firmware" button in the EvalTool Settings tab to load thebootloader firmware and IMX firmware.
ENABLE EVALTOOL INTERNAL MODE

EvalTool internal mode is used to access the EvalTool Manufacturing tab, used to restore serial numbers and calibration data.
1. Close the EvalTool so it isn't running.
2. Using a text editor, change the value of "DBGINT" to 99 (i.e. "DBGINT": 99, ) in settings file: C:\Users\[USERNAME]\Documents\Inertial Sense\settings.json.
3. Restart EvalTool and verify "[INTERNAL MODE]" is in the title bar.
RESTORE SENSOR CALIBRATION

Contact InertialSense and provide your uINS serial number to request the sensor calibration that corresponds with your uINS.
Use the EvalTool to upload the senor calibration onto your uINS.
1. Ensure the EvalTool is in Internal Mode which provides access the Manufacturing tab.
2. Ensure uINS is communicating with EvalTool.
3. Upload calibration data: EvalTool -> Manufacturing Tab -> "Load" button next to "System Test" button.
4. Verify "TC Pts" which is the number of calibration points located just below the "Load" button changes from "0,0" to two numbers
larger than 12 (i.e. "18,18").
5. Reset the uINS.
6. Run "Built-In Test" - Verify the built-in test passes by pressing the "Built-In Test" button in the EvalTool INS tab.
7. Verify IMU output - Place the uINS on a flat level surface. Using the EvalTool Sensor tab, verify that the gyro rates are near zero,
the accelerometer X and Y axes are near zero, and accelerometer Z axis is near -9.8m/s^2 for gravity.

- 345/348 -©2022

16.3 IMX Firmware Troubleshooting

16.3 IMX Firmware Troubleshooting
16.3.1 Antenna Baseline
Separation between GNSS antennas (or baseline distance) impacts the accuracy and fix time of the solution. Typical Dual GNSS
heading fix time is 60-90 seconds using a 1 meter baseline. Baseline distances shorter than 1 meter will impact both heading
accuracy and time to fix. However, having a short baseline of 0.35m should not cause an extremely long fix time.
ITEM TO TEST: Try increasing the antenna baseline to 0.5m or greater during initial testing.

16.3.2 Satellite CNO Strength, RFI and EMI
What is the satellite CNO (signal strength) level? The mean CNO would ideally be above 38-40. Anything lower could indicate thepresence of RF interference (RFI) or electromagnetic interference (EMI). You can see this in the EvalTool GPS tab or the
DID_GPS1_POS message.

ITEM TO TEST: Try powering off portions of the system while running the IMX. You may even try running the IMX
independently to a separate computer to monitor the system so you can completely power off your system with the IMX stillrunning. Pay close attention to the GPS CNO during each change.

16.3.3 USB Interface
USB-3 has been known to interfere with wireless and GNSS systems. It is the most common source of interference that has been
experienced. Properly shielded cables or signal filters can address this.
ITEM TO TEST: Disable USB-3, digital busses, or various switching supplies and observe the satellite CNO level. CNO mean
should be near or above 40 dB/Hz.

- 346/348 -©2022

16.3.4 Antenna Ground Planes

16.3.4 Antenna Ground Planes
The ground planes should be adequately sized. Larger ground planes help but are generally not the root cause of poor
performance. Separate and common ground planes are both acceptable.
ITEM TO TEST: Try doubling the ground plane below the antenna. A simple sheet of metal placed below the antenna is fine.
This is also not likely the root cause but worth testing.

16.3.5 Antenna Cable Ground Loops
In come cases the GNSS antenna cable can form an electrical loop and cause interfere.
ITEM TO TEST: Try to ensure cables never loop back or are bundled. If possible shorten cables to smallest required length.
Monitor GPS CNO before and after.

16.3.6 Local Interference
In some cases we have seen object in close proximity to the GNSS antennas act as a multi-path surface, reflect GNSS signals
onto the GNSS antennas. Ensure no objects are near the antennas above the plane of the antennas.

- 347/348 -©2022

16.3.7 Antenna Orientation

16.3.7 Antenna Orientation
A more accurate heading can be achieved if the GNSS antennas have the same antenna orientation (point the same way). You
should consider rotating one or both GNSS antennas so the coax cable exit in the same direction on each antennas.
Mismatch- 348/348 -©2022