Best posts made by felixdonkers

Veel toepassingen zullen het niet nodig hebben (alhoewel…), maar soms is het nodig om niet alleen korte berichtjes maar ook (middle-)grote bestanden te kunnen versturen of te ontvangen. Bijvoorbeeld als je een firmware upgrade wilt doen van je product of voor het versturen van uitgebreide meetdata in het geval je device een storing heeft. Met een download bandbreedte van 250kbps en een upload bandbreedte van 20kbps (of 250kbps igv dual tone) zou er binnen NBIOT wel wat mogelijk moeten zijn. Vraag: hoe is het versturen en ontvangen van bestanden binnen NBIOT het beste te realiseren?

Afzal once promissed to wash your car if you found a black spot in the NBIOT coverage. Wondering whether the offer still counts…

Seems to work fine

@afzal_m Ik ben vooral benieuwd wat de internationale afspraken hierover zijn, binnen 3GPP of GSMA. Want die 5 berichten per uur, geldt dat ook in andere landen waar T-mobile actief is en geldt dat ook voor andere providers (Vodafone etc)? En als we de applicatie beperken tot 5 berichten per uur, hoeveel % van de berichten gaat er dan maximaal verloren?
Dit zijn belangrijke parameters voor een robuust product ontwerp.

Today we’ve been doing some current measurements using an SODAQ NB-IoT board with an uBlox SARA-N211-02B (with v6.57 firmware). We notice some ‘strange’ behavior that might be related to the network. See the two pictures below. The first one is when transmitting 32 bytes, this is what I observe:

• sleep mode (~3 seconds)

• connection mode (~200 msec)

• transmit mode (~200 msec)

• receive mode (~22 seconds)

• idle mode (~1 second)

• eDRX mode (~27 seconds)

Now with 512 bytes I see a lot more, which a cannot explain:

• connection mode ? (from t=~3 until t=~23 seconds)

• transmit mode ? (from t=~24 until t=~35 seconds), i.e. 11 seconds for 512 bytes?

• a second transmit mode ? (from t=~56 until t=~58 seconds), why ?

Can this 512 byte transfer behavior be explained ?

T-mobile NL gebruikt band 8 voor NB-IoT, Zie frequentie tabel: https://en.wikipedia.org/wiki/LTE_frequency_bands

@nhan-nguyen use the ‘OpenSignal’ app available on iOS and Android. It will gave cell id and LAC code and show the cell to which your phone is connected. This is probably the same cell as for your NB-IOT device.

Klopt, NB-IOT heeft een bandbreedte van 180kHz, maar wel aparte kanalen voor uplink en voor downlink. Dus als je 1 antenne wilt gebruiken dan zal ie inderdaad 80MHz bandbreedte moeten hebben. Aparte antennes voor up en down link kan wellicht maar is zeker niet kosteneffectief. De reden voor de 180kHz bandbreedte is dan ook niet bedoeld voor de antenne zelf maar voor de antenneversterker van de zender, die kan daardoor energiezuinig ontworpen worden. Antenne efficiëntie is natuurlijk belangrijk, kies er maar een met een grote gain en plaats hem zodanig dat ie geen last heeft van omgevingsfactoren. Maar een extreem grote range is voor NB-IOT in Nederland niet noodzakelijk, de antennedichtheid van T-Mobile is enorm groot, zeker tov LoRa. Bovendien moet niet alleen de zender erg nefficient zijn maar ook de ontvanger. NB-IOT is namelijk, in tegenstelling tot LoRa, een protocol met veel interactie tussen UE en zendmast.

@afzal_m Krijgen we op 9 maart ook de volgende vraag beantwoord? Wanneer worden de MVP specificaties voor het NB-IoT netwerk gehaald, zowel qua (minimale) functionaliteit en performance, opdat we ook producten kunnen gaan ontwikkelen die zich overal ter wereld hetzelfde gedragen ?

@techniek Het verschil in LTE banden is bekend en daar kun je op designen. Ik ben inderdaad benieuwd naar die andere regionale verschillen, opdat we er bij by-design rekening mee kunnen houden. Hopelijk zijn die verschillen minimaal en leiden ze niet tot ander functioneel gedrag. Denk aan: wel of geen CDP, instellingen van de timers, andere latencies, etc.

@pieterhoenderken NB-IoT supports geo-localisation based on the network itself. At this moment only cell-ID can be used, accuracy of course depends on the cell density. As of release 14, NB-IoT will also support triangulation which is much more accurate (<100mtr). Don’t know what’s currently and will be supported by T-Mobile NL.

@felixdonkers 1 opvallend verschil is dat in NL alleen de uBlox N2xx is getest en dat die niet geschikt is voor gebruik in de USA. Daar wordt vooral de R410M-02B gepropagandeerd, maar die is helaas nog niet vrijgegeven op het netwerk in NL, zie ook: https://docs.iot.t-mobile.nl/docs/hardware. Is al bekend wanneer de R410 in Nederland wel geschikt wordt voor commercial deployment?

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

@afzal_m Deze vraag kan ik alleen in algemene zin beantwoorden. Ik zal er een separate treat voor opzetten zodat ook anderen hun input kunnen geven.

@Afzal_m Testen gedaan met
1.SARA N211 02B-00
2.06.57,A03.02 en 06.57,A07.03
Cell tower en postcode stuur ik vanavond per PM toe.

@techniek In ons geval (N211) kunnen de parameters in het modem wel gewijzigd worden, en bij read-back blijken de registers ook aangepast, maar het gedrag van het modem (en daarmee ook het stroomprofiel) verandert daardoor niet. Vandaar de aanname dat de timers door het network nog niet ondersteund worden.

P.s. wij meten de stroom door VCC naar het modem te onderbreken, daar een 1 ohm weerstand te plaatsen en daar het stroomprofiel over te meten. Daarmee meet je het stroomverbruik van het modem en de SIM kaart. In indel stand is dat ca 10 uA.

As indicated, you should wait until CSQ replies with something else than 99.99, e.g. 12.99. But you should also wait until CGATT replies with a ‘1’ instead of a ‘0’, indicating that the modem is connected to the network. This often takes more than 10 seconds…

@adriaan ATI9

@jonathan-carter Hi, this is known (timing) problem. The UEupdater very much relies on the timing of the PC’s serial port driver. E.g. in our case, corporate laptops often have shown serious problems, and I can imagine that virtualbox systems also have similar problems. In my case using a ‘family’ laptop solved the issue. It should be able to find someone with a regular family laptop in A’dam I hope, or are they all on Apple machines?

@jonathan-carter no experience with XP but it’s worth a try. Otherwise I suggest to go to one of the upcoming TMNL installfests. I’m sure there are people willing to help there.

Hi,

Inmiddels heb ik de migratie naar het Nokia Impact platform volledig doorgevoerd (UE firmware, settings, netwerk, cloud), en op basis daarvan een eerder experiment herhaald. De gebruikte software is daarbij zoveel mogelijk identiek gehouden. Alleen de door T-Mobile aangegeven noodzakelijke aanpassingen zijn doorgevoerd:

• scrambling aan (was uit)
• andere APN
• ander CDP IP-adres
• instellen van de Nokia Impact configuratie (o.a. aanmelden devices en instellen van de north applicatie)
• gewijzigde data extractie wegens andere JSON structure tbv de north application

De PSM en eDRX instellingen zijn bijv. dus nog niet aangepast. Naar ik heb begrepen volgt dit zeer binnenkort.

De ruwe data van zowel oude als de nieuwe experimenten plus wat eerste grafieken heb ik verzameld in een XLS. Ik kan 'm hier niet uploaden maar desgewenst evt wel toesturen.

Hierbij een samenvatting van mijn bevindingen:

• De migratie naar Nokia Impact verliep eigenlijk vrij soepel. mede door de heldere stappen op dit forum was het opnieuw up&running krijgen van mijn test applicatie binnen een 1/2 dag gebeurd .
• Wat als eerste opvalt is dat het modem nu met andere masten (i.e. andere cell-ID’s) verbinding maakt dan voorheen. Da’s vreemd, de test lokatie is niet veranderd, waarom de cell dan wel? Of zijn alle cellen tbv Nokia Impact spontaan hernummerd?
• In de eerdere testen was het modem zo nu en dan de weg kwijt (dwz. gaf om onduidelijke redenen onbruikbare waardes uit voor o.a. ECL, CSQ, RSSI, RSRP, etc). Na de migratie is dit probleem niet meer opgetreden; vreemd ?
• De RSRQ waarde lijkt nu hoger en gelijkmatiger dan voorheen (-10dBm ipv -20 dBm). Kennelijk is de signaalkwaliteit na de migratie significant verbeterd .
• Het N211 zendvermogen is na de migratie beduidend lager dan voorheen; Tx power <10 dBm ipv 23dBm. Op zich erg positief wat dat scheelt batterijverbruik . Maar wat de verklaring; scrambling on, of meer masten aangezet (zie ook cell-ID issue)?
• Net als in de oude situatie valt de verbinding regelmatig weg en moet er regelmatig opnieuw geregistreerd worden. In de nieuwe situatie is dat (toevallig??) elke 2 uur. Dit is uiteraard niet gunstig voor het batterijverbruik.
• Net als in de oude situatie komen ook na de migratie nog steeds niet alle berichten aan in de cloud. Dit terwijl het modem geen enkele foutmelding geeft.

Ergo: De migratie naar Nokia impact kostte weining moeite en heeft duidelijke verbeteringen opgeleverd, maar enkele serieuze problemen zijn nog steeds niet opgelost .

Via LinkedIn leerde ik over een T-Mobile NBIOT training die kennelijk in het buitenland al gegeven wordt. Is iets dergelijks binnenkort ook in nederland te verwachten? Zou wat mij betreft zeer welkom zijn.

P.s. bijgevoegde slide verteld iets over ECL levels, een onderwerp waar ik voor de overgang naar Nokia Impact erg veel tijd aan verloren heb . Uit metingen bleek namelijk dat het N211 modem om onverklaarbare redenen vooral in ECL-level 2 modes opereerde, ook in de buitenlucht. Sinds de overgang naar Nokia Impact en het aanschakelen van scrambling lijkt dit probleem over.