Unable to bring up the network!

[alexmaron81]

Hi Rob,

I have a new SIM card and a new device. The device could not dial in at first. The support from 1nce recommended that I put the SIM card in a smartphone and test it. The connection was successful. I then put the sim back into the device with the ublox module and it worked here too.

What could be the problem? what does a smartphone do more than the ubxlib API? Unable to bring up the network.txt subsequent successful connection.txt

[RobMeades]

Hi Alex: an excellent question, I've absolutely no idea I'm afraid. Gaining service, from the standpoint of the application/MCU, should simply be that: put the SIM card in, apply correct APN to the module if necessary, and off you go. I've never seen any other interaction required, even on initial connection.

It might, I guess, be that some sort of SIM configuration is performed by the network, but the MCU/application has nothing to do with that, as far as I am aware, it is all done automagically by the cellular module.

@philwareublox, @rebatoma, any ideas?

[alexmaron81]

This is the answer from 1nce support:

Our technical specialists see the reason for the previously unsuccessful connection attempts in the logic of your u-blox SARA-R412M-02B. We could see that the registration is running into a timeout. Please note that registering without a preferred network provider may take some time.

To speed up this process, you can manually connect to a specific network provider. To do this, use the AT command at+cops or another MNO profile to reduce the number of bands that the device has to scan for cells.

[RobMeades]

I had been wondering about that; 240 seconds is usually enough for most RATs but of course you are using NB1, which I'm told can take up to 20 minutes to find the network when it knows nothing of the radio environment (which would be the case on the first try). This is because it does deep coverages searches to achieve that extra 20 dB, the corollary being that if you do attach in such a deep coverage situation your data rate will be very low. That's just physics I'm afraid.

So I guess you should extend the network search timeout in your configuration to be MUCH longer. Of course, this burns power, but there's nothing much one can do about that, you gotta get coverage.

[alexmaron81]

As soon as the box has connected for the first time, all subsequent connections are established immediately.

Although we have a battery-powered application, we will run the first boot under a power supply anyway, so it is not a problem.

Thanks for the quick support!

[RobMeades]

Or of course, as 1nce suggest, if you know where your device will be operating you can set a bandmask or set an MNO profile that is appropriate for that region; there are ones for specific operators or Europe or Global etc, check the AT manual for your device to find the ones it supports.

[RobMeades]

One last thing: there is general advice on configuration of LTE in the README.md of the lte_cfg example.

[alexmaron81]

I use the current ubxlib version so that I can use "u_http_client.h". But can't build a network?

[RobMeades]

We will need a little more information in order to help with this. Can you show what you are putting in the uDeviceCfg_t structure passed to uDeviceOpen()? Return code -4 means U_ERROR_COMMON_NOT_SUPPORTED.

[alexmaron81]

[RobMeades]

That looks fine. Can you make sure this is a completely clean build, if you haven't done so already?

A few more questions: which MCU are you using (ESP32?) and how are you bringing all of the ubxlib files into your system - are you using one of either ubxlib.mk or ubxlib.cmake to do that, or do you have your own way of bringing in the files?

If you are using ESP32 [EDIT: of course you are! sorry] it is possible that this is an effect of a weird bug in the Espressif linker where, if a file happens to contain only functions that also have weak alternatives, it will pick up the weak versions instead and ignore the actual implementations. We include a workaround for this, you will see it in the commit message to bf8cd21ff293ba2e3cf2f750f682aff1cf335fc0, but if you are bringing in files manually yourself, rather than using ubxlib.mk or ubxlib.cmake, it is possible that something is going wrong with it somehow?

[alexmaron81]

I put the ubxlib in the "components" folder as usual. And just moved the CMake file to the main folder. The only thing I changed is to change the following two paths. CMakeLists.txt this is how it worked with the previous version

[RobMeades]

That looks fine: could you capture the output from the Espressif tools for a complete clean build and post it as an attachment here (please delete any lines from it that you consider might be sensitive)?

[alexmaron81]

do you mean this? debug ubxlib.txt

[RobMeades]

Yes, thanks, but I think that probably wasn't a clean build: there are no lines in there indicating that any of the ubxlib files (e.g. u_cell.c etc.) are being built and only about 100 files are being built, whereas with ESP-IDF it's usually more like 800 at the very minimum.

Maybe there are still some object files not being deleted somehow?

EDIT: looking more closely, it seems to be only building the bootloader, while at the start it has [6/1458], implying that it has skipped more than a thousand steps because the files do not need to be [re]built.

[alexmaron81]

the tool actually goes through all 1458 steps, but doesn't save them in the view. Is there any other way to log the build?

[RobMeades]

Hmph, that's irritating. Need to be able to see exactly which files it has chosen to build somehow. Maybe add -DDEBUG=1?

[alexmaron81]

maybe this helps ninja ubxlib log.txt

[RobMeades]

Ah, yes, that's good. You can see in there that the Espressif tools are building both u_device_private_cell.c and u_device_private_cell_stub.c, which is correct. u_device_private_cell_stub.c has weak functions in it which the Espressif linker will use instead of those in u_device_private_cell.c should you not include them in your build. The bug is that if ALL of the functions in a .c file (in this case u_device_private_cell.c) also have weak alternatives, the linker will ignore all the real functions and use the weak ones instead, which would give the result you are seeing.

The workaround for this bug is to include at least one function in u_device_private_cell.c that does NOT have a weak alternative, and make sure that function is called from somewhere so that the linker "gets it". For this particular case, you'll see the function uDevicePrivateCellLink(), which is called from uCellInit() to make the linker get it.

I wonder if the issue is to do with the source files being inside a component library .a file?

A temporary fix, assuming that this is the problem, would be to hand-modify the ubxlib.cmake file you have to remove the two lines which bring in a *_cell_stub.c file.

I don't have an ESP32 board with me at the moment (they are all in the test system) so I can't try to do exactly what you are doing myself; I will order a spare and investigate myself. Let me know if the workaround for the workaround above works.

[alexmaron81]

This has worked before. I commented out the two file attachments. how should I proceed? Can I keep it like this?

[RobMeades]

Yes: it just means that you would not be able to make a build that includes ubxlib without cellular, which I guess is not something you ever want to do.

I will let you know when I find out what's going on and have a fix such that you can revert the change.

[alexmaron81]

Many thanks for the support!

[RobMeades]

Thanks for your patience and apologies for causing the problem in the first place :-).

[RobMeades]

The issue should be fixed in commit 6eff2c4b669d2b42f85a7488304323012272c589, hence closing this; feel free to re-open, or open another issue, if you think there is more to do.

[RobMeades]

Apologies, found another place this linker bug hit in the uHttpClient API: if you are using that please use at least commit 80e76d49b97d8128202d5dd2a2fa9bfa2ecbc47a.