Seatalk instruments' data to website - open source project

[AngusMcDoon]

My boat is now an IoT thing. It's joined all the other useless things on the interweb like fridges and lightbulbs. What I've done is wired up a cheap GSM modem (SIM800L) which costs about $4 on a breakout board to a very cheap Blue Pill dev board which costs even less at about $3 and connected the lot to my Seatalk network to read boat data. The code on the Blue Pill reads the numbers from Seatalk and wraps them up in MQTT messages, then sends them off to a public MQTT broker. Now the data are available out there anything can just grab it and do what it wants with it, like this web page I knocked together with a bit of rough and ready javascript...

http://bluepilldemo.000webhostapp.co...tisathing.html

(Note: has to be http on that link, not https. It's to do with the lack of a https websocket interface on the Hive public MQTT broker)

The web page shows what's coming in over Seatalk. Clicking the button displays a map showing the lat/long data as a red square.

This is the Blue Pill board...



and this is the SIM800L modem with a cheap disposable PAYG SIM with a few $ of credit...



The SIM800L has a particular power requirement: 4.2 Volts and up to 2 Amps momentarily, so it needs a bit of a power supply jiggery-pokery to enable that. I've used a LM217 wiring it up as to its datasheet.

The software on the Blue Pill sounds simple enough - go round in a loop reading the Seatalk data, package up some MQTT messages, send them to the modem using a TCP socket connected to the broker. However...

- Seatalk is simple enough. I've whipped that out of many other pointless projects.

- MQTT is a simple protocol, and there are libraries out there to do the packaging, but they are all too big for the limited STM32F103C8 on the Blue Pill board. I only want a QoS of 0 and the published libraries all provide the full range of QoS which bloats the code. So I got the MQTT standards out and rolled out my own code to create the messages. That's a bit of a kerfuffle but not too onerous.

- The final bit it the hard bit - talking to the modem in a reliable way. Modems use a command set called AT, and despite it being only human readable messages pinging backwards and forwards along 2-way serial lines, it's the most awkward and unpredictable protocol to implement. Writing to the modem is ok, but reading from it is problematic. The commands are irregular in format, it's highly asynchronous, and the command/response sequences can go many ways - you just don't know when you are going to get what. Two further difficulties are that the complete AT command set for a modem is huge - many thousands of pages of documents, and non-standard. Some basic commands are common across manufacturers, but most are not. As the code doesn't know what or when the responses will be or will arrive they are buffered using DMA and are processed when processing time is available. This benefits from the use of a separate thread so FreeRTOS has been used as an OS. This means that the code must be made thread safe as there may be multiple threads trying to access the modem, but there's only one modem. The internal server concept has been used with the modem running as an internal server in its own thread with queues to communicate AT commands and responses to the client threads.

The code on the Blue Pill works, but could (and will be) better. Currently it's not fault tolerant. If a connection to the broker fails it all falls over and doesn't attempt to reconnect. This is not good for a socket going over a mobile connection as unexpected disconnects are, er, expected.

The project is on github here...

https://github.com/miniwinwm/BluePil...k_MQTT_Website

There's more information in the readme.txt there.

MIT license - do what you want with it but don't claim you wrote it or try to restrict what I can do with it.