Changes

Teltonika Data Sending Protocols (view source)

Revision as of 16:04, 3 July 2020

320 bytes added , 16:04, 3 July 2020

m

no edit summary

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:

{| 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 using for device data sending and differences between them.

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

Line 28: Line 28:

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

−

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

+

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

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

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

−

'''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 [[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, the minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

*AVL Data

−

~~Below~~ table represents AVL Data structure.

+

The below table represents the AVL Data structure.

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

|+

Line 92: Line 92:

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

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

−

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

+

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 integer (four bytes).

−

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

+

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

*Example:

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.

+

Hexadecimal stream of AVL Data Packet receiving and response in these examples are given in 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'''

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.

+

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 702: Line 702:

*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 validates AVL Packet ID and the Number of accepted AVL elements. If server response with valid AVL Packet ID is not received within configured timeout, the module can retry sending.

*Example:

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

−

'''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 [[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, the minimum AVL packet size is 45 bytes (all IO elements disabled). Maximum AVL packet size is 1280 bytes.

*AVL Data

Line 995: Line 995:

*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,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:

Line 1,320: Line 1,320:

*'''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 validates AVL Packet ID and the Number of accepted AVL elements. If server response with valid AVL Packet ID is not received within configured timeout, the module can retry sending.

*Example:

Line 1,575: Line 1,575:

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

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

Line 1,606: Line 1,606:

*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 2,008: Line 2,008:

*'''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 validates AVL Packet ID and the Number of accepted AVL elements. If server response with valid AVL Packet ID is not received within configured timeout, the module can retry sending.

*Example:

Line 2,252: Line 2,252:

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

−

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

+

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

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

Line 2,258: Line 2,258:

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

−

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

+

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

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

−

~~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 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 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 (acknowledge 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 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>'''

Line 2,324: Line 2,324:

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

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

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

Line 2,341: Line 2,341:

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

+

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

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

Line 2,518: Line 2,518:

*'''<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 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 a specified port (see Port field and Listen button below).

[[File:Hercules.jpeg]]

Line 2,526: Line 2,526:

*'''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,536:

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

−

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

+

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

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

Line 2,569: Line 2,569:

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

−

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

+

'''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>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 size of timestamp too, so it is equal to the size of payload + size of timestamp.

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

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

−

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

+

'''Command Quantity 2''' – a byte which 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]].

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

Line 2,633: Line 2,633:

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

−

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

+

Codec14 is the 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.

+

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

−

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

+

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

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

Line 2,644: Line 2,644:

*'''<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,703:

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

−

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

'''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 which 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 using to detect accidental changes to RAW data. For calculation we are using [[Codec#CRC-16|CRC-16/IBM]].

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

Line 2,891: Line 2,891:

='''<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. 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. 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,912: −

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

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

Line 3,050: Line 3,050:

'''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 using 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]]

SandraG

Administrators

2,544

edits

Namespaces

Variants

Views

More

Search

Changes

Teltonika Data Sending Protocols (view source)

Revision as of 16:04, 3 July 2020

Navigation menu

Personal tools

NAVIGATION

Tools

Categories