Minimaliseren stroomverbruik met UDP, release assist en PSM op een SARA-N211
-
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…
-
Begrijp ik goed dat in het laatste voorbeeld wel gelukt is om die van 30 seconden naar 0 seconden te krijgen?
Ik begreep van @techniek dat het hem vandaag ook is gelukt.
-
@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)
-
Mijn gebrek aan kennis dan. Hoe kan het dat eerst wel impact had op je energieverbruik en nu niet?
-
@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.
-
Haha… misschien moeten we vanaf nu gewoon praten over connected mode en idle mode (zoals 3GPP het ook noemt).
Toch vind ik het bijzonder @JanWillem van Sodaq gaf ooit aan dat de 30 seconden idle mode wel killing is voor energieverbruik…
-
@afzal_m Het totale overzicht houden is lastig. Het is een combinatie van eDRX, connected mode, activity timer en TAU
-
@andre-rodenburg said in Minimaliseren stroomverbruik met UDP, release assist en PSM op een SARA-N211:
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…
Super Andre… dank je voor deze bijdrage!
Dat noopt me om de test nog een keer te herhalen… en kijken of de ECL nog invloed heeft. -
@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
-
Andre,
interessante meting. Alles lijkt nog niet helemaal verklaarbaar, toch?
wij zijn ook geinteresseerd in power-reductie, zeker als het gaat om het gemiddeld opgenomen vermogen gemiddeld over een korte periode (< 100 ms) en zullen hier ook wat meetstappen moeten maken.
Om even appels met appels te blijven vergelijken:
Hoeveel samples per seconde neemt jouw meetapparatuur? (Was dit een STM32 ADC?)
Wat is de bandbreedte van jouw meetapparatuur?Groet,
Leon.
-
@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?)
