Difference between revisions of "Help with Server FAQ"

From Wiki Knowledge Base | Teltonika GPS
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Server Related Questions and Tips.
+
This page is dedicated to quickly find most commonly faced issues or questions when trying to create an IoT data platform which supports Teltonika Telematics devices.  
  
 
=='''Pre-Requisites for server implementation'''==
 
=='''Pre-Requisites for server implementation'''==
Line 14: Line 14:
 
|A high CPU count promotes better cloud tiering throughout because although object storage can be slow in I/O operations per thread, object storage can support many threads. Any standard x86 64-bit servers can be ideally used.
 
|A high CPU count promotes better cloud tiering throughout because although object storage can be slow in I/O operations per thread, object storage can support many threads. Any standard x86 64-bit servers can be ideally used.
 
|-
 
|-
|Memory/RAM Requirements
+
|Memory Requirements
 
|Cloud services demand a large amount of memory, which is why the minimum recommended memory size is 8GB.
 
|Cloud services demand a large amount of memory, which is why the minimum recommended memory size is 8GB.
 
|-
 
|-
|Harddisk
+
|Hard disk
|For a medium-sized server, 300GB RAID1 disks can be recommended.
+
|For a medium-sized (up to a 1000 devices) server, 300GB RAID1 disks can be recommended.
 
|-
 
|-
 
|Database
 
|Database
|A database is required to store the records/messages incoming from multiple devices. Further, this data must be assigned to its appropriate device ( recognized by IMEI ). MySQL can be used for the database.
+
|A database is required to store the records/messages incoming from multiple devices.  
 +
Further, this data must be assigned to its appropriate device ( recognized by IMEI ). MySQL can be used for the database.
 
|-
 
|-
 
|Security
 
|Security
|Teltonika devices support TLS Encryption which can be implemented on the server side.
+
|Teltonika devices support TLS Encryption which can be implemented.  
 +
[[How to generate TLS certificates (Windows)?]]
 
|-
 
|-
|
+
|Programming Skills
|
+
|Knowledge about programming language is a must. Teltonika Telematics is a hardware production company, we do not provide software programming services and cannot help with writing code for the server. Only consult on the logic and algorithms of device features and possible issues in data interpretation from the server side.
 +
|-
 +
|Hardware Knowledge
 +
|It can be found on our Teltonika WIKI: https://wiki.teltonika-gps.com/view/Main_Page
 +
To understand the devices, their use cases and how they send data.
 +
|-
 +
|Protocol Implementation
 +
|Teltonika Telematics device protocols need to be implemented for the server to understand and parse the received data correctly.
 +
[[Teltonika Data Sending Protocols]]
 +
|-
 +
|Socket Programming
 +
|Sockets and the socket API are used to send messages across a network. For Teltonika devices to make connection to your server, the server needs to have an application socket programmed to accept these connection request.
 +
'''Note:'''
 +
 
 +
Each socket should be dedicated to one device, this will allow the server to differentiate the devices when more than 1 device is sending data at the same time.
 +
|-
 +
|Network Considerations
 +
|Cloud storage supports storing cold data on a public cloud object storage service,such as Amazon S3. When using a public cloud, the connection is over a WAN.
 
|-
 
|-
|
+
|Bandwidth Requirements
|
+
|Bandwidth speed requirements are based on the amount of data transfer per month. It can be calculated using some online tools such as: https://www.calculator.net/bandwidth-calculator.html.
 
|-
 
|-
|
+
|IP Address Requirements
|
+
|Static IP or a dedicated port and domain is required otherwise device configuration would need to be updated constantly with a new IP or a new Port.
 
|-
 
|-
|
 
 
|}
 
|}
  
Line 83: Line 101:
 
For example, IMEI 356307042441013 would be sent as 000F333536333037303432343431303133. First two bytes denote IMEI length. In this case 0x000F means, that IMEI is 15 bytes long.
 
For example, IMEI 356307042441013 would be sent as 000F333536333037303432343431303133. First two bytes denote IMEI length. In this case 0x000F 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.
+
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.
 
|}
 
|}
  

Latest revision as of 10:03, 14 February 2024

This page is dedicated to quickly find most commonly faced issues or questions when trying to create an IoT data platform which supports Teltonika Telematics devices.

Pre-Requisites for server implementation

Documentation

Communication with server

Troubleshooting Data

Common Mistakes

Communication over GPRS

RAW Data Example