This sounds exactly what I am hoping to achieve. Just bought a couple of t-beams to experiment with for tracking dinghy racing. I really don’t have much time over the next couple of months but hope to look at this in detail later in the year. The use would be on a lake of 60 acres which is well within the capabilities of LoRa. From my short reading of the Meshtastic information, it looks like a potential starting point. I will check back here when I get started and will be happy to contribute what I can.
I’ve been interestingly reading through this, likewise would like to achieve something similar albeit on land. Tracking off road karts racing through fields up to around 1-2km away moving at speeds up to 80kph. Often these locations have very little 3/4G so options to use a phone and app aren’t suitable.
The point around having regular updates to location would be key, ideally sub 5 second updates. Initially I would be looking to try tracking one kart but look to add more in the future if sucessful. Back at base I would then like to use the co-ordinate data to overlay on something like google maps.
Am I barking up the wrong tree or could something like this project help?
Thanks!
The problem is the Lora duty cycle. I have worked out that with the minimum payload, basically just a timestamp and a location, I can broadcast once every 8 to 9 seconds. However, that is using the fastest parameters as the distance will be less than 800m and there is clear line of sight.
If you can cope with lower live frequency and more storage of positions to be uploaded after the race, that would be possible. We don’t need that frequent updates, and dinghies aren’t that fast anyway 
1 Like
Is the LoRa duty cycle not confined to just the LoRaWAN spec? If we are just using the LoRa protocol at the physical layer then aren’t we free to use whatever duty cycle we like? Meshtastic certainly doesn’t conform to duty cycle limits of LoRaWAN.
As far as I’m aware the duty cycle relates to the frequency band, not the protocol. In different countries the off-air period might be different.
1 Like
Here’s a good guide for you to look at:
https://github.com/meshtastic/Meshtastic-device/blob/master/docs/hardware/lora-fcc-requirements.pdf
1 Like
In the UK at least you have the law to consider - in simple terms, each node / gateway must adhere to a 1% transmission duty cycle. At the slower / longer distance Lora rates, the frequency you can send updates is pretty poor. If you want the same channel to be used by 20-30 devices not clashing, its very very poor!! LPWAN tech is not really designed to be updating every ‘x seconds’ its more like ‘read the gas meter once a day’ type stuff.
1 Like
Duty cycles will be the limit, you could be greedy and take up the specrtum your using but that will get you noticed pretty quick. More municipalities and utility companies are using LoRa for their services so they notice when someone is hoggin up all the duty cycles.
Am working on a similar project which involve outdoor weather buoys on mesh lora network within same outdoor scope. Would it be possible to use wifi as part of network? When devices are out of range from wifi then is switched over to Lora in order to allow for more network traffic. Obviously down side would be battery usage with addition of wifi. How possible would it be for meshtastic to do this?
“would be possible” is too broad, specially in open source. at the current state its not possible, and it probably never will be.
Im curious how the mesh plays into airtime. If i have 5 nodes but they are all so far apart that they can o ly hear 1 node… technically your air time utilization is way lower than if they can all hear and reach other causing more congestion.
You are correct.
If you have nodes A and B transmitting but C is out of range, then the utilization as seen by C will not include A and B.
I’ve just started to think through this exact use application for our races. Am looking for any advice/counsel
Hello i have a similar idea to use this for tracking keel boats during races with an extra nodes mounted in a nearby lighthouse and one at our club dock hoping that this mesh could handle enough boats (nodes) likely each division would be up to 20 and the repeaters would be set up for each division
So I’ve been poking at this for a month or so. For background, our race course is roughly a rectangle with 3 mile diagonals, about 1 mile offshore, where I’m planning on putting a base station.
Current thinking is to put TBeams on buoys on each end of the finish line, and then addtl units on each boat to capture the timestamp when a boat crosses between them. Buoys get moved depending on wind direction and strength, so location changes race to race, but the simplest way to think about it is we want to capture the timestamp when 3rd TBeam crosses between two others. Not so worried about the duty cycle conversation above, as I really only care where the boat is when it’s 50-100 ft from the finish line and can back way off on the refresh rate other times.
I have a couple of TBeams up and running and can send text messages back and forth between them, so that simple part works.
Concurrently, I’ve written the code in Python (just to work out the math and at least one option on logic) that detects when a boat (or TBeam) rounds a mark or crosses a finish line, and records the timestamps from GPS lat/lon.
I’ve been stymied by something I’m sure will be totally obvious in hindsight, but I simply can’t figure out how to capture the GPS coordinates from the buoy or boat TBeams. I have a feeling this is really simple and straightforward, but and I just have some mental block. I’ve been tempted to dive into MQTT, but unsure if that’s necessary.
Suggestions?
Figured it out from examples in Meshtastic Python library examples. and yes, it was simple. Thanks Raldi
Can you share your code? You’ve solved some problems I am facing. Thanks!
-David
Oliver, are you making progress?
I plan something similar for dinghy sailing in Wellington. NZ.
But I only want to know the GPS locations of the 6 mark Buoys we usually lay for club racing, so we can calculate correct VMGs for Race Management manuals etc.
And the locations of our ~6x rescue boats during racing so the Race Officials in the start box don’t get confused as they are all painted yellow and look the same from 2km away.
We have a good , elevated base station location, and the buoys and boats should make a ~12 unit mesh that will reach the base. Race course axis is rarely more than 0.6nm (1.1km ) and the closest buoys are within 0.3nm ( 600m ) of base. Speed is not important. There will be no interation with any of the afloat units. Just mounted securely with GPS and LoRa antennae doing there jobs with easy resealing after battery charging. We use the big blowup cylindrical buoys which have hardling straps across the top.
I would be interested to hear your progress advice.
If the buoys are not moving , you dont even have to attach a (waterproofed) Meshtastic device to it !
when you place the bouys by boat, you have 1 M device (can be without GPS) per bouy with you, let it find (or give by app) position and set position to fixed.
The M Will show up at this position from now on, even if its somewhere else.
you can leave the bouy, and take the M device to the Race-Managment Office 
you might even switch these devices Off, they will still show in the map. of devices that have seen them bevore.
only thing, if one of the bouys comes loose and goes with the wind, you wont see its “new position” to find it
even more simple, not using a M device for the bouys, you can set Waypoints in the app, that show up in fixed positions , little red flag in android app.
that way you save a lot of bandwith, since bouys positions are fixed, they dont have to send position very often (every 20 minutes or so would be fine). that way you can have the rescue boats post positions more often! like 30 seconds or so…
maybe long-fast
better medium fast
or maybe even short-fast would be the channel setting to have that many position updates