Examples of simple DSRC messages encoded with and without ...
PRELIMINARY
Examples of simple DSRC message encoded with and without tagging
davidkelley@
This paper presents a few simple DSRC messages with the literal encoding style defined in the current standard and also with the BER style of encoding being considered for use in the POC work and as a possible preferred encoding for future editions of the standard.
Prerequisites
In order to create these messages one will need two prerequisite items, first a set of common data values encoded into their hex representation forms and second a tool to encode the messages into the BER formats.
The first of these is provided by a simple utility tool I created over the weekend and available download at
The second is a low cost (~200) commercial tool called “ASN1VE ASN.1 viewer/editor” and available at There are other such tools, but I am been suggesting people use this one as a starting point.
I strongly urge anyone interested in creating these messages to obtain these two tools.
If you only want to read this document and understand the problem, you will not need them.
In order the make the data example more recognizable, I have re-used the same data values in multiple instances of the messages. A list of these values is given here in both the base ten and the hex values. These values will become patterns seen in the messages that appear subsequently.
The data itself
The data used in the message examples was encoded with the tool mentioned above.
The values chosen were as follows:
DSRCmsgID varies with each message type, basic safety is 0x02
Seconds at 0.010 sec becomes a value of 0x00-0A
(in seconds x 100, this is milliseconds precision for the current minute)
The tempID is chosen to be 0x1111-1111-11 (poss error here, should be 6)
(this may be the macID at times)
Longitude at -123.1234567 degrees is a value of 0xF8-A9-48-FF
in units of micro degrees
Longitude at -123.1234567 degrees is a value of 0xC5-4A-47-FA
in units of 1/8th micro degrees
Latitude at 30.0 degrees is a value of 0x01-C9-C3-80
in units of micro degrees
Latitude at 30.0 degrees is a value of 0x0E-4E-1C-00
in units of 1/8th micro degrees
Elevation at 300 meters is a value of 0x00-32-C8
Speed at 100 m/sec becomes a value of 0x27-10
Heading at 10 deg becomes a value of 0x07-1C
AccelerationSet4Way is made up of 0x00-00-00-00-00-00-0
Representing Accel in all three axis (lat, long and vert) set to zero and yaw rate also set to zero
Brakes is made up all brakes on (B1111) and ABS and traction set off, so of 0xF5
Steering is 30.01 degrees of angle, so of 0x05-DD
Throttle is 30 percent, so of 0x3C
Light Sets is made all lights off, so of 0x00
Vehicle size is made up of width 213 cm so 0x00-D5 and length of 640 cm
so 0x02-80 resulting in a 3-byte value of 0x0D-52-80
The valueCnts for item types one and two will be set to zero (no items) in our first example, so both are 0x00
The above values will be used in the message that follow. It is important for this study to use values where the full length of the data range is used. Some of the encoding rules found for ASN (such as BER) can take advantage of “shorter” data instances, encoding only a byte rather then more bytes at times. While this is laudable, we do not want it to have a hidden effect on the comparisons of the data we are sending as we examine encoding rules and message lengths.
A First Message, the basic safety message
The messages have been consistently laid out in an 8-byte across pattern. If you use the BER tool mentioned above you can see a layout similar to this and when you pause your mouse key over the data field a nice little pop-up will tell you what part of the message that is. This can be incredibly helpful when decoding raw bytes. Here is a template for the BasicSafetyMessage (see the on-line documentation pages 20-23) with implicit encoding following this format and using the data values just presented. Note that this message is 41 bytes in length with this content.
Bytes Values Meaning
01 02-00 0A-11 1111 1111 -- msgID, currSec, tempID
09 11-C5 4A45 FA-0E 4E1C -- tempID, Lat, Long.
17 00-00 32C8- 2710- 071C- -- Long, Elevation, Speed, Heading
25 0000 0000 0000 00-F5 -- AccelSet (7 bytes total), Brakes
33 05DD- 3C-00- 0D52 80-00 -- Steering, Throttle, LightSet, VehSize, cnt1
41 00 -- cnt2
The dashes in the above (“-“) show where data elements separate and are presented to help the reader the first time through all this.
If there was some content carried in the “item1” or “item2” part of the message, it might look like the above for the beginning of the message but the latter words would contain this additional data. We examine two examples of this next.
Example with type One Content
Presume we wish to send the airbag count. The airbag count itself (lets use a value of four airbags, so 0x04) is preceded by the airbag count tag item, which is defined as the value five (0x05) There is one set of data, so the cnt1 becomes a value of 0x01. These items are inserted before the final cnt2 item (which remains zero because no items of that type are sent). The resulting message is two bytes longer and is shown below. Note that this message is 43 bytes in length with this content.
Bytes Values Meaning
01 0200 0A11 1111 1111 -- msgID, currSec, tempID
09 11C5 4A45 FA0E 4E1C -- tempID, Lat, Long.
17 0000 32C8 2710 071C -- Long, Elevation, Speed, Heading
25 0000 0000 0000 00F5 -- AccelSet (7 bytes total), Brakes
33 05DD 3C00 0D52 8001 -- Steering, Throttle, LightSet, VehSize, cnt1
41 0504 00 -- airbagTag, airbagValue, cnt2
Example with type Two Content
Presume we wish to again extend this using a couple of the type2 items. These items are declared to be defined OUTSIDE the standard, and it is presumed that the sending and receiving party know the length of the data and the semantic meaning.[1] The length is vitally important in order to detect the end of each item and the beginning of the next item. Note this is true even when what is sent is a data element defined from the standard.
Consider a user defined 2-btye tag of 0xAAAA and one of 0xBBBB. Consider the payload data to be 4 bytes in length and consisting of the values 0xCCCC-CCCC and 0xDDDD-DDDD. The cnt2 value would be 0x02 representing that two items of some length (known by the tag the follows) are to be found. The message is shown below. Note that this message is 55 bytes in length with this content.
Bytes Values Meaning
01 0200 0A11 1111 1111 -- msgID, currSec, tempID
09 11C5 4A45 FA0E 4E1C -- tempID, Lat, Long.
17 0000 32C8 2710 071C -- Long, Elevation, Speed, Heading
25 0000 0000 0000 00F5 -- AccelSet (7 bytes total), Brakes
33 05DD 3C00 0D52 8001 -- Steering, Throttle, LightSet, VehSize, cnt1
41 0504 02AA AACC CCCC -- airbagTag, airbagValue, cnt2, 1st Item
49 CCBB BBDD DDDD DD -- 1st Item, 2nd item
Laziness and lack of time prevent me from adding more messages right here, forgive me. [Besides most of this work is really guide effort stuff]
Let consider these implicitly encoded test cases and their lengths, partial data is present in the table below.
Message Type Implicit Encoding BER Encoding
Basic Msg 1 41 Bytes ?? Bytes
Basic Msg with Type1 43 Bytes ?? Bytes
Basic Msg with Type2 55 Bytes ?? Bytes
Next step is to load this into the BER viewer tool and re-do the data their way.
Encoding the Same Message in BER form
First, it should be pointed out that an “empty” message of this type is 77 byes long when loaded with nothing but “zero data values” and the required tagging. You can see this with the ASN1VE tool when you first open an empty message. The message is longer (from 41 to 77 bytes) because of the presence of the tagging, but the actual data values are shorter (each is only one byte in length) because BER has the property to save extra bytes of length when it is not actually used by the data to be transmitted. This will become very important when we deal with the map fragment messages.[2]
Looking at this another way, we have ~20 elements in this message. Considering that each tag-value requires two bytes to encode in the BER style, we would expect to see about 40 bytes in pure tagging information added to our message. We have 41 bytes of pure information, this suggests that we should get a message of ~80 bytes when useful data is sent.
The below screen shot shows the ASN1VE tool with this message loaded. The panel on the left is showing the instance names from the ASN (in other words ‘secMark” is an instance of our DSRC defined type “Dsecond”). The gray highlighting of this element is reflected in the highlighting shown in the panel at the upper right, where the actual bytes over the wire for the value secMark is also highlighted. The panel below is the value of this data item (set to 10, as in 10 milliseconds, or 0x0A in Hex) as well as some of the actual tagging information for the element. The tabbed display allow seeing this same information in an XML and a textual format as well. Off to the right side (not shown for size reasons) is an ASCII-text decode of the message content as well.
Observe that the element ‘secMark” is sent in three bytes with the values 0x81-01-0A which reflect the BER style of encoding into a sequence of tag-length-value. Here you can see the encoding values clearly, In general the first two bytes are the tag and length value, followed by one or more bytes to send the data. Play with the tool if you want to see more, it is much more instructive when interactive.
[pic]
The Basic Safety Message (empty) displayed in raw bytes
Hand loading the rest of the data value from the prior example into the tool produced the image shown next. This file has been saved as msg1.dat and is a binary file.[3]
Observe that while the time value was “shortened” a byte by the BER process, the other values were chosen to be full length and representative to prevent any such shortening from occurring when we compared the data. Notice also that structures like the acceleration set, which was crafted to fit into a 7-byte length, is now larger (14 bytes) because the BER encoding has placed tags around each inner element. In the brakes structure, a similar thing has occurred. With some judicious re-coding of the ASN this can be overcome, but it is typical of the BER process.[4] You pay for extra tagging in greater transmitted word count (about two bytes per element), you get extra flexibility in the message design and handling and less custom coding effort.
Notes in developing the next example: The lat and long are reversed in the above example, but this does not change the byte counts. It just shows how what a pain it is to get these things right by hand. The elevation in the BER example was shorted by the BER rules by one byte. Note that there are short (2-byte) entries for “items1” and “items2” in the display, even though in this example there are no such items. Because we hand encoding the DSRC message we have a “count” value that appears in the message to allow the receiving side to decode what follows. With BER this is more or less handled automatically so 6 of these bytes would not be needed here. Overall the BER message below is perhaps 12 bytes longer then it would need to be if we were to re-code the ASN intending to use BER from the onset.
The resulting message is 96 bytes in length. A bit longer than the estimate of 81 bytes, but this is due to the inner tagging that BER has placed on some of our structures. I feel a value of 84 bytes is perhaps more representative.
[pic]
Basic Safety Message encoded with BER format, 96 bytes in length
For completeness, I also provide this same message rendered into the XML format called “XER” that this tool supports. The primary difference between this and the ITS style formats is that the enumerated values are not showed as quite the same style of textual strings and some values display in hex rather then base ten.
-
basicSafetyMessage
10
1111111111 ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- correcting lecture audios using speech synthesis
- an introduction to mpeg ts tsduck
- sorcerer installation and operation udxf
- decoderpro3 user s guide
- an end to end ocr text re organization sequence learning
- gb usa märklin decoder tool 3 märklin modellbahnen
- end to end text to speech synthesis stanford university
- access washington home
- convert text to audio premier at home
- more combinational circuits edward bosworth
Related searches
- examples of simple essays
- medical with and without sign
- polio numbers with and without the vaccine
- breast mri with and without cpt code
- mri brain with and without contrast cpt
- mri with and without contrast
- cpt code ct with and without contrast
- examples of simple business plans
- examples of simple scientific experiments
- with and without replacement probability
- with and without symbols medical
- examples of simple algebra equations