Live tracking of dinghies during race

Hello, I’m currently working on a project for our sailing club, and a friend pointed me towards meshtastic. I’m not really a DIY electronics person, but so far it looks like a close match; I thought I’d briefly outline our plans, and would be grateful for any feedback, especially whether meshtastic would be suitable for this.

We are racing dinghies on a small reservoir in the centre of Birmingham (UK). The idea is to equip each boat with a GPS tracker, to allow not only live-tracking for the purpose of running the race, but also for replays and post-mortem analysis (eg identifying where one boat is slower than another; this can be used for coaching purposes). The reservoir’s maximum dimensions are 800x550 metres.

There are commercial solutions, but they use SMS for data transmission, and are quite expensive. Our main feature is that we sail in a restricted area only, so SMS seems overkill. We have around 20 boats in a normal race, up to about 30 boats for bigger events. The maximum upper limit will probably be 40-50 boats. We have 7 marker buoys spread around the water which indicate the course; each of them would also have a tracker on it, so that we can check boats sail the proper course. They would also act as further mesh relays.

Each tracker would (after being switched on) regularly send its position to the mesh. A ‘base station’ on the shore receives the positions and stores them in a database for later processing (on a web server); at the same time the boats’ positions would be plotted on a screen. Each race lasts just over an hour, so power is not an issue. The trackers would need to be waterproofed, as boats do occasionally capsize (through they wouldn’t be underwater for very long, and not very deep). They would not need a screen, simply a couple of LEDs to indicate operating status. You switch them on, and they start broadcasting until you switch them off. Each device would have a unique id to link them to a boat. No pairing with phones would be required.

So my first question is whether meshtastic would be a good match for this. My feeling is that it would be ideal for this purpose, as we have a smallish number of units in close proximity, and only for a short duration at a time, and a very simple and small payload for each message.

Second, what would the transmission rate be? If each tracker sends out its position every n seconds, how low can n be without swamping the mesh?

Third, how accurate is the location information? It’s inner city, but under an open sky (except for the odd clouds). Would this typically be in the range of metres, or tens of centimetres? If we have a start line defined (with two marker buoys with trackers on), could we reliably identify if a tracker had crossed the line at a given time?

And finally, as I mentioned, I’m not really an electronics person (though I do have a soldering iron), so how easy would it be to assemble the units and use them in a race situation? The software side would not be an issue.

Thank you very much in advance,
Oliver

1 Like

That’s a really cool use case. I guess the thing would be to get the device small enough and in a waterproof case with a battery that can last the length of the race. I’ve only just started playing with my t-beams but I’ve found that the GPS acquisition to be quite slow/weak. I do get 7 satellites with a proper external antenna though.

I’m down in the Isle of Wight, so plenty of sailing around here too :slight_smile:

1 Like

Thanks! The GPS delay shouldn’t be a problem, as we would hand out the trackers before the race, and the participants would fix them to their boats (probably with a velcro strap) – this would usually be ten to fifteen minutes before the actual start of the race, so plenty of time for all trackers to acquire the satellite locks.
As for the case, I guess a 10x7x4 cm box would be about the largest we could do without it interfering in the sailing.

The smallest weatherproof case I’ve found to fit a T-Beam is about 11.5x9x5.5cm if you exclude the mounting ears. You can get these without the mounting ears, but if you intend to attach it to something, I really recommend getting an enclosure that’s made for that.

You end up with something like this (I think you can click the image for a larger view):

I’ve found that once a node acquires a GPS lock, re-acquisition is much faster, so if you’ve got all of the nodes out with a clear view of the sky prior to the race, you probably won’t have a problem getting a good GPS signal once they’re installed, as long as nothing is on top of them blocking the signal.

Another issue will be how frequently the nodes send position reports. I think by default, meshtastic nodes report their position every 900 seconds, every 15 minutes. I assume you can change this by programming a custom config using the Python API, but I don’t know of a way to change the position reporting interval from within the Android app. Hopefully someone else more familiar will chime in on that.

With 7 buoys and anywhere from 20-50 boats, that’s 27-57 nodes on a single mesh. Unless you use one of the faster (but shorter range) channel settings, I think you’ll be stretching the bounds of how many nodes a mesh can support. I’ve never had more than 4 meshtastic nodes on a single mesh, but I would assume the overhead grows exponentially.

If you’ve got some time to investigate this, it would be make great case study. You could be the one who proves larger-scale meshes are possible, or at least what the practical limits are.

Thanks, that case should work. The idea is to attach it to the front of the mast above deck level, so it’d be out of the way and also have good GPS reception.

We would initially not have more than 20 boats, the 50 is a somewhat optimistic projection; but I guess shorter range should be fine, as the maximum distance of a boat to the shore would not be much more then, say, 600m, and you’d have the buoys and other boats in-between to mesh. Alternatively we could run multiple meshes, as the boats don’t communicate their locations to each other, so it doesn’t matter if they are on different channels. If that is how it works :slight_smile:

The reporting interval: I would assume that the interval can be changed to any setting, so my main concern is overloading the mesh; if every boat sends it location every second, that would be a lot of messages. Now the buoy nodes would not need to do that, but if a boat sails with a speed of 5kts, that’s about 2 metres per second, so you want to have fairly frequent updates. Maybe it can vary dynamically with speed of movement, as it most likely will not be constant throughout. And different boats will be in different locations sailing at different speeds, so that might then balance out.

I’m happy to go with this; it’ll probably take a few months to work on it, with delivery of units and set-up, but we’re not thinking of using it until Summer 2021. We’re sailing all year round, so could do extended trials in winter. But I’m definitely getting the feeling that meshtastic would be a good solution, both from your responses and from the other posts on this forum!

I’m also working on a project where the nodes would send frequent position reports, so I’m very interested to see what you find out in practical trials. Based on my experience with my little 4-node mesh and dealing with large WiFi networks, here are some things you might start thinking about while you wait on the hardware.

I’d try to decide what the longest useful reporting interval would be and start there. Even the SMS-based trackers I’ve used can’t report any more frequently than once every few seconds. I’m pretty sure the position reports include heading and velocity, if that helps you with somewhat less frequent reports.
Setting the position report interval based on velocity would be very useful, but I don’t think that exists in the firmware right now. If you’re a developer, that might be a good place to contribute (or to recruit help).

Even using the faster channel settings, in practice, the nodes currently take 1-2 seconds to send each packet because of the built-in delays. I assume these delays are for packet collision avoidance, but I haven’t really looked into it. I seem to remember a post here talking about whether or not it was possible to shorten the delays based on the channel speed.

The conventional wisdom around here, based on @geeksville’s much-appreciated math, is that a single RF channel can support up to about 30 nodes. But I don’t think that takes into account most of the nodes making frequent transmissions of anything other than network management packets.

Sorry if this got long-winded, I get excited when I see projects with similar goals to mine.

No problem! Good to have a detailed discussion about these issues! I am indeed a developer, so that’s something I would be happy to work on.

As for the reporting interval: I guess we don’t need it all ‘live’; if we can interpolate with heading and velocity, we can probably guess/predict where the next location will be, and either not send a position (if that can be done on the device) or lower the interval and store the positions on the device. Once the race is finished, the ‘base station’ could send out a message that triggers the tracker sending the backlog of suppressed messages for the post-mortem analysis. We could also just send a ‘delta’ to the previous location, which could be smaller in size. No need to always broadcast the complete location when we already know that the tracker will be within a very specific area.

In fact, not sending every reading would be a good way of keeping the traffic down during the race, but still have all the information available afterwards. The base can easily send out signals when the race starts and ends, so that would define when we need to record information, and the nodes can then start broadcasting the readings they didn’t send.

Initially I guess one channel would be sufficient, but I would think that we’ll aim for several, just to be future-proof. We have three buoys that are near the shore, and three on the opposite side of the reservoir; if we assign two each to different channels/meshes, then we should still get good coverage even if all boats are clumped together in one area (as they will be on the start line).

So what exactly would I need?

  • 1x T-Beam V1.0 w/ NEO-M8N (apparently has better GPS?)
  • 1x waterproof case
  • 1x 18650 battery

One for each tracker; would I also need a waterproof USB connector cable? I understand the battery can be charged on-board by plugging it in?

I would also then need a further device for the base (which doesn’t need GPS, but might be useful for real-time processing). That would need to link to another machine that receives the messages and uploads them to the web. We’re already setting up a Raspberry Pi to drive the starting signals, so ideally we could combine the two tasks, or get a second Pi. To begin with a laptop would be better for testing etc. Could I simply connect the ‘base’ via USB (or bluetooth) to my laptop to read the incoming messages? Also, I guess I need one base per channel?

As I said, writing software to do this is not the problem; my difficulties are on the hardware side :slight_smile:

If you had too many boats out you could divide them in to sub groups on seperate channels that would avoid saturating the mesh.

For the base unit you could just link a tbeam or something like the Celtic non gps boards via usb to pi / laptop. I’ve tinkered with the python interface and it works well for extracting the packets then you can store the data on whatever format you need.

One issue I have is that I have to connect me tbeam to the pi via a powered usb hub or the pi (zero w and pi 2)reboots. Which is strange as the power tbeam uses should not be an issue.

@Oliver

Neat application!

Have you thought about separating the ‘live’ updates and ‘post-mortem’ reviews into two separate spaces? As in, if during the race you only want to have a general idea of where boats are on the course then you only need to know their position every few boat lengths, or probably 10 seconds give or take. Then, for the more precise data you could be storing the by-the-second data locally on an sd card. Data loggers are so inexpensive I don’t see this being that much more per device to implement.

Once the race is over, if you truly feel like it you can have each node individually upload their logged results to the central database. It might take a while but I assume there is going to be some time between the end of the race and the post-mortem analysis. Something like once the race is over, the official sets the mesh to a ‘race over - data retrieve’ mode and each node then gets permission to upload its logged csv in a more efficient manner than streaming it.

I have thought about doing something like this for my application (monitoring livestock) since I also don’t want to fill up the mesh with lots and lots of not-quite-necessary data. I was thinking in terms of ‘heartbeats’ and ‘charts’ like a hospital setting, but its the same idea.

I’ll definitely be watching what you do since it seems really interesting.

As an aside, I really like the idea of seeing a bunch of little boat sprites whirring about on an image of the lake live on my phone. As a spectator that could help a lot of people understand what is going on (I think).

Willow

2 Likes

This is a self-contained device with GPS and LoRa that might have enough RAM (20kB) to run meshtastic. The only missing radio is BLE, but you could likely commission these onshore using the USB interface?

I ran into this device while looking for solar/repeater devices to try as per this thread.

Are you sure the RAK7200 has logging capability I don’t see an mention of an sd card

Yes, the different transmission ‘modes’ is definitely one solution I’m thinking about. The complete data at the end can probably be heavily compressed, as there won’t be that much differential between subsequent data points.

And displaying the race on a screen with annotations (where is each boat on the course, who’s in the lead, etc) is also one important application.

For the distances you seem to be talking about LORA Mesh is likely over kill. Elevated antennas are all you should really need (as high on the boats as reasonable, and the base station antenna well above people and structures.

A few suggestions regarding data:

As @Roguewillow said, log to local storage if the data will have any affect on the outcome of the event for reliability and redundancy.

Considering packing more than one location update in to each transmission. Maybe each device transmits every 30 seconds, but the payload contains three locations in 10 second increments.

For the given range, and use of the mesh, you can likely use faster spreading factors and lower the transmit time of each payload.

Lowering the max number of hops from three to two, or even one could still provide reliable reception while lowering over all mesh utilization.

Use Lon and Lat offsets to minimize pay load sizes and transmit times. As an example, say the center of the event is 12.345000, 98.765000 an offset could be transmitted as +30, -6

Where this topic gets real interesting is for events where you are tracking teams over a larger area without anything resembling line of sight.

Has anyone considered spinning up a sub topic and project specifically for events like this? I think there is enough overlap to be ‘tied at the hip’ but this kind of thing would probably work best as a module using the Meshtastic API.

Right, so all the nodes talk directly to the base? That could be higher up on the shore. This would make things a lot simpler, and would also reduce traffic. We will always have line of sight, as our water is not that big.

And yes, there are lots of ways to compress the data, given that it is in a limited area. Sending multiple locations in a single message would improve the overhead/payload ratio, and we don’t need live updates that frequently.

That is my next question: would I need to fork the firmware for this and implement my own processing module? Ideally I would want to be able to operate each node as a state machine, which switches states when it receives a message from the base. As in, shortly before the start move into the ‘ready’ state by powering up the GPS and get a lock, then a minute before the gun move into ‘race’ state, where location updates are sent to the node, and after the race into ‘flush’ state where all the logged data is transmitted that wasn’t sent during the race.

It would be a bit like Erlang’s message passing model, where each node has a mailbox and reacts to incoming messages. If it is possible to have this as a module independent of the firmware, that would be useful, but I have no idea how that would work. I guess it would be flashed into the EPROM? Or could it be loaded into RAM on startup from a server? My hardware knowledge is a few decades out… :slight_smile:

If you don’t need mesh networking, text messaging, Bluetooth and use of phones to track nodes and send receive messages that are encrypted then a totally new project that just treats nodes as state machines, and has a different firmware for the base station would be much easier.

BUT… There are people who do want some or all of that, AND what you want so I think it would be great to develop an add-on that can accomplish this.

I specifically mentioned the API and doing this stuff in a module so a fork of the project would not be necessary.

I think this is more complicated than you think. So many considerations. How much time and budget do you have?

Before you embark on this, are you aware that there are very good, existing, free, smart phone apps that do very much of want to do?

Check out RaceQs (I am surprised that your sailing club don’t use it already)

Just equip each boat with an old smart phone in a water proof case and you are ready to go. I know that it is not in the DIY spirit of things, but with no development cost or time, it is something that you should be aware of.

Yes, I am aware of it, and have used it myself. It doesn’t really work for us, though.

1 Like