Trouble registering with LTE-M network on Hologram

Yes, I’ve seen this sort of thing.

Well, not precisely, but similar. The Digi LTE XBee3’s have the same chip and I’ve seen it happen several times that the XBee refused to register, then I put it in bypass to check the registration, got it to register, then it magically stayed registered when I went back. I haven’t seen it consistently, though, just occasionally.

Do you have the latest u-blox firmware?

I don’t have a uBee with the R410M, but I’ve updated a whole bunch of the Digi boards with the u-blox “Easy Flash” software and direct USB to the SARA chip. You should be able to use the same firmware and software to update. You may even be able to do the update through the serial port without soldering a USB connection on. (Sodaq breaks the pins out to J1, but that’s it.)

You can get the most recent u-blox firmware and Easy Flash here: ftp://ftp1.digi.com/support/firmware/u-blox_EasyFlash_10.02_SARA-R410M-02B-01_IP.zip

Are you still using ModularSensors or TinyGSM on your boards? I was thinking about it and remembered that TinyGSM had previously used “CEREG” to check registration but a while ago I changed it to “CREG” to query both EPS and GPRS registration to support 2G fallback on the R412 chip. That change might be why older code was having less trouble. I’ve modified TinyGSM (which ModularSensors uses) to use “CEREG” again – so that may help.

These 4G chips just seem to be so much more finicky about connecting than the 2G ones were. I don’t know how much of it is the u-blox chip vs the SIMCom (SIM800) that we used to use in the GPRSBee and how much is the network itself, but I miss having 2G service.

Adam, Maybe give ModularSensors 0.23.11 a try. See https://www.envirodiy.org/topic/response-code-504-sending-data-to-data-envirodiy-org/
It’s kind of working for me and Dan. Currently though I’m getting exactly 24 hour gaps in my data stream to MMW.

Thanks for the tips here.
I’ve also had trouble with a new Hologram SIM registering to the cell network with a Digi XB3M1.
I had a working hologram SIM that connected straight away, and then would power off and swop in the new Hologram enabled SIM, and it would poll the cell tower and not work.
I started trying about 2weeks ago, had to move on to a few other items, came back to it.
Tried a few more times yesterday, added the tip above, and it worked, and ran overnight OK.
I’m based 0.23.15 (but latest github.com/EnviroDIY/TinyGSM) and using DigiXBeeCellularTransparent.cpp
I included and monitored the AT responses
bool DigiXBeeCellularTransparent::extraModemSetup(void)
added at the end
gsmModem.sendAT(GF(“+CREG”));
and it sent back an ERROR
but then the XB3M1 registered.
Seems like its a magic recipe workaround of some sort, but no idea if this really works till I try registering my next sim.

The code is here – search “+CREG”
The first commented out “+CREG” is how I had it.
Then I introduced an algorithm to only issue “+CREG” it if has been monitoring for 100 times for the next time I register a sim.
https://github.com/neilh10/ModularSensors/blob/rel1_dvlp1m/src/modems/DigiXBeeCellularTransparent.cpp

The output is

Version 11413 <–DigiXBeeCellularTransparent
Loop=Sec] rx db : Status ‘ Operator ‘ #Polled Cell Status every 1sec
0=5.28] 0:0x22 ‘OK’
1=6.30] 0:0x22 ‘OK’
2=7.32] 0:0x22 ‘OK’
3=8.34] 0:0x22 ‘OK’
4=9.35] 0:0xff ‘OK’
5=10.37] 0:0xff ‘OK’
6=11.39] 0:0xff ‘OK’
7=12.41] 0:0xff ‘OK’
8=13.43] 0:0xff ‘OK’
9=14.44] 0:0x22 ‘OK’
10=15.46] 0:0x22 ‘OK’
11=16.48] 0:0x22 ‘OK’
12=17.50] 0:0x22 ‘OK’
13=18.52] 0:0x22 ‘OK’
14=19.53] 0:0x22 ‘OK’
15=20.55] 0:0x22 ‘OK’
16=21.57] 0:0x23 ‘OK’ Cnt=1
17=22.59] 0:0x0 ‘AT&T Hologram’ Cnt=2
Cell scan ‘ S MCC:310 MNC:410 Area:35651 CID:169103376 Signal:-98 ‘
… Setup successful! <–DigiXBeeCellularTransparent

I’m sorry I haven’t been responding on this. I’ve been working on other data projects and haven’t had a chance to look into this at all yet.

No problem – I appreciate the earlier tip.
What I haven’t figure out is there another manual that specifies +CREG cmd – it isn’t in the user manual I’m using.
I have seen it before where latest manual “inherits” a context of another set of cmds specified in an common manual.

What manual are you using? CREG, CGREG, and CEREG are all in the AT commands manual for the SARA R4: https://www.u-blox.com/sites/default/files/SARA-R4_ATCommands_%28UBX-17003787%29.pdf

CREG = Network (circuit-switching) registration status
CGREG = GPRS (packet-switching/General Packet Radio Service) network registration status
CEREG = EPS (Evolved Packet System) network registration status

This page has some nice diagrams explaining the “levels” of the network architecture: https://www.3gpp.org/technologies/keywords-acronyms/100-the-evolved-packet-core, but I’d guess you understand it better than I do.

I had thought that if you had any connection with the network at all, it would be visible in CREG. Rather, I’d thought of CREG as “any connection at all” not specifically circuit switching connection. Now that I’m looking harder, I think it might be possible to have the EPS connection without a CS connection since EPS doesn’t have any circuit switching. That would explain the issue with seeing nothing in CREG and but getting connection quickly with CEREG. The R410M doesn’t support GPRS, so I believe CGREG should always return unregistered for it. The R412 does have GPRS fallback, so at the request of a TinyGSM user I changed the code from checking CEREG to CREG. I’ve since changed it back, though, so if you have the latest version you should see CEREG being queried.

I hate trying to read any detailed explanations of cellular network architecture because there are a truly ridiculous number of acronyms used and I don’t use any of them enough to remember what they mean. It feels like 3/4 of the explanations of network architecture forget to define 3/4 of the acronyms so I’m always floundering back and forth between different articles trying to get it straight.

Yup – the network is challenging when making it work, and adding to the biggest and most diverse machine in the world.
I’ve been more the old wireline, POTS to ISDN (now ADSL) – moving the analog to the CircuitSwitched Digital, and now its packet switched.

Though when I was working with one customer, when our product wasn’t connecting to the bigger machines, he referred to us being on the “Bleeding Edge” (the other side of cutting edge).
It actually turned out our product was working, but we interworking with a German device that wasn’t coping with US standards.
That’s why its nice to know about the 7Layer OSI model to have some common language about what the scope of the discussion is.
A lot of the 2G v 3G v 4G is industry fashion, bands of specifications, the reality is related to very specific specifications which evolve slower than 2G->3G->4G. The cellular industry is coping with high bandwidth expectations (5G), as well as low bandwidth IoT.
Whatever the technology, what does it take for my packets to be delivered successfully at what cost of power and devices.
I have heard of new silicon that can have problems with memory deep inside the chip – debugging that is hard.
For manuals I’ve been using mostly the
“Digi XBee3® Cellular LTE-M_NB-IoT 90002258revLsept2019.pdf”
https://www.digi.com/resources/documentation/digidocs/PDFs/90002258.pdf
though I’ve seen the questions and advice in various support forums about the Sara-R4.
Again thanks for the details on CREG – I’m mostly a niche usage for some environmental monitoring I’m supporting.
When my bit is stable I’ll put it in a wiki.

The Digi documents don’t tell you what commands are exchanged between the u-blox chip – I don’t if the response the XBee3 gives to the “ATAI” command is based on CREG, CEREG, or some combination of those and any other commands that Digi found to be useful – and I doubt Digi is going to tell us. I suspect that it is a combination of commands.

If you’re interested in using bypass mode, you should reference the AT command manual from u-blox.