Changes

Codec (view source)

Revision as of 12:28, 2 November 2018

6,341 bytes added ,  12:28, 2 November 2018
→‎Codec 16 Nebaigta
Line 1,469: Line 1,469:     
CRC16 is 4 bytes, but first two are zeroes and last two are CRC-16 calculated for CodecID to NOD2.
 
CRC16 is 4 bytes, but first two are zeroes and last two are CRC-16 calculated for CodecID to NOD2.
 +
 +
 +
Received data:
 +
 +
[[Image:123.png|123.png]]
 +
 +
00000000 4 zeros, 4 bytes
 +
 +
0000009D data length, 4 bytes
 +
 +
10 – Codec ID
 +
 +
02- Number of Data (2 records)
 +
 +
1’st record data
 +
 +
0000013feb55ff74 – Timestamp in milliseconds (1374042849140)
 +
 +
GMT: Wed, 17 Jul 2013 06:34:09 GMT
 +
 +
00 – Priority
 +
 +
GPS Elements
 +
 +
0f0ea850 – Longitude 252618832 = 25,2618832º N
 +
 +
209a6900 – Latitude 546990336 = 54,6990336 º E
 +
 +
00AE – Altitude 174 meters
 +
 +
00B9 – Angle 185º
 +
 +
0B – 11 Visible sattelites
 +
 +
0000         – 0 km/h speed
 +
 +
IO Elements
 +
 +
0000 – IO element ID of Event generated (in this case when 0000 – data generated not on event)
 +
 +
07 - Generation type
 +
 +
0A – 10 IO elements in record (total)
 +
 +
05 – 5 IO elements, which length is 1 Byte
 +
 +
0001 – IO element ID = 01
 +
 +
00 – IO element’s value = 0
 +
 +
0002 – IO element ID = 02
 +
 +
00 – IO element’s value = 0
 +
 +
0003 – IO element ID = 03
 +
 +
00 – IO element’s value = 0
 +
 +
0004 – IO element ID = 04
 +
 +
00 – IO element’s value = 0
 +
 +
0120 – IO element ID = 288 (dec)
 +
 +
00 – IO element’s value = 0
 +
 +
02 – 2 IO elements, which value length is 2 Bytes
 +
 +
0018 – IO element ID = 24 (dec)
 +
 +
0000 – IO element’s value
 +
 +
0046 – IO element ID = 70 (dec)
 +
 +
0129 – IO element’s value
 +
 +
02 – 2 IO elements, which value length is 4 Bytes
 +
 +
00C7 – IO element ID = 199 (dec)
 +
 +
00000000 – IO element’s value
 +
 +
0046 – IO element ID = 70 (dec)
 +
 +
00000000 – IO element’s value
 +
 +
 +
01 – 1 IO elements, which value length is 8 Bytes
 +
 +
003E – IO element ID = 62 (dec)
 +
 +
0000000000000000 – IO element’s value
 +
 +
2’st record data
 +
 +
0000015B198C7498000F0DBC502095872F00AE00B90B00000000070A0500010000020
 +
 +
00003000004000120000200180000004601290200C700000000004C0000000001003E00000
 +
 +
00000000000
 +
 +
02 – Number of Data (2 records)
 +
 +
000009A5 - CRC-16, 4 Bytes (first 2 are always zeros)
 +
 +
 +
*'''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 123456789012345 would be sent as 000f333536333037303432343431303133
 +
 +
First two bytes denote IMEI length. In this case 000F 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.
 +
 +
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.
 +
 +
'''Example:'''
 +
 +
Module connects to server and sends IMEI:
 +
 +
000f333536333037303432343431303133
 +
 +
Server accepts the module:
 +
 +
01
 +
 +
Module sends data packet:
 +
 +
{| class="wikitable"
 +
|-
 +
!style="background: black; color: white;"| Codec type !!style="background: black; color: white;"| AVL data packet header !!style="background: black; color: white;"| AVL data array !!style="background: black; color: white;"| CRC
 +
|-
 +
|  || Four zero bytes,
 +
‘AVL data array’ length – 254
 +
|| CodecId – 08 or codec 16,
 +
NumberOfData – 2.
 +
(Encoded using continuous bit stream.
 +
 +
Last byte padded to align to byte boundary)
 +
|| CRC of ‘AVL data array’
 +
|-
 +
| Codec8 || 00000000000000FE || 0802...(data elements)...02 || 00008612
 +
|-
 +
| Codec16 || 00000000000000FE || 1002...(data elements)...02 || 00008612
 +
|}
 +
 +
Server acknowledges data reception (2 data elements):
 +
 +
00000002
 +
 +
 +
'''<big>Sending data over UDP/IP</big>'''
 +
 +
 +
*'''UDP channel protocol'''
 +
 +
UDP channel is a transport layer protocol above UDP/IP to add reliability to plain UDP/IP using acknowledgment packets. The packet structure is as follows:
 +
 +
{| class="wikitable "
 +
|-
 +
! colspan="4" align="center" style="background: black; color: white;"|UDP datagram
 +
|-
 +
| rowspan="4"| UDP channel packet x N
 +
| Example || 2 bytes || Packet length (excluding this field) in big ending byte order
 +
|-
 +
| Packet Id || 2 bytes || Packet id unique for this channel
 +
|-
 +
| Packet Type || 1 byte || Type of this packet
 +
|-
 +
| Packet payload || m bytes || Data payload
 +
|}
 +
 +
 +
{| class="wikitable"
 +
|-
 +
! colspan="3" align="center" style="background: black; color: white;"|Packet Type
 +
|-
 +
| 1 ||Data packet requiring acknowledgment
 +
|}
 +
 +
Acknowledgment packet should have the same packet id as acknowledged data packet and empty data payload.
 +
 +
Acknowledgement should be sent in binary format.
 +
 +
{| class="wikitable"
 +
|-
 +
! colspan="3" align="center" style="background: black; color: white;"|Acknowledgment packet
 +
|-
 +
| Packet length || 2 bytes || 0x0003
 +
|-
 +
| Packet id || 2 bytes || same as in acknowledged packet
 +
|-
 +
| Packet type || 1 byte || 0x02
 +
|}
 +
 +
 +
*'''Sending AVL data using UDP channel'''
 +
 +
AVL data are sent encapsulated in UDP channel packets (Data payload field).
 +
 +
{| class="wikitable"
 +
|-
 +
! colspan="3" align="center" style="background: black; color: white;"|AVL data encapsulated in UDP channel packet
 +
|-
 +
| AVL packet id (1 byte) || Module IMEI || AVL data array
 +
|}
 +
 +
 +
AVL packet id (1 byte) – id identifying this AVL packet
 +
 +
Module IMEI – IMEI of a sending module encoded the same as with TCP
 +
 +
AVL data array – array of encoded AVL data
 +
 +
{| class="wikitable"
 +
|-
 +
! colspan="3" align="center" style="background: black; color: white;"|Server response to AVL data packet
 +
|-
 +
| AVL packet id (1 byte) ||Number of accepted AVL elements (1 byte)
 +
|}
 +
 +
AVL packet id (1 byte) – id of received AVL data packet
 +
 +
Number of AVL data elements accepted (1 byte) – number of AVL data array entries from the beginning of array, which were accepted by the server
 +
 +
 +
'''Scenario:'''
 +
 +
Module sends UDP channel packet with encapsulated AVL data packet (Packet type=1 or 0). If packet type is 0, server should respond with valid UDP channel acknowledgment packet. Since server should respond to the AVL data packet, UDP channel acknowledgment is not necessary in this scenario, so Packet type=1 is recommended.
 +
 +
Server sends UDP channel packet with encapsulated response (Packet type=1 – this packet should not require acknowledgment)
 +
 +
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.
Retrieved from "https://wiki.teltonika-gps.com/view/Special:MobileDiff/21185"

Navigation menu