Hi,
I’m writing a Geolocation solver (in python) and I receive UplinkEvents and I get the gw_time for the TOA value. I don’t find any way to know the precision of the clock, meaning I can’t know if the .ToNanoseconds() ends with 000 just by chance or because the Gateway doesn’t support nanosecond precision.
How should I overcome this? Should the API also produce a precision field we could query?
Thanks @brocaar for your excellent work.
Cheers
I feel that this level you are looking at, is supposed to be agnostic towards the capabilities of the gateway and the packet forwarder protocol.
Actually, wouldn’t the lack of or support of nanosecond precision, depend on the packet forwarder’s protocol and shouldn’t you study that part? If it uses nanosecond precision, then whether the gateway actually supports that or not, cannot really be represented.
Hi,
“…or because the Gateway doesn’t support nanosecond precision?”
First, the Fine Timestamp feature depends on the LoRa chip used in the Gateway. Only the Semtech SX1303 chip supports Fine Timestamp nanosecond timing. Second, the Gateway should have GPS with PPS to synchronize the SX1303 clock. Check the specifications of your Gateway to see if it implements Fine Timestamping functionality.
Hi all,
Well, I’m not sure about this, it could have a field mentioning the precision. Somebody in the chain must be able to know what’s going on.
Sure!
What I mean is I’m making an integration that captures Uplink events, and from there there’s no way to know if the Gateways support that or not, so I cannot know from the integration (via MQTT or HTTP) if I can apply TDOA or not.
Do you know how is this handled in Lora Cloud integration? How does Chirpstack choose the solver (RSSI vs TDOA) to send the data to?
Hi ekaitz-zarraga,
Yes, there is a way in Uplink events to detect if the gateway supports fine timestamps (in the ChirpStack). The Uplink event has an rxinfo object with a set of rxinfo items. The rxinfo item has a fineTimeSinceGpsEpoch attribute with a nanosecond Fine timestamp. So if you find a fineTimeSinceGpsEpoch attribute in the rxinfo item, you can assume that the gateway supports Fine Timestamps.
Here is an example uplink with the fineTimeSinceGpsEpoch attribute:
“…Do you know how is this handled in Lora Cloud integration?”
No, I don’t know how this is implemented in Lora Cloud integration. But I assume the choice between TDoA and RSSI algorithms is which method has better accuracy?
P.S.
I have Implemented TDoA/RSSI geolocation resolver coded by the Rust language, but it still in experimental/test phase. Do you have a real test environment/testbed, at least three gateway setup? And would you like test the this solution or is your goal to implement own solution for the LoRa georesolver?
Here is a link to the live testbed if you want to explore the solution.
GLSensor tracker
Zoom in the map and you’ll see some synthetic sugar 
This is exactly what I was looking for. Thank you.
I made my own resolver using a 20-80 or 30-70 approach. The 20 percent of the effort for the 80 percent of the result.
I’m working on an R&D project around LoRaWAN and I wanted to give it a go. We can talk about how I implemented it and compare with yours. According to your previous messages, probably yours is better, but it has an incremental approach. Mine doesn’t, it’s more like the single-frame LoRa Cloud resolver in the sense that takes just one frame, detected by several gateways and tries to give a result with no state involved. It’s “just” a function.
EDIT: my hidden goal is to share this part of the project as a minimal open source solver and let the community improve on top of it.
I don’t have a proper testbed, but hopefully I will have one later. I took a look to your GLSensor tracker website but I don’t understand very well what I’m seeing.
Could you share more about it? Feel free to send me an email if you like to continue the conversation there. It’s not hard to find. Or send me a private message or something and we’ll talk.
Thank you.
Good, if you got the point in generally. This topic is quite broad and difficult to summarize in a few sentences.
Okay, there happens lot of behind the scenes. Sensors in the tesbed sends messages when something changes in test environment, for example, something happens in the radar sensor range or some other sensor send message in every 5 minutes.
In general, the UI map shows what has happened in the last hour.
But keep it simple, there is bunch of sensor in the test environment which sends messages to LoRa LNS. Immediately when the LNS get the Uplink message, it forwards the message to the georesolver module and the georesolver calculates the sensor location in real time and forwards the location information to the GLSensor tracker UI, which shows the real time situation on the map. This is only show case how to use the real time georesolver information.
Hi ekaitz-zarraga,
Let’s get back on topic when you get ready first version on your project. Happy coding.
