Amsterdam - GPS Location Tracking, wearable, suggestions?


Hello everyone!

I'm new to LoRaWAN, but interested to track a wearable with this. The ultimate idea is to create a portable wifi-hotspot, that people can connect to. (hotspot part) The location of this wearable can be followed online (gps part).

For the GPS part, I was thinking to use the Sodaq Tatu + Lora Bee + GPS Bee for this, ( & ) but since i'm new to the LoRaWan technology I have a few questions:
- At what rate can I get measurements from the GPS over lorawan? Will it be often enough to 'realtime' follow a moving person?

Hope that one of you can help me out!


Probably not, see (klick "see all" to see the presentation) around 50:30 so skip the first part.

For the dutch viewers:


I would go for the ESP8266 + hoperfm

I think you can make it for about $20,- (battery included). No GPS module needed :D.

Software is still alpha, look at my posts...

Realtime following is not allowed. Its to much data..


I suppose it depends on your definition of 'real time'. With the restrictive 30 sec airtime per day but 0.1s sending time for packets (probably even shorter?) you can send the location every 5 minutes.

(Brendan O'Gorman) #5

I think there are good opportunities at local level gamification, zone based by a node perhaps, sweepstakes, bingo, environment hunts (like the Easter egg hunt) .. things that can be that towns IoT things or activities.. from a user application level. For those that end up doing social based "activity" apps like this, then perhaps only a short step over to IoT-based commercial marketing opportunities with local merchants and brands. (in terms of tying into trackables, wearables)

It's also interesting when you consider the robust sensor packages people have in their smartphones, I can see this tying in later towards local crowdbased sensing and data collection initiatives that compliment fixed device sensors, and stuff like that..


First of all: I do think this is an interesting use case! It would also make a great showcase to convince people about the possibilities of LoraWAN. I just wanted to make sure people aware of the limitations (besides obviously bandwidth).

@turiphro About the mentioned 0.1s: Looking at the Lora Modem Design Guide that would limit our ranges in bandwidth and spreading factor and thus link budget / sensitivity / range (the mentioned 'time on air' numbers are for a 10 byte payload).

Looking at the guidelines for ISM in the Netherlands from "Agenschap Telecom" (AT) I wonder what is going on at K1: 869,400 - 869,650 MHz at 500 mW and 10% duty-cycle + allowed to use the whole band it looks interesting (although non-coorporation is probably a risk and 250 khz width is a limitation). I didn't see any mention of limitations on its use. But I'm probably not aware of some snag in it.


@turiphro What would be a typical response time for e.g. a burglar alarm. I would hope within a couple of seconds at most if I was keeping an eye on my bicycle while it is parked

(Thomas Telkamp) #8

First, note that the LoRa modems support a wider range of spreading factors and bandwidths than is defined in the LoRaWAN spec. We are obviously restricted to those.

For planning purposes, use the 30 sec. maximum air-time per day. Don't count on being able to use more than that. This translates for a 10 byte payload in 12 frames on SF12 to 500 on SF7. If your application requires more, you need to modify something: smaller payload, move closer to the gateway, etc. Or different technology.

Hint: don't use json in your payload!

The duty-cycle regulations per band limit the minimum interval you can use between frames.

Also note that there are two high-speed channels available, that will increase your number of frames over 500: SF7BW250 and FSK (50kbps in Europe). This works great at small distance, e.g. in and around your house.

(Thomas Telkamp) #9

Well spotted, but the snag is that you're not the only one who thinks this is a great band for your application. Hence, this is a busy and noisy channel.

We will use it though: for beacon broadcasts and downstream traffic (rx2 slot). There is very little, if not any, gain in using this for node upstream traffic.


Just for my curiosity, does this duty cycle limit impose to the gateway too?


Thank you everyone! From what I understand (yes I really need to digg into this and all the terminology etc haha) I won't be able to get a very high update rate, but since I just received the electronics I am just going to try out what I can get from this new technology. Always nice to experiment a bit. I'll keep you updated!

(Thomas Telkamp) #12

Yes, it is imposed on any device.


Or just make it smart.

When you want to know the location, send a message to the thing...

I mean, why you wanne follow it realtime?

And doe this hotspot have internet??



I continuously want to display it's location on a website, and thought this was the right way to go, since there is no action 'asking' the location, I always want to see it. Or do you mean that by sending a message this can be achieved as well?
And yes next to the lorawan there will be a router/hotspot with wifi, but for now i'm focussing on the lorawan + gps first.

I've opened a new topic concerning the hardware and my connection issues here to keep it a bit organized;


Sorry. When you have internet, you take a esp8266 and send wifi mac adress to your backend.

Dont use Lora' if you have internet and power!!!

Your solution is a ā‚¬5 nodemcu + 5volt usb cable!!!

Forget TTN if you track realtime, when you have internet.

Why should you go walking when you have a motorcycle???

(Alviso) #16

ESP8285 + HopeRF, no GPS


so you kick a one year old topic with no new information ... :sunglasses:


Well at least words have been turned into action :smiley::+1:

(Nidaros) #19

No GPS? How did you do that?


photoshop ? :wink: