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

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:

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.

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

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

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

Packet drop tijdens verzenden 28000+ packets:

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

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:

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.

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

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.

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.

@ericbarten Goed om te weten dat de data automatisch verwijderd wordt na een week. Ben een duurtest aan het doen voor de komende maanden, moet ik dus af en toe de boel even downloaden om geen metingen kwijt te raken.

Hoe kun je inPostman een andere ‘page’ zien dan de eerste?
Ik zie alleen deze:

{
“totalCount”: 1692,
“pageNo”: 0,
“pageSize”: 1692,
.
.
.

En is er een manier om de verzonden data weer te wissen?

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