Have you ever tried to parse a data stream from telematics or IoT devices? Have you ever interconnected various platforms available via API with each other? Do you know the difference between SOAP and REST API? What's better — JSON or XML? Or the difference between TCP, UDP, HTTP and MQTT?
We know. We are the experts in devices integrations and know how to connect one platform to another. We gathered this experience in Gurtam connecting thousands of various types of devices and hundreds of protocols. And we know these devices inside and out. We know which manufacturer is doing innovations, who thinks about the future and tries to predict it, and who is just trying to sell-fix-sell-fix.
Let's first talk about platforms providing telematics services via API. There are plenty of them: Daimler Mercedes, Scania, MAN, Caterpillar, Sigfox, etc. Some have loads of documentation and 3-5 generations of API. Some APIs are a pain for developers who need to extract data. Some are based on ancient XML-based SOAP API architecture, and some use modern JSON-based REST API. By looking at the API documentation, you can immediately imagine the team behind the product. And as the spirit and culture in each company go from head to bottom, you can expect the same technology and knowledge level in other areas of the given business.
Since transportation companies are complex and telematics represents only a small part of a large vehicle, it might not reflect the state of the entire vehicle or company. But for GPS tracking device manufacturers it’s 100% true. Look into the protocol specification, and you can tell how smartly the device is engineered, what country it originated from, and what future the company has.
Let's look at TCP and UDP options for the data flow. Both provide network layer connectivity for data packets transmission from device to a server. The difference is simple: with UDP the device does not know if the host received the data packet or not. With TCP the network stack (libraries on device, tracking server and in between) control the ordered flow of data packets. The pros of TCP: it is connection-based, so once a device connects to a server, it can seamlessly communicate with the device in both directions — read/update configuration and firmware, monitor the connection state, and deliver controlling commands. The cons of TCP: it consumes more traffic (for control packets) compared to UDP, especially when creating a connection.
10-15 years ago when GPRS traffic cost a lot and engineers developing this emerging market were cool, they used mostly UDP for data transmission and often implemented own TCP-stack on top of it with acknowledgement packets. Protocols were complex — one byte contained plenty of data divided by bits, but everything was usually clear and smart.
When the prices for GPRS traffic went down, a variety of GPS platforms on the market started to grow, and protocols started to simplify. Most companies switched to TCP — it’s simpler to maintain and implement since the system libraries do all the packets transmission control for you. Some device manufacturers upgraded their protocols to TCP but left the original UDP-based dataflow for simplicity. Imagine, a device connects via TCP, authorizes on the server, sends a few data packets, and disconnects. Loads of valuable GPRS traffic go to waste. Lack of persistent connection negates the main benefit of TCP. Most of these guys have died or are in their final days. Would you like to know their names? :)
At some moment of time, lots of Chinese companies popped up. They just copied the GPRMC text message from the GPS receiver, prepended or appended to it a device IMEI, and sent to the server. The idea was to make it as simple as possible for both the device and the server developer. The result? Yes, it is easy. But it is also a pain. When they sold the first 10 000 devices and established the business, they were flexible enough to release a special firmware for each customer. And each customer asked them to send additional information, e.g., current voltage or digital input states. They started to add more and more parameters to this text line. One device and hundreds of ways to parse the data. Sure, it is a dead end.
Some manufacturers focused on simplicity and never thought about traffic. For example, those who use simple HTTP as an underlying protocol. Probably they thought that their devices would be used over the Internet directly by web-servers?
On the other side of the spectrum, we see these North American manufacturers that still try to minimize traffic. They pack valuable information into bits and deliver a schema describing the packet itself and a few data packets to a server. These devices are usually good, but too complicated for use by platform developers. That's why they have problems with expansion to the world markets.
Finally, we can compare protocols by the ease of remote device configuration and stability of controlled devices. It is important — once you start sending commands to a device and it starts reacting, its internal logic can break. We saw this multiple times :)
It’s no longer enough for the tracker to send data to a server and receive it from commands. Devices often serve as hubs to which other devices connect, e.g. Garmin tablet or tachograph. These devices communicate over own protocol. Most modern devices can wrap these protocols into own, which again makes supporting all these features more complicated for GPS platforms developers. Companies like flespi attempt to unify the protocol descriptions to make multiprotocol infrastructures and switching between device manufacturers a feasible endeavor.
Should we judge hardware manufacturers by their protocol preference? I think no. A lot of factors influence the selection. Hardware engineers may want to change the protocol and make it modern, but they can't. Because of the history, because of platforms that can understand only the old protocol. The more platforms they integrate with, the harder this change is.
What we can do is look at the protocol description and form an opinion about how smart, experienced, and future-oriented the developers of this or that device are. And this is much more important than pitches of their sales reps.
Want to know the best GPS device manufacturer on the market? We know all of them by the name!