Eric,

Bedankt voor je antwoord! Ik heb mijn code toch iets simpeler gehouden met gewoon pollen met AT+CGATT? Dan hoef ik geen rekening te houden met URCs.

Het opnieuw connecten doe ik nu alleen als ik echt geen verbinding meer heb. Dus dit gebeurt eigenlijk niet zo vaak.

Handovers, jou verhaal verheldert wel een groot deel, dank daarvoor! Ik zag inderdaad netjes de PCI waarde van de cell veranderen na verloop van tijd. Dus dat werkte gewoon goed. Maar wat ik begrijp is dat dus een simpelere methode dan een echte handover.

Bij je laatste punt word het natuurlijk interessant! Stel ik verstuur een bericht en het wordt niet echt verstuurd maar het blijft in de buffer zitten?
Om welke reden kan dat gebeuren? Ik denk omdat er niet een goede verbinding is of omdat het versturen om een of andere reden iets langer duurt dan normaal? Dit zou betekenen dat ik dan net zo lang moet wachten tot het modem aangeeft dat de buffer leeg is?
Is dit een goede assumptie?

En dan zou ik moeten toevoegen dat mijn device dus pas weer data gaat versturen als de buffer leeg is?

Groetjes, Wieger

Nog maar even een update dan:

Even de meest stabiele situatie die ik nu heb:
Aanmelden op het netwerk:

bool connect() {
  1. wachten op signaal sterkte pollen met(AT+CSQ) met een timeout waarde van 60sec, 
    if (timeout) {reboot en nieuwe connectie poging.}
  2. Wachten op IP adres, pollen met(AT+CGATT?) met een timeout waarde van 120sec, 
    if(timeout) {reboot en nieuwe connectie poging.}
  3. Test ping naar de CDP server(AT+NPING=172.16.14.22) met timeout van 15 sec, 
    if (timeout) {reboot en nieuwe connectie poging.}
  Als het bovenstaande 3 stappen is gelukt dan ben je aangemeld en heb je een data connectie.
  return true;
}

bool sendData(data) {
  if( !_send_data(data) ) {
    // Verzenden van data niet gelukt.
   connect();
  }
}

void mainLoop() {
  sendData(data);
  delay(5000);
}

Ik heb gemerkt dat oplossingen zonder reboot van het modem uiteindelijk in een eindeloze ERROR state komen en daar komt hij dan niet meer uit. Mocht iemand andere ervaring hebben dan hoor ik dat ook graag.

Update:
Net nog even met een collega gesproken. En NB-IoT zoals die is gespecificeerd in juni 2016 heeft geen support voor handovers. Dat betekend dat de modules niet automatisch over zullen gaan naar een nieuwe cell. Ik had dit idee al een beetje, en ook nu ik alle Forum posts goed lees had ik dit ook al kunnen weten.

Als oplossing hiervoor noemen ze “autoconnect”. Deze functie kunnen we momenteel natuurlijk niet gebruiken met de huidige T-mobile opstelling. Tenminste dat staat zo beschreven in de handleiding. De auto connect zou er dan dus voor moeten zorgen dat de node zich zelf opnieuw aanmeld op ht netwerk bij het wisselen van een cel.

Ik denk dat dit heeft te maken met de het feit dat de simkaart IMSI niet begint met de nederlandse T-Mobile PLMN die we dus nu handmatig moeten selecteren. Maar ik hoor graag van Afzal of @ERICBARTEN of dat klopt.

Ik denk dus dat ik met de huidige simkaart zelf een soort autoconnect functie zal moeten bouwen. Weet iemand vanaf welk commando ik dan moet beginnen? Moet ik dan de device weer rebooten? en alles van voor af aan beginnen of hoef ik alleen maar het commando: AT+COPS=1,2,“20416” nog een keer te doen?

mvg, Wieger

Heren (en misschien dames?),

Ik ben nu uitgebreid de ublox SARA-N200 op een Arduino NB-IoT shield te testen. Ik ben nu opzoek naar een stabiele volgorde van AT commando’s zodat deze altijd opnieuw aanmeld al de connectie verdwenen is.

Ik heb echter 2 problemen:
Probleem 1 Als ik netjes ben aangemeld op het netwerk probeer ik elke 5 seconden 20 bytes te versturen via de COAP server. Echter na 100 of 200 berichten dan stop hij er mee. Hij geeft dan ERROR by het versturen van een Message.

De enige oplossing die ik hier voor kan bedenken is opnieuw aanmelden of een reboot doen? Of zijn er nog andere dingen die ik eerst kan proberen?

Probleem 2
Wat ik inderdaad ook merk is dat handovers niet goed werken? Als ik van de ene naar de andere Cell ga moet ik eigenlijk weer opnieuw aanmelden omdat de data verbinding daarna niet meer werkt en ik niks meer kan versturen.
Ik had ook al hier gekeken: https://forum.iot.t-mobile.nl/topic/51/roaming-performance/4
Maar daar staat niet echt aangeven wat je zou moeten doen.

Ik gebruik mijn aangepaste versie van de Sodaq lib voor Arduino. En inprincipe zou de module stand-alone moeten kunnen draaien. DWZ Accu, adriuno en NB-IoT shield echter heb ik nu vaak het mijn laptop er aan voor het debuggen.

Heeft iemand al een module die met zo een hoger frequentie al dit (1 keer per 5 seconden) dit werkend dan langer dan een uur?

Ik hoor graag wat jullie ervaringen zijn.

mvg, Wieger

Ik heb dit ook werkend! echter ook alleen bij de B656 firmware.

Misschien nog goed voor de nieuwe mensen die hier komen.
Nadat je hebt geupdate heb je waarschijnlijk versie:
V100R100C10B656

deze werkt ook goed met T-Mobile.
echter moet je de volgende commando’s voorlopig gebruiken om deze goed te laten werken.
AT+NCONFIG=CR_0354_0338_SCRAMBLING,FALSE
AT+NCONFIG=CR_0859_SI_AVOID,FALSE

mvg, Wieger IJntema

@maartentc said in Instructie: registreren van je eerste device:

UE Log Viewer gaf NO_SIM aan, en in het Quectel evaluation board bleek vervolgens de verbinding tussen BC-95 en SIM holder niet goed te zijn (lijkt op een productiefout in PCB). Met een paar draden was dit gefixed en werkt AT+CFUN=1 ook weer gewoon.

Laten we hopen dat de QA van de modules beter is. Of toch voor de Ublox gaan, heeft T-mobile daar ook ervaring mee?

Ik had dit net ook, misschien goed om mensen daar op te wijzen. Bij hielp het stevig aandrukken van de simkaart ook.

mvg, Wieger