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

    0_1502693110718_NB-IoTest.png

    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.

    0_1515773205719_07-network_attach-delay.jpg

    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.

    0_1515773345062_08-network_attach-delay_w._watchdog.jpg



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

    0_1515773778730_09-network_attach-aborts_distribution.jpg



  • 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).:

    0_1516294433650_tx_timing.png

    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 : 25
    

    Lijkt er op dat er packets verloren gaan. Hier een plotje van het veschil tussen
    de verzonden en ontvangen packet numbers:

    0_1518179901247_packet-drop_v5.67SP2_1.png

    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.



  • @intron

    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 -:

    @intron

    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;)

    ![0_1518874896685_packet-drop.png](/assets/uploads/files/1518874916074-packet-drop-resized.png

    @afzal_m said in - NB-IoTest -:

    @intron

    Thanks voor het delen van je bevindingen! Heb je kunnen testen hoe lang je device in sleep mode blijft?



  • @intron

    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 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:

    0_1519136587722_packet-drop.jpg



  • @andre-rodenburg said in - NB-IoTest -:

    @intron

    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.

    0_1519251625496_teller.png

    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. 0_1519497054352_packet intervals.png


Locked
 

Looks like your connection to Internet of Things was lost, please wait while we try to reconnect.