I see in the roadmap that TTN is planning class B and C support.
How does this time synchronisation work for class B ? does it work with non TTN gateways and what changes technically for a node ?
Is this the roadmap for the ‘free’ TTN, or will some features be reserved for premium services offered by TTI?
What will be the approach for transmitting the OTA firmware updates?
@ Wienke @ Johan … little kick 
@wienkegiezeman @johan Now that the TTN gateway is shipping, maybe it’s a good opportunity to update the roadmap ahead? 
Personally, I’m very interested in the status of the TTN gateway agent. Does @egourlao has any updates as well?
1 Like
@Epyon you’re very right about the need for an updated roadmap. We are working on this, and the Conference will cover a keynote about it for sure. The goal is to get it out before.
Here’s the key points that are public so far:
In the meantime, we are working with partners to get both LoRa and wifi geolocalization working, both RSSI/SNR based as well as TDOA.
4 Likes
Hm. How many LoRa-Loc - based GWs are currently installed there in the fields?
How many gateways were installed before TTN 
we’re technology enablers and that drives use and installed base. And in fact, there are quite some V2 based gateways on the network already
1 Like
The problem IMHO is that LoRaWAN is open technology, and LoRaLoc isn’'t so open one.
Well, and what about packet forwarder/HAL? May I take a look at the sources? 
And what about fine timestamp decription keys?
Most location solvers are proprietary indeed. As long as you have the fine timestamps, rssi and snr values you can do whatever, and I’m looking forward to open source solvers.
Sources depend on the gateway. The encryption keys of the fine timestamps can be the catch; Semtech sits on these. We’re starting with a hosted geoloc service by Semtech for community use
I was talking more about GW software.
Guess the sources themselves will give you almost nothing. The devil is in the details… Filter parameters etc.
rssi stddev and those misterious ratio enegies defined in the struct describing received signal are very useful too (to clearly understand if the signal was reflected too many times and so shouldn’t be taken into account).
They all use the same v2 HAL, altough it newer was publicly available and it seems that now at all the sources are closed.
Yeah, even GW v2 vendors sometime experience troubles with getting these one…
Thanks, that’s what I’d like to know.
In Dutch 
And I personally playes around with about 10 GWs from two different vendors and also saw some other data gathered by very respectable persons - fine timestamps accuracy is far away from being usable.
So, in my opinion, lora geoloc currently doesn’t worth the effort. We all have to wait for more advanced HW. But this is just my private opinion.
Looking forward to Gateway statistics.
I’ve just spotted a different network running near our gateway. It’s all IoT so good stuff…
realtime accurate tracking with 100% coverage will never be a lorawan thing… you’ll lose the competition from NB-IOT networks in the very ‘near’ future imho.
1 Like
Anything with 100% coverage will never be a lorawan thing.
Just out of curiosity: aren’t you going to support something like AGPS?
What could, potentially work, is to use LoRa TDOA and/or RSSI first, and based on a (rough) estimation, send that to the end device to get a quicker GPS fix. It’s all application level; there’s no need for network server support for that.
WiFi geoloc doesn’t seem to require support at NS level, but you mentioned it in your posr, that’s why I asked about AGPS. Thanks for your answer!