LoRa | Geolocation

  • 4 November 2016
  • 59 reacties
  • 14165 keer bekeken
Toon eerste bericht

59 reacties

rharte
Reputatie 1
Badge +1
However, if one gateway receives your signal quite strong, it will ask the device to tune down

Why do you think so?

BTW, a gateway typically is just unable to send a MAC command to a node, as it doesn't have access to NwkSKey.

Or then more generally speaking: the network functionality as a whole (ADR) is aimed at preserving link budget; the way it works does not change anything to the nature of my question, or does it?
rharte
Reputatie 1
Badge +1
A question for KPN: does geo-location also work if you send a message with an empty data-payload, carrying for instance only a MAC command?
rharte
Reputatie 1
Badge +1
@Tim, @Rick S., I have a question that I posed earlier, but never got an answer on:
I understand that the network calculates a position if 3 or more gateways receive a device's uplink message. I see, however, on numerous cases that there is no DevEUI_location message received by our backend, even though 3, 4 or even 5 gateways receive the uplink signal. As I see it, this makes the geolocation feature quite unreliable.
Can you please explain what the logic is when a position is calculated or not, and why DevEUI_Location messages are often not generated even when an uplink message is received by plenty of gateways?
rharte
Reputatie 1
Badge +1
No worries @Rick S. 😉

I have an observation along the same line that I would like to check with you: sometimes we see a position update but no DevEUI_location message! Let me give an example (and apologies for being quite comprehensive):

- At 02:00 we send an uplink messages that results in a position update. Immediately after the DevEUI_uplink message we receive a DevEUI_location update message (as expected)
- At 04:00 we send an uplink message that is only received by 2 gateways. There is no position update and the DevLocTime in the uplink message refers to the 02:00 position update (as expected)
- At 06:00 we send an uplink message that is received by 6 gateways. There should be a position update but there isn't any DevEUI_location message received, and the DevLocTime in the uplink message still refers to the 02:00 position update (not as expected)
- At 08:00 we send an uplink message that is received by 2 gateways. Again no position update but suddenly now the DevLocTime in the uplink message refers to an 06:00 position update!

So that means the netword did in fact calculate a new position at 06:00, but a DevEUI_location messages was not sent. We went through our logs in detail to make sure we didn't miss a DevEUI_location message but that was not the case. Also we notice that the FCntUp skips a number every time a DevEUI_location message is received and that was here not the case. So we think we have quite a strong indication that the network sometimes updates the position without sending a DevEUI_location message and the only way knowing is to compare the DevLocTime in subsequent DevEUI_uplink messages.
Is that observation correct, and is this in fact behaviour as designed, or is it a bug?😅
Gabzz
@Tim Sorry for not being clear enough.
What I wanted to say is:
Is there a situation where the backend needs more than one transmissions to compute a location? I suppose the answer is yes because my device might be able to send data but TDoA might fail because of harsh multi path environment (i.e. a densely built area for example). If the gateways gets numbers that are totally banana the backend might decide to treat them as outliers and not compute.
The result from the user PoV is that data is safely transmitted but no new location is computed (and the location timestamp remains the old one).

If, by chance, the backend decides instead to use a Last known location and, yet, it updates the Location Calculation timestamp or, worse, it sends a location message out, that is quite against criteria of data accuracy, consistency and timeliness.

I am sorry for this wordy response but I can't make it simpler. 😞
Gabzz
@Rick S. THX
Perhaps it's me but I find the wording ambiguous:
"but this will be reversed by the time-stamp DevLocTime (and the absence of an update)."

Means that neither an update is used nor the time-stamp is updated (to the failed computation time) in the next "data-message". In that case the response is accurate and consistent. Do I understand well?

Sorry, it's an old man typing here 😉
K
Beste KPN,

Alvast bedankt voor het activeren van geolocation op de Developer portal!
Ik ben aan het testen met ADP en OTAA op dezelfde LoRa mote (maar dan met aangepaste firmware), en verstuur per minuut een pakketje van 42 bytes met ADR.

Er zijn mij een tweetal zaken opgevallen:
1) Gebruik makende van ADP krijg ik niet, zoals verwacht, een 'DevEUI_uplink' optioneel gevolgd door een 'DevEUI_location'. maar vaak alleen een 'DevEUI_location' en af en toe een 'DevEUI_uplink'. Dus ik mis de payload data heel vaak...
2) Gebruik makende van OTAA krijg ik na het versturen van zo'n 6 uplinks (dus na 6 minuten) error-meldingen van mijn mote en kan vervolgens uren geen uplinks versturen (ik gebruik de Sodaq One V2 met retries geactiveerd). Dit gebeurt zowel bij Developer als Thingpark en alleen met de OTAA. Lijkt erop dat KPN iets controleert en vervolgens blokkeert. Klopt dit?
K
Hallo Rick,

Dit leg ik voor aan de specialisten om hier duidelijkheid in te krijgen.

Als je ze toch gaat benaderen, ik heb een test rit gedaan met geolocation waarbij het volgende is opgevallen:
- Iig in Lelystad staat geolocation uit. Ik krijg alleen 'uplink's met daarin een niet veranderd ,"DevLocTime" (laatste bekende vaststelling van een geolocation?)
- In de buurt van Huizen en Meerkerk is de nauwkeurigheid van geolocation ruim 7 km! Ik vermoed dat ook hier geen geolocation kan worden bepaald en ipv de coordinaten van de ontvangende gateway doorgeeft?

Ik hoor het graag en ook prettig weekend!
K
Hallo @Rick S.

Alvast bedankt voor de informatie!
Ik lees inderdaad dat het mote interne timers gebruikt om de duty-cycle 'af te dwingen'. Ik begrijp dus dat iig KPN hier geen controle over uitoefent.
Het blijkt een bepaald gebied van Lelystad te zijn waar geen geolocation is. De mote werd zowel in- als outdoor gebruikt, en hiermee werden dus wel uplinks verkregen.
Het verhaal over het schuivend window begrijp ik niet. U wilt hiermee zeggen dat als het mote 1 x per uur contact maakt, de geolocation van de vorige max. een uur later verzonden wordt?

Gr.

Kees

Reageer


Forumvoorwaarden