Posts made by felixdonkers

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

Zendvermogen wordt inderdaad automatisch geregeld tussen modem en zendmast. Wel is er in de NBIOT standaard een maximum zendvermogen van 23dBm vastgelegd. Daarnaast moet je er rekening mee houden dat het modem berichten zal gaan herhalen als de signaalkwaliteit slecht is, bijvoorbeeld ondergronds; de zgn ECL1 en 2 modes die ook eerder al eens op dit forum zijn besproken.

I didn’t post anything here… Who’s posting in my name?

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

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

Zoals te lezen is in onderstaand artikel, heeft T-mobile nu ook een NB-IoT netwerk live in de USA.
https://www.t-mobile.com/content/t-mobile/corporate/news/articles/2018/07/americas-first-narrowband-iot-network.html. Kan ik producten die in Nederland getest zijn nu ook zondermeer in de USA inzetten?

@techniek Nog een vraagje: je geeft aan dat COAP impliciet al gebruik maakt van early release. Betekent dit dat er met COAP geen downlink berichten mogelijk zijn (net zoals bij UDP met early release) ?

Proficiat met deze resultaten. Ik ben benieuwd onder welke RF condities deze metingen gedaan zijn, rssi waarde, TX power waarde, etc.

Heb je deze metingen ook al gedaan onder corner case situaties, dwz onder ECL1 en 2 mode condities?

Verder wordt in het volgende artikel gesproken over nog veel energie zuinigere technologie. Hebben jullie daar al concrete ervaring mee? https://www.eetimes.com/document.asp?doc_id=1332677

Bovendien kent NBIOT verschillende modes voor het gebruik van het LTE spectrum, zie figuur en ook white paper van Rohde en Schwartz (https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1ma296/1MA296_0e_NB-IoT_Measurements.pdf). Ik heb geen idee welke mode T-Mobile gebruikt.

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.

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

Multicast downlink is onderdeel van rel14. Veel netwerken en modems ondersteunen dit nog niet, die zitten nog op rel13.

Logisch dat je mikt op een alternatief voor LoRa en Sigfox.

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

Interessante test. Ik heb eerder ook hoge packet loss issues gehad, maar sinds scrambling aan staat was dat (nagenoeg) verdwenen. Nu is 1 bericht per seconde ook wel heel erg veel. Volgens mij is de TMNL netwerk capaciteit berekend op 10 berichten per uur (althans dat is hun eerder gecommuniceerde commerciële aanbod).

Je test is overigens wel erg relevant. Want stel dat je incidenteel een bestandje met uitgebreidere meetdata zou willen opsturen, dan zou je dat binnen de huidige NBIOT implementatie moeten opknippen in korte berichten (bijv 10kB = 20*512B) en apart versturen. Uiteraard mogen er hierbij geen pakketten verloren gaan, en een interval van 1 pakket per 6 minuten is niet wenselijk.

Misschien kun je de test herhalen met andere intervallen, bijvoorbeeld 1 bericht per 5 sec, 10 sec, 20 sec, 1 min, 2 min, 5 min, 10 min, 20 min, etc? Kijken of er een trend waarneembaar is.

p.s. Ben benieuwd hoe het netwerk gaat reageren op de SODAQ test die deze week wordt uitgevoerd; 100 devices op dezelfde mast, het is onbekend van hoeveel berichten per uur deze test uitgaat.

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?

@eric-barten, zie snapshot

@felixdonkers vandaag nog een geprobeer, zonder succes. Zie device detail hieronder.

Ik geef het op. Wellicht nog eens proberen tijdens een installfest ofzo…

===

{
“id”: 581,
“updatedOn”: 1525951104000,
“createdOn”: 1525951104000,
“deviceId”: “IMEI:357518080035967”,
“networkId”: “”,
“subscriberId”: “”,
“managed”: true,
“inUse”: true,
“model”: “Sensor”,
“manufacturer”: “Generic”,
“os”: “other”,
“logging”: false,
“hssSubscribe”: false,
“protocolRealm”: [
“NBIOT-SGI”,
“LORA”,
“DIAMETER”,
“XIRGO”,
“IMPACT_LWM2M”,
“MBUS”,
“OMA-DM”,
“HTTP”,
“MQTT-AL”,
“VA”
],
“nativeClient”: {
“bootstrap”: {
“type”: “FBU”,
“state”: “BOOTSTRAPPED”
},
“credentials”: {
“serverPassword”: “",
“clientUsername”: “188586798598929”,
“clientPassword”: "”
},
“operationalState”: [],
“pushChannels”: [
{
“name”: “SMS”,
“state”: “UP”
}
]
},
“customAttributes”: {
“attribute1”: “{“aggregateOfAttributesList”:[{“adaptationLayerName”:“TMNL_UDP_AL”}]}”,
“attribute3”: “HTTP”
},
“serviceTags”: [],
“dynamicVariables”: [],
“userTags”: []
}

@techniek Device opnieuw registreren is gelukt, ook de north bound en de subsc ription. Daarna HW opnieuw opgestart en succesvol UDP data verzonden. Komt echter niet aan op mijn UDP server :-(. Ik ben er zeker van dat portforwarding etc good staat want via node-red versturen en ontvangen lukt prima. Kan ik ergens anders zien dat het bericht daadwerkelijk door de CDP verstuurd is?

@andre-rodenburg Krijg het niet werkend. Kan het device namelijk niet toevoegen. Ik krijg nu foutmelding:

Terwijl het IMEI nummer niet voorkomt in de lijst die ik kan opvragen middels “get all devices”.

@andre-rodenburg Ik ben eigenlijk wel benieuwd in het praktische gebruik van de T3324 timer, met name in de vrijheid die een product ontwerper heeft om de 20 seconden terug te brengen naar een minimale waarde zonder dat de performance van het systeem er onder gaat leiden. Concrete vraag: op welke (minimale) waarde moet de T3324 timer ingesteld worden om betrouwbaar berichten te kunnen ontvangen die op de server klaar staan? En is deze waarde voor alle situaties hetzelfde, bijv. outdoor vs indoor vs basement (ECL levels)?

@andre-rodenburg Ik zie net een email van afzal dat voor UDP een device op een andere manier geregistreerd moet worden (dwz andere adaptationLayerName). Wil dit zojuist uitproberen in Postman maar krijg als response:
{
“msg”: “License expired for HTTP”,
“code”: 8000
}

@Afzal, is mijn licentie inderdaad verlopen?

Ik gebruik overigens een uBlox N211 en de AT-commando’s uit: https://forum.iot.t-mobile.nl/topic/110/udp-data-met-nsost