I hope I chose the right forum for this topic; if not, hopefully one of the mods will move my post.
I’m a part-time marshal at a golf resort. We currently use a system for monitoring the location of players on the course. The system makes heavy use of cellular data transmission, cloud communication and other complexities that make it expensive and often laggy. I’m exploring options for building a new system for this.
My question is, does LoRa seem appropriate for an application like this? The bandwidth need is quite low – each “tag” (a device placed on a golf cart or bag) only needs to submit location data say, once or twice a minute. Needed range would be about a mile. Battery life is not a barrier (the stuff we use today dies during the middle of the day as often as not).
Ideally, I’d like an edge device that reports back directly to a computer in the pro shop, where the data can be read and displayed by a dedicated application. I see no need to go to the cloud or any external WAN for this. Is this feasible, or am I barking up the wrong tree here?
Thanks for any input. I do look forward to this application.
Only? For LoRaWAN that is very frequent. A typical LoRaWAN sensor will only send updates a couple of times an hour, some even once or twice a day.
With Lora that can be done, for LoRaWAN you need a LoRaWAN network server which you can run locally on a server or is build into some gateways. However you will need other software as well to get the data, store it and visualize it. If you don’t want to use the cloud you’ll need to build and maintain that yourself.
For TTN your application would violate the FUP. You could look into using a (still cloud based) private instance. Check www.thethingsindustries.com for options. And keep in mind there are legal restrictions regarding transmissions you need to adhere to as well.
Well, I most definitely don’t want to do that. This needs to be a fully above-board system for enterprise applications.
Perhaps I should clarify what I said: I’d prefer to eliminate the need for the location devices to use a cloud to connect to the office PC. This is mostly because currently every tracker in our system incurs a monthly cellular fee, which seems really wasteful to me. I have no problem using (and paying for) a cloud connection as part of this application; just not for this purpose.
Is there a LoRaWAN server with a serial output that I can connect to the PC? If I can establish a network or even serial connection to this server, I can easily write the driver software to accept and process the incoming location information.
But, I’m still wondering whether I’m considering the right technology for this application, particularly given the normal traffic level you mentioned.
Have seen many Golf course focussed deployments over the years using LoRa and/or LoRaWAN, though as Jac says your specific use case doesnt fit with TTN due to 1) FUP limits and 2) potential volume of end points - a commercial option such as TTI makes sense, though as good neighbours you need to consider the update rates and on air times. As I think you are US based, this is (helpfully in this case) constrained by fact you cant use SF10 or higher SF’s due to US dwell time limits so a system based on SF’s7-9, with some capacity constraints and also faster on air time forcing overall reduced total airtime consumption. The challenge on many courses is topology, ensuring adequate GW coverage and reducing risk of slipping to higher SF’s. The beauty of a bounded environment like a golf course is that once you use LoRaWAN for one use case others drop in easily and essentially for free (subject to sensor costs) once the GW(s) and associated infrastructure are in place. Helping with topology issues and improving SF reduction they are well served by several GW’s in a relatively ‘area dense’ implementation. Impacting this is the location resolution you need/choose. If looking for reasonably precise location placement you need to send more GPS resolution which then drives larger packet size and longer on air time/reduced update rates. If happy with a ‘general’ location you can reduce location resolution reducing packet size and improving update rate for any given SF. What you do want to avoid is the thought of 'just cause legally you can push up to a limit does not mean your should!" - not least as given this is a Long Range technology your sensors will spill over to surrounding areas potentially at great distance. Once GW’s are in place assisting with locating say players/buggies, you can then add other asset class tracking/location reporting on same system - location of plant/equipment (sit on lawn mowers? rollers?, trailers, hose reels, other larger tools etc.), location of staff (golf pro’s, groundsmen, security staff, etc.) and of course environmental monitoring - weather stations (wind indicators), soil moisture sensors, irrigation monitoring/(limited) control etc., PAX counters (crowd control/locations for events etc.) So overall potantially a good LoRaWAN use case/environment BUT with the caveat of do you really need 2 x per minute or even once per minute updates? Play with this tool and see if your use cases can fit with the technology (but as stated please not pushing to the limits!), assume location data is anywhere from 15 (say basic GPS) to 27bytes (some sensors provide additional inputs - battery levels, local temperature, motion etc.). https://avbentem.github.io/airtime-calculator/ttn/us915/15
Not that I know of and I’ve been working with the technology for over 8 years now. However there are gateways with embedded servers that should allow acces using mqtt or equivalent technology. Might even be easier and allows multiple clients to get and process the data.
This comes dangerously close to “if you have to ask …”
LoRaWAN is non-trivial, so in the first instance having the servers run for you whilst you get to grips with the devices & gateways. Then you can add fire-breathing to your unicycling whilst juggling skills.
But for reference, the RAK Wireless range do this in a number of assorted guises - both boxed gateways as well as an installer for their Pi Gateway HATS that will provide you with someone else’s LNS that is not a part of TTI so is not-applicable for extended discussion on a TTI funded forum.
Running an LNS locally is taking your unicycling juggling fire breathing act out on a tightrope - you have one single point of failure and if you run it on a standard Pi with an SD Card you’ll need to obsessively back it up because if you lose the configs of each device it’s a mess. Which is why we love TTN so much as a learning platform & TTI for deployment of commercial setups.