Changes

5,621 bytes added , 09:49, 8 December 2023

Line 1: Line 1:

='''<big>Introduction</big>'''=

−

A codec is a device or computer program for encoding or decoding a digital data stream or signal. Codec is a portmanteau of coder – decoder. A codec encodes a data stream or a signal for transmission and storage, possibly in encrypted form, and the decoder function reverses the encoding for playback or editing.

+

A codec is a device or computer program for encoding or decoding a digital data stream or signal. Codec is a portmanteau of coder-decoder. A codec encodes a data stream or a signal for transmission and storage, possibly in encrypted form, and the decoder function reverses the encoding for playback or editing.

−

Below you will see a table of all Codec types with ~~ID’s~~:

+

Below you will see a table of all Codec types with IDs:

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

|+

Line 19: Line 19:

|-

|}

−

Also, there are using two data transport protocols: TCP and UDP. But it is not important which one will be ~~use~~ in Codec.

+

Also, there are using two data transport protocols: TCP and UDP. But it is not important which one will be used in Codec.

='''<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 used for device data sending and the 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 the server.

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

Line 36: Line 36:

*'''AVL Data Packet'''

−

~~Below~~ table represents AVL Data Packet structure:

+

The below table represents the AVL Data Packet structure:

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

|+

Line 61: Line 61:

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

'''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.

+

'''Number of Data 1''' – a number that defines how many records are 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”.

+

'''Number of Data 2''' – a number that defines how many records are 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 [[Codec#CRC-16|CRC-16/IBM]].

+

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

−

'''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.

+

'''Note:''' for [[FMB640]], [[FMB641]], [[FMC640]], and [[FMM640]], minimum AVL record size is 45 bytes (all IO elements disabled). The maximum AVL record size is 255 bytes. Maximum AVL packet size is 512 bytes. For other devices, the minimum AVL record size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

*AVL Data

−

~~Below~~ table represents AVL Data structure.

+

The below table represents the AVL Data structure.

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

|+

Line 85: Line 85: −

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

+

'''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).

+

'''Priority''' – a field that defines AVL data priority (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 the device (more information below).

*Priority

−

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

+

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

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

|+

Line 109: Line 109:

*GPS element

−

~~Below~~ table represents GPS Element structure:

+

The below table represents the GPS Element structure:

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

|+

Line 129: Line 129: −

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

+

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

−

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

+

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

'''Altitude''' – meters above sea level.

'''Angle''' – degrees from north pole.

−

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

+

'''Satellites''' – number of satellites in use.

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

'''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:

+

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

[[Image:GPS.png]]

Where:

d – Degrees; m – Minutes; s – Seconds; ms – Milliseconds; p – Precision (10000000)

−

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

+

If the longitude is in the west or latitude in the south, multiply the 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 0, the coordinate is positive. If it is 1, the coordinate is negative.

Example:

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.

Line 154: 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 <code>0xEF</code> (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 the event – this field defines which IO property has changed and generated an event. For example, when if the Ignition state changes and it generates an event, the Event IO ID will be <code>0xEF</code> (AVL ID: 239). If it’s not an 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 238: Line 238:

*'''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).

+

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

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

−

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

+

The 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 <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>.

+

After receiving IMEI, the 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 a 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).

+

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

−

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

+

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

*Example:

−

~~Module~~ connects to server and sends IMEI:

+

The module connects to the server and sends IMEI:

−

~~Server~~ accepts the module:

+

The server accepts the module:

01

−

~~Module~~ sends data packet:

+

The module sends data packet:

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

|+

Line 262: Line 262:

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x08,

Number of Data – '''0x02'''

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |CRC of “AVL Data Array”

|-

Line 276: Line 276:

*'''Examples'''

−

~~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.

+

The hexadecimal stream of AVL Data Packet receiving and response in these examples are given in the hexadecimal form. The different fields of packets are separated 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~~).

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

Parsed:

Line 305: Line 305:

| rowspan="24" style="vertical-align: middle; text-align: center;" |AVL Data

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

−

| style="vertical-align: middle; text-align: center;" |00 00 00 01 6B 40 D8 EA 30 (GMT: Monday, June 10, 2019 10:04:46 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 40 D8 EA 30 (GMT: Monday, June 10, 2019, 10:04:46 AM)

|-

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

Line 389: Line 389:

'''2'nd example'''

−

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

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

Parsed:

Line 415: Line 415:

| rowspan="20" style="vertical-align: middle; text-align: center;" |AVL Data

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 40 D9 AD 80 (GMT: Monday, June 10, 2019 10:05:36 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 40 D9 AD 80 (GMT: Monday, June 10, 2019, 10:05:36 AM)

|-

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

Line 468: Line 468:

| style="vertical-align: middle; text-align: center;" |5E 0F

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 488: Line 488:

'''3'rd example'''

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

<code>000000000000004308020000016B40D57B480100000000000000000000000000000001010101000000000000016B40D5C198010000000000000000000000000000000

101010101000000020000252C</code>

Line 515: Line 515:

(1'st record)

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 40 D5 7B 48 (GMT: Monday, June 10, 2019 10:01:01 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 40 D5 7B 48 (GMT: Monday, June 10, 2019, 10:01:01 AM)

|-

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

Line 556: Line 556:

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

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 606: Line 606:

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

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 626: Line 626:

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

−

UDP is a transport layer protocol above UDP/IP to add reliability to plain UDP/IP using acknowledgment packets.

+

Codec8 protocol [over UDP] is a transport layer protocol above UDP/IP to add reliability to plain UDP/IP using acknowledgment packets.

*'''AVL Data Packet'''

Line 657: Line 657:

*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.

+

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

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

|+

Line 679: Line 679:

*Sending AVL Packet Payload using UDP channel

−

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

+

The below table represents the Sending Packet Payload structure.

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

|+

Line 698: Line 698:

'''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''' – an 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.

+

The below table represents the Server Response Packet Payload structure.

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

|+

Line 717: Line 717:

*'''Communication with server'''

−

~~Module~~ sends UDP channel packet with encapsulated AVL data packet. ~~Server~~ sends UDP channel packet with encapsulated response module validates AVL Packet ID and Number of accepted AVL elements. If server response with valid AVL Packet ID ~~is not received~~ within configured timeout, module can retry sending.

+

The module sends the UDP channel packet with an encapsulated AVL data packet. The server sends the UDP channel packet with an encapsulated response module that validates the AVL Packet ID and the Number of accepted AVL elements. If the server response is not received with a valid AVL Packet ID within configured timeout, the module can retry sending.

*Example:

−

~~Module~~ sends the data:

+

The module sends the data:

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

|+

Line 734: Line 734:

IMEI Length – 0x000F

IMEI – 0x313233343536373839303132333435

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x08,

Number of Data – 0x02

Line 746: Line 746: −

~~Server~~ must respond with acknowledgment:

+

The server must respond with an acknowledgment:

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

|+

Line 765: Line 765:

*'''Example'''

−

~~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.

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

<code>003DCAFE0105000F33353230393330383634303336353508010000016B4F815B30010000000000000000000000000000000103021503010101425DBC000001</code>

Parsed:

Line 804: Line 804:

|-

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 4F 81 5B 30 (GMT: Thursday, June 13, 2019 6:23:26 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 4F 81 5B 30 (GMT: Thursday, June 13, 2019, 6:23:26 AM)

|-

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

Line 857: Line 857:

| style="vertical-align: middle; text-align: center;" |5D BC

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two Bytes~~ IO

+

| style="vertical-align: middle; text-align: center;" |N8 of EightBytes IO

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

|-

Line 869: Line 869: −

~~Server~~ response in hexadecimal stream:

+

The server response in the hexadecimal stream:

Parsed:

Line 902: 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 used for FMBXXX family devices. This protocol looks familiar to Codec8 but they have some differences. The main differences between them are shown in below table:

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

|+

Line 939: Line 939:

*'''AVL data packet'''

−

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

+

The below table represents the AVL data packet structure:

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

|+

Line 964: Line 964:

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

'''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.

+

'''Number of Data 1''' – a number that defines how many records are 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”.

+

'''Number of Data 2''' – a number that defines how many records are 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 [[Codec#CRC-16|CRC-16/IBM]].

+

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

−

'''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.

+

'''Note:''' for [[FMB640]], [[FMB641]], [[FMC640]], and [[FMM640]], minimum AVL record size is 45 bytes (all IO elements disabled). The maximum AVL record size is 255 bytes. For other devices, the minimum AVL record size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

*AVL Data

−

~~Below~~ table represents AVL Data structure:

+

The below table represents the AVL Data structure:

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

|+

Line 988: Line 988: −

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

+

'''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).

+

'''Priority''' – a field that defines 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 the device (more information below).

*Priority

−

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

+

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

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

|+

Line 1,012: Line 1,012:

*GPS element

−

~~Below~~ table represents GPS Element structure:

+

The below table represents the GPS Element structure:

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

|+

Line 1,032: Line 1,032: −

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

+

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

−

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

+

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

'''Altitude''' – meters above sea level.

'''Angle''' – degrees from north pole.

−

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

+

'''Satellites''' – number of satellites in use.

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

'''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:

+

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

[[Image:GPS.png]]

Where:

d – Degrees; m – Minutes; s – Seconds; ms – Milliseconds; p – Precision (10000000)

−

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

+

If the longitude is in the west or latitude in the south, multiply the 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 <code>0</code>, coordinate is positive, if it is <code>1</code>, 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>, the coordinate is positive, if it is <code>1</code>, the coordinate is negative.

Example:

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.

Line 1,057: Line 1,057:

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

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

−

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

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

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

Line 1,063: Line 1,063:

'''N4''' – number of properties, which length is 4 bytes.

'''N8''' – number of properties, which length is 8 bytes.

−

'''NX''' – a number of properties, which length is defined by length element.

+

'''NX''' – a number of properties, which length is defined by the length element.

'''N’th IO ID''' - AVL ID.

'''N'th Lenght''' - AVL ID value lenght.

Line 1,149: Line 1,149:

|-

! rowspan="1" style="width:15%; vertical-align: middle; text-align: center;" |1’st IO Value

−

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

+

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

|-

| colspan="2" style="vertical-align: middle; text-align: center;" |...

Line 1,160: Line 1,160:

|-

! rowspan="1" style="width:15%; vertical-align: middle; text-align: center;" |NX’th Value

−

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

+

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

|-

|}

Line 1,166: Line 1,166:

*'''Communication with server'''

−

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

+

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

*Example:

−

~~Module~~ connects to server and sends IMEI:

+

The module connects to the server and sends IMEI:

−

~~Server~~ accepts the module:

+

The server accepts the module:

−

~~Module~~ sends data packet:

+

The module sends data packet:

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

|+

Line 1,185: Line 1,185:

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x8E,

Number of Data – '''0x02'''

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |CRC of “AVL Data Array”

|-

Line 1,199: Line 1,199:

*'''Example'''

−

~~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.

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

<code>000000000000004A8E010000016B412CEE000100000000000000000000000000000000010005000100010100010011001D00010010015E2C880002000B000000003544C87

A000E000000001DD7E06A00000100002994</code>

Line 1,226: Line 1,226:

| rowspan="25" style="vertical-align: middle; text-align: center;" |AVL Data

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 41 2C EE 00 (GMT: Monday, June 10, 2019 11:36:32 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B 41 2C EE 00 (GMT: Monday, June 10, 2019, 11:36:32 AM)

|-

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

Line 1,273: Line 1,273:

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

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

Line 1,282: Line 1,282:

| style="vertical-align: middle; text-align: center;" |01 5E 2C 88

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 1,316: Line 1,316:

*'''UDP channel protocol'''

−

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

+

AVL data packet is the same as with Codec8, except Codec ID is changed to <code>0x8E</code>. AVL Data encoding was performed according to Codec8 Extended protocol.

*'''Communication with server'''

−

~~Module~~ sends UDP channel packet with encapsulated AVL data packet. ~~Server~~ sends UDP channel packet with encapsulated response module validates AVL Packet ID and Number of accepted AVL elements. If server response with valid AVL Packet ID ~~is not received~~ within configured timeout, module can retry sending.

+

The module sends the UDP channel packet with an encapsulated AVL data packet. The server sends the UDP channel packet with an encapsulated response module that validates the AVL Packet ID and the Number of accepted AVL elements. If the server response is not received with a valid AVL Packet ID within configured timeout, the module can retry sending.

*Example:

−

~~Module~~ sends the data:

+

The module sends the data:

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

|+

Line 1,337: Line 1,337:

IMEI Length – 0x000F

IMEI – 0x313233343536373839303132333435

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x8E,

Number of Data – 0x02

Line 1,349: Line 1,349: −

~~Server~~ must respond with acknowledgment:

+

The server must respond with an acknowledgment:

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

|+

Line 1,368: Line 1,368:

*'''Example'''

−

~~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.

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

<code>005FCAFE0107000F3335323039333038363430333635358E010000016B4F831C680100000000000000000000000000000000010005000100010100010011009D000100</code>

Line 1,392: Line 1,392:

| rowspan="3" style="vertical-align: middle; text-align: center;" |AVL Packet Header

| style="vertical-align: middle; text-align: center;" |AVL packet ID

−

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

+

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

|-

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

Line 1,400: Line 1,400:

| style="vertical-align: middle; text-align: center;" |33 35 32 30 39 33 30 38 36 34 30 33 36 35 35

|-

−

| rowspan="27" style="vertical-align: middle; text-align: center;" |AVL Data Array

+

| rowspan="28" style="vertical-align: middle; text-align: center;" |AVL Data Array

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

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

Line 1,455: Line 1,455:

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

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

Line 1,464: Line 1,464:

| style="vertical-align: middle; text-align: center;" |01 5E 2C 88

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 1,481: Line 1,481:

| style="vertical-align: middle; text-align: center;" |NX of X Byte IO

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

+

|-

+

| style="vertical-align: middle; text-align: center;" |Number of Data 2 (Records)

+

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

|-

|}

−

~~Server~~ response in hexadecimal stream:

+

The server response in the hexadecimal stream:

Parsed:

Line 1,518: Line 1,521:

*'''<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 series devices. This protocol looks familiar like Codec8 but they have some differences. The main differences between them are shown in the table below:

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

|+

Line 1,544: Line 1,547: −

'''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.

+

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

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

Line 1,550: Line 1,553:

*'''AVL data packet'''

−

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

+

The below table represents the AVL data packet structure:

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

|+

Line 1,575: Line 1,578:

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

'''Codec ID''' – in Codec16 it is always 0x10.

−

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

+

'''Number of Data 1''' – a number that defines how many records are 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”.

+

'''Number of Data 2''' – a number that defines how many records are 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 [[Codec#CRC-16|CRC-16/IBM]].

+

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

−

'''Note:''' for [[FMB630]] 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, the minimum AVL record size is 45 bytes (all IO elements disabled). The maximum AVL record size is 255 bytes.

*AVL Data

−

~~Below~~ table represents AVL Data structure:

+

The below table represents the AVL Data structure:

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

|+

Line 1,599: Line 1,602: −

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

+

'''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).

+

'''Priority''' – a field that defines AVL data priority (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 the device (more information below).

*Priority

−

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

+

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

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

|+

Line 1,623: Line 1,626:

*GPS element

−

~~Below~~ table represents GPS Element structure:

+

The below table represents the GPS Element structure:

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

|+

Line 1,643: Line 1,646: −

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

+

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

−

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

+

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

'''Altitude''' – meters above sea level.

'''Angle''' – degrees from north pole.

−

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

+

'''Satellites''' – number of satellites in use.

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

'''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:

+

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

[[Image:GPS.png]]

Where:

d – Degrees; m – Minutes; s – Seconds; ms – Milliseconds; p – Precision (10000000)

−

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

+

If the longitude is in the west or latitude in the south, multiply the 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 <code>0</code>, coordinate is positive, if it is <code>1</code>, 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>, the coordinate is positive, if it is <code>1</code>, the coordinate is negative.

Example:

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.

Line 1,668: Line 1,671:

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

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

−

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

'''Generation type''' - data event generation type. More information about it you can find here.

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

Line 1,789: Line 1,792:

*'''Communication with server'''

−

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

+

Communication with the 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:

+

The module connects to the server and sends IMEI:

−

~~Server~~ accepts the module:

+

The server accepts the module:

−

~~Module~~ sends data packet:

+

The module sends data packet:

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

|+

Line 1,808: Line 1,811:

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x10,

Number of Data – '''0x02'''

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |CRC of “AVL Data Array”

|-

Line 1,822: Line 1,825:

*'''Example'''

−

~~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.

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

Line 1,850: Line 1,853:

(1'st record)

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B DB C7 83 30 (GMT: Wednesday, July 10, 2019 12:06:54 PM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B DB C7 83 30 (GMT: Wednesday, July 10, 2019, 12:06:54 PM)

|-

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

Line 1,912: Line 1,915:

| style="vertical-align: middle; text-align: center;" |56 3A

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 1,921: Line 1,924:

(2'nd record)

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 6B DB C7 87 18 (GMT: Wednesday, July 10, 2019 12:06:55 PM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 6B DB C7 87 18 (GMT: Wednesday, July 10, 2019, 12:06:55 PM)

|-

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

Line 1,983: Line 1,986:

| style="vertical-align: middle; text-align: center;" |56 3A

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 2,001: Line 2,004:

Server response: <code>00000002</code>

−

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

+

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

*'''UDP channel protocol'''

−

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

+

AVL data packet is the same as with Codec8, except Codec ID is changed to <code>0x10</code>. AVL Data encoding is performed according to the Codec16 protocol.

*'''Communication with server'''

−

~~Module~~ sends UDP channel packet with encapsulated AVL data packet. ~~Server~~ sends UDP channel packet with encapsulated response module validates AVL Packet ID and Number of accepted AVL elements. If server ~~response~~ with valid AVL Packet ID is not received within configured timeout, module can retry sending.

+

The module sends the UDP channel packet with an encapsulated AVL data packet. The server sends the UDP channel packet with an encapsulated response module that validates the AVL Packet ID and the Number of accepted AVL elements. If the server responds with a valid AVL Packet ID that is not received within configured timeout, the module can retry sending.

*Example:

−

~~Module~~ sends the data:

+

The module sends the data:

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

|+

Line 2,025: Line 2,028:

IMEI Length – 0x000F

IMEI – 0x313233343536373839303132333435

−

(Encoded using continuous bit stream. ~~Last~~ byte padded to align to byte boundary)

+

(Encoded using continuous bit stream. The last byte is padded to align to the byte boundary)

| style="vertical-align: middle; text-align: center;" |Codec ID – 0x10,

Number of Data – 0x02

Line 2,037: Line 2,040: −

~~Server~~ must respond with acknowledgment:

+

The server must respond with an acknowledgment:

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

|+

Line 2,056: Line 2,059:

*'''Example'''

−

~~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.

+

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

−

Received data in hexadecimal stream:

+

Received data in the hexadecimal stream:

<code>015BCAFE0101000F33353230393430383532333135393210070000015117E40FE80000000000000000000000000000000000EF05050400010000030000B4000</code>

Line 2,096: Line 2,099:

|-

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

−

| style="vertical-align: middle; text-align: center;" |00 00 01 51 17 E4 0F E8 (GMT: Wednesday, November 18, 2015 12:00:01 AM)

+

| style="vertical-align: middle; text-align: center;" |00 00 01 51 17 E4 0F E8 (GMT: Wednesday, November 18, 2015, 12:00:01 AM)

|-

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

Line 2,164: Line 2,167:

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

|-

−

| style="vertical-align: middle; text-align: center;" |N4 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N4 of Four Bytes IO

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

|-

−

| style="vertical-align: middle; text-align: center;" |N8 of ~~Two~~ Bytes IO

+

| style="vertical-align: middle; text-align: center;" |N8 of Eight Bytes IO

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

|-

Line 2,176: Line 2,179: −

~~Server~~ response in hexadecimal stream:

+

The server response in the hexadecimal stream:

−

+

Parsed:

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

Line 2,201: Line 2,204:

|-

| style="vertical-align: middle; text-align: center;" |Number of Accepted Data

−

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

+

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

|-

|}

=='''<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,252: Line 2,255:

='''<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 used for communication over GPRS messages and the differences between them.

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

Line 2,258: Line 2,261:

*'''<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 the 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 commands on special firmware versions). This protocol is also necessary for using [[FMB630]]/[[FM6300]]/FM5300/FM5500/FM4200 features like Garmin, LCD communication, and COM TCP Link Mode.

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

−

~~Following~~ figure shows how GRPS command session is started over TCP.

+

The following figure shows how the GRPS command session is started over TCP.

[[File:Codec12.png|1150px]]

−

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.

+

First, the Teltonika device opens the GPRS session and sends AVL data to the server (refer to device protocols). Once all records are sent and the correct sent data array acknowledgment is received by the device then GPRS commands in Hex can be sent to the 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~~.

+

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

−

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 the GPRS session should remain active between the 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 Codec12 messages.

+

The following diagram shows the basic structure of Codec12 messages.

'''Command message structure:'''

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

Line 2,324: Line 2,327:

'''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.

+

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

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

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

Line 2,330: Line 2,333:

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

'''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 that defines how many records (commands or responses) are in the packet. This byte will not be parsed but it’s recommended that it should contain the same value as Command/Response Quantity 1.

−

'''CRC-16''' – calculated from Codec ID to the 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 [[Codec#CRC-16|CRC-16/IBM]].

+

'''CRC-16''' – calculated from Codec ID to the Command Quantity 2. CRC (Cyclic Redundancy Check) is an error-detecting code used to 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: <code>0x05</code> means command and <code>0x06</code> means response.

+

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

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

Line 2,341: Line 2,344:

*'''<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 ~~separate~~ into different table columns for better readability and understanding.

+

The hexadecimal stream of command and answer in this example is given in the hexadecimal form. The different fields of the message are separated 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 ~~separate~~ into different table columns for better readability and some of them are converted to ASCII values for better understanding.

+

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

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

−

Server request in hexadecimal stream:

+

Server request in the hexadecimal stream:

Parsed:

Line 2,388: Line 2,391:

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

−

Device response in hexadecimal stream:

+

Device response in the hexadecimal stream:

Line 2,432: Line 2,435:

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

−

Server request in hexadecimal stream:

+

Server request in the hexadecimal stream:

Parsed:

Line 2,473: Line 2,476:

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

−

Device response in hexadecimal stream:

+

Device response in the hexadecimal stream:

Parsed:

Line 2,518: Line 2,521:

*'''<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 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 using Hercules (in TCP server mode). Simply write the command into the Hercules Send field, check the HEX box and click Send button. Note that the TCP server must be listening on a specified port (see Port field and Listen button below).

[[File:Hercules.jpeg]]

Line 2,526: Line 2,529:

*'''Garmin'''

−

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

+

All information is provided in the “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 the “FMxx TCP Link mode test instructions.pdf” document.

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

Line 2,536: Line 2,539:

*'''<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 the original Teltonika protocol for device-server communication over GPRS messages and it is based on the Codec12 protocol. The main differences of Codec13 are that timestamp is used 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 the basic structure of Codec 13 messages:

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

|+

Line 2,560: Line 2,563:

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

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

−

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

+

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

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

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

Line 2,568: Line 2,571: −

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

+

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

−

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

+

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

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

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

−

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

+

'''Command Type''' – it is always <code>0x06</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.

+

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

−

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

+

'''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.

+

'''Command Quantity 2''' – a byte that defines how many records (commands) are in the packet. This byte will not be parsed but it’s recommended that it should contain the 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 Second Number of Data. CRC (Cyclic Redundancy Check) is an error-detecting code used to 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 the “Message Timestamp” parameter in RS232 settings is enabled.

−

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

+

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

+

*'''<big>About Codec14</big>'''

+

Codec14 is the original Teltonika protocol for device-server communication over GPRS messages and it is based on the Codec12 protocol.

+

The main difference of Codec14 is that the device will answer the GPRS command if the device's physical IMEI number matches the specified IMEI number in the GPRS command.

−

~~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~~. ~~ ~~

+

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

−

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

−

~~Hexadecimal stream: ~~

−

~~<code>00000000000000170D01050000000F0000016C0A81C320676574696E666F0100006855</code> ~~

−

~~Parsed:~~

−

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

−

|+

−

~~! colspan="2" style="border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Server Command~~

−

|-

−

~~! rowspan="1" style="width:50%; vertical-align: middle; text-align: center;" |Server Command Part~~

−

~~! rowspan="1" style="width:50%; vertical-align: middle; text-align: center;" |HEX Code Part~~

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Zero Bytes~~

−

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

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Data Size~~

−

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

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Codec ID~~

−

~~| style="vertical-align: middle; text-align: center;" |0D~~

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Command Quantity 1~~

−

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

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Command Type~~

−

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

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Command Size~~

−

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

−

|-

−

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

−

~~| style="vertical-align: middle; text-align: center;" |00 00 01 6C 0A 81 C3 20~~

−

|-

−

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

−

~~| style="vertical-align: middle; text-align: center;" |67 65 74 69 6E 66 6F~~

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |Command Quantity 2~~

−

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

−

|-

−

~~| style="vertical-align: middle; text-align: center;" |CRC-16~~

−

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

−

|-

−

|}

+

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

−

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

+

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

−

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

+

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

−

*'''<big>About Codec14</big>'''

−

~~Codec14 is original Teltonika protocol for device-server communication over GPRS messages and it is based on Codec12 protocol. ~~

−

~~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). ~~

−

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

−

~~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 the basic structure of Codec14 messages.

'''Command message structure'''

Line 2,703: Line 2,657:

'''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.

+

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

'''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 <code>0x06</code> if it’s ACK or <code>0x11</code> if it’s nACK.

+

'''Type''' – if it is a request command from the 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 (<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.

+

''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 the command message IMEI doesn’t match the actual device IMEI, the received command won’t be executed and a response to the 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.

+

''Note:'' make sure that size is IMEI size 8 + actual command size. The minimal value is 8 because Codec14 always contains 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 <code>0x0123456789123456</code> value.

+

'''IMEI (HEX)''' – it is send as HEX value. For example, if the device IMEI is 123456789123456 then the 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. '''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]].

+

'''Command/Response Quantity 2''' - a byte that defines how many records (commands or responses) are in the packet. This byte will not be parsed but it’s recommended that it should contain the 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 used to detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

*'''<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 ~~separate~~ into different table columns for better readability and some of them are converted to ASCII values for better understanding.

+

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

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

Server requests in Hexadecimal stream:

Line 2,747: Line 2,701:

|-

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

−

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

+

| style="vertical-align: middle; text-align: center;" |03 52 09 30 81 45 22 51

|-

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

−

| style="vertical-align: middle; text-align: center;" |~~03 52 09 30 81 45 22 51~~

+

| style="vertical-align: middle; text-align: center;" |67 65 74 76 65 72

|-

| style="vertical-align: middle; text-align: center;" |Command Quantity 2

Line 2,762: Line 2,716:

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

−

Device ACK response in hexadecimal stream:

+

Device ACK response in the hexadecimal stream:

Line 2,809: Line 2,763:

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:

+

Device nACK response in the hexadecimal stream:

Parsed:

Line 2,848: Line 2,802:

|}

−

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

+

−

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

+

=='''<big>Codec 15</big>'''==

+

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

+

Codec 15 relies on the Codec12 protocol and is employed when both message timestamp and device IMEI are enabled. It serves as the original Teltonika protocol for communication from the device to the server via GPRS messages. This protocol is exclusively applicable to FMX6 professional devices.

+

Codec15 is available in RS232 modes:

+

1. TCP/UDP Ascii

+

2. TCP/UDP Binary

+

3. TCP/UDP Ascii Buffered

+

4. TCP/UDP Binary Buffered.

+

*'''<big>Structure of Codec 15 messages</big>'''

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

|+

−

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |0x00000000 (Preamble)

−

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |~~Codec12~~

+

! rowspan="1" style="width:5%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Data Size

−

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |~~Codec13~~

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |0x0F (Codec ID)

−

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |~~Codec14~~

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Command quantity

+

! colspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Message type

+

! rowspan="1" style="width:14%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Command size + timestamp + imei

+

! rowspan="1" style="width:5%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Timestamp

+

! rowspan="1" style="width:5%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |IMEI

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Command

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Command quantity

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |CRC - 16

|-

−

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

+

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

−

| style="vertical-align: middle; text-align: center;" |Server - Device Communication

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

|-

+

|}

+

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

+

'''Preamble''' - four zero bytes.

+

'''Data size''' - size is calculated from codec id(0x0F) field to the second command quantity field.

+

'''Codec ID''' - in Codec 15 it is always 0x0F.

+

'''Command quantity''' - a number which defines how many commands are in the packet.

+

'''Message type''' - this value is configurable in RS232 settings box.

+

'''Command size + Timestamp + IMEI''' - it is equal to size of payload + size of timestamp + size of imei.

+

'''Timestamp''' – data record creation time in seconds(Unix timestamp).

+

'''IMEI''' - send as HEX value. Example if device IMEI is 123456789123456 then IMEI data field will contain 0x0123456789123456 value.

+

'''Command field''' - actual received data.

+

'''Command quantity''' - a number which defines how many commands are in the packet.

+

'''CRC field''' - calculated from Codec ID to the Second Number of Data.

+

*'''<big>Codec 15 examples</big>'''

+

Device sends message „Hello\n“ via GPRS Codec15:

+

000000000000001b0f010b00000013654b65a4012345678912345648656c6c6f210a01000093d6

+

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

+

! colspan="2" style="border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Parsed command

+

|-

+

! rowspan="1" style="width:50%; vertical-align: middle; text-align: center;" |Command Part

+

! rowspan="1" style="width:50%; vertical-align: middle; text-align: center;" |HEX Code Part

+

|-

+

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

+

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

+

|-

+

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

+

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

+

|-

+

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

+

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

+

|-

+

| style="vertical-align: middle; text-align: center;" |Quantity of commands

+

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

+

|-

+

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

+

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

+

|-

+

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

+

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

+

|-

+

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

+

| style="vertical-align: middle; text-align: center;" |65 4B 65 A4

+

|-

+

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

+

| style="vertical-align: middle; text-align: center;" |01 23 45 67 89 12 34 56

+

|-

+

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

+

| style="vertical-align: middle; text-align: center;" |48 65 6c 6c 6f 21 0a

+

|-

+

| style="vertical-align: middle; text-align: center;" |Quantity of commands

+

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

+

|-

+

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

+

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

+

|-

+

|}

+

CRC: 0x 000093d6

+

The algorithm to calculate CRC is CRC-16 (also known as CRC-16-IBM). All the fields from codec ID to second command/response quantity field are used to calculate CRC.

+

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

+

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

+

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

+

|+

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Codec12

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Codec13

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Codec14

+

! rowspan="1" style="width:10%; border-bottom: 2px solid #0054A6; vertical-align: middle; text-align: center;" |Codec15

+

|-

+

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

+

| style="vertical-align: middle; text-align: center;" |Server - Device Communication

| style="vertical-align: middle; text-align: center;" |One-way (Device -> Server communication)

| style="vertical-align: middle; text-align: center;" |Server - Device Communication

+

| style="vertical-align: middle; text-align: center;" |One-way (Device -> Server communication)

|-

! rowspan="1" style="width:10%; vertical-align: middle; text-align: center;" |Codec ID

Line 2,866: Line 2,927:

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

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

+

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

|-

! rowspan="1" style="width:10%; vertical-align: middle; text-align: center;" |Response Message Type

Line 2,871: Line 2,933:

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

| style="vertical-align: middle; text-align: center;" |0x06 (if it is ACK) or 0x11 (if it is nACK)

+

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

|-

! rowspan="1" style="width:10%; vertical-align: middle; text-align: center;" |Command / Response size

Line 2,876: Line 2,939:

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

| style="vertical-align: middle; text-align: center;" |Command/Response + IMEI

+

| style="vertical-align: middle; text-align: center;" |Command + IMEI

|-

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

Line 2,881: Line 2,945:

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

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

+

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

|-

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

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

+

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

|-

Line 2,891: Line 2,957:

='''<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 <code>0x04</code>).

+

24-hour SMS is usually sent once every day and contains GPS data for the last 24 hours. The 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 uses 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. The data packet can be interpreted as a bitstream, where all bits are numbered as follows:

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

|+

Line 2,912: Line 2,978: −

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 the 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 – is the most significant bit.

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

−

Below in the tables you will see SMS Data Structure:

+

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

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

|+

Line 2,955: Line 3,021: −

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 the Timestamp field. The time corresponding to each further element can be computed as elementTime = Timestamp + (1 hour * elementNumber).

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

|+

Line 3,025: Line 3,091:

*'''<big>SMS Events</big>'''

−

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

+

When configured to generate an 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:

Line 3,031: Line 3,097:

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

−

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]].

+

This type of data sent is used 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 <code>0x04</code>).

+

AVL data or events can be sent encapsulated in binary SMS. The 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 3,050: Line 3,116:

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

−

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

+

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

='''<big>CRC-16</big>'''=

−

CRC (Cyclic Redundancy Check) is an error-detecting code ~~using for~~ detect accidental changes to RAW data. The algorithm how to calculate CRC-16 (also known as CRC-16/IBM) you will find below.

+

CRC (Cyclic Redundancy Check) is an error-detecting code used to detect accidental changes to RAW data. The algorithm on how to calculate CRC-16 (also known as CRC-16/IBM) you will find below.

[[File:CRC16.png]]

+

[[Category:General Information|50]]

Sarunas.sveistys

Administrators

89

edits

Namespaces

Variants

Views

More

Search

Changes

Teltonika Data Sending Protocols (view source)

Revision as of 09:49, 8 December 2023

Navigation menu

Personal tools

NAVIGATION

Tools

Categories