@leon-woestenberg Hoi, ondertussen is alles goed verklaarbaar. De metingen zijn gedaan met een rigol ds1054z oscilloscoop en een keithley 2000 multimeter. (1 GSa/s dacht ik?)

@felixdonkers said in Packet loss impact:

Misschien kun je de test herhalen met andere intervallen, bijvoorbeeld 1 bericht per 5 sec, 10 sec, 20 sec, 1 min, 2 min, 5 min, 10 min, 20 min, etc? Kijken of er een trend waarneembaar is.

Ik heb de test herhaalt met een interval van 3 seconden, nu ben ik na 2000 pakketjes er maar 5 kwijt

@afzal_m said in Packet loss impact:

Vandaar dus dat je wat pakketten bent verloren. Met een hogere interval moet dat dus minder zijn.

Je kunt ons verder ook uitdagen door bijvoorbeeld met 5 devices te testen, waarbij elk device om de 5 seconden een berichtje stuurt. Als het goed is krijg je dan alles binnen!

Duidelijk verhaal, bedankt! Maar kunnen we hier ook absolute getallen aan koppelen? Het is erg lastig om nu te bepalen wat de grenzen zijn. Enkele seconden lijkt nu misschien niks maar over langere termijn kan dit wel veel invloed hebben op je batterijduur. Ik begrijp dat dit afhankelijk is van veel factoren, onder andere drukte op het netwerk, drukte per cell, interval van het device etc. Kun je een aanbeveling doen mbt maximale interval?

Hoi iedereen.

In mijn testen merk ik een redelijk hoge packet loss als het device meerdere berichten snel achter elkaar stuurt. In mijn meting stuurt één device één bericht per seconde. Na 1000 berichten waren er 204 pakketjes kwijt geraakt, een packet loss van 20,4% dus. Hoe komt dit en hoe kunnen we dit voorkomen?

@afzal_m Voorkomen is beter dan genezen dus… hoe voorkomen we dit?

@elfred-nieuwamerongen-van Dan is dat het probleem, ik zou @afzal_m even vragen of hij je device kan verwijderen dan kun je hem daarna weer opnieuw registreren

@elfred-nieuwamerongen-van Heeft je device toevallig data verstuurd sinds de update?

@techniek Hier nog een meting:

Die rare piek is verdwenen, geen idee wat dat was.

Debug log:

UDP no release flag:
[2018-06-08_08:48:52]0,4
[2018-06-08_08:48:52]OK //TX sent
[2018-06-08_08:48:53]
[2018-06-08_08:48:53]+NPSMR: 0
[2018-06-08_08:48:53]
[2018-06-08_08:48:53]+CSCON: 1 // t = 08:48:53
[2018-06-08_08:49:14]
[2018-06-08_08:49:14]+CSCON: 0 // t = 08:49:14 -> connected time = 21 sec
[2018-06-08_08:49:44]
[2018-06-08_08:49:44]+NPSMR: 1 // activity time = 44-14 = 30 seconden!

UDP release flag:
[2018-06-08_08:50:08]0,4
[2018-06-08_08:50:08]OK //TX sent
[2018-06-08_08:50:09]
[2018-06-08_08:50:09]+NPSMR: 0
[2018-06-08_08:50:09]
[2018-06-08_08:50:09]+CSCON: 1 //t = 08:50:09
[2018-06-08_08:50:09]
[2018-06-08_08:50:09]+CSCON: 0 //t = 08:50:09 -> connected time < 1 sec!
[2018-06-08_08:50:39]
[2018-06-08_08:50:39]+NPSMR: 1 // activity time = 39 - 9 = nog steeds 30 seconden!

Flag vs no flag is ongeveer factor 20 verschil in energieverbruik nu

@eric-barten @Jonathan-Carter I had the same error. @Rowan-Schaaf reset my password, that fixed it for me…

@afzal_m Het totale overzicht houden is lastig. Het is een combinatie van eDRX, connected mode, activity timer en TAU

@afzal_m Ik trok een foute conclusie, het was niet de activity timer die impact had op mijn energieverbruik maar het was de connected mode! Hier ben ik dus achter gekomen door te vergelijken met Vodafone, die gebruiken een activity timer van 2 seconden, 15 keer zo kort als T-Mobile dus. Deze timer van twee seconden leverde echter maar een hele kleine verbetering op.