Traditionally, modules such as GPS and AIS communicate with a serial protocol such as RS232 or RS422, whether or not packaged in a virtual COM port over USB or Bluetooth. That principle, of one producer supplying "hard-wired" data to one consumer, has its limitations. This becomes immediately clear when several customers have to be served or sensors of completely different nature have to work together. And, finally, it lacks a constact factor around which things can be organized in time. A marketplace where supply and demand of data come together, enrich each other, and remain available. An MQTT broker acts as a spider in the web and takes care of this. How to get from AIS via NMEA -> JSON -> Wi FI -> MQTT -> Node-Red -> both in every corner of the hobby space and in the wide world? That's what this story is about.
The ESP8266 and ESP32 as a prelude to the 'Internet of Things
At the end of 2014, Espressif (Shanghai, China) launched the ESP8266. An IC that is still widely available today and costs less than a euro. It is not just a microcontroller like all the others but -with its QFN32 package of 5 x 5 mm- a small monster that can rightly be called a SoC (a 'System on Chip'). It houses a powerful low power 32bit 80MHz RISC processor, 36kB SRAM, a WiFi radio with 100mW transmit power, a Wi-Fi stack, a Real-Time Operating System (RTOS) with 80% of the processing power available for the application, a 10 bit AD converter, SPI, I2C and 17 GPIO pins. The chip - supplemented with Flash RAM - can be found on numerous modules in the size (and price!) of a postage stamp. In 2016, Espressif released an even more powerful brother, the ESP32, with a dual core CPU at 240MHz, 520kB SRAM, crypto, better security, Bluetooth and much more IO in all kinds of capacities. The company also offers a ton of development tools including the ESP-IDF (Espressif IoT Development Framework) that the Arduino community has also embraced. And, with Eclipse or Microsoft Visual Studio IDE and the open source PlatformIO, a whole ecosystem of high-quality development tools has become available. Everything can be downloaded for free from the internet. Thanks in part to these two chips, the development of the Internet of Things (IoT) has received an enormous boost.
MQTT
A second development that can be mentioned in the same breath as the Internet of Things is the MQTT network protocol. Released to the public domain by IBM around the turn of the century, it originally served to enable machine-to-machine messaging along oil pipelines between components with a limited memory footprint and communications paths with limited bandwidth. MQTT works on a "publish-subscribe" principle. Producers of information send it over TCP/IP to a server on the network, the MQTT broker. Consumers who need this 'subscribe' to all or a selection and receive one-time or continuous updates.
In this way, sensors and actors can exchange information through the intermediary of the broker. Unlock an AIS feed via WiFi for use in all corners of the hobby room, but also to clients far from home. And at the same time doing something trivial in the sphere of domotics: an outdoor lighting that is switched on because an internet source reports that the sunset has set at the home address. There are endless combinations possible, but the idea is clear: Devices of completely different origin can suddenly work together and support decisions.And perhaps more importantly, MQTT provides a "seperartion fo conserns". The same applies to the AIS receiver described here: do not think too long about how it should eventually be connected to a PC or smartphone for map presentation, but focus on the MQTT broker and make sure that the content of the AIS messages is there. be expressed in clear terms. Often this is in the form of JSON objects, less elegant but also possible are raw NMEA sentences, or the very efficient Google's Protobuf data format. One does not exclude the other.And it is also conceivable that yet another MQTT client acts as an interpreter for the others. The MQTT broker is the constant factor in the network around which everything can be organized step-by-step.
To establish the relationships between different clients and to subject them to a series of rules, use can be made of a "flow editor" in which the various nodes are graphically connected to each other. Node-Red is one such product. Also developed by IBM and made available in 2016 as an open source OpenJS Foundation project.
In the image above an example with (in purple) the 'ais_esp32'-node representing the AIS receiver described here. In blue some Inject-labels to test commands to the AIS receiver. In green two Monitor-labels that are the input for the monitor window on the right. There, JSON strings with position and static ship information updates are now shown. In gray a UDP-node through which the NMEA stream is routed to MarineTraffic.
For the presentation to the end user there is a so-called Nodered Dashboard available and a world number of widgets that can be displayed on it: buttons, dropdowns, sliders, labels, forms, charts, etc. etc.
DThe AIS ESP32-MQTT receiver
After this introduction some more information about the actual project. On the right the bottom side of the PCB with the ESP32. An ESP32-WROOM-32UE was chosen because it has a U.FL connector for an external Wi-Fi antenna, which is necessary given the metal housing. A variant with a PCB-trace antenna would therefore also be chosen for a plastic housing. The module has a Flash memory of 16Mb. A simple ESP8266 (for example in the form of the ESP-07 which also has a U.FL connector and 4Mb Flash) would also have worked well. The ESP32-WROOM has a slightly wider range of options with the number of UART pins that are available and you don't have to worry about the price difference: about 3.50 EURO/USD at AliExpress for the ASP32 at the time of writing.
The receiver is powered with a standard 5V USB adapter. In addition to a simple (AMS1117) 3V3 voltage regulator, there is (NTR4101) P-Channel MOSFET and BC847 NPN as High-Side switch to switch off the AIS receiver remotely. This can be easily bridged when there is no need for it.
The AIS receiver is placed at the top of the PCB. A professional OEM module was chosen here, but that can be replaced by any other model with an RS232/RS422 output, with or without reverse polarity or a different baud rate. That is easy to adjust in the ESP32 firmware. For an affordable alternative, for example, look at the
my article about an AIS-receiver with two Silabs Si4362 | Si4463 chips and STM32 processer
The dimensions of the print are based on a (half) Hammond1455J1601BK housing that was still available. If there is enough interest, I be happy to adapt the design to a specific AIS receiver and housing.
The software
A short description of the firmware in the ESP32: The shipping updates from the AIS receiver arrive as (inverted) RS232 messages on UART-2 of the ESP32. These NMEA sentences can be forwarded in raw state to the MQTT broker immediately after they are received, but they can also be decoded into (huma readable_ JSON-strings. In that case, the NMEA-strings are presented to an integrated AIS parser and stored as JSON-objects in two buffers. The first buffer stores the 'dynamic' updates of all vessels in the service area. This concerns matters such as current position, speed and course from the AIS frames type 1, 2, 3 and 18. In the second buffer, the more 'static' information from the AIS-frames type 5, 8, and 24 is collected. . In that case, this concerns matters such as ship names, ship type, the dimensions of the ship, draft, etc., but also data specific to inland shipping and related to the cargo and the voyage: hazard class and convoy length, etc. This last group of data is derived from the type 8 'Binary Broadcast Messages' with the reference DAC=200 / FID=10 that European inland shipping is obliged to broadcast.
During the collection, the information of the vessels already present in buffer is continuously updated. Periodically, both buffers are emptied independently of each other, then serialized and sent to the MQTT server as a collection of JSON-strings. The interval for sending the dynamic data is set to 10 seconds for the default and 30 seconds for the static data. The connecting element between both blocks is the MMSI of each ship.
For each position update of a ship, the straight line distance (in meters) to the given location of the home base is also calculated, making it possible to limit the number of messages in advance to within a certain radius. The distance is also passed in JSON-position string
The firmware in the ESP32 can be reprogrammed 'Over The Air' (OTA) and watchdogs are active on both the connection to WiFi and the MQTT server. The amount of RAM is about 112k (35%), mainly consumed by both buffers. About 78k of the flash memory is in use (60%). Programming 'Over The Air' requires double the amount of Flash memory, but that is readily available in the ESP32.
The circuit diagram
Downloads
