AngusMcDoon
Well-known member
My boat is an IoT thing. It's joined all the other useless things on the interweb like fridges and lightbulbs. This is yet another pointless project to keep me amused while I'm not allowed out to worry the sheep. What I've done is wired up a cheap GSM modem (SIM800L) which costs about £3.50 on a breakout board to a very cheap Blue Pill dev board which costs even less at about £2 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.com/myboatisathing.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 (you can click on the red square for added japes).
This is the Blue Pill board...
and this is the SIM800L modem with a cheapo disposable PAYG SIM with a fiver 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 GSM connection as unexpected disconnects are, er, expected.
This will all be open sauce once I've got things a bit more organised, and then I'll plonk it on Github with my other YAPPs. I've yet to draw up the circuit diagram schematic; currently it exists only as a tangle of wires on the breadboard and a tangle of lines in my head, so more to come later.
http://bluepilldemo.000webhostapp.com/myboatisathing.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 (you can click on the red square for added japes).
This is the Blue Pill board...
and this is the SIM800L modem with a cheapo disposable PAYG SIM with a fiver 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 GSM connection as unexpected disconnects are, er, expected.
This will all be open sauce once I've got things a bit more organised, and then I'll plonk it on Github with my other YAPPs. I've yet to draw up the circuit diagram schematic; currently it exists only as a tangle of wires on the breadboard and a tangle of lines in my head, so more to come later.
Last edited:
