2019-09-24 at 1:55 PM #13170
I’ve run into an issue registering our modems on the Hologram network (AT&T), and I wanted to see if anyone else using LTE-M has had the same issue or had possible fixes. We are using the Sodaq Ubee R410M with Hologram SIMs to send data from our Mayflys, and up the modems were working great when we pulled our stream gauges from the field two months ago.
The modems appear to work like normal when I first connect to them using an Xbee explorer-type board and the M-Center program from Ublox (4 bars of service on the AT&T network, network status is “registered, roaming”, green LED indicating that the modem is on), but the modems are denied registration on the AT&T Hologram network when the modem is sent the command “AT+CREG?” to check the registration. Sending the modem the command to check the EPS registration, “AT+CEREG?”, returns “0, 5” indicating that it is registered, and the network status then switches back to “registered, roaming”.
I’ve asked this question on the Hologram Community forum (no responses yet), but I wanted to see if anyone else was experiencing this problem using LTE-M.
2019-09-25 at 3:20 PM #13171
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.
2019-09-25 at 5:00 PM #13172
Do you have the latest u-blox firmware?
2019-09-26 at 2:38 PM #13173
Interesting, thanks for the reply! It’s odd that bypass mode works for the Xbees because the Sodaq Ubee I think is always talking directly to the Ublox.
I don’t have the latest firmware update. I’ve gotten in touch with Ublox for help updating the firmware because it looks like some Hologram folks have had LTE-M issues that have been resolved by an update, although a Hologram engineer said that my issues likely weren’t related and asked me to make a new thread.
Have you had success updating any Sodaq Ubee firmware? I think my only option is using AT commands to update and so far that has been unsuccessful.
2019-09-27 at 4:25 PM #13180
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.
2019-10-11 at 9:03 AM #13223
Thanks, @srgdamiano! I think that the “CEREG” change helped with the registration issue. I’m still not able to get ModularSensors 0.23.16 up and running, though. Seems like another modem issue – these things are definitely finicky! I’ll reach out through the SARA R410M modem GitHub thread or email. Thanks again for your help!
2019-10-11 at 9:58 AM #13224BrianJastramParticipant
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.
2019-10-11 at 11:46 AM #13225
Hi Brian, I wasn’t able to get version 0.23.11 to work, but I think my issue is related to code for the Sodaq Ubee R410M modem that I’m using (and possibly PlatformIO). I do get a 504 sending error when running 0.22.6, though. Fortunately, I was able to get version 0.21.4 working great after I made a fresh PlatformIO project and manually installed 0.21.4
2019-10-21 at 2:46 PM #13236
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
added at the end
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.
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
2019-10-24 at 2:52 PM #13248
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.
2019-10-24 at 4:07 PM #13249
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.
2019-10-24 at 4:44 PM #13250
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.
2019-10-24 at 4:50 PM #13251
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.
2019-10-24 at 7:39 PM #13252
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”
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.
2019-10-25 at 12:17 PM #13253
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.
- You must be logged in to reply to this topic.