Nowadays, when the media write about the Internet of Things, nobody worries about transfer speed issues. We assume that networks are fast enough to consign this issue to the past. But is it really the case? Not so sure...
When you work only on a local area network, it's true that current performances allow almost anything. The practice of using web applications, designed to use optimally the powerful resources of web server and clients, tend to make us forget the underlying technological constraints.
In the context of connected objects, things are slightly different. To save energy, cost, and heat dispersal, we usually work with small processors which have very little memory. The network is not often cabled and, in some cases, it's a network with a strong latency (such as a GSM network, for example for applications linked to agriculture). Does this latency have a significant impact? One might think that connected objects transmit only very little data and that, in any case, latency would not really affect the transfer rate. Well... it's wrong!
First, on the quantity of data to be transferred: if the connected object has a web interface worthy of the name, it will certainly require the transfer of at least a few tens of kilobytes. And even if there is no web interface and it transmits its data with a much lighter protocol, it necessarily must have a mechanism to update the firmware, to be able to apply the unavoidable security patches. This mechanism probably requires the transfer of several hundreds of kilobytes.
Second pitfall: 200KB, 500KB, it doesn't seem much for a 3G network with a theoretical data rate counted in Mbit/s... but this is without taking into account the internals of TCP/IP, the protocol used for most transfers on the network. In TCP, to warrant an error-free transfer, the sender cannot send more data than the size allowed by the recipient's memory. Moreover, the sender must keep these data in its memory until the target has confirmed the good reception of the transfer. Therefore, the actual throughput is limited by the size of the smallest of the two transmission windows and by the time necessary to receive the receipt, so by the network latency. And this is where the shoe pinches: small memory, high latency, those are specifically the characteristics we were mentioning earlier.
A sensor is connected on a GSM 3G HSPA+ network at 15 Mbits/s but with a 300ms latency. If it has 1 KB of input network buffers, how much times is needed to update a 1 MB firmware?
Max throughput = window / latency = 1[KB] / 0.3s = 3.333 [KB/s]
Transfer time = size / throughput = 1024 [KB] / 3.333 [KB/s] = 307 [s], so more than 5 minutes!
By itself, it's not an issue for a firmware update to take 5 minutes, if it has been correctly planned by the designer and doesn't create an upload failure because of a timeout. However, we can't accept this kind of delay wherever in a web interface. Therefore, doing IoT is not as simple as taking a small project built on a napkin that works on an Ethernet network and putting behind it a GSM modem :-)
Not the same design goals, not the same network throughput
Then how is it that I can view a video on my 3G phone ?
A mobile phone has much more ressources than a typical IoT device: current smartphones have 4 GB RAM, which is 40,000 times more than a YoctoHub-Ethernet for instance. This allows for large receive buffers and avoids the bottleneck effect described above. Moreover, there are specific video streaming protocols with algorithms more efficient than TCP on GSM networks, but that are not be applicable for a firmware update for instance.
How do Yoctopuce products fare?
Yoctopuce falls right into the IoT case: small processors, small memory. Our first YoctoHubs have been designed to work on low-latency local network, and were therefore not very reactive when used over a GSM or satellite link. Until now, firmware updates had to be done either using USB, or over a local area network.
We have developed a new version of the Web UI and new network protocols for the YoctoHub-GSM. It is based on WebSockets rather than vanilla HTTP, since this makes it possible to better handle low-bandwidth networks. Today, we are bringing this new feature to the YoctoHub-Ethernet and YoctoHub-Wireless-gas well, by mean of similar new firmware.
So once this new firmware will be installed, you should be able -with a bit of patience- to perform the next firmware updates even over a GSM link !
- Firmware 23693 for YoctoHub-Ethernet
- Firmware 23693 for YoctoHub-Wireless-g
- Firmware 23693 for YoctoHub-Wireless-SR
- Firmware 23693 for YoctoHub-Wireless