Assuming ‘non ideal’ antenna conditions likely in a personal or non fixed tracker, higher SF might be expected. So, even an optimised GPS encoded location packet, with the 13 byte overhead, could well be on-air for around a second or more. Given the 30 secs / 24 hour fair use (not to be confused with the EU 1% duty cycle) that means around 30 fixes per day. This would be one fix every 48 mins for an ‘always on’ dumb tracker, or perhaps a fix every 15 mins for a ‘movement activated 7 hours a day’. Neither seems real world viable. Is asset / person / vehicle / animal tracking just not a good use case at TTN, or am I missing something?
You’re right, such a thing is not viable in base form. And keep in mind that in many places second long packets aren’t even allowed!
But you can get a bit smarter. You don’t have to transmit the full fix, just the last digits to combine with the general location that can be determined (at least in areas of interest) from which gateways were involved. Make sure you’re using a very efficient representation, too!
But indeed, tracking with a limited coverage, limited capacity network is only borderline viable.
Mostly I’d say no unless you have a really well thought out use case based on firmware as suggested above but also bearing in mind that it relies on gateways being present to hear the uplinks - so the big van full of iPads taken out of the area isn’t going to be tracked any time until it hits another population centre or happens to come across a random gateway.
For tracking people, if they fall over and are lying on the tracker, the signal may never reach anywhere ever.
But if you want to track high value pallets in a van (that is tracked on GSM) with LoRa phoning home within the compound the state of the pallet & where it is to about ~2.5m just in case the forklift driver has put it in the wrong place, then it is a good solution - local gateway so shorter data bursts and only needs to transmit when moved.
So your mileage may vary.
Slightly, on-air time at SF12 would be circa 1417mS, so 21 fix packets a day or once every 68 minutes.
If you want to send fixes more often, then you need to pay for the access, which is reasonable enough …
Maybe this year I will try a firmware to send with lower SF when the tracker is close to a gateway. This of course is complicated for various reasons. A) If the GW goes offline the tracker must be notified, b) or if a new GW in a area c) add your problem.
I think the main solution is more gateways. For tracking in urban areas I think every 1km we need a GW.
Generally, maybe SF10 is pretty good with mediocre number of gateways at ~50% success.
For TTN to offer ‘free’ GPS tracking you are probably right, but that density of gateways would be very rare, which rather negates the purpose of a ‘tracker’
‘free’ GPS tracking is probably not possible given that someone else has to pay for all the traffic generated to be processed.
@LoRaTracker You suggest that we have to forget dense GW’s? I hope they don’t create a problem.
I don’t get your second statement. In which traffic you are referring? From GW to TTN? Or something else?
This may be a bit of a translation issue - having a gateways every 1km would be rare as in unlikely.
There is no such thing as a free lunch - someone somewhere has to pay for the gateways, the electricity and the internet traffic - so it may appear that you could maybe possibly run a tracker for free, you are just getting someone else to pay for it.
Which, on a community network, is a bit marginal. If I had a gateway that was picking up a pile of socially useful sensors and they’d benefit from better coverage, I’d be there to find a way. But if it’s just people running round wanting to have their whereabouts logged, not so much.
As I said above, there are some use cases where LoRaWAN is a no brainer for tracking. But most of the typical use cases are suspect at best and sometimes down right dangerous. How so dangerous? Because people relax more when they have a safety net - but if the safety net is more like wet tissue that works well on a demonstration but doesn’t work in real life, that’s not good.
Ok, I just wanted clarification. Thanks.
In my city with BAD coverage the most distanced GW’s have 2.5km between them. I think it’s feasible to add some in between. In some areas I have 50% success (SF10) in some areas less than 10%. ttnmapper is really helpful for a community to find the “black holes”.
It’s not free, but LoRaWAN / TTN GW’s are very-very cheap to run. If a community* adds one or two every year it’s relatively easy to have a dense network. Electricity is so little (not noticeable) and network traffic even less (not noticeable #2). Cost for those two it’s not a problem (unnoticeable #3) . The problem is the installation and the cost of hardware.
* by community I mean that we can install GW’s on friends houses. Electricity it’s not a problem, or internet. 
Yes I agree that it’s not a reliable solution. But currently my GPS tracker runs 3 months and the battery is at 50% Set-it-and-forget-it.
To me it’s very interesting if schools, universities**, public buildings have LoRaWAN GW’s.
** Realy shame that not all universities have LoRaWAN GW’s
(excuse my bad English)
I understand what you are saying, no free lunch indeed. With that said, shouldn’t a GW owner at least get a free drink?
I did not say that at all.
The required density of Gateways to allow general reliable GPS tracking at say SF7, is very rare and is unlikly ever to happen.
1 Like
If you had a city, say 10km square, with a gateway every 2.5km, then the city is covered by around 9 gateways.
To have a Gateway evey 1 km would need around 64 Gateways, so if ‘a community adds one or two every year’ it would take 25 years or so to get to 1km density.
1 Like
Sadly that is not the way the Community network works i.e. deploying infrastructure =/= elevated privaleges and increased use…
Probably just as well not, or I might be borderline alcoholic by now! 
1 Like
@LoRaTracker I don’t get your calculations.
10km square is 1km x 10km? So, 10 GW’s is a good start but not ideal (dense). I suppose most of cities are not flat.
My city is around 70km square. When I travel 9km’s straight, 3-4 GW’s give me around 50% “deliverability”. I suppose with 3 more I will have around 75% success which I found pretty usable. With 6 more (every kilometer) I think even with lower SF7’s we can have usable tracking.
I said 10km square not 10 square km, as in sides of the square area are 10km, so 100 square kilometres.
Stick the tracker in the boot (trunk) of a car with a person on top - that’s the acid test!
6 gateways in that area would mean that each gateway, even if placed optimally, would need to cover 70/6 = 11.66sqkm, so each gateway would need to provide a coverage range of 1.75km or so.
1.75km range at ground level in a city @ SF7 is maybe a bit optimistic.
But rather than theoretical calculations perhaps say what distance coverage you get at SF7 with your cities gateways ?
No doubt if you could install a great deal more gateways in a city then you could maybe make tracking viable @ SF7.
In reality for most locations using TTN for GPS tracking is really planning to breach the fair use policy.
1 Like
El Capone style 
In my efforts I saw that with SF7 I have 200m range to have safe delivery. So dense GW in my view is every 200m. I agree with you, this is very rare. But with GW’s every 1km, you can transmit with SF10 and occasionally with SF7/8/9.
I experienced an exception to 200m “rule”. A very “tall” GW is missing many transmissions even in <200 meters. Maybe noisy environment or something else.
I repeat: You can use SF10 and switch to SF7/8/9 if you are close to a GW or in “white zone”. Also in my efforts I saw very rare cases that GW’s that are 7-10km away are catching my signal (currently testing with SF9). So, again in those areas you can switch to SF7-9. I even will try to use FSK when close to GW. This is something unstested. Also you can transmit only when necessary, not every X time.
The TTN fair usage policy is easy to follow. Don’t transmit with SF11, SF12 and don’t exceed the 30secs limit.
My payload is 7 bytes and I transmit: location, position (stand, fall), gps fix (on/off), battery level (4 states), direction (accuracy 24 degrees) and speed (accuracy according to needs), quality of GPS fix. If the device has the same position (50meters). I trasmitt only one byte with the above info minus location but with full battery info (0-100%)
Just re-checked my numbers: (SF: Success)
SF12: 71%
SF11: untested (covid-19 quarantines not helpful)
SF10: 68%
SF9: 62%
SF8: 41%
SF7: Untested (covid-19 quarantines not helpful #2)
Those are not scientific measurements, just traveling 9km’s with differents SF’s with the tracker. The tracker was transmitting in RANDOM / unpredictable times.
And how will your device know it is close to a gateway?
Hmmmm, no fix is like saying “on planet earth, last seen in the vicinity of” and is made somewhat redundant by the quality figure.
Maybe roll that in to one bit rather than a whole byte. What do you report after they have fallen. How can you tell they have fallen. And the fact you have “fallen” in your payload turns this from a bit of ‘too and fro’ and some discussion repeated else where on the forum in to a “you are kidding”.
Hmmmmm, you get two free bytes at SF7, one at SF8, four at SF9 and one at SF10. But you have the port numbers to use as well. However unless something really radical happens to battery life, it’s not really needed on every uplink - there are techniques to transmit it as it changes regardless of the payload format in use at the time of the uplink that I have but commercial in confidence.
Apart from the general consensus that tracking using LoRaWAN has some very specific useful use cases but not as a general tracker and certainly not to track little old ladies and if they have taken a tumble, you are going to have to get very scientific if you don’t want your plans shredded on here.
If you do go ahead, can you tell us which papers to look out for in your area so we can read about the court case!