This is going to be a rather short post because it has been covered by other people elsewhere. I will concentrate on which protocol works best for the tutorial we are on. This is the third post of the tutorial. You may find the previous posts here: Post #1: SIM900 Dialup Connection Setup Post #2: SIM900 PPP Driver for KEIL Network-DS
At the tail end of this post, there are additional resources for further reading.
There are a number of protocols out there and sometimes we get confused by the marketing around some of them. That is evident in the picture below.
In this case, I had a few objectives:
- The relative ease of incorporation. I really would not like to implement the whole protocol from scratch. I would like to find an open-source implementation that would work well with little to no tweaking.
- The relative usage of resources. If we were using a computer, this would not be an issue. Having a computer with 4GB of RAM and 128GB of storage is relatively normal. Unfortunately, we have 1MB of flash storage for my program and less than 100kB of RAM on the LPC4337, yet we have to keep in mind that there are other pieces of code and libraries in the entire application.
My choices were HTTP, AMQP, MQTT, CoAP. Do you hate acronyms as I do? Don’t worry I’ll give the meaning of each shortly. I know there are probably other protocols that are out there but I cannot keep the search on for too long. Besides, change in protocol is a software bit and if the hardware has already been built, all we’ll need is a couple of hours to get the newer (or other) protocol working.
Almost everyone who has used a browser knows this one. At least for the acronym. HTTP has been used to share documents online but more so in the browser. When you open a website, your browser downloads one file, parses it to determine if there are any other documents linked which it would then download. The fancy design actually comes from stylesheet kind of documents. Unfortunately, this protocol uses text for everything meaning that you need a proper engine for parsing strings. You can google on how a typical HTTP request/response looks like. Strings take a lot of memory and if you are not careful, you may end up with memory leakage or corrupt memory sections when working in C on a microcontroller. You will realize that unless unavoidable, strings are barely used in microcontroller applications, say for static text. I find HTTP best fit for stuff that lives in the cloud with enough resources. Stuff like websites, REST APIs and micro-services. After some searching, I could not find a proper library for an HTTP client that I could use on my microcontroller but the searching for this hasn’t ended yet. At the moment, it is not viable.
Well, I have not completely implemented this on anything yet. So my experience here is very limited if any. My first experience required me to install Qpid Proton libraries for Windows. It was right here. I really don’t like it when I am messing around with my environment variables. AMQP is mainly defined by messages having orientation, use of queues and presence of routing. Wikipedia describes it further. Since it is an OASIS standard, there is more information on its homepage plus the actual pdf document. AMQP is quite reliable. It seems to me as reliable as HTTP. The Microsoft Azure guys even support it on their Service Bus product offering. It also seems to be their default transport for their IoT Hub.
To many, this may seem very new but it is not. It was originally developed by IBM for use with satellite communications. Some years back satellite communications were very expensive. Not to say that it is any cheaper today when compared to normal communication on GSM or CDMA. This meant that it had to very lightweight in the amount of data sent. It did not really matter if it was running on a computer. Yes, it did deliver and that’s why it was made open. Wikipedia gives some brief here. It is also an OASIS standard with the homepage here and a pdf document.
Well, this one has been here for the shortest time compared to the others above but it has quite some following. The most interesting part of this is that it is easily translatable to HTTP, yet remaining very lightweight in the amount of data sent. The normal headers in HTTP which take at least 100bytes of data are now combined into only 4 bytes! Awesome, huh? It is not yet an OASIS standard but it is so constrained that the whole spec was written into a one-page cheatsheet. The first time I saw it, I could not believe it. Unlike the other three above, CoAP runs on UDP (User Datagram Protocol) and not TCP (Transmission Control Protocol), meaning that one would have to implement their own packet-loss checking mechanisms. This is supported in TCP already but with an overhead in data size and time. On the other side, using UDP makes it possible for CoAP to be used even over SMS.
The image below does some extra explaining
It is rather obvious at this point that HTTP and AMQP were not options for me. CoAP follows the same line because I did not find any libraries plus I would need a proxy server to do the HTTP to CoAP and CoAP to HTTP translation. After choosing MQTT, I went with the Eclipse Paho client library for C. It is extremely lightweight, open-source and easy to use.
- MQTT and CoAP, by Electronics Design
- Comparison of MQTT, AMQP, and STOMP, on VMware
- MQTT 101, by HiveMQ
- MQTT and CoAP compared, by Eclipse
- MQTT and CoAP Explained, by Sine Wave
- MQTT on Arduino, by m2mio. Although I really hate Arduino, it helps to show how lightweight MQTT is.
- Exploring the protocols for IoT, by Sparkfun
In the next post, I shall discuss getting MQTT working in the tutorial I mentioned above. There will be code; yes! See you then if not sooner in the comments.