Stabiel krijgen ublox met arduino

wijntema

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

wijntema

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

wijntema

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.

afzal_m

@ericbarten @christiaanvermeulen @JanWillem @jan_sodaq @FransLutz

Iemand van jullie die een oplossing heeft?

ericbarten

Hoi @wijntema ik weet niet of ik je volledig op weg kan helpen maar ik heb wel enkele opmerkingen op basis van jouw informatie.

Allereerst in je Connect functie hoef je niet te pollen voor netwerk registratie met AT+CGATT? je kunt een URC aanvragen met AT+CEREG=2 dan krijg je een Unsollicited Result Code (URC) wanneer je verbonden bent met het netwerk.

Ten tweede is het niet noodzakelijk steeds opnieuw te connecten, je doet daar het netwerk ook geen plezier mee.

Het verhaal over handovers die niet werken geldt als je aan het communiceren bent. Als er geen communicatie is zal na een tijdje vanzelf een andere cel geselecteerd worden.

Ten derde wordt er slechts 1 bericht gebuffered, dus als je vorige bericht nog niet verzonden werd heeft het geen zin een nieuwe te versturen, je krijgt dan een error terug.

Ik hoop dat dit helpt om het stabieler te maken.

wijntema

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