Posts made by Andre Rodenburg

Same here, not receiving messages anymore, last message received 03:55.
Since last year we were very impressed with how the overal NB-iot network performed, but now with the missing messages this is putting NB-iot via T-mobile in a bad spotlight with our customers.

Also not receiving packets anymore since 2020-03-05 01:41, seems that local nodes seem to think they can deliver the data, but nothing is received in the backend anymore.

Best regards,

André Rodenburg

@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.

@afzal_m Nee, dat is niet gelukt. Lijkt ook helemaal niet nodig te zijn nu, een activity timer van 30 seconden heeft in mijn metingen alleen effect op het aantal pages (die piekjes van ~10 samples breed)

@pmb_nl Als het niet lukt kun je het altijd vragen

@pmb_nl
Hoi, je moet deze manuals volgen: https://forum.iot.t-mobile.nl/category/19/early-access-impact-platform-test

“By entering your IMEI no. in your devreg.iot.t-mobile.nl portal, you registered the IMEI in your own application on our IoT-network. Hence, there is a double registration right now so no one is able to receive the data.”

Klopt dit en is er een ander alternatief?

Dit gaat volgens mij over de hardware van SODAQ, geen idee of dat nog steeds van toepassing is. Ik zou eerst gewoon de manuals proberen te volgen.

@thijsbuuron hier zijn mijn bevindingen: Stroomverbruik minimaliseren

Gisteren heb ik een paar stroommetingen gedaan op een uBlox SARA-N211 modem. Mijn doel was om een zo laag mogelijk stroomverbruik te krijgen. Tijdens het installfest heb ik met @techniek gekeken naar release assist. Hier bleek dat het toen vrijwel geen effect had op het stroomverbruik (zie: link) :

Ik was er toen heilig van overtuigd dat de activity timer het probleem was (misschien dat het in de naam zit…). Na wat meer onderzoek en een vergelijking met Vodafone had ik het volgende:

• +CSCON: ‘Signalling connection status’, oftewel: 1 = in connected mode, 0 = idle mode
• +CEREG: ‘Network registration status’, “00001111” = 2 sec x 15 = 30 seconden, klopt precies! Voor vodafone is dit 2 sec x 1 = 2 seconden, klopt ook precies! Vodafone en T-Mobile hebben dus verschillende activity timers. De activity timer heeft geen effect op de connected mode (de interval tussen CSCON=1 en CSCON=0 blijft ongeveer gelijk) en hier gaat juist de meeste energie verloren. We moeten dus de tijd dat het modem in ‘connected’ mode is verkleinen.

Bij een video van Rohde & Schwarz had ik deze foto gevonden:

• ‘Setting T3324 activity timer to zero’: Dit is voor ons onmogelijk. T-Mobile ondersteund het veranderen van de PSM timers niet. De activity timer beinvloed de tijd dat het device kan pagen, deze tijd verkleinen verbeterd het stroomverbruik maar de verbetering is niet groot.
• ‘Release assistance’: sinds de release van UDP voor T-Mobile NB-IoT is dit mogelijk. Als het goed is minimaliseert dit de connected mode, in de post van @techniek leek het geen effect te hebben.

Ik besloot om het toch te proberen:

Eerst een bericht zonder release flag:

• AT+NSOST=0,“172.27.131.100”,15683,4,“45726963”

Levert eigenlijk geen verbetering op vergeleken met CoAP (AT+NMGS). Zoals verwacht gaat er enorm veel energie ‘verloren’ in de connected modus.

Nu een bericht met release flag:

• AT+NSOSTF=0,“172.27.131.100”,15683,0x200,4,“48656c6a”

Dit levert een enorme verbetering. De hoeveelheid verbruikte energie voor één TX bericht is hiermee vijf keer kleiner geworden, precies wat we wilden! Het device zakt nu na de TX-piek vrijwel meteen naar een laag stroomverbruik van ~3 uA. Het rare is dat dit niet te zien is bij de metingen van @techniek terwijl we hetzelfde modem gebruikten. Misschien dat het per cell verschilt?

Nog iets wat ik niet kan verklaren is de grote piek tussen 400 en 500 samples, die zie ik de laatste paar dagen in al mijn metingen terug komen. Hiervoor heb ik deze nooit gezien…

@thijsbuuron Heel fijn! Heb je toevallig ook al UDP release assist geprobeerd?

Hallo iedereen,

De JSON die impact naar het backend stuurt bevat geen RSSI waarde van de mast. Het is waardevolle informatie en zegt veel over de kwaliteit van het signaal. De Sigfox backend doet dit standaard wel.

De RSSI waarde van het device (en ik geloof ook de mast zelfs met at+nuestats=cell) is ook op te vragen met een AT-Commando. Echter is dit een stuk minder efficiënt, er moet immers een onnodig at-commando verstuurd worden, de reactie moet verwerkt worden en de waarde moet meegestuurd worden met de payload.

Nu is mijn vraag:

• Wordt de RSSI überhaupt gemeten op de mast?
• Zo nee, kan dit in de toekomst toegevoegd worden?

@gbme Hi, please follow manual part 2: register device, also check our parts one and two.

Answers:

• No, the devreg tool is obsolete (it was built for the old oceanconnect platorm, which got replaced by Impact)
• Postman allows you to use API calls to register devices, register an application, delete devices etc, so it basically allows you to manage all your devices!

@paul-koenen said in Add more devices:

@Andre-Rodenburg ieder sim-kaart heeft toch zijn eigen IMEI nummer? of hoe onderscheidt T-mobile anders zijn devices?

Nee, imei nummers zijn niet gekoppeld aan simkaarten. Misschien dat @afzal_m je dit beter uit kan leggen. Misschien dat je je imei op een ander account hebt geregistreerd?

@paul-koenen IMEI nummers zijn niet gekoppeld aan simkaarten. Registeren van een tweede device gaat op dezelfde manier als het registeren van je eerste device

@thijsbuuron Deel je bevindingen!