- NB-IoTest -
-
Bordje gemaakt met als doel een zo laag mogelijk stroomverbruik
te realiseren zodat gevoed kan worden uit een enkele batterij. MCU
clock staat zo laag mogelijk, power naar alle delen van de hardware
zijn firmware controlled en er komt nog code zodat de MCU het
grootste deel van de tijd in een low-power stop mode staat.
Connecten met het network lukt, pingen van de server ook,
alleen blijven messages nog ‘pending’, dus dat moet nog ff
gefixed worden.En nog een dankje aan de jongens van SODAQ voor de
mooie gratis antenne:) -
Wauw! Cool bordje en mooie foto’s!
Wat betreft je pending messages: heb je je device al geregistreerd via de rest API?
-
@intron Mooi!
Zie ook deze thread voor je pending probleem:
https://forum.iot.t-mobile.nl/topic/45/pending-messages/7 -
@afzal_m Ik heb de SIM gebruikt die ook in mijn
SODAQ bord zat en dat bord werkt gewoon. Maar
ik zal dit nieuwe bord ook eens aanmelden.Hangt aanmelden dan af van een ID in de u-blox/
BC95 module en niet van de SIM? -
Cool! Het is niet afhankelijk van SIM maar van IMEI. Als je IMEI al dus bekend is in het IoT platform van Sodaq, zul je 'm dus niet bij ons kunnen registeren. In dat geval kun je het best eerst aan Sodaq vragen om daar jouw device registratie te deleten.
-
@afzal_m Spullen werken nu, kan data verzenden.
Bedankt voor de hulp. -
Het viel me op dat het maken van een netwerk connectie niet altijd
even lang duurt. Na power-up van de BC95 NB-IoT module neemt
het stroomverbruik flink toe, dus de tijd dat de module under power
is kan het best zo kort mogelijk zijn. Heb wat code gemaakt om de
network attach tijd te loggen, zie plotje.
Meestal is een connectie tot stand gebracht in zo’n 20 seconden,
maar er zijn enorme uitschieters. Een watchdog laten meelopen
en die laten ingrijpen na zeg 30 seconde helpt.
-
En dan hier nog een distributie van de ‘attach aborts’, dus
de verdeling in de tijd van momenten dat een attach te lang
duurde en de module gereset werd om opnieuw te proberen.
Is geen uniforme verdeling, geen idee waarom.
-
Interresante test, ik ervaar hetzelfde maar heb nog geen uitgebreide testen kunnen doen. Ik heb wat aanvullende vragen:
-
Welk AT commando is het meest tijdrovend, bijv wachten op AT+CSQ of AT_CGATT? of … ?
-
is er nog een afhankelijkheid van de signal kwaliteit (bijv vanwege afstand tot cell / indoor) ?
-
is er nog een afhankelijk van tijdstip van de dag (bezetting van de cell) ?
-
-
Nadere bestudering van de datasheet van een bekend NB-IoT modem leert dat de responsetijd op network commando’s (zoals CGATT) tot 3 minuten kan duren. Da’s wellicht een spec in 3GPP NB-IoT standaard.
-
@felixdonkers said in - NB-IoTest -:
Interresante test, ik ervaar hetzelfde maar heb nog geen uitgebreide testen kunnen doen. Ik heb wat aanvullende vragen:
-
Welk AT commando is het meest tijdrovend, bijv wachten op AT+CSQ of AT_CGATT? of … ?
-
is er nog een afhankelijkheid van de signal kwaliteit (bijv vanwege afstand tot cell / indoor) ?
-
is er nog een afhankelijk van tijdstip van de dag (bezetting van de cell) ?
Ik heb een log gemaakt met timing van de stappen die gedaan worden om een
packet te verzenden. Meeste tijd gaat zitten in het opzetten van de verbinding
(met ‘AT+COPS?’ pollen of het al gelukt is).:
Soms blijft een message lang ‘pending’, dat kost dan ook nog wat tijd. Merk wel dat
ongeveer 1% van de packets niet aankomt op de T-Mobilie server, packet drop is veel
minder als de BC95 module stteeds onder power blijft lijkt. -
-
Met wat kunst en vliegwerk firmware V5.67SP2 in een BC95 weten te schieten
om er achter te komen dat PSM nu werkt en de module tijdens idle time niet
meer van de voeding afgeschakeld hoeft te worden om stroom te sparen. Er
hoeft dan maar eenmaal een connect gemaakt te worden met het netwerk,
dus data transmit kan veel sneller dan voorheen.Lees wat sensoren uit, middel/min/max de data en stop het in een JSON met packet
counter. Dat gaat naar de overkant zodat vergeleken kan worden of er een verschil
is in het aantal verzonden en aangekomen packets.t: 20.7 h: 35.1 p: 1018 t: 20.7 h: 35.2 p: 1018 t: 20.7 h: 35.2 p: 1018 t: 20.7 h: 35.2 p: 1018 t: 20.7 h: 35.2 p: 1018 t: 20.7 h: 35.2 p: 1018 0x0000 - 7b 22 6e 22 3a 20 32 35 - 2c 20 22 76 62 61 74 22 : {"n": 25, "vbat" 0x0010 - 3a 20 33 2e 31 33 2c 20 - 22 74 5f 6d 69 6e 22 3a : : 3.13, "t_min": 0x0020 - 20 32 30 2e 37 2c 20 22 - 74 5f 6d 61 78 22 3a 20 : 20.7, "t_max": 0x0030 - 32 30 2e 37 2c 20 22 74 - 5f 61 76 67 22 3a 20 32 : 20.7, "t_avg": 2 0x0040 - 30 2e 37 2c 20 22 68 5f - 6d 69 6e 22 3a 20 33 35 : 0.7, "h_min": 35 0x0050 - 2e 31 2c 20 22 68 5f 6d - 61 78 22 3a 20 33 35 2e : .1, "h_max": 35. 0x0060 - 32 2c 20 22 68 5f 61 76 - 67 22 3a 20 33 35 2e 31 : 2, "h_avg": 35.1 0x0070 - 2c 20 22 70 5f 6d 69 6e - 22 3a 20 31 30 31 38 2c : , "p_min": 1018, 0x0080 - 20 22 70 5f 6d 61 78 22 - 3a 20 31 30 31 38 2c 20 : "p_max": 1018, 0x0090 - 22 70 5f 61 76 67 22 3a - 20 31 30 31 38 7d 00 00 : "p_avg": 1018}.. 0x00a0 - 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 : ................ start : 00000 [ms] get APN (AT+CGDCONT?) : 01000 [ms] APN set, go on : 04000 [ms] get radio state (AT+CFUN?) : 05000 [ms] radio is on, go on : 07000 [ms] get operator (AT+COPS?) : 08000 [ms] connected with operator : 10000 [ms] get network state (AT+CGATT?) : 11000 [ms] connected with network, go on : 13000 [ms] get current Tx queue state : 14000 [ms] send JSON : 16000 [ms] get updated Tx queue state : 18000 [ms] pending messages: 0 sent messages : 25 errors : 0 Tx done, packet : 25Lijkt er op dat er packets verloren gaan. Hier een plotje van het veschil tussen
de verzonden en ontvangen packet numbers:
Nog geen idee waar dit vandaan komt. Stap nu met 1 Hz door een state machine heen die de BC95
stuurt, als dat wordt verhoogd naar 10Hz of 100Hz neemt ogenschijnlijk het aantal verloren packets toe. -
Thanks voor het delen van je bevindingen! Heb je kunnen testen hoe lang je device in sleep mode blijft?
-
@afzal_m said in - NB-IoTest -:
Thanks voor het delen van je bevindingen! Heb je kunnen testen hoe lang je device in sleep mode blijft?
Hoe bedoel je dat precies? Ik zend nu nog alleen, dus bij
ieder AT command dat naar de BC95 verzonden wordt
gaat de module uit sleep mode om na executie automatisch
weer terug te keren naar sleep mode.Op de multimeter zie ik inderdaad de beloofde 5uA
‘Deep Sleep State Current’.Packet drop snap ik echter nog niet. Lange test gedaan en
meer dan 28000 packets verzonden en gekeken wat er aan
de andere kant aankwam. Gaat hele stukken goed en dan
gebeurt er wat lijkt. (Die naaldjes op de plot zijn packets die
out-of-order uit Postman komen, dat is verder geen probleem.)
Zal nog eens goed naar m’n ARM code kijken;)
-
Ik heb net een testje gedaan met de UBLOX firmware:
name value type_number SARA-N200-02B modem_version 06.57 application_version A07.03 manufacturer u-blox Hier is een trace met wat indicaties voor de response tijden van de commands, op 9600 baud:
De scrambling setting staat op TRUE, en is alleen van toepassing voor een aantal test sites… Later zal dit default aan staan voor het gehele netwerk…1519043532.805931 > AT+CFUN=0 1519043532.855598 < OK [50 ms] 1519043532.855884 > AT+NCONFIG="AUTOCONNECT","TRUE" 1519043532.899101 < +CEREG: 0,"0000","0",7,, OK [43 ms] 1519043532.899360 > AT+NCONFIG="CR_0354_0338_SCRAMBLING","TRUE" 1519043532.954500 < OK [55 ms] 1519043532.954778 > AT+NCONFIG="CR_0859_SI_AVOID","TRUE" 1519043533.002462 < OK [48 ms] 1519043533.002725 > AT+NCONFIG? 1519043533.304685 < +NCONFIG: "AUTOCONNECT","TRUE" +NCONFIG: "CR_0354_0338_SCRAMBLING","TRUE" +NCONFIG: "CR_0859_SI_AVOID","TRUE" +NCONFIG: "COMBINE_ATTACH","FALSE" +NCONFIG: "CELL_RESELECTION","FALSE" +NCONFIG: "ENABLE_BIP","FALSE" +NCONFIG: "NAS_SIM_POWER_SAVING_ENABLE","TRUE" OK [302 ms] 1519043533.304990 > AT+NCDP="172.16.14.22" 1519043533.339584 < OK [35 ms] 1519043533.339868 > AT+CGDCONT=1,"IP","oceanconnect.t-mobile.nl" 1519043533.395785 < OK [56 ms] 1519043533.396048 > AT+NRB 1519043537.439082 < REBOOTING \x{00}&\x{FC}\x{00}\x{A2}\x{B0}\x{00} REBOOT_CAUSE_APPLICATION_AT u-blox 1519043537.439399 > AT+CGDCONT? 1519043537.493356 < +CGDCONT: 0,"IP",,,0,0,,,,,1 OK [54 ms] 1519043537.493645 > AT+CFUN? 1519043537.523257 < +CFUN: 0 OK [30 ms] 1519043537.523541 > AT+CEREG=3 1519043537.543134 < OK [20 ms] 1519043537.543393 > AT+CFUN=1 1519043539.007523 < +CEREG: 0,"0000","0",7,, OK [1464 ms] 1519043539.007792 > AT+CIMI 1519043539.044882 < 901405700000000 OK [37 ms] 1519043539.045215 > AT+NBAND=8 1519043539.065764 < OK [21 ms] 1519043539.066032 > AT+COPS=1,2,"20416" 1519043539.095258 < OK [29 ms] 1519043539.095540 > AT+CSQ 1519043539.146033 < +CEREG: 2,"0000","0",7,, +CSQ: 99,99 OK [50 ms] 1519043540.146617 > AT+CSQ 1519043540.178023 < +CSQ: 15,99 OK [31 ms] 1519043540.178323 > AT+CGATT? 1519043540.210179 < +CGATT: 0 OK [32 ms] 1519043541.210781 > AT+CSQ 1519043541.243340 < +CSQ: 13,99 OK [33 ms] 1519043541.243653 > AT+CGATT? 1519043541.275906 < +CGATT: 0 OK [32 ms] 1519043542.276462 > AT+CSQ 1519043542.308554 < +UFOTAS: 0,1 +CSQ: 13,99 OK [32 ms] 1519043542.308867 > AT+CGATT? 1519043542.341434 < +CGATT: 0 OK [33 ms] 1519043543.341963 > AT+CSQ 1519043543.387685 < +CEREG: 5,"04EE","6C8E67",7,, +CSQ: 14,99 OK [46 ms] 1519043543.388000 > AT+CGATT? 1519043543.420091 < +CGATT: 1 OK [32 ms] 1519043543.420481 > AT+NSMI=1 1519043543.438579 < OK [18 ms] 1519043543.438853 > AT+NMGS=11,"48656c6c6f20576f726c64" 1519043544.394786 < +NSMI: SENT OK [956 ms] -
Image uploaden ging niet echt lekker, nog maar een keer dan.
Packet drop tijdens verzenden 28000+ packets:
-
@andre-rodenburg said in - NB-IoTest -:
Beste Intron,
Erg fijn dat je je bevindingen deelt!
Ik heb een paar vraagjes. Welke MCU gebruik je? Zou ik misschien je code mogen zien? Ik ben erg benieuwd hoe jij het aan pakt :)
Ik gebruik nu een STM32L151, die heeft een sleep mode met
heel weinig verbruik. Maar de MCU maakt niet veel uit, je
moet gewoon die AT commands naar het modem sturen
met 9600 Baud en de response afwachten. Dat kan met zo
ongeveer iedere MCU. (Kan zelfs met de hand vanuit een
terminal emulator:)En PM me maar, kunnen we het over de code hebben.
-
Vannacht een soortgelijke test gedaan met een tweetal SODAQ NB-IoT boards; eentje met een uBlox N200 en eentje met een N211 modem. Beiden modem bevatten 06.57 firmware (AT+CGMR) en in beide gevallen staat scrambling uit. Het cell-ID = 6405223 (AT+NEUSTATS). In beide gevallen draait exact hetzewlfde programma op de Crowduino (op wat AT-syntax verschillen na vanwege de verschillende modems).
De test is eenvoudig; elke 150 seconde (2.5 min) wordt een bericht van 46 bytes opgestuurd. In die payload zit een teller die bij elk bericht met 1 opgehoogd wordt en een timestamp (msec van de MCU) waarop het bericht verzonden is. In de log bij de ontvanger wordt daar nog een server_timestamp aan toegevoegd zodra het sample bij mij ontvangen wordt. De totale test duurt ~18,5 uur.
Wat opvalt is dat het verzenden met de N200 prima verloopt. Alle samples komen keurig en ook op de juiste volgorde binnen. Met de N211 gaat het minder goed. Dwz regelmatig (om de 1 a 2 uur, geen vast interval) valt de verbinding weg en moet het device opnieuw geregistreerd worden. Na 7.5 uur (180 samples) lukt het helemaal niet meer om verbinding te maken. Wat ook opvalt is dat er regelmatig samples ontbreken en soms ook niet in de juiste volgorde ontvangen worden.
Bovenstaand figuur illustreert dat. Het horen 2 rechte lijnen te zijn; de ene geeft de tellerstand weer, de andere de delta van de tellerstand tussen 2 opeenvolgend ontvangen samples. Positieve waarde betekent dat er een gat in de tellerstand zit, een negatieve waarde betekent dat er oude samples ontvangen worden. Met name vanaf sample 150 (na 6.25 uur) lijkt er iets goed fout te gaan.
Het verschijnsel is niet nieuw, ook in eerdere treats is er al over gesproken. Ben ewrg benieuwd of deze problemen in de volgende netwerk release opgelost gaan zijn.
-
Kleine aanvulling; in tegenstelling tot eerder bericht treedt het effect ook op bij een N200. Dzw ontbrekende samples, samples in verkeerde volgorde, en veel jitter op de aankomsttijd van een berichtje. Ter illustratie van het laatste hierbij nog een grafiekje dat de jitter illustreert. Weergegeven is de intervaltijd tussen twee opeenvolgende berichten. De berichten worden elke 2,5 minuut verstuurd, om de 150 sec dus.
-
Nog een meting, nu met N211 met nieuwe uBlox firmware (06.57,A07.03). De intervaltijd tussen opeenvolgende berichten is nu 60sec. Deze keer komen alle samples in de juiste volgorde binnen en ontbreken er slechts 2 van de 1225 samples (0,16%). Wel zit er nog grote spreiding op het tempo waarin de samples ontvangen worden. In het eerste plaatje is te zien dat de variatie op het interval typisch kleiner is dan +/-20 sec. Op het 2e plaatje is te zien dat er soms grote uitschieters zijn, met als grootste uitschieter bij sample 716. Daar werden een 8-tal samples ca8 minuten gebufferd en daarna alsnog als burst verstuurd.
-
Ik heb zelf ook een meting gedaan. Interval tijd was 60 sec, hetzelfde als de test van @felixdonkers dus. Ik maak ook gebruik van de Ublox N211, wel met oudere firmware (06.57,A03.02).
Zoals je kan zien is de interval redelijk stabiel, behalve rond 12:07 en in het begin. Ook zijn er geen samples kwijt geraakt of in verkeerde volgorde aangekomen.
Helaas viel ook bij mij na 2 uur de verbinding weg. Aangezien vrijwel iedereen met elk modem en elke firmware hier last van heeft (zover ik gelezen heb op het forum) ga ik er van uit dat dit een fout is bij T-Mobile. Het om de 2 uur verliezen van de connectie heeft grote gevolgen op het stroomverbruik dus ik ben benieuwd wanneer dit opgelost gaat worden…
Hoe lossen jullie momenteel het verliezen van de verbinding op? Ik dacht aan het CGATT of het COPS commando, dan kun je na ieder bericht pollen of je nog verbinding hebt maar ik heb dit nog niet getest.
-
@andre-rodenburg Opvallende verschillen, overigens lijkt dit niet afhankelijk te zijn van de firmware versie. Ook met de (06.57,A03.02) versie had ik dezelfde effecten. Mbt het 2 uur disconnect fenomeen, ikzelf gebruik voor elke Tx een CGATT om te kijken of er nog verbinding is, zo niet dan reset ik het modem en registreer ik opnieuw. Da’s inderdaad niet zo batterij vriendelijk :-(.
