Reacties geplaatst door rharte

24 Reacties

Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

I have geolocation provisioned and sending with SF12 and ADR off as advised by KPN in this thread. I find that quite regular my signal is received by 3 or 4 gateways, but only occasionally the geo position is updated. I can send dozens of messages per day and still find that my calculated position may be two days old! Is my observation correct that there is not always a position update when a signal is received by 3 or more gateways? Or am I doing something wrong?

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

I have another question about geolocation: I guess for the best results and accuracy, it's beneficial if as much gateways receive your signal as possible. At least more than 3. However, if one gateway receives your signal quite strong, it will ask the device to tune down, meaning that less gateways will receive the signal, and the geolocation accuracy will deteriorate if at all enough gateways recieve the signal for a position determination. I guess in the long run KPN doesn't want any devices that ignore mac commands and keep sending at SF12 and max power to get the best geolocation results. How are these mechanisms planned to co-exist in a sort of optimum configuration?

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

[quote=hobo][quote=rharte] However, if one gateway receives your signal quite strong, it will ask the device to tune down[/quote] 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.[/quote] 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?

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

[user=14980]Gijs[/user] you need a LoRa subscription with the feature Geolocation activated. Then you need an application that sends some data (even if it is a dummy payload, so no specific changes needed in your application), then you need to make sure that at least 3 gateways can pick up your signal for triangulation, so you need to check your antenna effectivity, TX-power and SF, and then you will receive a new message type on your backend server, the DevEUI_location message that you need to decode. That's basically it :wink:

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

[user=14980]Gijs[/user] You can forget better than GPS accuracy, the only thing you may achieve is better than GPS [i]coverage[/i]. I think KPN strives for 20-50 meter accuracy, but they are not there yet. The actual accuracy depends on the geometry of the network, which is still changing from day to day because KPN still expands the number of sites, and it also depends on your location of course. We have done a lot of tests and as a rough estimate I would say that in 80% of the cases, the accuracy lies between 20 and 200 meters. Statistically, I would say the outdoor accuracy is better than indoor. Simply because the reception level indoor is less, this means fewer gateways receive your signal, and the triangulation quality is less.

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

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?

59
Rick S.
Community manager
6 jaar geleden
J
jawoveActieve Deelnemer
gevraagd in LoRa Forum

Downlink test message or ACK not received by node

A question for KPN along the same line, [user=8294]Rick S.[/user]: is a downlink message always sent in RX1 [i][u]and [/u][/i]RX2, or does the network choose one of these two? I seem to always get a timeout in RX1 and always a succesful reception in RX2, but I am wondering if this is a network feature, or an error in my software! :wink:

18
Rick S.
Community manager
6 jaar geleden
J
jawoveActieve Deelnemer
gevraagd in LoRa Forum

Downlink test message or ACK not received by node

[user=8294]Rick S.[/user] thanks for your answer, but I don't quite get it...... [user=917]michieljol[/user] writes in this thread > https://zakelijkforum.kpn.com/lora-forum-16/downlink-berichten-verstuurd-op-channel-lc127-8441 "Overigens hebben we ook bij andere klanten gezien dat er problemen kunnen ontstaan wanneer downlink via RX2/LC127 wordt verstuurd. Beste is natuurlijk hier niet in terecht te komen en gewoon het eerste receive window te gebruiken. " This suggests that a mobile device should always listen for (and expect to receive) a downlink message in RX1. This seems to be in contradiction with your answer!?

18
Rick S.
Community manager
6 jaar geleden
J
jawoveActieve Deelnemer
gevraagd in LoRa Forum

Downlink test message or ACK not received by node

Yes [user=8294]Rick S.[/user] that would be great! My software first listens in RX1 for a downlink reply, then in RX2, and I find that there is never anything received in RX1, and always a succesful reception in RX2. So I am in doubt if the network does not send anything in RX1, or my software is just faulty.... :sweat_smile: I am observing the following parameters: RX1: delay 1 sec, frequency same as TX-frequency, sending and receiving on SF12 RX2: delay 2 sec, frequency 869.525 MHz, sending and receiving on SF12 (I am sending and receiving on SF12 to prevent any misinterpretation/effect of the parameter RX1DROffset).

18
Rick S.
Community manager
6 jaar geleden
J
jawoveActieve Deelnemer
gevraagd in LoRa Forum

Downlink test message or ACK not received by node

Hi [user=8294]Rick S.[/user], thank you for your quick reply! So do I understand correct that the network chooses to send in RX1 [b][i][u]OR[/u][/i][/b] RX2, but not in both? The other thing you are saying about receiving default on SF9 in RX2 must be incorrect: this is in contradiction with the LoraWan standard, that says that the RX2 datarate is always SF12. And the datarate in RX1 is governed by the parameter RX1DROffset that gives the relation between the uplink SF and the downlink SF. So a fixed SF will never work neither in RX1 nor in RX2. We are using a radio module that is fully transparent and is controlled by our own LoraWan stack implementation, therefore we can see all that is going on on the radio layer and we control what this module is doing.

18
Rick S.
Community manager
6 jaar geleden
J
jawoveActieve Deelnemer
gevraagd in LoRa Forum

Downlink test message or ACK not received by node

[user=8294]Rick S.[/user], I wrote my reply before reading your second message! :grinning: Now it is all clear to me! Thanks, I am going to do some more testing on other datarates!

18
Rick S.
Community manager
6 jaar geleden
michieljol
KPN Moderator
michieljolProductmanager LoRa for Developers
geplaatst in LoRa Forum

Adaptive Data Rate (ADR)

[user=917]michieljol[/user], [user=8294]Rick S.[/user], I have a technical question about ADR. In the reply from the network on an uplink message, you find the MAC command [b]LinkADRReq[/b], (MAC command 0x03). This MAC command gives an advice on SF and TX, power, and it also contains a channel mask, defining the channels available for uplink messages. I notice this channel mask is always 0x00 0x07, or binary 0000000000000111, and this means if I interpret correctly only channels 1, 2 and 3 are available for uplink messages. However in practise, I think there are 8 channels available for uplink messages, at least my software use all 8 and messages arrive correctly, and in the messages from KPN's backend system this is indicated by the parameter [b]Channel [/b]which has values LC1.... LC8. My question is: why is the channel mask in MAC command 0x03 indicating that only 3 channels are available while in fact there are 8? I would like to design a proper mechanism to use a certain cha

9
rharte
6 jaar geleden
michieljol
KPN Moderator
michieljolProductmanager LoRa for Developers
geplaatst in LoRa Forum

Adaptive Data Rate (ADR)

[user=8294]Rick S.[/user], Ok it is some logic explanation, but still the mechanism seems a bit cumbersome. I see for instance when I turn a device on, after sending the first uplink message, the channel mask communicated is 0x0007 meaning ch1, ch2 and ch3 are available, while in this same downlink reply the device receives two NewChannelReq messages for ch3 and ch4. So a NewChannelReq for ch3 which is already included in the channel mask? A NewChannelReq for ch4 I understand but then what about ch5..... ch8? I think a lot of airtime goes wasted this way on handshake on these parameters, while they are the same for every channel anyway, and all 8 frequencies can be known upfront to all devices, right?

9
rharte
6 jaar geleden
michieljol
KPN Moderator
michieljolProductmanager LoRa for Developers
geplaatst in LoRa Forum

Adaptive Data Rate (ADR)

[quote=hobo] You're bragging that your device doesn't follow the specs, aren't you? :-)[/quote] :joy: Well actually if you read the spirit of my post, I am trying hard to comply to the spec, but in the grey area of network behaviour where the LoraWan specification does not provide, I find it sometimes hard to follow the logic. Luckily, KPN answers quickly and thoroughly on my detailed technical questions, so I gladly stand corrected when that means I receive another piece of the puzzle :wink:

9
rharte
6 jaar geleden
michieljol
KPN Moderator
michieljolProductmanager LoRa for Developers
geplaatst in LoRa Forum

Adaptive Data Rate (ADR)

Excellent [user=8294]Rick S.[/user]! :thumbsup_tone2: Thank you very much!

9
rharte
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

[user=227]Tim[/user], [user=8294]Rick S.[/user], 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?

59
Rick S.
Community manager
6 jaar geleden
Tim
TimAllesweter
geplaatst in LoRa Forum

LoRa | Geolocation

No worries [user=8294]Rick S.[/user] :wink: 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 [b]02:00[/b] 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 [b]04:00[/b] 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 [b]06:00[/b] 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 [b]08:00[/b] we send an uplink message that is received by 2 gateways. Again n

59
Rick S.
Community manager
6 jaar geleden
JesseAtBlue
JesseAtBlueStarter
gevraagd in LoRa Forum

Huidige status van geolocatie-functionaliteit in het KPN LoRa netwerk

[user=8294]Rick S.[/user], die nauwkeurigheid van 100 meter moet je nog wel met een korreltje zout nemen hoor :wink: :sweat_smile:

12
rharte
5 jaar geleden
JesseAtBlue
JesseAtBlueStarter
gevraagd in LoRa Forum

Huidige status van geolocatie-functionaliteit in het KPN LoRa netwerk

[user=13006]peter schwab[/user], zoals ik het begrijp moet je minimaal 3 willekeurige gateways bereiken met je signaal. Echter de werking van de functie is nog niet optimaal: KPN tuned nog aan e.e.a. en er worden nog bugs opgelost. Je krijgt bijv. regelmatig geen positie update als je [i]precies [/i]3 gateways bereikt, dat zal je ongetwijfeld bij jullie tests opgevallen zijn. Wij zitten ook met smart te wachten totdat dit opgelost is! :grinning:

12
rharte
5 jaar geleden
JesseAtBlue
JesseAtBlueStarter
gevraagd in LoRa Forum

Huidige status van geolocatie-functionaliteit in het KPN LoRa netwerk

Hoi [user=8294]Rick S.[/user], Dank voor deze info. Nog een vraagje: van 'static', 'slow moving' en 'fast moving' begrijp ik wat het betekent, maar wat is dan precies de definitie van 'nomadic'? Groeten, Rene

12
rharte
5 jaar geleden
JesseAtBlue
JesseAtBlueStarter
gevraagd in LoRa Forum

Huidige status van geolocatie-functionaliteit in het KPN LoRa netwerk

Nog een aanvulling: mij lijkt me die 60 meter voor static bijzonder optimistisch, en die wordt waarschijnlijk met name buiten de bebouwde kom gehaald. Binnen de bebouwde kom heb je meer delay spread a.g.v. reflecties en dergelijke (tot wel een microseconde variatie in looptijd, dus 300 meter onnauwkeurigheid). Wij hebben pas een leuk proefje afgerond: met een static node zo'n 2400 posities verzameld, op een locatie in de bebouwde kom in Rotterdam. Hierbij lag 80% van de metingen binnen 400 meter. Ik moet er wel bij zeggen: volgens mij heeft KPN nog bugs opgelost [b]nadat [/b]deze proef al was afgerond. Plaatje bijgevoegd! [img]292b342f-2596-4c6c-a312-eb77ecf283dc.jpg[/img]

12
rharte
5 jaar geleden
JesseAtBlue
JesseAtBlueStarter
gevraagd in LoRa Forum

Huidige status van geolocatie-functionaliteit in het KPN LoRa netwerk

In dit plaatje en op deze locatie zit maar weinig offset, maar als ik bij mezelf thuis test zit er wel degelijk een systematische offset van 50-100 meter in. Wat betreft die locatie waar je nog nooit een locatie fix hebt gekregen, daar zou ik een ticket voor aan laten maken. Wellicht staat de optie geolocatie niet aan op dat abonnement, of er is een server die niet goed functioneert. Ik heb ook wel eens problemen gehad op een bepaalde locatie en die verdwenen nadat KPN een server had gereboot.

12
rharte
5 jaar geleden
E
EileenNieuwkomer
gevraagd in LoRa Forum

LoRa for urban animal shelter detection

Hoi Eileen, wij hebben hier een pasklare oplossing voor: een LoRa PIR sensor welke samenwerkt met onze mobiele app. Je kan een onbeperkt aantal sensoren koppelen op de app, dus zo kun je eenvoudig een overzicht krijgen van activiteit rond alle shelters. De sensoren zijn klein en werken meerdere jaren op een batterij. Ze kunnen zowel op het KPN LoRa netwerk als op het gratis netwerk van The Things Network werken. Als je geen programmeerervaring hebt kan het nogal eens een hele (lange) klus worden om zelf zo'n oplossing te ontwikkelen, dus weet waar je aan begint ;-) [img]https://uploads-eu-west-1.insided.com/kpn-business/attachment/41e2c5d8-f2eb-4440-95df-947003e4abbd.jpg[/img]

4
rharte
5 jaar geleden
L
LoraInNieuwkomer
gevraagd in LoRa Forum

How to increase delay in Up-Link transmission of end device?

[user=34360]LoraIn[/user] the duty cycle is something your own application controls and you can choose whatever you want as long as you don't exceed 1% duty cycle per subband! So for instance if you send a message on SF9, using 250 ms airtime, you then need to be silent in that sub-band for minimum 25 seconds so the duty cycle does not exceed 1%. But your application may straightaway send another message in another sub-band, should other sub-bands be available, as long as you respect the 1% duty cycle per sub-band.

4
Rick S.
Community manager
5 jaar geleden

Badges

Toon alle badges
Forumvoorwaarden