iotcreators.com web
    • Login
    • Search
    • forum.iotcreators.com
    • docs.iotcreators.com
    • Tags
    • Popular
    • Recent
    • Register

    - NB-IoTest -

    Archive
    7
    36
    11557
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • intron
      intron last edited by

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

      cvonken 1 Reply Last reply Reply Quote 1
      • afzal_m
        afzal_m iotcreators.com team last edited by

        Wauw! Cool bordje en mooie foto’s!

        Wat betreft je pending messages: heb je je device al geregistreerd via de rest API?

        intron 1 Reply Last reply Reply Quote 0
        • cvonken
          cvonken @intron last edited by

          @intron Mooi!
          Zie ook deze thread voor je pending probleem:
          https://forum.iot.t-mobile.nl/topic/45/pending-messages/7

          1 Reply Last reply Reply Quote 1
          • intron
            intron @afzal_m last edited by

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

            1 Reply Last reply Reply Quote 0
            • afzal_m
              afzal_m iotcreators.com team last edited by afzal_m

              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.

              intron 1 Reply Last reply Reply Quote 0
              • intron
                intron @afzal_m last edited by

                @afzal_m Spullen werken nu, kan data verzenden.
                Bedankt voor de hulp.

                1 Reply Last reply Reply Quote 0
                • intron
                  intron last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • intron
                    intron last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • felixdonkers
                      felixdonkers last edited by

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

                      intron 1 Reply Last reply Reply Quote 0
                      • felixdonkers
                        felixdonkers last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • intron
                          intron @felixdonkers last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • intron
                            intron last edited by

                            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.

                            afzal_m 1 Reply Last reply Reply Quote 1
                            • afzal_m
                              afzal_m iotcreators.com team @intron last edited by

                              @intron

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

                              intron 1 Reply Last reply Reply Quote 0
                              • intron
                                intron @afzal_m last edited by

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

                                A intron 2 Replies Last reply Reply Quote 0
                                • A
                                  Andre Rodenburg @intron last edited by

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

                                  intron 1 Reply Last reply Reply Quote 0
                                  • T
                                    techniek last edited by techniek

                                    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]
                                    
                                    A 1 Reply Last reply Reply Quote 0
                                    • intron
                                      intron @intron last edited by

                                      Image uploaden ging niet echt lekker, nog maar een keer dan.

                                      Packet drop tijdens verzenden 28000+ packets:

                                      0_1519136587722_packet-drop.jpg

                                      1 Reply Last reply Reply Quote 0
                                      • intron
                                        intron @Andre Rodenburg last edited by

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

                                        1 Reply Last reply Reply Quote 1
                                        • felixdonkers
                                          felixdonkers last edited by

                                          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.

                                          felixdonkers 1 Reply Last reply Reply Quote 0
                                          • felixdonkers
                                            felixdonkers @felixdonkers last edited by

                                            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

                                            1 Reply Last reply Reply Quote 0
                                            • felixdonkers
                                              felixdonkers last edited by

                                              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.0_1519761676037_sample1.png
                                              0_1519761688919_sample2.png

                                              1 Reply Last reply Reply Quote 0
                                              • A
                                                Andre Rodenburg last edited by

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

                                                alt text

                                                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.

                                                felixdonkers 1 Reply Last reply Reply Quote 0
                                                • felixdonkers
                                                  felixdonkers @Andre Rodenburg last edited by

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

                                                  1 Reply Last reply Reply Quote 1
                                                  • 1
                                                  • 2
                                                  • 1 / 2
                                                  • First post
                                                    Last post