Hi all,
Im planning to install a gateway to support thethingsnetwork because I think its great!
Im pretty new to the whole lora thing. Im partucular intrested in lora gps tracking.
But one question what comes when looking for such device. For example
Is this device bound to be used at a specific loranetwork or are the gps updates received by any gateway of any lorawan within range? Can I use it with thethingsnetwork for example?
Another thing is what I dont quit understand is. if I have a loraGPS which communicated with thethingsnetwork, how do I get this from thethingsnetwork to my linux server.
Do I need to call a API or something @ my server to extract the data from the sensor?
Your developer does have a point, assuming you adhere to the fair use limits of 30 seconds air time per day.
A TTN GPS location packet is 22 bytes.
At SF7 a GPS location packet takes 56.6mS of airtime and allows for 30000/56.6 = 530 packets per day.
At SF12 a GPS location packet takes 1319mS of airtime and allows for 30000/1319 = 22 packets per day.
So if the vehicle is always close to a gatewway then the tracking might work, but if its not and the node goes into SF12 mode, the number of packets allowed is so low as to be not very useful at all.
The fair access policy of TTN is stricter than duty cycle limitations. You could check the Professional or Enterprise versions of TTN, maybe they are more relaxed (but not totally).
Yeah I understand the issue. There is a limited amount of airtime so a limit amount of data we can sent. But let me put it another way:
Lets say this kind of tracker is important to trace objects in case of emergency. Think about theft, or kidnapping. A few location updates a day might be enough to solve the case. Especiallyh when the object is not moving.
I have also read about Geohasing todo compression on the GPS location.
you could think of building a node that sleeps whole day, but wakes up every midnight and send a status byte.
some bits in that byte represent :
battery full
battery halffull
battery almost empty
object didnāt move
object moved
so once a day one byte, that is for static objects (like a container) enough and saves a lot of energy.
however, when the object has moved, it switches to a regulary update inclusive gps location and set an alarm bit
That comment suggests you may not appreciate what you are getting for free.
There may well be potential applications for TTN requiring higher bandwidths or data handling capacity.
If you think there is a market for these applications, that has not occured to anyone else, then perhaps set up your own network and make lots of profit ?
There are many companies using LoRa based solutions for tracking apps - Vehicles, Plant & Machinery, Lone Workers, Animals, etc.
There are many companies using LoRaWAN based solutions forā¦
TTN Community FUP limits scope (even as yet unenforced though as @LoRaTracker says you should plan for it just in case, though I would hope that as we (the users) populate more GWās TTN may see fit to relax any enforcement levels once they are policed) but doesnāt eliminate option for GPS trackers on the network. If tracker always @ SF12 thatās a problem but depending on tracking app and developer choices and also the ādensificationā (credit Francois Hede) of the network (how many GWās in range/locality), node will often have the chance to run at lower SFās, either through ADR (yes I know not ārecommendedā for mobile devices, but can be used with care depending on application implementation) or developed implementation.
It will also depends on where you are in the world and the purpose of vehicle trackingā¦ e.g if used for recovery after theft/hijack then in many places the local law enforcement folks are more interested in the recovery act than the issue of RF regs breach (think S.Africa, parts of S.America etc.) if device Tx ERP is hiked/spiked well above nominal limits for the short duration (minutes, hours, poss limited duty cycle bursts over a couple of weeks even to conserve battery?) imagine SF 7 or 8 burst at +25/27dbm instead of +14dbm <Note I dont condone deliberate reg breach - just saying check local attitudes & practices >
Consider reducing resolution & compressing to reduce payload - perhaps increasing every (10/20?) readings to update on accuracy, consider dropping Altitude or limiting resolution? reduce updates rate unless overridden by external trigger - e.g. illegal movement/theftā¦a few rapid high res updates, perhaps triggered by OTA application command, if not sustained may assist in recovery in case of theft/hijack and do so before breach of duty cycle &/or fair use policy anyhow
LoRa(WAN) can potentially support LoRaLoc type location based services (though perhaps not on TTN community network?) - albeit with variable resolution (street block level) - perhaps in dense GW environments down to 20-50m or typically with fewer GWās perhaps ~200m+ā¦GPS can then be used as an enhancement and on lower update ratesā¦again will depend on use cases
Private nets and some public nets donāt impose the same FUPā¦
ā¦so please donāt write off LoRa(WAN) generally based on a few forum posts without digging deeper into your own needs/use cases and the various optionsā¦ Good luckā¦
What Iām saying is that cost of the Lorawan devices seem very high when compared to the proven GSM devices that are already āmainstreamā out there.
If you use Lorawan, you also need the TTN gateway infrastructure in place, and not only that, but there is substantial support for tracking and plotting these GSM devices in the cloud already
Hi Pete, I recall you showing me some of this kit during the visit and really should follow up/investigate further for some near term price sensitive use cases. Medium & longer term the problem as I see it is one of maturity, these things are cheap as we are at the tail end of 2G services and cost has been driven out. LoRa(WAN) is still ramping and maturing with cost still to be reduced and volumes ramped. Also battery life is important - on a car, truck or even motorbike with a decent sized battery it is not an issue but tracking a bicycle or other assets - many of which have no specific power supply - as part of the ātrackingā class of apps generically will struggle.
In addition for new product & service introductions including vehicles you need to consider the design life of a product. Designing today for 2019/2020 market intro with a 10+ year product life (and in the case of automotive looking at 2023/2025 intro with a 15+ year end product life there is no way you consider designing in 2G products and even 3G gets questionable! As @Borroz says 2G services are already being turned off and many more are planned for exit in 2019-2024 (I think UK looks like 2022/23 EOL for 2G & GPRS), and Iām hearing many places already looking to turn off 3G 2027-2032ā¦2G is now what 25 years old?..where will LoRaWAN product pricing and development be in 15 yet alone 25 years time? (and follow-ons & enhancements?).
The supporting infrastructure, back end services, device on-boarding etc. will all evolve and expand rapidly in the coming months and years (I recall you had some good/promising thoughts in that direction also ) and we should all remember that good though it is TTN =/= LoRaWAN market and ecosystem, just a small but well loved part of it and one that isnāt supposed to be used for mission critical use cases as many have stated on other forum threads. What happens in other LORaWAN network deployments, especially wrt standardised products and volume ramps & where they can be readily be reprogrammed, re-targeted and on-boarded to TTN will also help its users with respect to driving down cost and improving usability.
Hereās to an optimistic LoRaWAN enable futureā¦
