@andre-rodenburg said in PSM op de uBlox SARA-N211:
CPSMS
Vanuit verschillende kanten heb ik begrepen dat timers nog niet via de UE (modem) zijn in te stellen… En dat hier een update van de netwerksoftware is vereist…
Echter volgens mij veel echo, maar heeft nog niemand dat getest…
Ik ga het vandaag is proberen te testen… 
AT+CEREG=<n>
9.6.1 Description
Controls the presentation of the network registration URC.
Dus alleen de manier van presenteren…
Wil je met de timers en PSM experimenteren dan gebruik je:
AT+CPSMS
Je hebt gelijk!
In mode 5 krijg ik ook informatie over de timers…
AT+CEREG=5
AT+CEREG=5
< OK [37 ms]
AT+CEREG?
AT+CEREG?
< +CEREG: 5,5,“04ED”,“200867”,7,“00001111”,“01011111” OK [98 ms]
@felixdonkers said in NB-IOT in nomadic mode:
Will this also work abroad and with other MNO’s (NB-IOT interoperability question) ?
Definitely 3gpp standard will be inter operable across all operators global…
The latest non-backwards compatible change happened during rel 13… but this is a rare event… Not all operators have this change implemented but this will be resolved in the next couple of months… And this has only some effects on PSM I believe.
Today read: "GSMA counts 31 NB-IoT launches to date… " As far as I can see is the NB-Iot rollout pace a lot faster than Cat-M1…
What if connection is lost after all, e.g. due to a bad signal, how to detect that in a reliable manner? Using parameters CSQ=99 or RSRP=0 does not seem to be reliable. Is there a white paper that describes a solid solution?
I would assume that connection only gets lost when after device misses its periodic registration requirements…
AT+CGATT? if returns 1 the device is attached.
NB-IOT provides various parameters to minimize power consumption; T3314, T3324, etc. I’m wondering how to apply those parameters in the most efficient way. And also what the impact is, e.g. on responsiveness, when changing these parameters. Is there a white paper that demonstrates adequate use of these parameters. And when will they be supported (roadmap question), as experiments have shown that these parameters currently seem to have no noticeable effect.
AT+CPSMS command influences this.
White paper covering these topics:
NB-IoT Deployment Guide to Basic Feature set Requirements.pdf
regards,
Hi Felix, PBM_NL
Ik heb de “requirements / opmerkingen” geregistreerd in een excel.
En ik ga hier intern de antwoorden verzamelen.
@andre-rodenburg said in PSM op de uBlox SARA-N211:
Lukt het jou ook om de AT+CEREG parameters aan te passen met het AT+CPSMS commando?
Zijn volgens mij twee verschillende dingen:
+CEREG beperkt zich tot de radio access van het netwerk: roaming/native, locatie, en access technologie…
Voorbeeld:
AT+CEREG?
< +CEREG: 3,5,“04ED”,“200867”,7, OK [79 ms]
+CPSMS geeft de informatie ten aanzien van de PSM mode en de betreffende timer instellingen…
Voorbeeld:
AT+CPSMS?
< +CPSMS: 1,“01000001”,“00000101” OK [79 ms]
Hmm niet geprobeerd. Zou dat moeten kunnen?
Ik kan het zo even voor je testen al je wilt.
Als je al een aantal AT commands hebt geef maar door anders moet ik even de documentatie erbij pakken…
@andre-rodenburg said in PSM op de uBlox SARA-N211:
Dit commando geeft bij iedere verandering in PSM een melding. ‘1’ betekent dat PSM aan is, ‘0’ is uit.
Inderdaad:
Voor de PSM testen gebruik ik het volgende:
AT+NSMI=1 # Enable send message notification (If message is delivered it will return +SENT)
AT+CEREG=3 # Set extended registration status (info on network level cell lac ect..)
AT+NPSMR=1 # Enable power mode notification ( +NPSMR: 0 leave psm mode, +NPSMR: 1 enter psm mode)
@marcel-duijnisveld said in Testing SIM7000E:
I’m not sure about the port. Normally a webserver uses port 80, but I believe I must use port 5683 for this test.
On port 5683 runs a “lightweight” COAP , based on UDP …
http will most definitely NOT work would be my assumption …
besides http has more overhead and is therefore less energy efficient
Here is an UDP implementation of the used COAP protocol: Neulmessenger
Ik heb net een testje gedaan met de UBLOX firmware:
| name | value |
|---|---|
| type_number | SARA-N200-02B |
| modem_version | 06.57 |
| application_version | A07.03 |
| manufacturer | u-blox |
Hier is een trace met wat indicaties voor de response tijden van de commands, op 9600 baud:
De scrambling setting staat op TRUE, en is alleen van toepassing voor een aantal test sites… Later zal dit default aan staan voor het gehele netwerk…
1519043532.805931 > AT+CFUN=0
1519043532.855598 < OK [50 ms]
1519043532.855884 > AT+NCONFIG="AUTOCONNECT","TRUE"
1519043532.899101 < +CEREG: 0,"0000","0",7,, OK [43 ms]
1519043532.899360 > AT+NCONFIG="CR_0354_0338_SCRAMBLING","TRUE"
1519043532.954500 < OK [55 ms]
1519043532.954778 > AT+NCONFIG="CR_0859_SI_AVOID","TRUE"
1519043533.002462 < OK [48 ms]
1519043533.002725 > AT+NCONFIG?
1519043533.304685 < +NCONFIG: "AUTOCONNECT","TRUE" +NCONFIG: "CR_0354_0338_SCRAMBLING","TRUE" +NCONFIG: "CR_0859_SI_AVOID","TRUE" +NCONFIG: "COMBINE_ATTACH","FALSE" +NCONFIG: "CELL_RESELECTION","FALSE" +NCONFIG: "ENABLE_BIP","FALSE" +NCONFIG: "NAS_SIM_POWER_SAVING_ENABLE","TRUE" OK [302 ms]
1519043533.304990 > AT+NCDP="172.16.14.22"
1519043533.339584 < OK [35 ms]
1519043533.339868 > AT+CGDCONT=1,"IP","oceanconnect.t-mobile.nl"
1519043533.395785 < OK [56 ms]
1519043533.396048 > AT+NRB
1519043537.439082 < REBOOTING \x{00}&\x{FC}\x{00}\x{A2}\x{B0}\x{00} REBOOT_CAUSE_APPLICATION_AT u-blox 1519043537.439399 > AT+CGDCONT?
1519043537.493356 < +CGDCONT: 0,"IP",,,0,0,,,,,1 OK [54 ms]
1519043537.493645 > AT+CFUN?
1519043537.523257 < +CFUN: 0 OK [30 ms]
1519043537.523541 > AT+CEREG=3
1519043537.543134 < OK [20 ms]
1519043537.543393 > AT+CFUN=1
1519043539.007523 < +CEREG: 0,"0000","0",7,, OK [1464 ms]
1519043539.007792 > AT+CIMI
1519043539.044882 < 901405700000000 OK [37 ms]
1519043539.045215 > AT+NBAND=8
1519043539.065764 < OK [21 ms]
1519043539.066032 > AT+COPS=1,2,"20416"
1519043539.095258 < OK [29 ms]
1519043539.095540 > AT+CSQ
1519043539.146033 < +CEREG: 2,"0000","0",7,, +CSQ: 99,99 OK [50 ms]
1519043540.146617 > AT+CSQ
1519043540.178023 < +CSQ: 15,99 OK [31 ms]
1519043540.178323 > AT+CGATT?
1519043540.210179 < +CGATT: 0 OK [32 ms]
1519043541.210781 > AT+CSQ
1519043541.243340 < +CSQ: 13,99 OK [33 ms]
1519043541.243653 > AT+CGATT?
1519043541.275906 < +CGATT: 0 OK [32 ms]
1519043542.276462 > AT+CSQ
1519043542.308554 < +UFOTAS: 0,1 +CSQ: 13,99 OK [32 ms]
1519043542.308867 > AT+CGATT?
1519043542.341434 < +CGATT: 0 OK [33 ms]
1519043543.341963 > AT+CSQ
1519043543.387685 < +CEREG: 5,"04EE","6C8E67",7,, +CSQ: 14,99 OK [46 ms]
1519043543.388000 > AT+CGATT?
1519043543.420091 < +CGATT: 1 OK [32 ms]
1519043543.420481 > AT+NSMI=1
1519043543.438579 < OK [18 ms]
1519043543.438853 > AT+NMGS=11,"48656c6c6f20576f726c64"
1519043544.394786 < +NSMI: SENT OK [956 ms]
@jeroend said in Kan ik data vanaf een node versturen met "standaard" AT HTTP commando's:
@techniek Dank voor je reactie. Ik wil alvast wat exerimenteren, kan je me helpen aan een link welke CoAp berichten er verstuurd moeten worden, maw welke inhoud de server van T-Mobile verwacht om een payload te ontvangen?
Een goede start kan zijn:
https://github.com/otheruse/NeulMessenger
Al heb ik er nog niet mee geexperimenteerd…
Aha schiet me nog iets te binnen:
Alle AT+NCONFIG? parameters op FALSE
Of iets proberen deze twee tergelijkertijd op TRUE… te zetten:
AT+NCONFIG=CR_0354_0338_SCRAMBLING,TRUE
AT+NCONFIG=CR_0859_SI_AVOID,TRUE
nogmaals syntax kan per fabrikant en type verschillen…
Misschien moet je in het modem exliciet aangeven dat je NB-iot wilt gebruiken. Heb je wel band 8 geselecteerd?
AT+CGATT? geeft je de aanlog status…
@felixdonkers hi Felix,
The network experts tel me that NB-Iot has a devides a packet into variable length segments, dempending on the quality of the transmission channel…
3gpp specs that might shed some light… for the deternmined…
http://www.3gpp.org/ftp/Specs/archive/45_series/45.820/45820-d10.zip
@jeroend said in Kan ik data vanaf een node versturen met "standaard" AT HTTP commando's:
@techniek Ik ben inmiddels een stukje verder. Ik neem aan dat het CoAp protocol gebruikt wordt over UDP. Ik probeer met AT+CIPSEND een bericht te versturen in plaats van met AT+NMGS maar weet niet wat de server van T-Mobile verwacht. Kunnen jullie me dat vertellen? Ik neem aan een CoAp POST, moeten er opties gezet worden? Zo ja welke? Moet er een token gestuurd worden? Zo ja: hoe bepaal ik het token? Ik heb geprobeerd om hex 50 02 30 FF 41 42 43 44 te sturen (CoAp versie 1, non confirmable, geen token, POST, message id 30 hex, marker FF en payload ABCD) maar dat werkt niet. Kan iemand mij helpen? Alvast dank!
Klopt OceanConnect praat een Huawei implementatie van CoAp. In de nabije toekomst gaan we ook plain UDP over de module mogelijk maken even geduld… we zitten in de pilot fase en ik voorzie nog een aantal grote aanpassingen…
Groetjes,
@jeroend said in Hulp nodig met verbinden:
In de dev reg heb ik het device een aantal keer gedelete en weer gecreeerd. Ik gebruik de IMEI die ik krijg door at+cgsn en niet het nummer op dat op de simkaart gedrukt is. Doe ik dat goed?
Hi Jeroen,
Klopt AT+CGSN(=1) geeft je de IMEI, hiermee registreer je je device.
Op dit moment heb ik alleen nog met UBlox en Quectel modems ervaring, helaas;)
Een redelijk groot aantal modem fabrikanten sleutelen ook nog aan hun firmwares dus nog even geduld.
Groetjes,
Updated link:
https://forum.iot.t-mobile.nl/topic/161/connecting-and-testing-your-service-with-iot-originating-messages
Regarding the AT commands, things to check.
Check if you have set the ocieanconnect APN. (In the manual parts 0 and 1 below you will see a few examples)
Some devices need a reboot in order to make the APN persistent…
https://forum.iot.t-mobile.nl/category/9/starterkit
Scrambling, try to see if you can set it to FALSE…
Device registration, is the device visible in the devreg tool, maybe delete and reregister with the IMEI of the device?
http://devreg.iot.t-mobile.nl/login
Hope this helps…
@jeroend said in HTTP POST en GET:
@techniek een beetje een newbie vraag, maar als ik alle topics goed gelezen heb kan ik alleen berichten van beperkte grootte via Ocean Connect naar mijn device sturen? Eigenlijk wil ik direct een HTTP POST en GET doen naar een (publieke) webserver, maar met NB-IoT kan dat niet? Kan dat wel met LTE CAT-M1? Is die techniek ook beschikbaar via het early access programma?
Hi Jeroen,
De gateway heeft een mogelijkheid om een call-back te registreren… De gateway zal niet zo snel een bericht beperken is mijn inschatting… Volgens mij is het device hier meestal de beperkende factor.
Hier is wat uitleg over de callback registratie:
https://forum.iot.t-mobile.nl/topic/161/connecting-and-testing-your-service-with-iot-originating-messages
Aha, based on the HL specs looks promising.
We have not tested this module ourselves so I cant give you a definitive recommendation.
Reminds me to see if we can get an update on the compatible modules list.
@erikkate said in Could not use devreg:
When trying to register my device using the acquired IMEI number I get the following error:
Just a question, is this a Sodaq board?
In that case, could be that the device is still registered under the Sodaq account… and needs to be de-registered there first.
regards
@mark-ruys said in SIM7000E support:
SIMCOM 7000E
Hi Mark,
Just looking at the specifications from the SIMCom website:
Specifications for Data transfer
• LTE CAT1
I don’t see any of the NB-Iot standards specifically mentioned, so I would be cautious…
Regards,
@waltert said in sturen vanuit oceanconnect naar node:
Wat handig werkt (zeker als je veel stuurt
is het query-en met een starttijd, bv:
Interessant goede herrinering om ook nog is verder in de OC interface te duiken.