LORD MicroStrain 3DM-CV5-10 User manual

LORD Data Communications Protocol Manual
3DM®-CV5-10
Inertial Measurement Unit

MicroStrain®Sensing Systems
459 Hurricane Lane
Suite 102
Williston, VT 05495
United States of America
Phone: [phone]
www.microstrain.com
[e-mail]
[e-mail]
Copyright © 2018 LORD Corporation
3DM®, 3DM-DH®, 3DM-DH3®, 3DM-GX2®, Ask Us How™, DEMOD-DC®, DVRT®, EmbedSense®, FAS-A®, G-Link®,
Little Sensors, Big Ideas.®, LORD Microstrain®, Live Connect™, LXRS®, MathEngine®, MicroStrain®, MIP™, MXRS®, Node
Commander®, SensorCloud™, SensorConnect™, SG-Link®, Strain Wizard®, TC-Link®, V-Link®, Wireless Simplicity,
Hardwired Reliability™, and WSDA®are trademarks of LORD Corporation.
Document 8500-0070 Revision E
Subject to change without notice.

3DM®-CV5-10 DCP Manual
Table of Contents
1. API Introduction 6
2. Basic Programming 7
2.1 MIP Packet Overview 7
2.2 Command Overview 9
2.2.1 Example “Ping” Command Packet 9
2.2.2 Example “Ping” Reply Packet 10
2.3 Data Overview 10
2.3.1 Example Data Packet: 11
2.4 Example Setup Sequence 11
2.4.1 Continuous Data Example Command Sequence 12
2.4.2 Polling Data Example Sequence 15
2.5 Parsing Incoming Packets 16
2.6 Multiple Rate Data 17
2.7 Communications Bandwidth Management 18
2.7.1 UART Bandwidth Calculation 19
3. Command and Data Summary 21
3.1 Commands 21
3.1.1 Base Command Set (0x01) 21
3.1.2 3DM Command Set (0x0C) 21
3.2 Data 21
3.2.1 IMU Data Set (0x80) 21
4. Command Reference 23
4.1 Base Commands 23
4.1.1 Ping (0x01, 0x01) 23
4.1.2 Set To Idle (0x01, 0x02) 24

3DM®-CV5-10 DCP Manual
4.1.3 Get Device Information (0x01, 0x03) 25
4.1.4 Get Device Descriptor Sets (0x01, 0x04) 26
4.1.5 Device Built-In Test (0x01, 0x05) 27
4.1.6 Resume (0x01, 0x06) 29
4.1.7 GPS Time Update (0x01, 0x72) 29
4.1.8 Device Reset (0x01, 0x7E) 30
4.2 3DM Commands 32
4.2.1 Poll IMU Data (0x0C, 0x01) 32
4.2.2 Get IMU Data Base Rate (0x0C, 0x06) 33
4.2.3 IMU Message Format (0x0C, 0x08) 34
4.2.4 Enable/Disable Continuous Data Stream (0x0C, 0x11) 36
4.2.5 Device Startup Settings (0x0C, 0x30) 38
4.2.6 Accel Bias (0x0C, 0x37) 39
4.2.7 Gyro Bias (0x0C, 0x38) 40
4.2.8 Capture Gyro Bias (0x0C, 0x39) 41
4.2.9 Coning and Sculling Enable (0x0C, 0x3E) 42
4.2.10 UART Baud Rate (0x0C, 0x40) 43
4.2.11 Advanced Low-Pass Filter Settings (0x0C, 0x50) 44
4.2.12 Device Status (0x0C, 0x64) 46
4.3 Error Codes 48
5. Data Reference 49
5.1 IMU Data 49
5.1.1 Scaled Accelerometer Vector (0x80, 0x04) 49
5.1.2 Scaled Gyro Vector (0x80, 0x05) 50
5.1.3 Delta Theta Vector (0x80, 0x07) 50
5.1.4 Delta Velocity Vector (0x80, 0x08) 51
5.1.5 GPS Correlation Timestamp (0x80, 0x12) 52

3DM®-CV5-10 DCP Manual
6. MIP Packet Reference 53
6.1 Structure 53
6.2 Payload Length Range 53
6.3 MIP Checksum Range 53
6.4 16-bit Fletcher Checksum Algorithm (C Language) 53
7. Advanced Programming 54
7.1 Internal Diagnostic Functions 54
7.1.1 3DM-CV5-10 Internal Diagnostic Commands 54
7.2 Handling High Rate Data 54
7.2.1 Runaway Latency 54
7.2.2 Dropped Packets 54
7.3 Creating Fixed Data Packet Format 55
8. Glossary 56

3DM®-CV5-10 DCP Manual
1. API Introduction
The 3DM-CV5-10 programming interface is comprised of a compact set of setup and control commands
and a very flexible user-configurable data output format. The commands and data are divided into two
command sets and one data set corresponding to the internal architecture of the device. The command
sets consist of a set of “Base” commands (a set that is common across many types of devices) and a set of
unified “3DM” (3D Motion) commands that are specific to the LORD Sensing inertial product line. The data
set represent s the one type of data that the3DM- CV5- 10 is capable of producing: “IMU” (Inertial
Measurement Unit) data.
Base commands Ping, Idle, Resume, Get ID Strings, etc.
3DM commands Poll IMU Data, Estimation Filter Data, etc.
IMU data Acceleration Vector, Gyro Vector, etc.
The protocol is packet based. All commands, replies, and data are sent and received as fields in a
message packet. Commands are all confirmed with an ack/nack (with a few exceptions). The packets
have a descriptor type field based on their contents, so it is easy to identify if a packet contains IMU data,
commands, or replies.
6

3DM®-CV5-10 DCP Manual
2. Basic Programming
The 3DM-CV5-10 is designed to stream and IMU data packets over a common interface as efficiently as
possible. To this end, programming the device consists of a configuration stage where the data messages
and data rates are configured. The configuration stage is followed by a data streaming stage where the
program starts the incoming data packet stream.
In this section there is an overview of the packet, an overview of command and reply packets, an overview
of how an incoming data packet is constructed, and then an example setup command sequence that can
be used directly with the 3DM- CV5- 10 either through a COM utility or as a template for software
development.
2.1 MIP Packet Overview
This is an overview of the 3DM-CV5-10 packet structure. The packet structure used is the LORD “MIP”
packet. A reference to the general packet structure is presented in the MIP Packet Reference section.
An overview of the packet is presented here.
The MIP packet “wrapper” consists of a four byte header and two byte checksum footer:
7

3DM®-CV5-10 DCP Manual
The packet payload section contains one or more fields. Fields have a length byte, descriptor byte, and
data. The diagram below shows a packet payload with a single field.
8

3DM®-CV5-10 DCP Manual
Below is an example of a packet payload with two fields (gyro vector and mag vector). Note the
payload length byte of 0x1C which is the sum of the two field length bytes 0x0E +0x0E:
Header Packet Payload (2 Fields) Checksum
SYNC1
“u”
SYNC2
“e”
Descriptor
Set byte
Payload
Length
byte
Field 1
Length
Field 1
Descriptor Field 1 Data Field 2 Length
Field 2
Descriptor
Field 2
Data MSB LSB
0x75 0x65 0x80 0x1C 0x0E 0x05
0x3E 7A 63 A0
0xBB 8E 3B 29
0x7F E5 BF 7F
0x0E 0x06
0x3E 7A 63 A0
0xBB 8E 3B 29
0x7F E5 BF 7F
0xE0 0xC6
2.2 Command Overview
The basic command sequence begins with the host sending a command to the device. A command
packet contains a field with the command value and any command arguments.
The device responds by sending a reply packet. The reply contains at minimum an ACK/NACK field. If
any additional data is included in a reply, it appears as a second field in the packet.
2.2.1 Example “Ping” Command Packet
Below is an example of a “Ping” command packet from the Base command set. A “Ping” command
has no arguments. Its function is to determine if a device is present and responsive:
Header Packet Payload Checksum
SYNC1 “u SYNC2 “e” Descriptor
Set byte
Payload Length
byte
Field
Byte
Length
Field
Descriptor
Byte
Field Data MSB LSB
0x75 0x65 0x01 0x02 0x02 0x01 N/A 0xE0 0xC6
Copy-Paste version of command: “7565 0102 0201 E0C6”
The packet header has the “ue” starting sync bytes characteristic of all MIP packets. The descriptor
set byte (0x01) identifies the payload as being from the Base command set. The length of the
payload portion is 2 bytes. The payload portion of the packet consists of one field. The field starts
with the length of the field which is followed by the descriptor byte (0x01) of the field. The field
descriptor value is the command value. Here the descriptor identifies the command as the “Ping”
command from the Base command descriptor set. There are no parameters associated with the
ping command, so the field data is empty. The checksum is a two byte Fletcher checksum (see the
MIP Packet Reference for instructions on how to compute a Fletcher two byte checksum).
9

3DM®-CV5-10 DCP Manual
2.2.2 Example “Ping” Reply Packet
The “Ping” command will generate a reply packet from the device. The reply packet will contain an
ACK/NACK field. The ACK/NACK field contains an “echo” of the command byte plus an error code.
An error code of 0 is an “ACK” and a non-zero error code is a “NACK”:
Header Packet Payload Checksum
SYNC1 “u SYNC2 “e” Descriptor
Set byte
Payload Length
byte
Field
Byte
Length
Field
Descriptor
Byte
Field Data MSB LSB
0x75 0x65 0x01 0x04 0x04 0xF1 Command Echo: 0x01
Error code: 0x00 0xD5 0x6A
Copy-Paste version of reply:... “7565 0104 04F1 0100 D56A”
The packet header has the “ue” starting sync bytes characteristic of all MIP packets. The descriptor
set byte (0x01) identifies the payload fields as being from the Base command set. The length of the
payload portion is 4 bytes. The payload portion of the packet consists of one field. The field starts
with the length of the field which is followed by the descriptor byte (0xF1) of the field. The field
descriptor byte identifies the reply as the “ACK/NACK” from the Base command descriptor set. The
field data consists of an “echo” of the original command (0x01) followed by the error code for the
command (0x00). In this case the error is zero, so the field represents an “ACK”. Some examples of
non-zero error codes that might be sent are “timeout”, “not implemented”, and “invalid parameter in
command”. The checksum is a two byte Fletcher checksum (see the MIP Packet Reference for
instructions on how to compute a Fletcher two byte checksum).
The ACK/NACK descriptor value (0xF1) is the same in all descriptor sets. The value belongs to a
set of reserved global descriptor values.
The reply packet may have additional fields that contain information in reply to the command. For
example, requesting Device Status will result in a reply packet that contains two fields in the packet
payload: an ACK/NACK field and a device status information field.
2.3 Data Overview
The IMU data packet is generated by the device. When the device is powered up, it may be configured
to immediately stream the data packet out to the host or it may be “idle” and waiting for a command to
either start continuous data or to get data by “polling”. Either way, the data packet is generated by the
device in the same way.
10

3DM®-CV5-10 DCP Manual
2.3.1 Example Data Packet:
Below is an example of a MIP data packet which has one field that contains the scaled
accelerometer vector.
Header Packet Payload Checksum
SYNC1
“u
SYNC2
“e”
Descriptor
Set byte
Payload
Length byte
Field Byte
Length
Field
Descriptor
Byte
Field Data:
Accel vector (12 bytes,
3 float – X, Y, Z)
MSB LSB
0x75 0x65 0x80 0x0E 0x0E 0x04
0x3E 7A 63 A0
0xBB 8E 3B 29
0x7F E5 BF 7F
0x84 0xEE
Copy-Paste version: "7565 800E 0E04 3E7A 63A0 BB8E 3B29 7FE5 BF7F 84EE”
The packet header has the “ue” starting sync bytes characteristic of all MIP packets. The descriptor
set byte (0x80) identifies the payload field as being from the IMU data set. The length of the packet
payload portion is 14 bytes (0x0E). The payload portion of the packet starts with the length of the
field. "E The field descriptor byte (0x04) identifies the field data as the scaled accelerometer vector
from the IMU data descriptor set. The field data itself is three single precision floating point values of
4 bytes each (total of 12 bytes) representing the X, Y, and Z axis values of the vector. The checksum
is a two byte Fletcher checksum (see the MIP Packet Reference for instructions on how to compute
a Fletcher two byte checksum).
The format of the field data is fully and unambiguously specified by the descriptor. In this example,
the field descriptor (0x04) specifies that the field data holds an array of three single precision IEEE-
754 floating point numbers in big-endian byte order and that the values represent units of “g’s” and
the order of the values is X, Y, Z vector order. Any other specification would require a different
descriptor (see the Data Reference section of this manual).
Data polling commands generate two individual reply packets: An ACK/NACK packet and a data
packet. Enable/Disable continuous data commands generate an ACK/NACK packet followed by
the continuous stream of data packets.
2.4 Example Setup Sequence
Setup involves a series of command/reply pairs. The example below demonstrates actual setup
sequences that you can send directly to the 3DM-CV5-10 either programmatically or by using a COM
utility. In most cases only minor alterations will be needed to adapt these examples for your application.
11

3DM®-CV5-10 DCP Manual
2.4.1 Continuous Data Example Command Sequence
Most applications will operate with the 3DM-CV5-10 sending a continuous data stream. To reduce
the amount of streaming data, if present during the configuration, the device is placed into the idle
state while performing the device initialization; when configuration is complete, the required data
streams are enabled to bring the device out of idle mode. Finally, the configuration is saved so that it
will be loaded on subsequent power-ups, eliminating the need to perform the configuration again.
1. Put the Device in Idle Mode
Send the "Set To Idle" command to put the device in the idle state (reply is ACK/NACK), disabling
the data-streams. This is not required but reduces the parsing burden during initialization and
makes visual confirmation of the commands easier.
MIP Packet Header Command/Reply Fields Checksum
SYNC1
“u
SYNC2
“e”
Descriptor
Set byte
Payload
Length
Field
Length
Cmd.
Descriptor Field Data MSB LSB
Command:
Set to Idle
0x75 0x65 0x01 0x02 0x02 0x02 N/A 0xE1 0xC7
Reply:
ACK/NACK
0x75 0x65 0x01 0x04 0x04 0xF1 Cmd echo: 0x02
Error code: 0x00 0xD6 0x6C
Copy-Paste version of the command: “7565 0102 0202 E1C7”
2. Configure the IMU Data-stream Format
Send a “Set IMU Message Format” command (reply is ACK/NACK). This example requests GPS
correlation timestamp, scaled gyro, and scaled accelerometer information at 100 Hz (1000Hz base
rate divided by a rate decimation of 10 on the3DM-CV5-10 = 100 Hz.) This will result in a single
IMU data packet sent at 100Hz containing the IMU GPS correlation timestamp followed by the
scaled gyro field and the scaled accelerometer field. This is a very typical configuration for a base
level of inertial data. If different rates were requested, then each packet would only contain the data
quantities that fall in the same decimation frame (see the Multiple Rate Data section). If the stream
was not disabled in the previous step, the IMU data would begin stream immediately.
Please note, this command will not append the requested descriptors to the current IMU data-
stream configuration, it will overwrite it completely.
12

3DM®-CV5-10 DCP Manual
MIP Packet Header Command/Reply Fields Checksum
SYNC1
“u
SYNC2
“e”
Descriptor
Set byte
Payload
Length
Field
Length
Cmd.
Descriptor Field Data MSB LSB
Command:
New IMU
Message
Format
0x75 0x65 0x0C 0x0D 0x0D 0x08
Function: 0x01
Desc. count: 0x03
GPS TS Desc.: 0x12
Rate Dec: 0x000A
Accel Desc.: 0x04
Rate Dec: 0x000A
Ang Rate Desc: 0x05
Rate Dec: 0x000A
0x45 0xF2
Reply:
ACK/NACK
0x75 0x65 0x0C 0x04 0x04 0xF1 Cmd echo: 0x08
Error code: 0x00 0xE7 0xBA
Copy-Paste version of the command: “7565 0C0D 0D08 0103 1200 0A04 000A 0500 0A45 F2”
3. Enable the IMU Data-stream
Send an Enable/Disable Continuous Stream command to enable the IMU continuous stream (reply
is ACK). This stream may have already been enabled by default; this step is to confirm they are
enabled. The stream will begin streaming data immediately.
MIP Packet Header Command/Reply Fields Checksum
SYNC1
“u
SYNC2
“e”
Descriptor
Set byte
Payload
Length
Field
Length
Cmd.
Desc. Field Data MSB LSB
Command
Field 1:
Enable Continu-
ous IMU Mes-
sage
0x75 0x65 0x0C 0x0A 0x05 0x11
Function: 0x01
IMU: 0x01
On: 0x01
Reply Field 1:
ACK/NACK
0x75 0x65 0x0C 0x08 0x04 0xF1 Cmd echo: 0x11
Error code: 0x00
Copy-Paste version of the command: “7565 0C0A 0511 0101 0105 1101 0301 24 CC”
4. Resume the Device: (Optional)
Sending the “Resume” command is another method of re-enabling transmission of enabled data
streams. If the "Resume" command is sent before the "Enable IMU Data Stream" command, the
13

3DM®-CV5-10 DCP Manual
node will resume the state it was in when the "Idle" command was sent. If the "Resume" command
is sent after enabling the IMU Data Stream, the node will continue streaming. (reply is ACK/NACK).
MIP Packet Header Command/Reply Fields Checksum
SYNC1
“u
SYNC2
“e”
Descriptor
Set byte
Payload
Length
Field
Length
Cmd.
Desc. Field Data MSB LSB
Command:
Resume
0x75 0x65 0x01 0x02 0x02 0x06 N/A 0xE5 0xCB
Reply:
ACK/NACK
0x75 0x65 0x01 0x04 0x04 0xF1 Cmd echo: 0x06
Error code: 0x00 0xDA 0x74
Copy-Paste version of the command: “7565 0102 0206 E5CB”
14

3DM®-CV5-10 DCP Manual
2.4.2 Polling Data Example Sequence
Polling for data is less efficient than processing a continuous data stream, but may be more
appropriate for certain applications. The main difference from the continuous data example is the
inclusion of the Poll data commands in the data loop:
1. Put the Device in Idle Mode (Disabling the data-streams)
Same as continuous streaming ( see Put the Device in Idle Mode on page 12 ).
2. Configure the IMU data-stream format
Same as continuous streaming ( see Configure the IMU data-stream format on page 12 ).
3. Enable the IMU data-stream format
Same as continuous streaming ( see Enable IMU Data-stream on page 13 ).
4. Resume the Device
Returns to the state when Idle was called, except for when Enable Stream command is sent
( see Resume the Device (Optional) on page 13 ).
Send Individual Data Polling Commands
Send an individual Poll IMU Data command in your data collection loop. After the ACK/NACK is
sent by the device, a single data packet will be sent according to the settings in the previous steps.
Note that the ACK/NACK has the same descriptor set value as the command, but the data packet
has the descriptor set value for the type of data (IMU or Estimation Filter):
MIP Packet Header Command/Reply Fields Checksum
SYNC1
“u
SYNC2
“e”
Desc.
Set
Payload
Length
Field
Length
Cmd.
Desc. Field Data MSB LSB
Command:
Poll IMU Data
0x75 0x65 0x0C 0x04 0x04 0x01 Option: 0x00
Desc Count: 0x00 0xEF 0xDA
Reply Field 1:
ACK/NACK
0x75 0x65 0x0C 0x04 0x04 0xF1 Cmd echo: 0x01
Error code: 0x00 0xE0 0xAC
IMUData
Packet Field 1:
Gyro Vector
0x75 0x65 0x80 0x1C 0x0E 0x04
0x3E 7A 63 A0
0xBB 8E 3B 29
0x7F E5 BF 7F
0x41 0xBB
IMUData
Packet Field 2:
0x0E 0x03 0x3E 7A 63 A0
0xBB 8E 3B 29 0xAD 0xDC
15

3DM®-CV5-10 DCP Manual
Accel Vector
0x7F E5 BF 7F
Copy-Paste version of the command: “7565 0C04 0401 0000 EFDA”
You may specify the format of the data packet on a per-polling-command basis rather than using the
pre-set data format (see the Poll IMU Data )
The polling command has an option to suppress the ACK/NACK in order to keep the incoming
stream clear of anything except data packets. Set the option byte to 0x01 for this feature.
2.5 Parsing Incoming Packets
Setup is usually the easy part of programming the 3DM-CV5-10. Once you start continuous data
streaming, parsing and processing the incoming data packet stream will become the primary focus.
Polling for data may seem to be a logical solution to controlling the data flow, and this may be
appropriate for some applications, but if your application requires the precise delivery of inertial data, it
is often necessary to have the data stream drive the process rather than having the host try to control
the data stream through polling.
The “descriptor set” qualifier in the MIP packet header is a feature that greatly aids the management of
the incoming packet stream by making it easy to sort the packets into logical sub-streams and route
those streams to appropriate handlers. The first step is to parse the incoming character stream into
packets.
It is important to take an organized approach to parsing continuous data. The basic strategy is this:
parse the incoming stream of characters for the packet starting sequence “ue” and then wait for the
entire packet to come in based on the packet length byte which arrives after the “ue” and descriptor set
byte. Make sure you have a timeout on your wait loop in case your stream is out of sync and the starting
“ue” sequence winds up being a “ghost” sequence. If you timeout, restart the parsing with the first
character after the ghost “ue”. Once the stream is in sync, it is rare that you will hit a timeout unless you
have an unreliable communications link. After verifying the checksum, examine the “descriptor set” field
in the header of the packet. This tells you immediately how to handle the packet.
16

3DM®-CV5-10 DCP Manual
Based on the value of the descriptor set field in the packet header, pass the packet to either a
command handler (if it is a Base command or 3DM command descriptor set) or a data handler (if it is an
IMU Filter data set). Replies to commands generally happen sequentially after a command so the
incidence of these is under program control.
For multi-threaded applications, it is often useful to use queues to buffer packets bound for different
packet handler threads. The depth of the queue can be tuned so that no packets are dropped while
waiting for their associated threads to process the packets in the queue. See Advanced Programming
Models section for more information on this topic.
Once you have sorted the different packets and sent them to the proper packet handler, the packet
handler may parse the packet payload fields and handle each of the fields as appropriate for the
application. For simple applications, it is perfectly acceptable to have a single handler for all packet
types. Likewise, it is perfectly acceptable for a single parser to handle both the packet type and the
fields in the packet. The ability to sort the packets by type is just an option that simplifies the
implementation of more sophisticated applications.
2.6 Multiple Rate Data
The IMU Message Format command allows you to set different data rates for different data quantities.
This is a very useful feature because some data, such as accelerometer and gyroscope data, usually
requires higher data rates (>100 Hz). The ability to send data at different rates reduces the parsing
load on the user program and decreases the bandwidth requirements of the communications channel.
Multiple rate data is scheduled on a common sampling rate clock. This means that if there is more than
one data rate scheduled, the schedules coincide periodically. For example, if you request
Accelerometer data at 100 Hz and Delta Theta data at 50 Hz, the Delta Theta schedule coincides with
the Accelerometer schedule 50% of the time. When the schedules coincide, then the two data
quantities are delivered in the same packet. In other words, in this example, you will receive data
packets at 100 Hz and every packet will have an accelerometer data field and EVERY OTHER packet
will also include a Delta Theta data field:
Packet
1Packet 2 Packet 3Packet 4 Packet 5Packet 6 Packet 7
Packet
8...
Accel Accel
Delta
Theta
Accel Accel
Delta
Theta
Accel Accel
Delta
Theta
Accel Accel
Delta
Theta
Accel
If a timestamp is included at 100 Hz, then the timestamp will also be included in every packet in this
example. It is important to note that the data in a packet with a timestamp is always synchronous with
the timestamp. This assures that multiple rate data is always synchronous.
Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 ...
17

3DM®-CV5-10 DCP Manual
Accel
Timestamp
Accel
Delta Theta
Timestamp
Accel
Timestamp
Accel
Delta Theta
Timestamp
Accel
Timestamp
Accel
Delta Theta
Timestamp
Accel
2.7 Communications Bandwidth Management
Because of the large amount and variety of data that is available from the 3DM-CV5-10, it is quite easy
to overdrive the bandwidth of the communications channel. This can result in dropped packets. The
3DM- CV5- 10 does not do analysis of the bandwidth requirements for any given output data
configuration, it will simply drop a packet if its internal serial buffer is being filled faster than it is being
emptied. It is up to the programmer to analyze the size of the data packets requested and the available
bandwidth of the communications channel. Often the best way to determine this is empirically by trying
different settings and watching for dropped packets. Below are some guidelines on how to determine
maximum bandwidth for your application.
18

3DM®-CV5-10 DCP Manual
2.7.1 UART Bandwidth Calculation
Below is an equation for the maximum theoretical UART baud rate for a given message
configuration. Although it is possible to calculate the approximate bandwidth required for a given
setup, there is no guarantee that the system can support that setup due to internal processing
delays. The best approach is to try a setting based on an initial estimate and watch for dropped
packets. If there are dropped packets, increase the baud rate, reduce the data rate, or decrease the
size or number of packets.
Where:
Sf= size of data field in bytes
fdr = field of data rate in Hz
fmr = maximum date rate in Hz
n= size of UART word = 10 bits
k= size of MIP wrapper = 6 bytes
which becomes:
Example:
For an IMU message format of Accelerometer Vector (14 byte data field) + Internal Timestamp (six
byte data field), both at 100 Hz, the theoretical minimum baud rate would be:
In practice, if you set the baud rate to 115200 the packets come through without any packet drops. If
you set the baud rate to the next available lower rate of 19200, which is lower than the calculated
19

3DM®-CV5-10 DCP Manual
minimum, you get regular packet drops. The only way to determine a packet drop is by observing a
timestamp in sequential packets. The interval should not change from packet to packet. If it does
change then packets were dropped.
20