Changes

Codec (view source)

Revision as of 20:55, 30 October 2019

428 bytes added , 20:55, 30 October 2019

Minor style improvements

Line 22: Line 22:

='''<big>Codec for device data sending</big>'''=

−

In this chapter you will find information about every Codec protocol which are using for device data sending and differences between them. ~~ ~~

+

In this chapter you will find information about every Codec protocol which are using for device data sending and differences between them.

=='''<big>Codec 8</big>'''==

Line 28: Line 28:

*'''<big>Protocol Overview</big>'''

−

Codec8 – a main FM device protocol that is used for sending data to server. ~~ ~~

+

Codec8 – a main FM device protocol that is used for sending data to server.

*'''<big>Codec8 protocol sending over TCP</big>'''

−

TCP is a connection-oriented protocol that is using for communication between devices. How this type protocol works you will read later. ~~ ~~

+

TCP is a connection-oriented protocol that is using for communication between devices. How this type protocol works you will read later.

*'''AVL Data Packet'''

Line 60: Line 60:

'''Preamble''' – the packet starts with four zero bytes.

'''Data Field Length''' – size is calculated starting from Codec ID to Number of Data 2.

−

'''Codec ID''' – in Codec8 it is always 0x08.

+

'''Codec ID''' – in Codec8 it is always <code>0x08</code>.

'''Number of Data 1''' – a number which defines how many records is in the packet.

'''AVL Data''' – actual data in the packet (more information below).

'''Number of Data 2''' – a number which defines how many records is in the packet. This number must be the same as “Number of Data 1”.

−

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]].

+

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

'''Note:''' for ~~FMB6XY~~ and FM63XY, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes. For other devices, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

+

'''Note:''' for [[FMB630]], [[FMB640]] and [[FM6300|FM63XY]], minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes. For other devices, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

−

*AVL Data

Line 85: Line 83:

|-

|}

+

'''Timestamp''' – a difference, in milliseconds, between the current time and midnight, January, 1970 UTC (UNIX time).

'''Priority''' – field which define AVL data priority (more information below).

−

'''GPS Element''' – ~~locational~~ information of the AVL data (more information below).

+

'''GPS Element''' – location information of the AVL data (more information below).

−

'''IO Element''' – additional configurable information from device (more information below). ~~ ~~

+

'''IO Element''' – additional configurable information from device (more information below).

*Priority

Line 105: Line 105:

! rowspan="1" style="width:40%; vertical-align: middle; text-align: center;" |2

| style="vertical-align: middle; text-align: center;" |Panic

−

|}

+

|}

*GPS element

Line 127: Line 127:

|-

|}

+

'''Longitude''' – east – west position.

'''Latitude''' – north – south position.

Line 133: Line 135:

'''Satellites''' – number of visible satellites.

'''Speed''' – speed calculated from satellites.

−

'''Note:''' Speed will be 0x0000 if GPS data is invalid.

+

'''Note:''' Speed will be <code>0x0000</code> if GPS data is invalid.

Longitude and latitude are integer values built from degrees, minutes, seconds and milliseconds by formula:

[[Image:GPS.png]]

Line 143: Line 145:

To determine if the coordinate is negative, convert it to binary format and check the very first bit. If it is 0, coordinate is positive, if it is 1, coordinate is negative.

Example:

−

Received value: 20 9C CA 80 converted to BIN: 00100000 10011100 11001010 10000000 first bit is 0, which means coordinate is positive converted to DEC: 547146368. For more information see two‘s complement arithmetic. ~~ ~~

+

Received value: <code>20 9C CA 80</code> converted to BIN: <code>00100000 10011100 11001010 10000000</code> first bit is 0, which means coordinate is positive converted to DEC: <code>547146368</code>. For more information see two‘s complement arithmetic.

*IO Element

Line 152: Line 154:

| style="vertical-align: middle; text-align: center;" |1 byte

| rowspan="26" style=" width:5%; vertical-align: middle; text-align: left;" |

−

| rowspan="26" style=" width:65%; vertical-align: middle; text-align: left;" |'''Event IO ID''' – if data is acquired on event – this field defines which IO property has changed and generated an event. For example, when if Ignition state changed and it generate event, Event IO ID will be 0xEF (AVL ID: 239). If it’s not eventual record – the value is 0.

+

| rowspan="26" style=" width:65%; vertical-align: middle; text-align: left;" |'''Event IO ID''' – if data is acquired on event – this field defines which IO property has changed and generated an event. For example, when if Ignition state changed and it generate event, Event IO ID will be <code>0xEF</code> (AVL ID: 239). If it’s not eventual record – the value is 0.

'''N''' – a total number of properties coming with record (N = N1 + N2 + N4 + N8).

'''N1''' – number of properties, which length is 1 byte.

Line 232: Line 234:

| style="vertical-align: middle; text-align: center;" |8 bytes

|-

−

|} <br~~> <br~~>

+

|}

*'''Communication with server'''

First, when module connects to server, module sends its IMEI. First comes short identifying number of bytes written and then goes IMEI as text (bytes).

−

For example, IMEI 356307042441013 would be sent as 000F333536333037303432343431303133.

+

For example, IMEI <code>356307042441013</code> would be sent as <code>000F333536333037303432343431303133</code>.

−

First two bytes denote IMEI length. In this case 0x000F means, that IMEI is 15 bytes long.

+

First two bytes denote IMEI length. In this case <code>0x000F</code> means, that IMEI is 15 bytes long.

−

After receiving IMEI, server should determine if it would accept data from this module. If yes, server will reply to module 01, if not - 00. Note that confirmation should be sent as binary packet. I.e. 1 byte 0x01 or 0x00.

+

After receiving IMEI, server should determine if it would accept data from this module. If yes, server will reply to module <code>01</code>, if not - <code>00</code>. Note that confirmation should be sent as binary packet. I.e. 1 byte <code>0x01</code> or <code>0x00</code>.

Then module starts to send first AVL data packet. After server receives packet and parses it, server must report to module number of data received as integer (four bytes).

−

If sent data number and reported by server doesn’t match module resends sent data. ~~ ~~

+

If sent data number and reported by server doesn’t match module resends sent data.

*Example:

Module connects to server and sends IMEI:

−

000F333536333037303432343431303133

+

Server accepts the module:

01

−

Module sends data packet: ~~ ~~

+

Module sends data packet:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 267: Line 269:

| style="vertical-align: middle; text-align: center;" |00008612

|-

−

|} ~~ ~~

+

|}

−

Server acknowledges data reception (2 data elements): '''00000002''' ~~ ~~

+

Server acknowledges data reception (2 data elements): '''<code>00000002</code>'''

*'''Examples'''

−

Hexadecimal stream of AVL Data Packet receiving and response in these examples are given in hexadecimal form. The different fields of packets are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding. ~~ ~~

+

Hexadecimal stream of AVL Data Packet receiving and response in these examples are given in hexadecimal form. The different fields of packets are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

'''1'st example'''

Receiving one data record with each element property (1 byte, 2 bytes, 4 byte and 8 byte).

Received data in hexadecimal stream:

−

000000000000003608010000016B40D8EA30010000000000000000000000000000000105021503010101425E0F01F10000601A014E0000000000000000010000C7CF

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 379: Line 383:

| style="vertical-align: middle; text-align: center;" |00 00 C7 CF

|-

−

|} ~~ ~~

+

|}

−

Server response: 00000001

+

Server response: <code>00000001</code>

'''2'nd example'''

Receiving one data record with one or two different element properties (1 byte, 2 byte).

Received data in hexadecimal stream:

−

000000000000002808010000016B40D9AD80010000000000000000000000000000000103021503010101425E100000010000F22A

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 475: Line 481:

| style="vertical-align: middle; text-align: center;" |00 00 F2 2A

|-

−

|} ~~ ~~

+

|}

−

Server response: 00000001

+

Server response: <code>00000001</code>

'''3'rd example'''

Receiving two or more data records with one or more different element properties.

Received data in hexadecimal stream:

−

000000000000004308020000016B40D57B480100000000000000000000000000000001010101000000000000016B40D5C198010000000000000000000000000000000

+

<code>000000000000004308020000016B40D57B480100000000000000000000000000000001010101000000000000016B40D5C198010000000000000000000000000000000

−

101010101000000020000252C

+

101010101000000020000252C</code>

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 611: Line 619:

| style="vertical-align: middle; text-align: center;" |00 00 25 2C

|-

−

|} ~~ ~~

+

|}

−

Server response: 00000002

+

Server response: <code>00000002</code>

*'''<big>Codec8 protocol sending over UDP</big>'''

Line 620: Line 630:

*'''AVL Data Packet'''

−

The packet structure is as follows: ~~ ~~

+

The packet structure is as follows:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 638: Line 648:

|-

|}

+

'''Example''' – packet length (excluding this field) in big ending byte order.

'''Packet ID''' – packet ID unique for this channel.

'''Not Usable Byte''' – not usable byte.

−

'''Packet payload''' – data payload. ~~ ~~

+

'''Packet payload''' – data payload.

*Acknowledgment packet

−

Acknowledgment packet should have the same Packet ID as acknowledged data packet and empty Data Payload. Acknowledgement should be sent in binary format. ~~ ~~

+

Acknowledgment packet should have the same Packet ID as acknowledged data packet and empty Data Payload. Acknowledgement should be sent in binary format.

{| class="nd-othertables_2" style="width:100%;"

|+

Line 659: Line 671:

|-

|}

+

'''Packet Length''' – packet length by sending/response data.

'''Packet ID''' – same as in acknowledgment packet.

−

'''Not Usable Byte''' – always will be 0x01.

+

'''Not Usable Byte''' – always will be <code>0x01</code>.

*Sending AVL Packet Payload using UDP channel

−

Below table represents Sending Packet Payload structure. ~~ ~~

+

Below table represents Sending Packet Payload structure.

{| class="nd-othertables_2" style="width:100%;"

|+

Line 682: Line 696:

|}

'''AVL Packet ID''' – ID identifying this AVL packet.

−

'''IMEI Length''' – always will be 0x000F.

+

'''IMEI Length''' – always will be <code>0x000F</code>.

'''Module IMEI''' – IMEI of a sending module encoded the same as with TCP.

−

'''AVL Data Array''' – array of encoded AVL data (same as TCP AVL Data Array). ~~ ~~

+

'''AVL Data Array''' – array of encoded AVL data (same as TCP AVL Data Array).

*Server response Packet Payload using UDP channel

−

Below table represents Server Response Packet Payload structure. ~~ ~~

+

Below table represents Server Response Packet Payload structure.

{| class="nd-othertables_2" style="width:100%;"

|+

Line 699: Line 713:

| style="vertical-align: middle; text-align: center;" |1 byte

|-

−

|}

+

|}

*'''Communication with server'''

Line 707: Line 721:

*Example:

−

Module sends the data: ~~ ~~

+

Module sends the data:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 729: Line 743:

| style="vertical-align: middle; text-align: center;" |0802…(data elements)…02

|-

−

|} ~~ ~~

+

|}

−

Server must respond with acknowledgment: ~~ ~~

+

Server must respond with acknowledgment:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 745: Line 761:

| style="vertical-align: middle; text-align: center;" |DD02

|-

−

|}<br~~> <br~~>

+

|}

*'''Example'''

−

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

Received data in hexadecimal stream:

−

003DCAFE0105000F33353230393330383634303336353508010000016B4F815B30010000000000000000000000000000000103021503010101425DBC000001

+

<code>003DCAFE0105000F33353230393330383634303336353508010000016B4F815B30010000000000000000000000000000000103021503010101425DBC000001</code>

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 850: Line 866:

| style="vertical-align: middle; text-align: center;" |01

|-

−

|} ~~ ~~

+

|}

−

Server response in ~~hexademical~~ stream:

+

−

0005CAFE010501

+

Server response in hexadecimal stream:

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

Line 878: Line 896:

| style="vertical-align: middle; text-align: center;" |01

|-

−

|} <br~~> <br~~>

+

|}

=='''<big>Codec 8 Extended</big>'''==

Line 884: Line 902:

*'''<big>Protocols overview</big>'''

−

Codec8 Extended is using for FMBXXX family devices. This protocol looks familiar like Codec8 but they have some differences. Main differences between are shown in below table: ~~ ~~

+

Codec8 Extended is using for FMBXXX family devices. This protocol looks familiar like Codec8 but they have some differences. Main differences between are shown in below table:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 915: Line 933:

| style="vertical-align: middle; text-align: center;" |Includes variable size elements

|-

−

|} <br~~> <br~~>

+

|}

*'''<big>Codec 8 Extended protocol sending over TCP</big>'''

Line 921: Line 939:

*'''AVL data packet'''

−

Below table represents AVL data packet structure: ~~ ~~

+

Below table represents AVL data packet structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 941: Line 959:

|-

|}

+

'''Preamble''' – the packet starts with four zero bytes.

'''Data Field Length''' – size is calculated starting from Codec ID to Number of Data 2.

−

'''Codec ID''' – in Codec8 it is always ~~0x08~~.

+

'''Codec ID''' – in Codec8 Extended it is always <code>0x8E</code>.

'''Number of Data 1''' – a number which defines how many records is in the packet.

'''AVL Data''' – actual data in the packet (more information below).

'''Number of Data 2''' – a number which defines how many records is in the packet. This number must be the same as “Number of Data 1”.

−

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]].

+

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

'''Note:''' for ~~FMB6XY~~ and FM63XY, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes. For other devices, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes. ~~ ~~

+

'''Note:''' for [[FMB630]], [[FMB640]] and [[FM6300|FM63XY]], minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes. For other devices, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

*AVL Data

−

Below table represents AVL Data structure: ~~ ~~

+

Below table represents AVL Data structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 966: Line 986:

|-

|}

+

'''Timestamp''' – a difference, in milliseconds, between the current time and midnight, January, 1970 UTC (UNIX time).

'''Priority''' – field which define AVL data priority (more information below).

'''GPS Element''' – locational information of the AVL data (more information below).

−

'''IO Element''' – additional configurable information from device (more information below). ~~ ~~

+

'''IO Element''' – additional configurable information from device (more information below).

*Priority

−

Below table represents Priority values. Packet priority depends on device configuration and records sent. ~~ ~~

+

Below table represents Priority values. Packet priority depends on device configuration and records sent.

{| class="nd-othertables_2" style="width:25%;"

|+

Line 986: Line 1,008:

! rowspan="1" style="width:40%; vertical-align: middle; text-align: center;" |2

| style="vertical-align: middle; text-align: center;" |Panic

−

|} <br~~> <br~~>

+

|}

*GPS element

−

Below table represents GPS Element structure: ~~ ~~

+

Below table represents GPS Element structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,008: Line 1,030:

|-

|}

+

'''Longitude''' – east – west position.

'''Latitude''' – north – south position.

Line 1,014: Line 1,038:

'''Satellites''' – number of visible satellites.

'''Speed''' – speed calculated from satellites.

−

'''Note:''' Speed will be 0x0000 if GPS data is invalid.

+

'''Note:''' Speed will be <code>0x0000</code> if GPS data is invalid.

Longitude and latitude are integer values built from degrees, minutes, seconds and milliseconds by formula:

[[Image:GPS.png]]

Line 1,022: Line 1,046:

If longitude is in west or latitude in south, multiply result by –1.

Note:

−

To determine if the coordinate is negative, convert it to binary format and check the very first bit. If it is 0, coordinate is positive, if it is 1, coordinate is negative.

+

To determine if the coordinate is negative, convert it to binary format and check the very first bit. If it is <code>0</code>, coordinate is positive, if it is <code>1</code>, coordinate is negative.

Example:

−

Received value: 20 9C CA 80 converted to BIN: 00100000 10011100 11001010 10000000 first bit is 0, which means coordinate is positive converted to DEC: 547146368. For more information see two‘s complement arithmetic. ~~ ~~

+

Received value: <code>20 9C CA 80</code> converted to BIN: <code>00100000 10011100 11001010 10000000</code> first bit is 0, which means coordinate is positive converted to DEC: <code>547146368</code>. For more information see two‘s complement arithmetic.

*IO Element

Line 1,138: Line 1,162:

| style="vertical-align: middle; text-align: center;" |Defined by lenght

|-

−

|} <br~~> <br~~>

+

|}

*'''Communication with server'''

−

Communication with server is the same as with Codec8 protocol, except in Codec8 Extended protocol Codec ID is 0x8E. ~~ ~~

+

Communication with server is the same as with Codec8 protocol, except in Codec8 Extended protocol Codec ID is 0x8E.

−

*Example: ~~ ~~

+

*Example:

Module connects to server and sends IMEI:

−

000F333536333037303432343431303133

+

Server accepts the module:

−

01

+

−

Module sends data packet: ~~ ~~

+

Module sends data packet:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,168: Line 1,192:

| style="vertical-align: middle; text-align: center;" |00008612

|-

−

|}~~ ~~

+

|}

−

Server acknowledges data reception (2 data elements): '''00000002''' ~~ ~~

+

Server acknowledges data reception (2 data elements): '''<code>00000002</code>'''

*'''Example'''

−

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

Received data in hexadecimal stream:

−

000000000000004A8E010000016B412CEE000100000000000000000000000000000000010005000100010100010011001D00010010015E2C880002000B000000003544C87

+

<code>000000000000004A8E010000016B412CEE000100000000000000000000000000000000010005000100010100010011001D00010010015E2C880002000B000000003544C87

−

A000E000000001DD7E06A00000100002994

+

A000E000000001DD7E06A00000100002994</code>

Parsed data:

{| class="nd-othertables_2" style="width:100%;"

Line 1,281: Line 1,307:

| style="vertical-align: middle; text-align: center;" |00 00 29 94

|-

−

|} ~~ ~~

+

|}

−

Server response: 00000001

+

Server response: <code>00000001</code>

*'''<big>Codec8 Extended protocol sending over UDP</big>'''

Line 1,288: Line 1,316:

*'''UDP channel protocol'''

−

AVL data packet is the same as with Codec8, except Codec ID is changed to 0x8E.

+

AVL data packet is the same as with Codec8, except Codec ID is changed to <code>0x8E</code>.

*'''Communication with server'''

Line 1,296: Line 1,324:

*Example:

−

Module sends the data: ~~ ~~

+

Module sends the data:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,318: Line 1,346:

| style="vertical-align: middle; text-align: center;" |8E02…(data elements)…02

|-

−

|} ~~ ~~

+

|}

−

Server must respond with acknowledgment: ~~ ~~

+

Server must respond with acknowledgment:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,334: Line 1,364:

| style="vertical-align: middle; text-align: center;" |DD02

|-

−

|} <br~~> <br~~>

+

|}

*'''Example'''

−

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

Received data in hexadecimal stream:

−

005FCAFE0107000F3335323039333038363430333635358E010000016B4F831C680100000000000000000000000000000000010005000100010100010011009D000100

+

<code>005FCAFE0107000F3335323039333038363430333635358E010000016B4F831C680100000000000000000000000000000000010005000100010100010011009D000100</code>

−

10015E2C880002000B000000003544C87A000E000000001DD7E06A000001

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,452: Line 1,482:

| style="vertical-align: middle; text-align: center;" |00 00

|-

−

|} ~~ ~~

+

|}

−

Server response in ~~hexademical~~ stream:

+

−

0005CAFE010700

+

Server response in hexadecimal stream:

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

Line 1,480: Line 1,512:

| style="vertical-align: middle; text-align: center;" |00

|-

−

|} ~~ ~~

+

|}

=='''<big>Codec 16</big>'''==

Line 1,486: Line 1,518:

*'''<big>Protocol overview</big>'''

−

Codec16 is using for FMB630/FM63XY devices. This protocol looks familiar like Codec8 but they have some differences. Main differences between are shown in table below: ~~ ~~

+

Codec16 is using for FMB630/FM63XY devices. This protocol looks familiar like Codec8 but they have some differences. Main differences between are shown in table below:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,509: Line 1,541:

| style="vertical-align: middle; text-align: center;" |Is Using

|-

−

|} ~~ ~~

+

|}

−

'''Note:''' Codec16 is supported from firmware – 00.03.xx and newer. (FMB630/FM63XY) || AVL ID‘s which are higher than 255 will can be used only in ~~Codec 16~~ protocol. ~~ ~~

+

'''Note:''' Codec16 is supported from firmware – 00.03.xx and newer. ([[FMB630]]/FM63XY) || AVL ID‘s which are higher than 255 will can be used only in Codec16 protocol.

*'''<big>Codec 16 protocol sending over TCP</big>'''

Line 1,516: Line 1,550:

*'''AVL data packet'''

−

Below table represents AVL data packet structure: ~~ ~~

+

Below table represents AVL data packet structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,536: Line 1,570:

|-

|}

+

'''Preamble''' – the packet starts with four zero bytes.

'''Data Field Length''' – size is calculated starting from Codec ID to Number of Data 2.

Line 1,542: Line 1,578:

'''AVL Data''' – actual data in the packet (more information below).

'''Number of Data 2''' – a number which defines how many records is in the packet. This number must be the same as “Number of Data 1”.

−

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]].

+

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

'''Note:''' for ~~FMB6XY~~ and FM63XY, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes. ~~ ~~

+

'''Note:''' for [[FMB630]] and FM63XY, minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 255 bytes.

*AVL Data

−

Below table represents AVL Data structure: ~~ ~~

+

Below table represents AVL Data structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,561: Line 1,597:

|-

|}

+

'''Timestamp''' – a difference, in milliseconds, between the current time and midnight, January, 1970 UTC (UNIX time).

'''Priority''' – field which define AVL data priority (more information below).

−

'''GPS Element''' – ~~locational~~ information of the AVL data (more information below).

+

'''GPS Element''' – location information of the AVL data (more information below).

−

'''IO Element''' – additional configurable information from device (more information below). ~~ ~~

+

'''IO Element''' – additional configurable information from device (more information below).

*Priority

−

Below table represents Priority values. Packet priority depends on device configuration and records sent. ~~ ~~

+

Below table represents Priority values. Packet priority depends on device configuration and records sent.

{| class="nd-othertables_2" style="width:25%;"

|+

Line 1,581: Line 1,619:

! rowspan="1" style="width:40%; vertical-align: middle; text-align: center;" |2

| style="vertical-align: middle; text-align: center;" |Panic

−

|} <br~~> <br~~>

+

|}

*GPS element

−

Below table represents GPS Element structure: ~~ ~~

+

Below table represents GPS Element structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,603: Line 1,641:

|-

|}

+

'''Longitude''' – east – west position.

'''Latitude''' – north – south position.

Line 1,609: Line 1,649:

'''Satellites''' – number of visible satellites.

'''Speed''' – speed calculated from satellites.

−

'''Note:''' Speed will be 0x0000 if GPS data is invalid.

+

'''Note:''' Speed will be <code>0x0000</code> if GPS data is invalid.

Longitude and latitude are integer values built from degrees, minutes, seconds and milliseconds by formula:

[[Image:GPS.png]]

Line 1,617: Line 1,657:

If longitude is in west or latitude in south, multiply result by –1.

Note:

−

To determine if the coordinate is negative, convert it to binary format and check the very first bit. If it is 0, coordinate is positive, if it is 1, coordinate is negative.

+

To determine if the coordinate is negative, convert it to binary format and check the very first bit. If it is <code>0</code>, coordinate is positive, if it is <code>1</code>, coordinate is negative.

Example:

−

Received value: 20 9C CA 80 converted to BIN: 00100000 10011100 11001010 10000000 first bit is 0, which means coordinate is positive converted to DEC: 547146368. For more information see two‘s complement arithmetic. ~~ ~~

+

Received value: <code>20 9C CA 80</code> converted to BIN: <code>00100000 10011100 11001010 10000000</code> first bit is 0, which means coordinate is positive converted to DEC: <code>547146368</code>. For more information see two‘s complement arithmetic.

*IO Element

Line 1,712: Line 1,752:

| style="vertical-align: middle; text-align: center;" |8 bytes

|-

−

|} <br~~> <br~~>

+

|}

*Generation type

Line 1,745: Line 1,785:

| style="vertical-align: middle; text-align: center;" |Periodical

|-

−

|} <br~~> <br~~>

+

|}

*'''Communication with server'''

−

Communication with server is the same as with Codec8 protocol, except in Codec16 protocol Codec ID is 0x10 and has generation type. ~~ ~~

+

Communication with server is the same as with Codec8 protocol, except in Codec16 protocol Codec ID is <code>0x10</code> and has generation type.

*Example:

Module connects to server and sends IMEI:

−

000F333536333037303432343431303133

+

Server accepts the module:

−

01

+

−

Module sends data packet: ~~ ~~

+

Module sends data packet:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,775: Line 1,815:

| style="vertical-align: middle; text-align: center;" |00008612

|-

−

|} ~~ ~~

+

|}

−

Server acknowledges data reception (2 data elements): '''00000002''' ~~ ~~

+

Server acknowledges data reception (2 data elements): '''<code>00000002</code>'''

*'''Example'''

−

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

Received data in hexadecimal stream:

−

000000000000005F10020000016BDBC7833000000000000000000000000000000000000B05040200010000030002000B00270042563A00000000016BDBC78718

+

−

00000000000000000000000000000000000B05040200010000030002000B00260042563A00000200005FB3

+

−

Parsed data: ~~ ~~

+

Parsed data:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,954: Line 1,996:

| style="vertical-align: middle; text-align: center;" |00 00 5F B3

|-

−

|} ~~ ~~

+

|}

−

Server response: 00000002

+

Server response: <code>00000002</code>

*'''<big>Codec16 Extended protocol sending over UDP</big>'''

*'''UDP channel protocol'''

−

AVL data packet is the same as with Codec8, except Codec ID is changed to 0x10.

+

AVL data packet is the same as with Codec8, except Codec ID is changed to <code>0x10</code>.

*'''Communication with server'''

Line 1,968: Line 2,012:

*Example:

−

Module sends the data: ~~ ~~

+

Module sends the data:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 1,990: Line 2,034:

| style="vertical-align: middle; text-align: center;" |1002…(data elements)…02

|-

−

|} ~~ ~~

+

|}

−

Server must respond with acknowledgment:~~ ~~

+

Server must respond with acknowledgment:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,006: Line 2,052:

| style="vertical-align: middle; text-align: center;" |DD02

|-

−

|} <br~~> <br~~>

+

|}

*'''Example'''

−

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of AVL Data Packet receiving and response in this example are given in hexadecimal form. The different fields of packet are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

Received data in hexadecimal stream:

−

015BCAFE0101000F33353230393430383532333135393210070000015117E40FE80000000000000000000000000000000000EF05050400010000030000B4000

+

<code>015BCAFE0101000F33353230393430383532333135393210070000015117E40FE80000000000000000000000000000000000EF05050400010000030000B4000</code>

−

0EF01010042111A000001

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,127: Line 2,173:

| style="vertical-align: middle; text-align: center;" |01

|-

−

|} ~~ ~~

+

|}

−

Server response in ~~hexademical~~ stream:

+

−

0005CAFE010700

+

Server response in hexadecimal stream:

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

Line 2,155: Line 2,203:

| style="vertical-align: middle; text-align: center;" |00

|-

−

|} <br~~> <br~~>

+

|}

=='''<big>Differences between Codec 8, Codec 8 Extended and Codec 16</big>'''==

−

In the table below you will see differences between Codec8, Codec8 Extended and Codec16. ~~ ~~

+

In the table below you will see differences between Codec8, Codec8 Extended and Codec16.

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,201: Line 2,249:

| style="vertical-align: middle; text-align: center;" |Does not include

|-

−

|} <br~~> <br~~>

+

|}

='''<big>Codec for communication over GPRS messages</big>'''=

−

In this chapter you will find information about every Codec protocol which are using for communication over GPRS messages and differences between them. ~~ ~~

+

In this chapter you will find information about every Codec protocol which are using for communication over GPRS messages and differences between them.

=='''<big>Codec 12</big>'''==

Line 2,210: Line 2,258:

*'''<big>About Codec12</big>'''

−

Codec12 is original and main Teltonika protocol for device-server communication over GPRS messages. Codec12 GPRS commands can be used for sending configuration, debug, digital outputs control commands or other (special purpose command on special firmware versions). This protocol is also necessary for using FMB630/FM6300/FM5300/FM5500/FM4200 features like: Garmin, LCD communication, COM TCP Link Mode. ~~ ~~

+

Codec12 is original and main Teltonika protocol for device-server communication over GPRS messages. Codec12 GPRS commands can be used for sending configuration, debug, digital outputs control commands or other (special purpose command on special firmware versions). This protocol is also necessary for using [[FMB630]]/[[FM6300]]/FM5300/FM5500/FM4200 features like: Garmin, LCD communication, COM TCP Link Mode.

*'''<big>GPRS command session</big>'''

Line 2,218: Line 2,266:

First, Teltonika device opens GPRS session and sends AVL data to server (refer device protocols). Once all records are sent and correct sent data array acknowledgment is received by device then GPRS commands in Hex can be sent to device.

The ACK (acknowledge of IMEI from server) is a one byte constant 0x01. The acknowledgement of each data array send from device is four bytes integer – number of records received.

−

Note, that GPRS session should remain active between device and server, while GPRS commands are sent. For this reason, active datalink timeout (global parameters in device configuration) is recommended to be set to 259200 (maximum value). ~~ ~~

+

Note, that GPRS session should remain active between device and server, while GPRS commands are sent. For this reason, active datalink timeout (global parameters in device configuration) is recommended to be set to 259200 (maximum value).

*'''<big>General Codec12 message structure</big>'''

−

The following diagram shows basic structure of ~~Codec 12~~ messages.

+

The following diagram shows basic structure of Codec12 messages.

−

'''Command message structure:''' ~~ ~~

+

'''Command message structure:'''

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,246: Line 2,294:

| style="vertical-align: middle; text-align: center;" |4 bytes

|-

−

|} ~~ ~~

+

|}

−

'''Response message structure:''' ~~ ~~

+

'''Response message structure:'''

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,271: Line 2,321:

|-

|}

+

'''Preamble''' - the packet starts with four zero bytes.

'''Data Size''' - size is calculated from Codec ID field to the second command or response quantity field.

−

'''Codec ID''' - in Codec12 it is always 0x0C.

+

'''Codec ID''' - in Codec12 it is always <code>0x0C</code>.

'''Command/Response Quantity 1''' - it is ignored when parsing the message.

'''Type''' - it can be 0x05 to denote command or 0x06 to denote response.

Line 2,279: Line 2,331:

'''Command/Response''' – command or response in HEX.

'''Command/Response Quantity 2''' - a byte which defines how many records (commands or responses) is in the packet. This byte will not be parsed but it’s recommended that it should contain same value as Command/Response Quantity 1.

−

'''CRC-16''' - calculated from Codec ID to the ~~Command/Response Quantity 2~~. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]].

+

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

Note that difference between commands and responses is message type field: 0x05 means command and 0x06 means response. ~~ ~~

+

Note that difference between commands and responses is message type field: <code>0x05</code> means command and <code>0x06</code> means response.

*'''<big>Command coding table</big>'''

Command has to be converted from ASCII characters (char) to hexadecimal (HEX):

−

[[File:ASCII.png]] ~~ ~~

+

[[File:ASCII.png]]

*'''<big>Command parsing example</big>'''

−

Hexadecimal stream of command and answer in this example are given in hexadecimal form. The different fields of message are ~~seperate~~ into different table columns for better readability and understanding. ~~ ~~

+

Hexadecimal stream of command and answer in this example are given in hexadecimal form. The different fields of message are separate into different table columns for better readability and understanding.

*'''<big>GPRS commands examples</big>'''

−

Hexadecimal stream of GPRS command and answer in these examples are given in hexadecimal form. The different fields of messages are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of GPRS command and answer in these examples are given in hexadecimal form. The different fields of messages are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

−

'''1'st example:''' Sending ''getinfo'' SMS command via GPRS Codec12

+

'''1'st example:''' Sending ''[[FMB getinfo|getinfo]]'' SMS command via GPRS Codec12

Server request in hexadecimal stream:

−

000000000000000F0C010500000007676574696E666F0100004312

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,332: Line 2,384:

| style="vertical-align: middle; text-align: center;" |00 00 43 12

|-

−

|} ~~ ~~

+

|}

−

Note that Server Command converted from HEX to ASCII means ''getinfo''

+

Note that Server Command converted from HEX to ASCII means ''[[FMB getinfo|getinfo]]''

Device response in hexadecimal stream:

−

00000000000000900C010600000088494E493A323031392F372F323220373A3232205254433A323031392F372F323220373A3533205253543A32204552523A

+

−

312053523A302042523A302043463A302046473A3020464C3A302054553A302F302055543A3020534D533A30204E4F4750533A303A3330204750533A312053

+

−

41543A302052533A332052463A36352053463A31204D443A30010000C78F

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,375: Line 2,429:

|}

Note that Device Response converted from HEX to ASCII means:

−

''INI:2019/7/22 7:22 RTC:2019/7/22 7:53 RST:2 ERR:1 SR:0 BR:0 CF:0 FG:0 FL:0 TU:0/0 UT:0 SMS:0 NOGPS:0:30 GPS:1 SAT:0 RS:3 RF:65 SF:1 MD:0'' ~~ ~~

+

''INI:2019/7/22 7:22 RTC:2019/7/22 7:53 RST:2 ERR:1 SR:0 BR:0 CF:0 FG:0 FL:0 TU:0/0 UT:0 SMS:0 NOGPS:0:30 GPS:1 SAT:0 RS:3 RF:65 SF:1 MD:0''

−

'''2'nd ~~xample~~:''' Sending ''getio'' SMS command via GPRS Codec12

+

'''2'nd example:''' Sending ''[[FMB getio|getio]]'' SMS command via GPRS Codec12

Server request in hexadecimal stream:

−

000000000000000D0C010500000005676574696F01000000CB

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,415: Line 2,469:

| style="vertical-align: middle; text-align: center;" |00 00 00 CB

|-

−

|} ~~ ~~

+

|}

+

−

Note that Server Command converted from HEX to ASCII means ''getio''

+

Note that Server Command converted from HEX to ASCII means ''[[FMB getio|getio]]''

Device response in hexadecimal stream:

−

00000000000000370C01060000002F4449313A31204449323A30204449333A302041494E313A302041494E323A313639323420444F313A3020444F323A3101000066E3

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,455: Line 2,510:

| style="vertical-align: middle; text-align: center;" |00 00 66 E3

|-

−

|} ~~ ~~

+

|}

+

Note that Device Response converted from HEX to ASCII means:

−

''DI1:1 DI2:0 DI3:0 AIN1:0 AIN2:16924 DO1:0 DO2:1'' ~~ ~~

+

''DI1:1 DI2:0 DI3:0 AIN1:0 AIN2:16924 DO1:0 DO2:1''

*'''<big>Communication with server</big>'''

−

The GSM/GPRS commands can be sent from a terminal program. We recommend to use Hercules (in TCP server mode). Simply write command as explained below into Hercules Send field, check HEX box and click Send button. Note that the TCP server must be listening on specified port (see Port field and Listen button below). ~~ ~~

+

The GSM/GPRS commands can be sent from a terminal program. We recommend to use Hercules (in TCP server mode). Simply write command as explained below into Hercules Send field, check HEX box and click Send button. Note that the TCP server must be listening on specified port (see Port field and Listen button below).

[[File:Hercules.jpeg]]

−

~~ ~~

+

*'''<big>FMXX and Codec12 functionality</big>'''

*'''Garmin'''

−

All information is provided in “FMXX and Garmin development.pdf” document. ~~ ~~

+

All information is provided in “FMXX and Garmin development.pdf” document.

*'''COM TCP Link Mode'''

−

All information is provided in “FMxx TCP Link mode test instructions.pdf” document. ~~ ~~

+

All information is provided in “FMxx TCP Link mode test instructions.pdf” document.

=='''<big>Codec 13</big>'''==

Line 2,479: Line 2,536:

*'''<big>About Codec13</big>'''

−

Codec13 is original Teltonika protocol for device-server communication over GPRS messages and it is based on Codec12 protocol. Main differences of Codec13 are that timestamp is using in messages and communication is one way only (Codec13 is used for Device -> Server sending). ~~ ~~

+

Codec13 is original Teltonika protocol for device-server communication over GPRS messages and it is based on Codec12 protocol. Main differences of Codec13 are that timestamp is using in messages and communication is one way only (Codec13 is used for Device -> Server sending).

*'''<big>General Codec13 message structure</big>'''

−

The following diagram shows basic structure of Codec 13 messages: ~~ ~~

+

The following diagram shows basic structure of Codec 13 messages:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,509: Line 2,566:

|-

|}

−

'''~~4 Zeros~~''' – the packet starts with preamble field (four zero bytes).

+

'''Preamble''' – the packet starts with preamble field (four zero bytes).

'''Data Size''' – size is calculated from Codec ID field to the second Command Quantity field.

−

'''Codec ID''' – in Codec13 it is always 0x0D.

+

'''Codec ID''' – in Codec13 it is always <code>0x0D</code>.

−

'''Command Quantity 1''' – 0x01, it is ignored when parsing the message.

+

'''Command Quantity 1''' – <code>0x01</code>, it is ignored when parsing the message.

−

'''Command Type''' – it is always 0x05 since the packet is direction is FM->Server.

+

'''Command Type''' – it is always <code>0x05</code> since the packet is direction is FM->Server.

'''Command Size''' – command size field includes size of timestamp too, so it is equal to size of payload + size of timestamp.

'''Timestamp''' – a difference, in milliseconds, between the current time and midnight, January, 1970 UTC (UNIX time).

'''Command''' – actual received data.

'''Command Quantity 2''' – a byte which defines how many records (commands) is in the packet. This byte will not be parsed but it’s recommended that it should contain same value as Command/Response Quantity 1.

−

'''CRC-16''' - calculated from Codec ID to ~~Command Quantity 2~~. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]].

+

'''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

'''Note:''' Codec13 packets are used only when “Message Timestamp” parameter in RS232 settings is enabled. ~~ ~~

+

'''Note:''' Codec13 packets are used only when “Message Timestamp” parameter in RS232 settings is enabled.

*'''<big>Command parsing example</big>'''

−

Hexadecimal stream of GPRS command in this example is given in hexadecimal form. The different fields of message are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of GPRS command in this example is given in hexadecimal form. The different fields of message are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

−

Sending ''getinfo'' SMS command via GPRS Codec13.

+

Sending ''[[FMB getinfo|getinfo]]'' SMS command via GPRS Codec13.

Hexadecimal stream:

−

00000000000000170D01050000000F0000016C0A81C320676574696E666F010000AAD2

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,565: Line 2,624:

| style="vertical-align: middle; text-align: center;" |00 00 AA D2

|-

−

|} ~~ ~~

+

|}

−

Note that Server Command converted from HEX to ASCII means ''getinfo'' ~~ ~~

+

Note that Server Command converted from HEX to ASCII means ''[[FMB getinfo|getinfo]]''

=='''<big>Codec 14</big>'''==

Line 2,575: Line 2,636:

Main difference of Codec14 is that, device will answer to GPRS command if device physical IMEI number matches specified IMEI number in GPRS command.

−

Codec14 GPRS commands can be used for sending configuration, debug, digital outputs control commands or other (special purpose command on special firmware versions). ~~ ~~

+

Codec14 GPRS commands can be used for sending configuration, debug, digital outputs control commands or other (special purpose command on special firmware versions).

*'''<big>FMB firmware requirements</big>'''

−

Implemented in base firmware from FMB.Ver.03.25.04.Rev.00 and newer. ~~ ~~

+

Implemented in base firmware from FMB.Ver.03.25.04.Rev.00 and newer.

*'''<big>General Codec14 message structure</big>'''

−

The following diagram shows basic structure of Codec14 messages. ~~ ~~

+

The following diagram shows basic structure of Codec14 messages.

'''Command message structure'''

Line 2,610: Line 2,671:

| style="vertical-align: middle; text-align: center;" |4 bytes

|-

−

|} ~~ ~~

+

|}

+

'''Response message structure'''

Line 2,638: Line 2,700:

|-

|}

+

'''Preamble''' – the packet starts with four zero bytes.

'''Data Size''' – size is calculated from Codec ID field to the second command or response quantity field.

−

'''Codec ID''' – in Codec14 it is always 0x0E.

+

'''Codec ID''' – in Codec14 it is always <code>0x0E</code>.

'''Command/Response Quantity 1''' – it is ignored when parsing the message.

−

'''Type''' – if it is request command from server it has to contain 0x05. The response type field will contain 0x06 if it’s ACK or 0x11 if it’s nACK.

+

'''Type''' – if it is request command from server it has to contain 0x05. The response type field will contain <code>0x06</code> if it’s ACK or <code>0x11</code> if it’s nACK.

−

''Explanation:'' If command message IMEI is equal to actual device IMEI, received command will be executed and response will be sent with ACK (0x06) message type field value. If command message IMEI doesn’t match actual device IMEI, received command won’t be executed and response to server will be sent with nACK (0x11) message type field value.

+

''Explanation:'' If command message IMEI is equal to actual device IMEI, received command will be executed and response will be sent with ACK (<code>0x06</code>) message type field value. If command message IMEI doesn’t match actual device IMEI, received command won’t be executed and response to server will be sent with nACK (<code>0x11</code>) message type field value.

'''Command/Response Size''' – command or response length.

''Note:'' make sure that size is IMEI size 8 + actual command size. Minimal value is 8 because Codec14 always contain IMEI and it’s 8 bytes.

−

'''IMEI (HEX)''' – it is send as HEX value. Example if device IMEI is 123456789123456 then IMEI data field will contain 0x0123456789123456 value.

+

'''IMEI (HEX)''' – it is send as HEX value. Example if device IMEI is 123456789123456 then IMEI data field will contain <code>0x0123456789123456</code> value.

'''Command/Response''' – command or response in HEX.

−

'''Command/Response Quantity 2''' - a byte which defines how many records (commands or responses) is in the packet. This byte will not be parsed but it’s recommended that it should contain same value as Command/Response Quantity 1.

+

'''Command/Response Quantity 2''' - a byte which defines how many records (commands or responses) is in the packet. This byte will not be parsed but it’s recommended that it should contain same value as Command/Response Quantity 1. '''CRC-16''' – calculated from Codec ID to the Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

−

'''CRC-16''' - calculated from Codec ID to the ~~Command/Response Quantity 2~~. CRC (Cyclic Redundancy Check) is an error-detecting code using for detect accidental changes to RAW data. For calculation we are using ~~CRC-16/IBM. More information about it you can found~~ [[Codec#CRC-16|~~here~~]]. ~~ ~~

*'''<big>GPRS in Codec14 examples</big>'''

−

Hexadecimal stream of GPRS command and answer in this example are given in hexadecimal form. The different fields of message are ~~seperate~~ into different table columns for better readability and some of them are ~~coverted~~ to ASCII values for better understanding.

+

Hexadecimal stream of GPRS command and answer in this example are given in hexadecimal form. The different fields of message are separate into different table columns for better readability and some of them are converted to ASCII values for better understanding.

−

Sending ''getver'' SMS command via GPRS Codec14:

+

Sending ''[[FMB getver|getver]]'' SMS command via GPRS Codec14:

Server requests in Hexadecimal stream:

−

00000000000000160E01050000000E0352093081452251676574766572010000D2C1

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,695: Line 2,758:

| style="vertical-align: middle; text-align: center;" |00 00 D2 C1

|-

−

|} ~~ ~~

+

|}

−

Note that Server Command converted from HEX to ASCII means ''getver''

+

Note that Server Command converted from HEX to ASCII means ''[[FMB getver|getver]]''

Device ACK response in hexadecimal stream:

−

00000000000000AB0E0106000000A303520930814522515665723A30332E31382E31345F3034204750533A41584E5F352E31305F333333332048773A464D42313230

+

−

204D6F643A313520494D45493A33353230393330383134353232353120496E69743A323031382D31312D323220373A313320557074696D653A3137323334204D4143

+

−

3A363042444430303136323631205350433A312830292041584C3A30204F42443A3020424C3A312E362042543A340100007AAE

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,739: Line 2,804:

| style="vertical-align: middle; text-align: center;" |00 00 7A AE

|-

−

|} ~~ ~~

+

|}

+

Note that Device Response converted from HEX to ASCII means:

''Ver:03.18.14_04 GPS:AXN_5.10_3333 Hw:FMB120 Mod:15 IMEI:352093081452251 Init:2018-11-22 7:13 Uptime:17234 MAC:60BDD0016261 SPC:1(0) AXL:0 OBD:0 BL:1.6 BT:4''

Device nACK response in hexadecimal stream:

−

00000000000000100E011100000008035209308145246801000032AC

+

−

Parsed: ~~ ~~

+

Parsed:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,779: Line 2,846:

| style="vertical-align: middle; text-align: center;" |00 00 32 AC

|-

−

|} <br~~> <br~~>

+

|}

=='''<big>Differences between Codec 12, Codec 13 and Codec 14</big>'''==

−

In the table below you will see differences between Codec12, Codec13 and Codec14. ~~ ~~

+

In the table below you will see differences between Codec12, Codec13 and Codec14.

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,820: Line 2,887:

| style="vertical-align: middle; text-align: center;" |Is Using

|-

−

|} <br~~> <br~~>

+

|}

='''<big>24 Position SMS Data Protocol</big>'''=

−

24-hour SMS is usually sent once every day and contains GPS data of last 24 hours. TP-DCS field of this SMS should indicate that message contains 8-bit data (i.e. TP-DCS can be 0x04).

+

24-hour SMS is usually sent once every day and contains GPS data of last 24 hours. TP-DCS field of this SMS should indicate that message contains 8-bit data (i.e. TP-DCS can be <code>0x04</code>).

−

Note, that 24 position data protocol is used only with subscribed SMS. Event SMS use standard AVL data protocol. ~~ ~~

+

Note, that 24 position data protocol is used only with subscribed SMS. Event SMS use standard AVL data protocol.

*'''<big>Encoding</big>'''

−

To be able to compress 24 GPS data entries into one SMS (140 octets), the data is encoded extensively using bit fields. Data packet can be interpreted as a bit stream, where all bits are numbered as follows: ~~ ~~

+

To be able to compress 24 GPS data entries into one SMS (140 octets), the data is encoded extensively using bit fields. Data packet can be interpreted as a bit stream, where all bits are numbered as follows:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,842: Line 2,909:

| style="vertical-align: middle; text-align: center;" |Bits 25 - ...

|-

−

|} ~~ ~~

+

|}

−

Bits in a byte are numbered starting from least significant bit. A field of 25 bits would consist of bits 0 to 24 where 0 is the least significant bit and bit 24 – most significant bit. ~~ ~~

+

Bits in a byte are numbered starting from least significant bit. A field of 25 bits would consist of bits 0 to 24 where 0 is the least significant bit and bit 24 – most significant bit.

*'''<big>Structure</big>'''

−

Below in the tables you will see SMS Data Structure: ~~ ~~

+

Below in the tables you will see SMS Data Structure:

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,867: Line 2,936:

{| class="nd-othertables_2" style="width:100%;"

|+

+

! colspan="4" style="border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |SMS Data Structure

|-

Line 2,882: Line 2,953:

| style="vertical-align: middle; text-align: center;" |IMEI of sending device as 8 byte long integer

|-

−

|} ~~ ~~

+

|}

−

The time of only the first GPS data element is specified in Timestamp field. Time corresponding to each further element can be computed as elementTime = Timestamp + (1 hour * elementNumber). ~~ ~~

+

The time of only the first GPS data element is specified in Timestamp field. Time corresponding to each further element can be computed as elementTime = Timestamp + (1 hour * elementNumber).

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,934: Line 3,007:

|-

|}

+

'''Longitude''' - longitude field value of GPSDataElement

'''Latitude''' - latitude field value of GPSDataElement

Line 2,939: Line 3,014:

'''LatDegMult''' - latitude in degrees multiplied by 107 (integer part)

'''prevLongitude''' - longitude field value of previous GPSDataElemen

−

'''prevLatitude''' - latitude field value of previous GPSDataElement ~~ ~~

+

'''prevLatitude''' - latitude field value of previous GPSDataElement

*'''<big>Decoding GPS position</big>'''

Line 2,945: Line 3,020:

When decoding GPS data with DifferentialCoords = 1, Latitude and Longitude values can be computed as follows: Longitude = prevLongitude – LongitudeDiff + 213 – 1, Latitude = prevLatitude – LatitudeDiff + 213 – 1.

If there were no previous non-differential positions, differential coordinates should be computed assuming prevLongitude = prevLatitude = 0.

−

When Longitude and Latitude values are known, longitude and latitude representation in degrees can be computed as follows: ~~ ~~

+

When Longitude and Latitude values are known, longitude and latitude representation in degrees can be computed as follows:

[[File:24SMS.png]]

Line 2,952: Line 3,027:

When Configured to generate SMS event user will get this SMS upon event:

−

+

''<Year/Month/Day> <Hour:Minute:Second> P:<profile_nr> <SMS Text> Val:<Event Value> Lon:<longitude> Lat:<latitude> Q:<HDOP>''

Example:

−

2016./04/11 12:00:00 P:3 Digital Input 1 Val:1 Lon:51.12258 Lat: 25.7461 Q:0.6 ~~ ~~

+

''2016./04/11 12:00:00 P:3 Digital Input 1 Val:1 Lon:51.12258 Lat: 25.7461 Q:0.6''

='''<big>Sending data using SMS</big>'''=

−

This type data sending is using for FMBXXX devices which can be ~~cofigured~~ in ~~SMS Data Sending settings. More information about this feature you will find~~ [[~~FMB120_SMS~~/~~Call_settings~~#~~SMS_Data_Sending~~|~~here~~]]. ~~ ~~

+

This type data sending is using for FMBXXX devices which can be configured in [[FMB120 SMS/Call settings#SMS Data Sending|SMS Data Sending settings]].

*'''<big>Data sending via SMS</big>'''

−

AVL data or events can be sent encapsulated in binary SMS. TP-DCS field of these SMS should indicate that message contains 8-bit data (for example: TP-DCS can be 0x04). ~~ ~~

+

AVL data or events can be sent encapsulated in binary SMS. TP-DCS field of these SMS should indicate that message contains 8-bit data (for example: TP-DCS can be <code>0x04</code>).

{| class="nd-othertables_2" style="width:100%;"

|+

Line 2,973: Line 3,048:

|-

|}

+

'''AVL data array''' – array of encoded AVL data.

'''IMEI''' – IMEI of sending module encoded as a big endian 8 byte long number.

SandraG

Administrators

2,544

edits