Data Communication UMRR Traffic Management - UMRR11

DATA COMMUNICATION | USER MANUAL
DATA COMMUNICATION
TRAFFIC MANAGEMENT SENSOR
UMRR-11
s.m.s, smart microwave sensors GmbH Phone: +49 531 39023-0

In den Waashainen 1 Fax: +49 531 39023-599
38108 Braunschweig info@smartmicro.de
Germany www.smartmicro.com
CONTENTS
1 Document Control ................................................................................................................................... 5
Page 1 of 47 | December 14, 2021

Proprietary - This document may be subject to change without notice. The
information shall remain the exclusive property of s.m.s, smart microwave sensors GmbH.
1.1 Abbreviations .................................................................................................................................. 5

1.2 Reference Documents .................................................................................................................... 5
1.3 Message Identifier Overview ........................................................................................................... 6
2 Introduction ............................................................................................................................................. 6
2.1 Migrating from UMRR-0C Sensors.................................................................................................. 6
2.2 Main Processor and Communication Processor ............................................................................ 6
2.3 Standard Messages and UDT Messages ........................................................................................ 7
3 Command Messages .............................................................................................................................. 7
3.1.1 UAT Command Version 4 ......................................................................................................... 7
4 Boot Loader Status Message ................................................................................................................ 14
5 Tracked Object Output Specification .................................................................................................... 15
5.1 Status Messages .......................................................................................................................... 15
5.2 Object Data Messages .................................................................................................................. 17
5.2.1 4D/HD X-, Y-Point, Speed, Heading Interpretation (no updated_flag)..................................... 18
6 Specification of the Statistic Output Data ............................................................................................. 20
6.1 Statistic Output – CAN-based Protocol ........................................................................................ 20
6.1.1 Statistic Output – Info Message 1 (CAN-Based Protocol)...................................................... 21
6.1.2 Cyclical Statistic Output – Info Message 2 (CAN-Based Protocol) ........................................ 22
6.1.3 Statistics Output – Time Info Message 3 (CAN-Based Protocol)........................................... 22
6.1.4 Statistics Output Data (CAN-based Protocol)......................................................................... 23
6.2 Per Vehicle Record (PVR) - CAN-Based Protocol .......................................................................... 24
6.2.1 PVR – Per Vehicle Record Header (CAN-based Protocol) ...................................................... 24
6.2.2 PVR – Per Vehicle Record Object (CAN-based Protocol) ....................................................... 25
6.3 Specification of the Event Trigger Output Data ............................................................................ 25
6.3.1 Event Trigger Output – Output Control Message (CAN-Based Protocol) ............................... 26
6.3.2 Queue Length Output .............................................................................................................. 26
7 Read Sensor Parameter ........................................................................................................................ 28
7.1 Using UAT Commands .................................................................................................................. 28
7.1.1 UATv4 Response .................................................................................................................... 29
8 Read Software and Hardware Information............................................................................................ 32
9 CAN Bus Settings .................................................................................................................................. 33
10 Ethernet UDP Communication .............................................................................................................. 34

10.1 Physical ......................................................................................................................................... 34

10.2 MAC .............................................................................................................................................. 34
10.3 IP ................................................................................................................................................... 34
10.4 UDP ............................................................................................................................................... 35
10.5 smartmicro Transport Protocol with Client ID .............................................................................. 35
10.5.1 Outgoing Data Packets ........................................................................................................... 35
10.5.2 Incoming Data Packets........................................................................................................... 35
10.6 smartmicro Application Protocols (Alive) ..................................................................................... 35
10.7 Data Streams ................................................................................................................................ 36
10.8 Network Set-Up ............................................................................................................................. 36
10.8.1 Option 1 - Alive........................................................................................................................ 36
10.9 Alive Protocol ................................................................................................................................ 36
10.9.1 Word Byte Order (Endian) ....................................................................................................... 36
10.9.2 Maximum Transfer Unit .......................................................................................................... 36
10.9.3 Timing ..................................................................................................................................... 36
10.9.4 Header .................................................................................................................................... 37
10.9.5 Body ........................................................................................................................................ 37
11 smartmicro transport protocol .............................................................................................................. 39
11.1 Header Specification..................................................................................................................... 39
11.1.1 Start Pattern ........................................................................................................................... 39
11.1.2 Protocol Version ..................................................................................................................... 39
11.1.3 Header Length ........................................................................................................................ 40
11.1.4 Payload Length ....................................................................................................................... 40
11.1.5 Application Protocol Type....................................................................................................... 40
11.1.6 CRC 16 (Header) ..................................................................................................................... 40
11.1.7 Optional Header Information .................................................................................................. 40
11.1.8 Flags ....................................................................................................................................... 41
11.1.9 Message Counter.................................................................................................................... 41
11.1.10 Timestamp .......................................................................................................................... 42
11.1.11 Skip Payload CRC ............................................................................................................... 42
11.1.12 Source Client ID .................................................................................................................. 42
11.1.13 Destination Client ID ........................................................................................................... 42

11.2 Body Specification ........................................................................................................................ 42

11.2.1 Payload Data........................................................................................................................... 44
11.2.2 CRC 16 (Payload).................................................................................................................... 44
11.3 CRC 16 Calculation ....................................................................................................................... 44
12 Legal Disclaimer Notice ........................................................................................................................ 47

1 DOCUMENT CONTROL
1.1 ABBREVIATIONS
CAN Controller Area Network
PC Personal Computer
TMC Traffic Management Configurator
UDT Universal Data Transmission
UMRR Universal Medium Range Radar
1.2 REFERENCE DOCUMENTS

[RD1] Documentation_UMRR_Traffic_Sensor_2G
[RD2] Documentation_TM_Statistics_Module
[RD3] Documentation_Data Communication_Stellaris
[RD4] Documentation_UMRR_Traffic_Sensor_4DHD

1.3 MESSAGE IDENTIFIER OVERVIEW
Identifier Document/Chapter Model Function
0x320 4 All sensors Boot Loader Status
0x430 5 TMIB CoProcessor Status Message
0x500 5.1 All sensors Sensor Control
0x501 5.2 All sensors Object Control
0x502 5.2.1 UMRR-11, TRUGRD Object_data_1
0x780 … [RD2] All sensors Statistic and Trigger module

0x786
2 INTRODUCTION
This document explains in detail the sensor data communication and protocols. All data communication
with the smartmicro sensor is based on a Controller Area Network (CAN) message structure. However, it is
also possible to use RS485 or Ethernet1 for communication. In these cases, the CAN messages will be
wrapped and transmitted as payload of the respective data format.
2.1 MIGRATING FROM UMRR-0C SENSORS

The structure of the 4D/HD communication is comparable to the nature of the 2D/(U)HD and 3D/(U)HD
based sensor communication. The message identifiers and data representation are similar. Parameters
and command scheme, however, are different. The UAT V4 command scheme unifies the different
command methods in one modern scheme.
2.2 MAIN PROCESSOR AND COMMUNICATION PROCESSOR

The sensor has two processors. Each processor has a Communication ID. Each processor has dedicated
parameters and dedicated firmware. The user has to select the correct target processor for a parameter
setting or a firmware upgrade.
Table 2-1 CAN-ID vs. Target Assignment
1 the Ethernet option may require additional or special hardware. Available in future firmware release.

CAN ID Target Parameters / Firmware to send
0 MAIN processor ID0 Control Parameters

Feature Parameters
Tracking Parameters
Detection Parameters
2.3 STANDARD MESSAGES AND UDT MESSAGES

For the case that the 64-bit payload of a CAN message is insufficient more than one CAN message with
the same CAN identifier are sent. These kinds of messages are called Universal Data Transmission (UDT)
messages.
3 COMMAND MESSAGES
Command messages are used to transmit new parameters or initiate various actions of the sensors. It is
broadcasted but the destination sensor is the only one to execute the command. If the destination ID is set
to 255 = broadcast, all sensors in a network will execute the command.
Command messages may be initiated by the PC and are transmitted to the sensors.
3.1.1 UAT COMMAND VERSION 4

In the UAT-command version 4 it is possible to differentiate basic parameters, „special” commands, and
status requests. It is also possible to collect more than one commands to send it as one block. A UAT
version 4 block consists of a header message 1 and n*2 messages (two messages per command), which
are described in the following chapter.
MESSAGE 1 (HEADER)
Table 3-1 Message 1 of the UART Command version 4
Data Data Data Data Data Data Data Data
Byte 7 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1 Byte 0
CRC-16 CRC-16 Number of Target Format- Message UAT – ID

Hi-Byte Low-Byte following Device ID Versions Index Hi-Byte Low-
commands Number Byte
Details:
- UAT-ID: The UAT-ID is the unique ID for UAT commands. The UAT-ID of the header message is not
important. It is possible to use the UAT-ID of the first UAT command.
- Message index: Each UAT command has a sequence number. The message index starts always
with 0 and in the following message the index gets incremented by one. For the third message, the
message index is two.

- Format version number: UAT version number 4

- Number of following commands: It is possible to send more than one command via UAT version 4
in one block. Every command consists of 2 messages. The „number of following commands“
describes the number of commands and not the number of messages. E.g., should 3 commands
be sent in one block, the „number of following commands” is 3. It will then be sent as follows:
o 1 x header + 2 x 3 messages for the 3 commands = 7 messages
- Target Device ID: This is the receiver ID of the sent command. It is only possible to send a block of
UAT command version 4 to one receiver.
- The sensor only supports Device ID 0 or 255 (=broadcast)
Please note: The UAT V4 Command is able to transmit more than one command message in one UAT
block. However, the UMRR-11 sensor is not able to receive more than 5 command messages in one UAT
block per sensor cycle. If it is needed to send more command messages to the sensor, it is recommended
to send multiple UAT V4 blocks with a maximum of 5 single sensor commands in further sensor cycles.
Every command (e.g., parameter, commands, and status requests) of the UAT command version 4
consists of 2 command messages, which are described in the following table. This table shows the
content of the first command message.
Table 3-2 Command message of the UAT-format version 4
Dim1 Dim0 Parameter Number Message Message UAT – ID

Hi-Byte Low- Type Index Hi-Byte Low-
Byte Byte
Details:
- UAT-ID: The UAT-ID is the unique ID for the UAT command. Both UAT command messages
have the same ID.
- Message Index: See Message 1 Header
- Parameter number: Parameter number
- Dim0..Dim1: Dim0…1 give the information which arrays indexes is used in which dimension in
the parameter structure. To analyze the command, compare the number of dimensions with
the parameter structure dimension. It should be equal otherwise ignore the command.
- Message Type: Describes the type of the command. See Table 1
Example for a parameter with multiple dimensions:

Figure 3-1: Example with multi-dimensional parameter (TMC command window)
The example shows a spline x-position parameter with the following values:
Par No: 0 = x-position of a spline
Value: ## = x position value [m]
Action: 301 = spline x & y parameters)
I1 == Dim0 = spline 8 (spline 0…21 possible)
I2 == Dim1 = spline control point 1 (control point 0 …5 possible)
Table 1: Definition of field „Message Type”

Value Operation
0 Command
1 Status Request
2 Parameter write
3 Parameter read
4 Parameter write / read
- Command: A command has only influence of the next cycle. A command is not storable and cannot
read out (i.e.: Sensor-Reset)
- Status request: Sensor request for specific data, which the sensor shall send. (i.e.: Firmware
version)
- Parameter write: Changes a specific parameter value
- Parameter read: Read out a specific parameter. Nothing will be changed
- Parameter write/read: Changes a parameter and read it out after changing (verifying)

SECOND COMMAND MESSAGE

Table 2: 2. Command message of the UAT-command version 4
Parameter Parameter Parameter Parameter Data Message UAT – ID

Data byte Data byte Data byte Data byte Format Index Hi-Byte Low-
3 2 1 0 Byte
Hi-Byte Low-Byte
Details:
- UAT-ID: see Message 1 (Chapter 0)
- Message Index: see message 1 (Chapter 0)
- Parameter Data-Byte 0..4: parameter data
- Data Format: described the data format
Table 3-3 Definition of field “Data Format”

Value Data Type
0 Integer
1 Float (smartmicro)
2 Float (IEEE 754)
3.1.1.1 EXAMPLE
Sent Parameter 201 as Action 2000, UAT v4:

Figure 3-2 Parameter in the Command View

Is sent with three 0x3fb messages:
Figure 3-3 messages in the “Data to Sensor” View

With:
0x3FB == UAT Message ID
Message1:
Byte 1..0: 0x07D0 = UAT ID == action number (2000)
Byte 2: 0x00 == Message Index
Byte 3: 0x04 == Format version number
Byte 4: 0xFF == Destination ID (0xFF == broadcast)
Byte 5: 0x01 == number of instructuions
Byte 7..6: 0x9550 == CRC checksum
Message2:
Byte 3: 0x02 == Message type (2== parameter write)
Byte 5..4: 0x00C9 == Param Number (=201)
Byte 7..6: 0x0000 == Dimensions

Message3:
Byte 3: 0x00 == Data Format (0= integer)
Byte 7..4: 0x00000001 == Value (=1)
Transmitted RS485 data UAT V4 command (controller to sensor):

7E 01 0C 00 21 04 00 00 00 00 04 76 03 FB 08 D0 07 00 04 FF 01 50 95 03 FB 08 D0 07 01 02 C9 00 00 00
03 FB 08 D0 07 02 00 01 00 00 00 EE 7D
Description:
Start Sequence Header Checksum Ident Length ____Data____ Checksum
Interpretation:
Table 3-4 Start-Sequence and Header with Checksum
Start Sequence Header CRC Header
Byte 0 Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Byte 9 Byte 10
0x7E 01 0C 00 21 04 00 00 00 00 04 76
Table 3-5Messages with Ident, Length and Payload

Ident Length Data Payload
Byte 1 Byte 0 Byte 0 Byte 0 Byte 1 Byte 2 Byte 3 Byte Byte Byte Byte 7
4 5 6
03 FB 08 D0 07 00 04 FF 01 50 95
03 FB 08 D0 07 01 02 C9 00 00 00
03 FB 08 D0 07 02 00 01 00 00 00
Table 3-6 Checksum of the data payload

CRC Payload

Byte 1 Byte 0
EE 7D
CRC calculation for the whole message without the CRC-16 value:
Figure 3-4Example of CRC calculation

(https://crccalc.com/)

4 BOOT LOADER STATUS MESSAGE

While the sensor runs in boot loader mode, a status message is transmitted every cycle or (depending on
the software) only when requested by the PC.
Message-Specification sensor echo:
Message Type: sensor echo
Identifier: ID0 0x320
DLC: 8
Source: UMRR sensor
Destination: PC
Table 4-1 Data
Hi-Byte: Lo-Byte: Hi-Byte: Lo-Byte: High Nibble:

CAN CAN DSP Board DSP Board DSP DSP spare DSP
Message Message Serial ID Serial ID Cycle Software Status
Counter Counter modulo Version
Low Nibble:
0xff
DSP ID
(uint) (uint) (uint) (uint)

(hexString) (hexString) (uint)
(uint)
Table 4-2
DSP Status Meaning
0 DSP in normal mode
1 DSP ready for flash data reception
2 DSP received end of can load data block

and transmits message counter
3 DSP indicates flash process successful
4 DSP initiated break of the can load sequence (e.g., message counter incorrect)
or

DSP acknowledges PC initiated break of the can load sequence
5 DSP Error while changing the sensor ID
6 DSP Error: Application password not found or wrong
16 DSP Memory Test Error
5 TRACKED OBJECT OUTPUT SPECIFICATION

There are two categories of messages to be transmitted:
a) Status messages of the sensor
b) Data of detected objects.
5.1 STATUS MESSAGES

Part a) is used to transmit information on:
sensor_control
- Sensor ID in the network
- Field of view
- Timestamp
The sensor control message is transmitted every cycle.
Message-Specification sensor_control:
Message Type: sensor_control
Format: Intel (little endian)
Table 5-1: Sensor control message

Time since Time since Time since Time since spare Source spare Sensor
sensor sensor sensor sensor Device status
start_3 start_2 start_1 start_0

(int)
= ID in the
network
Table 5-2: Sensor status Byte

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Diagnostic Diagnostic Diagnostic reserve reserve reserve reserve Diagnostic

Bit 2 Bit 1 Bit 0 Byte
Rain Interference Error_Flag
Event indicator (Bit 0 to 3): Indicates that a diagnostic event occurred. (see diagnostic bits)
Table 5-3: Sensor control message

Sensor_Control Source = Sensor/TraCon
Signal Bit Offset Resolution Interval Type Byte Bit Comment
Sensor_Status 0..7 0 1 0...255 u8 0 [0;7]
Interface_Mode 8..11 0 1 0...7 u4 1 [0;3]
Network_ID 12..15 0 1 0...7 u4 1 [4;7]
Diagnose 16..23 0 1 0...255 u8 2 [0;7]
Reserve 24..31 0 1 0...255 u8 3 [0;7]
Time 32..63 0 1ms 0...4294967s u32 [4;7] [0;7]
Table 5-4: Sensor status

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Diagnostic Diagnostic Diagnostic Diagnostic spare spare spare spare

Bit 3 Bit 2 Bit 1 Bit 0

Rain Interference Error_Flag Blind
- Diagnostic Bit 0: Blind – Sensor is blind or is masking by snow or ice

- Diagnostic Bit 1: Error_Flag – General error flag. Send “ParNo: 40; Val: 64; Action: 0” to request the
Diagnostic Message for further information.
- Diagnostic Bit 2: Interference – Sensor is affected by interference or jamming.
- Diagnostic Bit 3: Rain (precipitation) – Sensor detects rain or falling snow.
5.2 OBJECT DATA MESSAGES

Part b) is used for targets, which can be represented by one point. It is again composed of two types of
messages:
b 1) Control message used as a header for the object list object_control
b 2) Object data messages object_data_1...3.
Each individual Central Processor system prioritizes the detected objects and limits the number of
transmitted objects, according to the commands sent to this system. The data specification in this
document limits the number to a max. of 64 objects. The object data message can be sent in different
specifications. The specification is not selectable and needs special firmware configuration.
Object Control Message (Header for Object List)

In part b 1) the following data are transmitted with high priority:
object_control:
- Number of objects in the appending list nofobjects
- Number of messages for each object nofmessages (1 by default)
- Cycle duration of the current cycle cycle_duration
- Current value of the cycle counter cycle_count
Message-Specification object_control:
Message Type: object_control
Table 5-5: Object control message

Object_Control Source = Sensor/TraCon

Number_Of 0..7 0 1 0...255 u8 0 [0;7]

_Objects
Number_Of_ 8..15 0 1 0...255 u8 1 [0;7]

Messages
Cycle_ Duration 16..23 0 1ms 0...255ms u8 2 [0;7]
Object_data0 24..27 0 1 0...15 u4 3 [0;3] Coded format of the

_format Object_data0
7 = x-, y-point, speed,

heading
Object_data1 28..31 0 1 0...15 u4 3 [4;7] Coded format of

_format object_extension
1 = TM extension
Cycle_Count 32..63 0 1 0... u32 [4;7] [0;7]

4294967295
5.2.1 4D/HD X-, Y-POINT, SPEED, HEADING INTERPRETATION (NO UPDATED_FLAG)

Message Type: object_data_1
Identifier:
Object #0: ID0 0x502
...
…
Object #125: ID0 0x57F
Table 5-6 Data format of the object message

Object_Data0 Source = Sensor/TraCon
Mode_Signal1 0 0 1 0 u1 0 0 0
x_Point1 1..13 4096 0.128m -524.288m...+524.16m u13 [0;1] [1;5]
y_Point1 14..26 4096 0.128m -524.288m...+524.16m u13 [1;3] [6;2]
Speed_Abs 27..37 1024 0.1m/s -102.4m/s...+102.3m/s u11 [3;4] [3;5]
Heading 38..48 1024 0.177deg -180.0deg...+180.0deg u11 [4;6] [6;0]
Object_Length 49..55 0 0.2m 0...25.4 u7 6 [1;7] See Table 5-7
Object_ID 56..63 0 1 0...255 u8 7 [0;7]
Data explanation:
- Object length: Object length – representation of the detected vehicle class
o Each class has a predefined default length
o The classes will be encoded as follows:
Table 5-7 coded length of classes
Length Class Comment
1.0m pedestrian Fixed length
1.6m bicycle Fixed length
2.6m bike/motorcycle Fixed length
4.6m … 5.4m passenger car object with estimated length as reported
5.6m … 8.8m delivery/pickup object with estimated length as reported
9.0m … 13.8m short truck object with estimated length as reported
>= 14.0m long truck object with estimated length as reported
Details:
- Object ID:
o Internal track / object ID
o All IDs are retained during lifetime of an object

All objects are reported in unsorted order.
Example:
Object messages: 0502 08 44 92 00 13 E10 03 9A 32
Table 5-8 HEX to binary number
Byte No. 0 1 2 3 4 5 6 7
HEX 0x44 0x92 0x00 0x13 0x10 0x03 0x9A 0x32
BIN 01000100 10010010 00000000 00010011 00010000 00000011 10011010 00110010
Table 5-9 Binary number to value

Name BIN HEX DEC (DEC-Offset)*Resolution Value
ModBit 0 0x0 0 - 0
x_Point1 1000100100100 0x1124 4388 (4388 - 4096) * 0.128m 37.376m
y_Point1 1000000000000 0x1000 4096 (4096 - 4096) * 0.128m 0m
Speed_Abs 10011000100 0x4c4 1220 (1220 - 1024) * 0.1m/s 19.6m/s
Heading 00000000111 0x7 7 (7 - 1024) * 0.177° -180.009°
Object_Length 0011010 0x1A 26 (26 - 0) * 0.2m 5.2m
Object_ID 00110010 0x32 50 (50 - 0) * 1 50
6 SPECIFICATION OF THE STATISTIC OUTPUT DATA

For each statistic zone the sensor will collect and report statistic data periodically for a predefined report
interval time (statistic data) and instant output for each counted object (Per Vehicle Record data).
6.1 STATISTIC OUTPUT – CAN-BASED PROTOCOL

For the CAN-based protocol the statistic output general info data will be transmitted cyclical within three
header “info” messages. The additional “statistic output data” will be transmitted for each zone and each
statistic feature when the statistic report interval has expired.

6.1.1 STATISTIC OUTPUT – INFO MESSAGE 1 (CAN-BASED PROTOCOL)

Identifier: 0x780
DLC: 8
Source: UMRR sensor
Destination: Controller
Type: unsigned
Table 6-1 STATISTIC OUTPUT – INFO MESSAGE 1
Byte # Bit # Description Resolution Offset Values Bits
0 0…1 Info Part ID [1] 0 0 2
0 2…7 Number of used zones [1] 0 0…32 6
0…1 8…12 Number of used classes [1] 0 0…16 5
1 13…15 Status bits 0...3 [1] 0 0…7 3

B0: last zone transmitted
B1: unused
B2: unused
2 16…23 Active statistics features, bit coded [1] 0 0…255 8

B0: Volume
B1: Occupancy
B2: Av Speed
B3: 85th perc. speed
B4: Headway
B5: Gap
B6…7: reserved
3 24…31 Failsafe Flags, bit coded [1] 0 0…255 8

B0: failsafe rain
B1: failsafe Interference
B4: Failsafe Blind
4…5 32…47 Number of Statistic Lists [1] 0 0…65535 16
6…7 48…63 Reserve - - - 16

6.1.2 CYCLICAL STATISTIC OUTPUT – INFO MESSAGE 2 (CAN-BASED PROTOCOL)

Identifier: 0x780
DLC: 8
Source: UMRR sensor
Type: unsigned
Table 6-2 CYCLICAL STATISTIC OUTPUT – INFO MESSAGE 2
Byte Bit Description Resolution Offset Values Bits
0 0…1 Info Part ID [1] 0 1 2
0…1 2…11 Milliseconds of UTC [ms] 0 0…999 10

Timestamp
1 12 Statistic Output Type [1] 0 0 = current data 1
1 13…15 Output Format Version [1] 0 0…7 3

unused
2…3 16…31 FrameID# of the Statistic Cycle [1] 0 1… 65535 16
4…7 32…63 Seconds of UTC Timestamp [s] 0 0… (2^32)-1 32
6.1.3 STATISTICS OUTPUT – TIME INFO MESSAGE 3 (CAN-BASED PROTOCOL)

Identifier: 0x782
DLC: 8
Source: UMRR sensor
Table 6-3 STATISTICS OUTPUT – TIME INFO MESSAGE 3
0 0…1 reserved - - - 2
0 2…3 SRO2 version [1] - 1 2

0…1 4…15 Interval Countdown [1s] 0 0…4095 12
2…3 16…29 Statistic Report Interval Time [1] 0 0…65535 16
4…7 32…63 Serial Number [1] 0 UMRR 32

serial
number
6.1.4 STATISTICS OUTPUT DATA (CAN-BASED PROTOCOL)

Identifier: 0x781
DLC: 5
Source: UMRR sensor
Type: unsigned
Table 6-4 STATISTICS OUTPUT DATA
Byte Bit Description Resolution Offset Value Type Bits
0 0…8 Statistic Message Number [1] 0 0…511 Int 9
1 9…13 Zone Number [1] 0 0…31 Int 5
1…2 14…16 Mode: Volume Count Output [1] 0 0 Int 3
2 17…20 Class [1] 0 0…15 Int 4
2 21…23 reserved [1] 0 - - 3
3...4 24…39 Statistic_Output_i [1] 0 0… (2^16)-1 Int 16
Based on the mode signal within Bit14…16 the Statistic_Output_i has to be interpreted as follows:
Table 6-5 Mode Bits Value:0 Volume Count Output
Byte Bit Statistic_Output_i Resolution Offset Value Type Bits
3...4 24…39 Volume Count [1] 0 0… (2^16)-1 Int 16
Table 6-6 Mode Bits Value:1 Mode: Average Speed Output

3...4 24…39 Average speed [0.01m/s] 0 0… (2^16)-1 Int 16

Table 6-7 Mode Bits Value:2 Mode: 85th percentile Speed Output
3...4 24…39 85th perc. speed [0.01m/s] 0 0… (2^16)-1 Int 16
Table 6-8 Mode Bits Value:3 Mode: Occupancy Output

3...4 24…39 Occupancy [0.05 %] 0 0…2047 Int 11
Table 6-9 Mode Bits Value:4 Mode: Headway Output

3...4 24…39 Headway [0.055 s] 0 0… (2^16)-1 Int 16
Table 6-10 Mode Bits Value:5 Mode: Gap Output

3...4 24…39 Gap [0.055 s] 0 0… (2^16)-1 Int 16
6.2 PER VEHICLE RECORD (PVR) - CAN-BASED PROTOCOL

For each counted object a Per Vehicle Record (PVR) output is generated. The following chapter describes
the PVR-CAN-Based structure.
6.2.1 PVR – PER VEHICLE RECORD HEADER (CAN-BASED PROTOCOL)

Message Type: header data
Identifier: 0x785
DLC: 7
Source: UMRR sensor
Table 6-11 PVR – PER VEHICLE RECORD HEADER
0 0 Mode Bit: [1] 0 0 1

0 == PVR Header
0 1…7 Number of counted objects [1] 0 0…127 7

1…4 8…39 Unix-Time [s] [1] 0 0… (2^32)-1 32
5…6 40…49 Milliseconds [ms] [1] 0 0…1023 10
6.2.2 PVR – PER VEHICLE RECORD OBJECT (CAN-BASED PROTOCOL)

Message Type: target data
Identifier: 0x785
DLC: 7
Source: UMRR sensor
Table 6-12 PVR – PER VEHICLE RECORD OBJECT
0 0 Mode Bit: [1] 0 1 1

1== PVR Object Message
0 1…6 object counter of nof_pvr_objects [1] 0 0…64 6
0…1 7…14 Object ID [1] 0 0…255 8
1…2 15…19 Zone [1] 0 0…31 5
2 20…23 Class [1] 0 0…15 4
3…4 24…35 Speed Magnitude [0.025m/s] 0 0… (2^12)-1 12
4…5 36…47 Heading [0.0884961°] 2048 0… (2^12)-1 12
6 48…54 Length [0.2m] 0 0…127 7
6.3 SPECIFICATION OF THE EVENT TRIGGER OUTPUT DATA

For each virtual relay the sensor transmits the current status within the Event Trigger Port.

6.3.1 EVENT TRIGGER OUTPUT – OUTPUT CONTROL MESSAGE (CAN-BASED PROTOCOL)

Message Type: object_data
Identifier: 0x783
DLC: 8
Source: UMRR sensor
Type: unsigned
Table 6-13 EVENT TRIGGER OUTPUT – OUTPUT CONTROL MESSAGE
0…7 0…63 Output 0…63 on/off [1] 0 0… (2^64)-1 64
6.3.2 QUEUE LENGTH OUTPUT

For the Queue Length Event Trigger application, the sensor sends additional messages of the objects
which are within the Queue Length.
QUEUE APPLICATION OUTPUT – CAN-BASED PROTOCOL

Header Message
Identifier: 0x786
DLC: 2
Source: UMRR sensor
Table 6-14 QUEUE APPLICATION OUTPUT HEADER
0 0…5 Mod Bit [1] 0 0 6
0…1 6…3 Number of Queue [1] 0 0 … 63 6

Elements
Elements Message
Identifier: 0x786
DLC: 4
Source: UMRR sensor
Table 6-15 QUEUE APPLICATION OUTPUT DATA

0 0…5 Mod Bit [1] 0 1 6
0…1 6…2 Queue element number [1] 0 0 … 31 5
1 3…7 Zone number [1] 0 0 … 31 5
2 0…7 Queue length [m] 0 0 … 255 8
3 0…7 Number of objects within the queue [1] 0 0 … 255 8

7 READ SENSOR PARAMETER
7.1 USING UAT COMMANDS

The sensor sends a few acknowledgment messages after receiving a UAT command message to readout
the set parameter. These messages are sent in the following sensor cycle before the cyclical data payload.
The number of response messages depends on the UAT command version.
The response messages have the same identifier (0x700) and an additional UDT Index, in order to separate
the data payload.
The message scheme for UATv1 is 17000-17001-17002-17003-17000 in sequence. The messages are
described in the following tables.
Table 7-1: Read Parameter Messages at UAT query (Overview)

CAN Word3 CAN Word2 CAN Word1 CAN Word0
Data2 Data1 Data0 Index
unused unused version_number 17000
parnumber (bit 8..15) Destination device ID (bit 8..15)

u16_counter 17001
partype (bit 0..5) Result (bit 0..7)
UAT ID (Action) CRC (bit 0..15) u16_counter 17002

(bit 0..15)
Parameter value u16_counter 17003
Data explanation:
- Version number: (UAT version) 1, 2,3 or 4.
- u16_counter: sequential counter incremented at each parameter read in this cycle.
- Result:
o 0: no error
o 1: unspecified error
o 2: parameter not present
o 4: action not present
o 8: wrong device ID

o 16: invalid CRC

o 64: message type invalid
o 128: ID mismatch
- CRC:
o The CRC is built over all contents excluding the CRC field
7.1.1 UATV4 RESPONSE

Message sequence for UATv4: 17000-17016-17017-17018
Table 7-2: UAT v4 Response Header Message (overview)
CRC Number of Device ID UAT_Format_Version UDT index

Instructions
(High Byte) (Low Byte) (High Byte) (Low Byte) (High-Byte) (Low-Byte)
Table 7-3 UAT v4 Response Header Message (specification)

Signal Name Byte Bit Init Offset Resolution Type Description
Modsig_u16_udt_index 0..1 0..15 17000 Int16 sequence number
UAT_Format_Version 2..3 16..31 5 Int16 UAT version

(5=Version4)
Device ID 4 32..39 0 Int8 ID of the device which

sends the message.
Number of Instructions 5 40..47 1 Int8 Number of the following

instruction answers
CRC 6..7 48..63 Int16 Checksum

CRC: CRC checksum. Over instruction message 1-3 for all instructions. Header is ignored for CRC
calculation. Start value: 0xFFFF, polynomial: X^16 + X^12 + X^5 + 1
Table 7-4: UAT v4 Response Data Message 01 (overview)

Parameter Number UAT ID Type Object UDT index

(High-Byte) (Low-Byte) (High-Byte) (Low-Byte) Number (High-Byte) Low-Byte)
Table 7-5 UAT v4 Response Data Message 01 (specification)

UDT index 0..1 0..15 17016 Int16 sequence number (Modsig)
Object_Number 2 16..23 Int8 Number ‚N‘ of Message transmitted.

Start at 0. Increment by 1 for each
additional Message.
Type 3 24..31 Int8 Type of the Parameter
UAT ID 4..5 32..47 Int16 Type: int, float, IEEE Float
Parameter 6..7 48..63 Int16 Number of the Parameter

Number

Value Value Value Value Result Object UDT index

(High-Byte) (Low-Byte) Number (High-Byte)...(Low-Byte)

Signal Byte Bit Init Offset Resolution Type Description
Name
UDT index 0..1 0..15 17017 Int16 sequence number (Modsig)
Object 2 16..23 Int8 Number ‚N‘ of Message transmitted.

Number Start at 0. Increment by 1 for each
additional Message.
Result 3 24..31 Int8 Return value or error code 0-16 (see

chapter 7.1)
Value 4..7 32..63 Int32 Parameter value


Byte 7 Byte 6 Byte 5 Byte 4 Byte3 Byte 2 Byte 1 Byte 0
Reserve reserve Dim 1 Dim 0 Data Object UDT index

Format Counter (High-Byte)…….(Low-Byte)

Modsig_u16_udt_index 0..1 0..15 17018 Int16 sequence number
Object_Number 2 16..23 Int16 Number ‚N‘ of

Message
transmitted. Start at
0. Increment by 1 for
each additional
Message.
Dim 0 3 24..31 Int16 Index of dimension 0
Dim 1 4 32..39 Int16 Index of dimension 1

8 READ SOFTWARE AND HARDWARE INFORMATION

The sensor provides information about software and hardware versions, modifications, configurations and
some other important informations like application, type and status values of the sensor itself.
Please use the following parameter to readout the software version numbers, hardware identification and
additional status information.
Table 8-1: Read Sensor Status Information
Name Description UAT ParNo. Action Instruction Data
Version Type Type
Interface TM user interface version major. 4 0 2003 Status Int

Version Increased, if user interface is not totally
Major backward compatible to older version.
Interface TM user interface version minor. 4 1 2003 Status Int

Version Increased, if statuses or parameters
Minor are changed or added. The new version
is still backward compatible.
SW TM Software Version generation 4 2 2003 Status Int

Generation
SW Version TM Software Version major 4 3 2003 Status Int

Major
SW Version TM Software Version minor 4 4 2003 Status Int

Minor
SW Version TM Software Version patch 4 5 2003 Status Int
Patch
Customer ID Customer Identifier 4 6 2003 Status Int
Antenna Antenna Type 4 7 2003 Status Int
Config Code SW Configuration Code 4 8 2003 Status Int
Sensor Serial 32Bit product id serial 4 9 2003 Status Int
Sensor HW Product Generation (e.g. 17 for umrr11) 4 10 2003 Status Int

Generation
Sensor HW Product Modification High Byte 4 11 2003 Status Int

Mod high

Sensor HW Product Modification Low Byte 4 12 2003 Status Int

Mod low
Sensor HW Product Revision 4 13 2003 Status Int

Revision
Sensor Run Sensor Run Time Low Word (32 bit) 4 20 2003 Status Int
Time low (power cycle or restart resets the
timer)
Sensor Run Sensor Run Time High Word (32 bit) 4 21 2003 Status Int
Time high (power cycle or restart resets the
timer)
Parameter Indicator, if parameter settings (e.g. 4 22 2003 Status Int

Check valid waveform and tx power) are valid
according to the frequency regulations
or not. If invalid (=0) the tx power will
automatically be reduced to minimum.
Roll Angle Accelerometer angle of roll in degree 4 23 2003 Status Int
Pitch Angle Accelerometer angle of pitch in degree 4 24 2003 Status Int
ACC Calib Accelerometer calibration status. 4 25 2003 Status Int

Status Indicates, if accelerometer is
calibrated.
RFE Radar Frontend temperature in deg C, 0 4 26 2003 Status Int

Temperature = temperature not available.
Number of Number of used classes in tracking 4 30 2003 Status Int

Tracking
Classes
BIT output will be enabled in a future firmware update.
9 CAN BUS SETTINGS

Default baud rate: 500 kBaud (other baud rates are available on request)
Tseg1: 8

Tseg2: 7
Tsjw: 2
Presc: 1
Synchronization on one Edge only.
10 ETHERNET UDP COMMUNICATION

10.1 PHYSICAL
The supported Ethernet specification depends on the hardware. The software requires a specific device
driver to control the PHY, the peripheral hardware. Typical specifications are:
- 100BASE-T (100-Mbit/s)
- 1000BASE-T (Gigabit Ethernet)
- 100BASE-T1 (Automotive Ethernet)
10.2 MAC
The software requires a hardware-specific device driver to control the MAC component. It is typically part
of the processor and part of the CSP. On MAC layer, each device must have a unique identification called
MAC address. The MAC address consists of two values, a fixed registered smartmicro identification and a
unique device number. The device MAC address is part of the OTP data of a device and set during
production. It is not possible to change the MAC address.
smartmicro Device#
MAC: 90-DF-B7-XX-XX-XX
Figure 10-1: smartmicro MAC address definition
10.3 IP
The software supports IPv4. Every device type has the same default IP, subnet mask and gateway. It is
possible to change those values of a device by parameterization. Optionally, the software has a DHCP
client feature for automatized IP distribution. The software also supports IP multicast for the Alive
(network discovery) feature.
Table 10-1: Parameterization IP level
Parameter Default Comment
DHCP Disabled Default configuration for a class C network with valid IP

range from 192.168.11.11 to 192.168.11.254. The device
Device IP 192.168.11.11

Subnet mask 255.255.255.0 IP is set to 192.168.11.11 and no gateway is set. This is a

typical sensor default.
Gateway 0.0.0.0 (disabled)
The software resolve the IP addresses of other devices in the Alive network discovery setup.
10.4 UDP
The UDP packet interface and protocol implementation is the (proprietary) smartmicro transport protocol
[see chapter 11 smartmicro transport protocol], which features network discovery [2], logging [3] and CAN
message-based data exchange [4]. The data exchange requires an open UDP port for incoming datagrams.
TABLE 10-2: PARAMETERIZATION UDP LEVEL
Incoming UDP port 55555 Open port is 55555 in IANA free range 49152-65535 [6]
The software resolve the incoming UDP ports of other devices in the Alive network discovery setup.
10.5 SMARTMICRO TRANSPORT PROTOCOL WITH CLIENT ID

The protocol for incoming and outgoing data packets is the same as for RS485, which will be explained in
chapter 11.
10.5.1 OUTGOING DATA PACKETS

When a device sends a packet, setting the source client ID is mandatory. Therefore, each device must have
a unique client ID and add it to the data as described in the protocol [1]. When a device forwards data, it
shall leave the source client ID untouched.
Setting the destination client ID is optional. The device may set a valid unique client ID. The device must
not set an invalid or software-internal used static client ID [5]. Setting a destination client ID is mandatory
for data forwarding.
10.5.2 INCOMING DATA PACKETS

When a device receives a packet, it must check for a valid source client ID. When a device forwards data, it
shall leave the source client ID untouched. When a client receives a packet with an enabled destination
client ID, it must compare the incoming destination client ID with its own or possible forwarding options.
10.6 SMARTMICRO APPLICATION PROTOCOLS (ALIVE)

When the network discovery feature (Alive) is active on a device, it periodically sends a UDP packet to a
specific multicast group. The smartmicro Alive protocol features network monitoring and presence
detection. All devices (any sensor, PC, controller, etc.) join the IP multicast group and periodically send a
UDP message. This message signalizes the presence of the device and reports client ID, IP address, and
open UDP port of the device [ref]. The network must support IP multicast.

IP multicast group Incoming UDP port
Alive multicast: 239.144.0.0:60000

Figure 10-2: Alive multicast definition
The feature enables all clients to monitor the network. All clients report their IP address, incoming UDP
port, and client ID to all other clients.
10.7 DATA STREAMS

Data streams are periodic data outputs of a device. The software sends any data stream (e.g., the target
list) to a client in the network.
10.8 NETWORK SET-UP
10.8.1 OPTION 1 - ALIVE

When the Alive protocol is used, the software accepts data (e.g., instructions) from clients if the incoming
source client ID is set and available in the network. For data streams, the software checks if the
destination client ID is available before it sends data. To configure a data stream, the user (or setup
wizard) sets the client ID of the recipient. The configuration without explicit IP addresses allows using
DHCP, out-of-the-box and interface independent solutions.
Table 10-3: Parameterization of a data stream to a client ID
Data Stream OBJECT_LIST Device sends the target list to a specific client ID.
Client ID 0x01000001
10.9
10.9
10.9 ALIVE PROTOCOL
10.9.1 WORD BYTE ORDER (ENDIAN)

Data transfers in network byte order (BIG ENDIAN). Any word eventually needs an endian conversion
between the platform and the network.
10.9.2 MAXIMUM TRANSFER UNIT

A limit may result from the Maximum Transfer Unit (MTU) of the underlying transport protocol but there is
no limit defined here.
10.9.3 TIMING
- A client shall send an Alive message not more than once every tALIVE_PERIOD.

- A client should send Alive messages with an interval as close to tALIVE_PERIOD as possible.
- When a client receives an Alive message from another client, it shall consider this client active for
at least tALIVE_TIMEOUT_MIN and no longer than tALIVE_TIMEOUT_MAX.
- When a client receives an Alive message from another client, it should consider this client active for
a time as close to tALIVE_TIMEOUT_MIN as possible.
tALIVE_PERIOD = 1s
tALIVE_TIMEOUT_MIN = 5s
tALIVE_TIMEOUT_MAX = 10s
10.9.4 HEADER
Table 10-4: Protocol Header
Byte offset Data words
Byte 0 Byte 1 Byte 2 Byte 3
0 u8_version_major u8_version_minor u16_reserved
VERSION MAJOR
Size: 1 byte
Format: Unsigned integer
Range: 1 … 255
Description: The major version of the protocol.
VERSION MINOR
Size: 1 byte
Range: 0 … 255
Description: The minor version of the protocol.
10.9.5 BODY
Table 10-5: Data of the Body
Byte Offset Byte 0 Byte 1 Byte 2 Byte 3
0 Client ID
4 IP v4 address
8 UDP port reserved

CLIENT ID
Size: 4 byte
Range: 0 … (232 – 1)
Description: The Smartmicro client ID.
IP V4 ADDRESS
Size: 4 byte
Range: 0 … (232 – 1)
Description: The IP v4 address of the device in 32-bit representation.
UDP PORT
Size: 2 byte
Range: 1 … (216 – 1)
Description: The open UDP port for incoming UDP datagrams.

11 SMARTMICRO TRANSPORT PROTOCOL

For simplification purposes the transport protocol is stateless and does not support any features for
segmentation or reliability. Those issues have to be handled in the application layer. The data transfer
format on the bus is Big Endian LSB first.
11.1 HEADER SPECIFICATION

The header is defined as shown in Table 11-1. All mandatory parts have a white background and all
optional parts a grey background.
Table 11-1: Header format definition

Bit 0 Bit 8 Bit 16 Bit 24 Bit40 Bit48 Bit63
Start Protocol Header Payload length Application protocol Reserved for

pattern version length type optional header
parts
Reserved for optional header parts

Reserved for optional header parts CRC 16
11.1.1 START PATTERN

As start pattern the value 0x7E shall be used.
11.1.2 PROTOCOL VERSION

The protocol version is related to this transport protocol. If there is a change in format of the header or the
body of this protocol, the version needs to be increased. Currently valid protocol versions:
1: Internal usage by smartmicro
2: Internal usage by smartmicro (half-duplex) limited size

11.1.3 HEADER LENGTH

The minimum length of the header is 8 bytes. Optionally, the header can be extended up to 64 bytes. Valid
header sizes are 8…64 bytes.
11.1.4 PAYLOAD LENGTH

The payload length is given in bytes. Valid length information is 0….65535.
11.1.5 APPLICATION PROTOCOL TYPE

The application protocol type field holds information about the application protocol type of the payload
data. Currently there are the following valid application protocol versions:
Table 11-2: Application protocol types (APT) defined for smartmicro transport protocol
APT Description
1 smartmicro CAN based data v1 (with byte stuffing)
2 Payload according to the ATXMega/SDLC CoPro Interface
3 STG (stationary target grid) application protocol
4 smartmicro CAN based data v2 (without byte stuffing)
5 Debug data (RADAR frame/cycle based)
6 Log Message data (ascii string, not null-terminated!)
7 ALIVE protocol (network discovery)
8 smartmicro Port based data

9 Smartmicro Interview Application Protocol
11.1.6 CRC 16 (HEADER)

For the 16 Bit CRC calculation CCITT (polynom X^16 + X^12 + X^5 + 1), the start value is always 0xFFFF.
The CRC is calculated over all header bytes, excluding the 16 CRC bytes themselves. The optional header
parts have to be considered in the CRC calculation as well (see 11.3 CRC 16).
11.1.7 OPTIONAL HEADER INFORMATION

Depending on the protocol version, the header size can be extended to up to 64 bytes. For protocol version
1 and 2 (11.1.2), the optional header parts are defined as follows:
Table 11-3: Optional Header Information
Bit 0 Bit 8 Bit 16 Bit 24 Bit40 Bit48

Bit63
Start Protocol Header Payload length Application protocol Flags

pattern version length type
Flags Message Counter Timestamp high
Timestamp low Reserved for optional header parts
Reserved for optional header parts CRC 16
11.1.8 FLAGS
The flags field is mandatory in protocol version 1 and 2 if optional information is added to the header. The
bits in the 32-Bit flag value define whether parts of the optional header are present (1) or not (0). If more
than one flag is activated, the content is attached in the following order:
Table 11-4: Header Flags
Flag Name Added Header Content
0 Message Counter Message Counter (2 bytes)
1 Timestamp Timestamp (8 bytes)
2 Skip Payload CRC -
3 Source Client ID Source Client ID (4 bytes)
4 Destination Client ID Destination Client ID (4 bytes)
5…31 Reserved -
11.1.9 MESSAGE COUNTER

The message counter is a specific 16-Bit value which is increased by the sender instance for every
message by 1. It starts at 0 and rolls over to 0 after 65535 is reached. The message counter is optional
and can be activated by the corresponding flag via the flag field.

11.1.10 TIMESTAMP
The timestamp is a 64-Bit UTC time, and the format is given by the NTP standard. The timestamp is
optional and can be activated by the corresponding flag via the flag field.
11.1.11 SKIP PAYLOAD CRC

When the Skip Payload CRC flag is set, it:
- Adds no additional data to the header
- Skips the CRC calculation for the payload
- The field Payload CRC is not attached
- Does not affect the header CRC calculation
11.1.12 SOURCE CLIENT ID

The Source Client ID is the unambiguous smartmicro client identification of the transmitter. The source
client ID is mandatory for Ethernet communication.
11.1.13 DESTINATION CLIENT ID

The Destination Client ID is the unambiguous smartmicro client identification of the recipient.
11.2 BODY SPECIFICATION

Bit 0 Bit (Payload Length*8) Bit (Payload length*8 +15)
Payload data CRC16
For the 16-Bit CRC calculation CCITT (polynom X^16 + X^12 + X^5 + 1), the start value is always 0xFFFF.
The CRC is calculated over the complete payload block.
Every data message consists of its own message ID, the number of used data bytes, and the data bytes
themselves. The message decoding is described earlier in this document.
Table 11-5: Structure of a data payload block

Byte\Bit 7 6 5 4 3 2 1 0
0 CAN message ID (UINT16) High
1 Low
2 CAN message length (UINT8)
3 CAN data payload (length x UINT8)

10
Example of a data cycle:

Transmitted RS485 data (sensor to controller):
7E 01 0C 00 6E 04 00 00 00 00 AB 65
05 00 08 10 00 00 00 3A 12 06 00 05 01 08 14 01 4B 07 B8 14 00 00 05 02 08 BE E1 F5 23 23 00 8D 00 05
03 08 F6 E2 F5 23 23 00 8D 01 05 04 08 2E E4 F5 23 23 00 8D 02 A6 31
Description:
Start Sequence Header CRC
Ident Length ____Data____Ident Length ____Data____Ident Length ____Data____Ident Length
____Data____Ident Length ____Data____ CRC
Interpretation:
Table 11-6: Interpretation example of the Header block
Start Sequence Header CRC Header
Byte 0 Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte
0 1 2 3 4 5 6 7 8 9 10
0x7E 01 0C 00 6E 04 00 00 00 00 AB 65
Table 11-7: Interpretation example of the payload block

Byte 1 Byte 0 Byte 0 Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
05 00 08 10 00 00 00 3A 12 06 00

05 01 08 14 01 4B 07 B8 14 00 00
05 02 08 BE E1 F5 23 23 00 8D 00
05 03 08 F6 E2 F5 23 23 00 8D 01
05 04 08 2E E4 F5 23 23 00 8D 02
CRC Payload
Byte 1 Byte 0
A6 31
11.2.1 PAYLOAD DATA

The payload data can contain any binary data with valid length of 0….65535 bytes.
11.2.2 CRC 16 (PAYLOAD)

For the 16 Bit CRC calculation CCITT (polynom X^16 + X^12 + X^5 + 1), the start value is always 0xFFFF.
The CRC is calculated over all payload data bytes, except the CRC itself.
11.3 CRC 16 CALCULATION

There are two different types of calculations for the CRC. Older versions of hardware use only an even
count of bytes for the calculation. That means, if the payload consists of an uneven number of count bytes,
it will add a last byte automatically for the calculation.
The kind of CRC calculation will be transmitted as protocol type. Typical types are 1 (UMRR-0C/-0F) or 4
(UMRR-11/-12) (see 11.1.5 Application Protocol Type):
Type 1:
If the payload has an uneven number of bytes, the protocol type 1 adds a 0x00 stuffing byte to the payload
at the low byte just before the CRC.
Type 4:
The CRC will be calculated with the transmitted count of bytes.
Example of a data cycle (UAT V4 command UMRR-11/-12) Type 4:
Transmitted RS485 data (controller to sensor):

7E 01 14 00 21 04 00 00 00 18 01 00 00 01 00 02 C3 D5 39 9A 03 FB 08 D0 07 00 04 FF 01 50 95 03 FB 08
D0 07 01 02 C9 00 00 00 03 FB 08 D0 07 02 00 01 00 00 00 EE 7D
Description:
Start Sequence Header Checksum Ident Length ____Data____ Ident Length ____Data____ Ident Length
____Data____ Checksum
Interpretation:
Table 11-8: Interpretation example of the Start Sequence
Start Sequence
Byte 0
0x7E
Table 11-9: Interpretation example of the header payload block

Header Payload
Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
01 14 00 21 04 00 00 00 18 01 00 00 01 00 02 C3 D5
Table 11-10: Interpretation example of the CRC Header

CRC Header
Byte 9 Byte 10
39 9A
Table 11-11: Interpretation example of the payload block

Byte 1 Byte 0 Byte 0 Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
03 FB 08 D0 07 00 04 FF 01 50 95
03 FB 08 D0 07 01 02 C9 00 00 00
03 FB 08 D0 07 02 00 01 00 00 00

Table 11-12: Interpretation example of the payload CRC

CRC Payload
Byte 1 Byte 0
EE 7D

12 LEGAL DISCLAIMER NOTICE

All products, product specifications and data in this document may be subject to change without notice to improve reliability, function or
otherwise.
Not all products and/or product features may be available in all countries and regions. For legal reasons features may be deleted from
products or smartmicro may refuse to offer products. Statements, technical information and recommendations contained herein are believed
to be accurate as of the stated date. smartmicro disclaims any and all liability for any errors, inaccuracies or incompleteness contained in this
document or in any other disclosure relating to the product.
To the extent permitted by applicable law, smartmicro disclaims (i) any and all liability arising out of the application or use of the product or
the data contained herein, (ii) any and all liability of damages exceeding direct damages, including - without limitation - indirect, consequential
or incidental damages, and (iii) any and all implied warranties, including warranties of the suitability of the product for particular purposes.
Statements regarding the suitability of products for certain types of applications are based on smartmicro’s knowledge of typical requirements
that are often placed on smartmicro products in generic/general applications. Statements about the suitability of products for a
particular/specific application, however, are not binding. It is the customer’s/user’s responsibility to validate that the product with the
specifications described is suitable for use in the particular/specific application. Parameters and the performance of products may deviate
from statements made herein due to particular/specific applications and/or surroundings. Therefore, it is important that the customer/user
has thoroughly tested the products and has understood the performance and limitations of the products before installing them for final
applications or before their commercialization. Although products are well optimized to be used for the intended applications stated, it must
also be understood by the customer/user that the detection probability may not be 100% and that the false alarm rate may not be zero.
The information provided, relates only to the specifically designated product and may not be applicable when the product is used in
combination with other materials or in any process not defined herein. All operating parameters, including typical parameters, must be
validated for each application by the customer’s/user’s technical experts. Customers using or selling smartmicro products for use in an
application which is not expressly indicated do so at their own risk.
This document does not expand or otherwise modify smartmicro’s terms and conditions of purchase, including but not being limited to the
warranty. Except as expressly indicated in writing by smartmicro, the products are not designed for use in medical, life-saving or life-sustaining
applications or for any other application in which the failure of the product could result in personal injury or death.
No license, expressed or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document or by any conduct of
smartmicro. Product names and markings noted herein may be trademarks of their respective owners.
Please note that the application of the product may be subject to standards or other regulations that may vary from country to country.
smartmicro does not guarantee that the use of products in the applications described herein will comply with such regulations in any country.
It is the customer’s/user’s responsibility to ensure that the use and incorporation of products comply with regulatory requirements of their
markets.
If any provision of this disclaimer is, or is found to be, void or unenforceable under applicable law, it will not affect the validity or enforceability
of the other provisions of this disclaimer.


Data Communication UMRR Traffic Management - UMRR11

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Communication UMRR Traffic Management - UMRR11

Uploaded by

Copyright:

Available Formats

DATA COMMUNICATION | USER MANUAL

s.m.s, smart microwave sensors GmbH Phone: +49 531 39023-0

Page 1 of 47 | December 14, 2021

1.1 Abbreviations .................................................................................................................................. 5

Page 2 of 47 | December 14, 2021

10.1 Physical ......................................................................................................................................... 34

Page 3 of 47 | December 14, 2021

11.2 Body Specification ........................................................................................................................ 42

Page 4 of 47 | December 14, 2021

1.2 REFERENCE DOCUMENTS

Page 5 of 47 | December 14, 2021

1.3 MESSAGE IDENTIFIER OVERVIEW

Identifier Document/Chapter Model Function

0x320 4 All sensors Boot Loader Status

0x430 5 TMIB CoProcessor Status Message

0x500 5.1 All sensors Sensor Control

0x501 5.2 All sensors Object Control

0x502 5.2.1 UMRR-11, TRUGRD Object_data_1

0x780 … [RD2] All sensors Statistic and Trigger module

2.1 MIGRATING FROM UMRR-0C SENSORS

2.2 MAIN PROCESSOR AND COMMUNICATION PROCESSOR

Table 2-1 CAN-ID vs. Target Assignment

Page 6 of 47 | December 14, 2021

CAN ID Target Parameters / Firmware to send

0 MAIN processor ID0 Control Parameters

2.3 STANDARD MESSAGES AND UDT MESSAGES

3.1.1 UAT COMMAND VERSION 4

CRC-16 CRC-16 Number of Target Format- Message UAT – ID

Page 7 of 47 | December 14, 2021

- Format version number: UAT version number 4

Dim1 Dim0 Parameter Number Message Message UAT – ID

Example for a parameter with multiple dimensions:

Page 8 of 47 | December 14, 2021

Figure 3-1: Example with multi-dimensional parameter (TMC command window)

Table 1: Definition of field „Message Type”

4 Parameter write / read

Page 9 of 47 | December 14, 2021

SECOND COMMAND MESSAGE

Parameter Parameter Parameter Parameter Data Message UAT – ID

Table 3-3 Definition of field “Data Format”

2 Float (IEEE 754)

Page 10 of 47 | December 14, 2021

Figure 3-2 Parameter in the Command View

Figure 3-3 messages in the “Data to Sensor” View

Page 11 of 47 | December 14, 2021

Transmitted RS485 data UAT V4 command (controller to sensor):

Table 3-5Messages with Ident, Length and Payload

Table 3-6 Checksum of the data payload

Page 12 of 47 | December 14, 2021

Figure 3-4Example of CRC calculation

Page 13 of 47 | December 14, 2021

4 BOOT LOADER STATUS MESSAGE

Hi-Byte: Lo-Byte: Hi-Byte: Lo-Byte: High Nibble:

(uint) (uint) (uint) (uint)

0 DSP in normal mode

1 DSP ready for flash data reception

2 DSP received end of can load data block

3 DSP indicates flash process successful

Page 14 of 47 | December 14, 2021

DSP acknowledges PC initiated break of the can load sequence

5 DSP Error while changing the sensor ID

6 DSP Error: Application password not found or wrong

16 DSP Memory Test Error