Best posts made by Andre Rodenburg

Afgelopen week heb ik een interessante feature van NB-IoT ontdekt, genaamd “release assist”.
Deze feature moet de RX tijd van het modem minimaliseren door na het versturen van een bericht direct in PSM te gaan, het modem wacht dan niet op een antwoord van het netwerk:

Zoals te zien in deze stroommeting heeft de RX-tijd een significant effect op het stroomverbruik.

Release assist zou de RX tijd van het modem effectief naar 0 krijgen, heel positief voor het stroomverbruik dus. Nu is mijn vraag: Wordt dit al ondersteund? (Ik heb het werkend gezien bij de ‘concurrent’) Zo nee, staat het wel op de roadmap?

Wat de relatie is tussen release assist en de activity timer van PSM begrijp ik ook nog niet helemaal. Wanneer de activity timer op 0 staat wordt er dan alsnog gewacht op een antwoord of gaat het modem dan ook meteen in PSM?

@thijsbuuron hier zijn mijn bevindingen: Stroomverbruik minimaliseren

UDP passthrough werkend met een SARA-N211! @afzal_m @Eric-Barten @felixdonkers

@iotguy

Beste IoTguy,

Bedankt voor je reactie. Ik heb je aanwijzing gevolgd en het is nu gelukt.
De ontvangen base64 string wordt geconverteerd naar een hexadecimale string van 8 karakters lang. Vervolgens gebruik ik substr(0,4) en substr(4,8) om de eerste twee bytes temperatuur en de volgende twee bytes vochtigheid van elkaar te scheiden. Deze converteer ik apart van elkaar naar een decimale waarde welke ik in een array stop op plaats 0 en plaats 1.

De output ziet er zo uit:

De volgende stap is om de deviceId mee te sturen welke onze database nodig heeft.
Ook ga ik nu proberen om een LED aan te sturen

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…

@felixdonkers

Interessant, mooie grafiekjes ook. RSRP = 0 is hetzelfde als AT+CSQ = 99 in mijn grafiek, dat betekent dat je het signaal kwijt bent. Dit zou kunnen betekenen dat de coverage niet voldoende is of je gaat net zoals ik te dicht langs een zend mast.

Als ik zo kijk naar de plaatsing van zendmasten in jouw buurt zou dat best het geval kunnen zijn:

Over die ECL metingen, het enige wat ik daar over kon vinden was dit, misschien heb je er wat aan:

Foto staat op de volgende link: https://futurelab.community/challenge-hardware/

@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?)

@afzal_m PM is gestuurd

@afzal_m Ik heb je een update gestuurd in PM

@bokse001 said in track&trace device met een Quectel BG96:

@afzal_m ik heb overal gezocht op het forum en de website maar kan de roadmap nog niet vinden. Kan je een link ernaar svp delen?

Helemaal onderaan deze pagina: link

Beetje raar geplaatst inderdaad, ik moest ook even zoeken…

Firmware ondertussen geüpgraded, dezelfde intervaltest nog een keer gedaan en het probleem lijkt nu opgelost te zijn:

Waar het modem het na 1,5 - 2 uur ophield met zenden loop hij nu al meer dan 4 uur.

Één pakketje verloren op de pakweg 250…

@techniek Helemaal top, ik ga proberen je resultaten te reproduceren, misschien met een iets kortere duur…

Ik heb wel een paar vraagjes.

1. De schaal in je tweede foto is in [A] neem ik aan?
2. Ik zie dat je in NCONFIG “AUTOCONNECT” op true hebt staan, is hier een reden voor?
3. Wat is NAS_SIM_POWER_SAVING_ENABLE?
4. Waarom staat bij +CGDCONT <cid> op 0 en niet op 1?
5. Als de <TAU> aan de netwerk kant op 310 uur stond betekent dit dat AT+CEREG=5 een waarde van “010 11111” terug gaf? Volgens GPRS Timer 3 welke gespecificeerd wordt door 3GPP is dit namelijk 310 uur.
6. Ik zie dat het AT+CPSMS commando voor <TAU> een waarde van “010 000111” terug geeft. Volgens dezelfde GPRS Timer 3 timer is dit 70 uur, maar toch slaapt je device voor 310 uur… hoe kan dit?

Hoop dat je het iets kan verduidelijken

@tcs I had the same problem. In my case, the RawData app wasn’t added to my OceanConnect profile. OceanConnect is the T- Mobile southbound API, I think.

I didn’t have access to OceanConnect so I asked @afzal_m or @techniek to fix it for me, they can probably help you aswell.

You could try this in your arduino code:

MODEM_STREAM.print(“AT+CFUN=1”);
delay(4000);
MODEM_STREAM.print(“AT+CGDCONT=1,“IP”,“oceanconnect.t-mobile.nl””);
delay(4000);
MODEM_STREAM.print("AT+COPS=1,2,“20416"”);

This stopped working for me, no clue why:
AT+CGDCONT=1,“IP”,“oceanconnect.t-mobile.nl”
AT+CFUN=1 //radio on
AT+COPS=1,2,“20416”

(you don’t need to select band 8 everytime you connect, it will save the setting in NV memory even through powercycles)

Let me know if it works

@adriaan Misschien dat er een probleem met de sim kaart is.

Probeer anders eens:

• AT+CIMI (= IMSI)
• AT+CCID

etc.

@afzal_m

Will the new manual be ready before tuesday?
Btw, why did you decide to implement the new scrambling feature?

Good luck!

@jonathan-carter Or buy a good windows pc

@felixdonkers Beste Felix

Bedankt voor het delen van je bevindingen. Het gebruiken van scrambling zou inderdaad de SNR waarde en signaalpenetratie moeten verhogen, dit heeft een positief effect op het gebruikte zendvermogen.

Ik heb zelf de overstap nog niet gemaakt dus over de problemen die jij beschrijft kan ik nog weinig zeggen. Aankomende woensdag op het installfest van t-mobile ga ik er mee aan de slag, deze week zal ik een aantal soortgelijke testen uitvoeren.

@awk Je kunt beter @afzal_m vragen om je toegang te geven. Je profiel mist waarschijnlijk bepaalde rechten dus nieuwe documenten zul je ook niet kunnen zien.

@felixdonkers 23 mei bij het volgende installfest kunnen we er wel even goed naar kijken

@elfred-nieuwamerongen-van You can enable extended error reporting with the command AT+CMEE=1.

@paul-koenen Hoi Paul, als je opnieuw de collectie van T-mobile import op postman krijg je een aantal extra API calls, hiermee krijg je onder andere de optie om subscriptions te verwijderen.

Misschien ook handig om te weten voor anderen, als je deze stap van het manual opnieuw doet krijg je een aantal extra API calls: IMPACT manual Part 2

@paul-koenen Misschien is het een idee om eerste een stapje terug te doen, probeer het eens werkend te krijgen in node-red met een simpele http-in en http-response. Ik kan bevestigen dat het nog steeds werkt met node-red.