Skip to content
This repository has been archived by the owner on Nov 11, 2024. It is now read-only.

HTTP connectivity issue #179

Closed
jamal-mouline opened this issue Dec 18, 2023 · 29 comments
Closed

HTTP connectivity issue #179

jamal-mouline opened this issue Dec 18, 2023 · 29 comments

Comments

@jamal-mouline
Copy link

Test environment

we have a uBlox module mounted on a SparkFun board
https://www.sparkfun.com/products/14997

which itself is mounted on a nRF54840 devKit using the Arduino Header

we are able to successfully power up and register on the network
run some MQTT exchange with the test.mosquitto.org broker

but we are having issues with the HTTP test as provided with the example under
https://github.com/u-blox/ubxlib/blob/master/example/http_client/http_main.c
unable to create an HTTP instance (either secure or non-secure) using the pUHttpClientOpen() API

we are using a hologram SIM card with a NULL APN

copy / paste of output log below

uart:$ modem_ctrl power_up
Cell Modem Power Up
uart:$ U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin not connected.
AT
AT
AT
AT

[00:00:11.093,505] CellModem: Opening a modem device instance...

[00:00:11.093,536] CellModem: [CM] MODEM_POWERED_DOWN->MODEM_POWERING_UP
uart:~$ AT
U_CELL_PWR: powering on.
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT
AT

OK
AT

OK
ATE0
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

L0.0.00.00.05.12,A.02.19

OK
AT&C1

OK
AT&D0

OK
AT+UCGED=5

OK
AT&K0

OK
AT+UPSV=0

OK
AT+CPSMS?

+CPSMS:0,,,"00011000","00001010"

OK
AT+CEDRXS?

+CEDRXS:

OK
AT+UMNOPROF?

+UMNOPROF: 0

OK
AT+UGPRF?

+UGPRF: 2,0,""

OK
AT+CFUN=4

OK
AT+CGSN

350857124811117

OK
U_CELL_INFO: IMEI is 350857124811117.
[00:00:24.261,718] CellModem: Modem power up and ready to be configured

[00:00:24.261,779] CellModem: [CM] MODEM_POWERING_UP->MODEM_POWERED_UP
[00:00:24.412,078] CellModem: subTopic messages/350857124811117/devicebound/

[00:00:24.412,170] CellModem: httpPath /350857124811117.html

uart:$ modem_ctrl network_up
U_CELL_NET: preparing to register/connect...
Cell Modem Register
uart:$ AT+CREG=2

OK
AT+CGREG=2

OK
AT+CEREG=4

OK
AT+CIMI

234500007895849

OK
AT+CIMI

234500007895849

OK
U_CELL_NET: APN from database is "jtm2m".
AT+CGDCONT=1,"IP","jtm2m"

OK
AT+UAUTHREQ=1,0

OK
U_CELL_NET: setting automatic network selection mode...

[00:00:43.949,493] CellModem: Bringing up the network interface...

uart:~$ AT+COPS?

+COPS: 0

OK
AT+CFUN=1

OK
AT+CREG?

+CREG: 2,0

OK
-1: NReg

+CREG: 2

+CGREG: 2
-1: Search
-1: Search

+CEREG: 2,,,,,,,"00000000","01100000"
-1: Search
AT+CGREG?

+CGREG: 2,4

OK
-1: OoC
AT+CEREG?

+CEREG: 4,2

OK
-1: Search
AT+CREG?

+CREG: 5,"FFFE","105950D", 7

+CGREG: 5,"FFFE","105950D",7

+CEREG: 5,"7BDE","0","105950D",7,,,"00000000","01100000"

+CREG: 2,5,"FFFE","105950D",7

OK
3: RegR
7: RegR
7: RegR
AT+COPS=3,0

OK
AT+COPS?

+COPS: 0,0,"T-Mobile Hologram",7

OK
AT+CGATT?

+CGATT: 1

OK
AT+CGACT?

+CGACT: 1,1

OK
U_CELL_NET: connected after 2 second(s).
[00:00:47.338,745] CellModem: [CM] MODEM_POWERED_UP->MODEM_NETWORK_REGISTERED
uart:$ modem_ctrl http_test
Http test
uart:$ AT+UHTTP=0

OK
AT+UHTTP=0,1,"ubxlib.com"

OK
AT+UHTTP=0,5,8080

OK
AT+UHTTP=0,4,0

OK
AT+UHTTP=0,7,0
+CME ERROR: Operation not supported

[00:01:06.278,930] CellModem: Failed to create HTTP instance!
@RobMeades
Copy link
Contributor

RobMeades commented Dec 19, 2023 •
edited
Loading

Hi there, sorry to hear your having problems. The command AT+UHTTP=0,7,0 should be supported by all of our module types:

image

...so my guess is that the SARA-R410M-02B module you have has a really old FW version (L0.0.00.00.05.12,A.02.19).

The best way forward would be to update it.

Take a look in the "Firmware Update" section of the SARA-R4 pages on our website, and you should find the SARA_R410M-02B entry. In that .zip file you will find a .dof file, which is the FW image, and a .pdf file. Towards the end of the .pdf file you will find a link to the tool EasyFlash 13.03, which is the tool you use to perform the update (over the USB port of the SARA-R410M-02B module).

Hopefully all of that will bring the module forward to a state where it will accept AT+UHTTP=0,7,0. Let us know how that goes.

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 23, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 24, 2024 •
edited
Loading

Hi again: the usual reason for this is that the narrow-band (NB) RAT is active in SARA-R422; an initial search of all of the bands of this RAT, i.e. the kind of search that is performed when there is no previous registration information to use, for 3GPP reasons, can take up to 20 minutes. We have an example which shows how you would read out the currently active RATs and modify them as you wish, or for a quick fix you could just call uCellCfgSetRat(devHandle, U_CELL_NET_RAT_CATM1) to set the sole RAT to Cat-M1 (as you seemed to be registered on Cat-M1 in your earlier log).

EDIT: you will need to re-boot:

if (uCellPwrRebootIsRequired(devHandle)) {
    uCellPwrReboot(devHandle, NULL);
}

...for the change to take effect.

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 24, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 24, 2024 •
edited
Loading

This module does not support setting an MNO profile.

That's a bit weird: SARA-R410M does support MNO profile setting, not sure why you are getting that. The segment of log you have posted above doesn't include any AT commands: by default (i.e. unless you have switched them off) the commands should be being printed to the log. I guess that the module is powered up at this point, i.e. uDeviceOpen() has returned success (0)?

@RobMeades
Copy link
Contributor

Ah, it might be because you are connected, you have called uNetworkInterfaceUp() already - once you are connected you can't modify radio-related stuff. Try putting the code before the uNetworkInterfaceUp().

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 24, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 24, 2024 •
edited
Loading

Something to try: I think we need to get the module out of MNO profile 0. That particular module doesn't support MNO profile 90 (later modules do), so can you try setting MNO profile 3 instead (which is Verizon)? That might unlock it.

@RobMeades
Copy link
Contributor

...or, since you appeared to have been on T-Mobile before, you could use MNO profile 5, which is T-Mobile.

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 24, 2024 via email •
edited by RobMeades
Loading

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 24, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 24, 2024 •
edited
Loading

Actually, no need, 2 is fine, anything other than 0.

The thing I don't understand is that the module is returning not supported for things I know very well it supports:

AT+URAT?
+CME ERROR: Operation not supported
AT+UBANDMASK?
+CME ERROR: Operation not supported

I am enquiring with relevant people internally as to how this is possible.

@RobMeades
Copy link
Contributor

Ah, checking the details, it looks as though, on the AT&T MNO profile, the AT+URAT and AT+UBANDMASK commands are locked:

image

However, that should not be a problem as the RAT is also locked to be LTE Cat M1 only, and in the list of networks you get back:

+COPS: (1,"T-Mobile","T-Mobile","310260",7),(1,"AT&T","AT&T","310410",7),(1,"313 100","313 100","313100",7),,(0,1,2,3,4),(0,1,2)

...all of them are Cat-M1 (the 7 on the end). All of which doesn't explain why the module is not registering. Let me think...

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 24, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 24, 2024 •
edited
Loading

Good stuff: it might be just that, since the FW was updated, the module has ended up doing an "initial" search, with no prior knowledge of the carriers (because the previous network had been erased), a process which is mandated to behave in such a way that it will take longer.

Hopefully, now that it has registered, it should register again more quickly.

If you are going to stick with one of the MNO profiles that has locked the AT+URAT and AT+UBANDMASK commands (see appendix C.6 of the AT manual) then yes, remove those commands. Of course, you also don't need those commands to do normal stuff, it was just useful to explore the module settings with them. If you move to an MNO profile that unlocks those two commands (e.g. MNO profile 100, which is Europe), then you could use them if you wish.

I'd say that if you are happy with AT&T then leave it on that MNO profile.

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 29, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

Is there a more restricted setting to URAT=7 only (no NB-IOT)

Yes, to set just a single RAT and no others it is simplest to use uCellCfgSetRat().

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 29, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 29, 2024 •
edited
Loading

The less good news is that it triggers the reboot API systematically

Indeed: if you have called uCellCfgSetRat() to set the RAT then, internally ubxlib will flag that you need to reboot the cellular module for the change to take effect; uCellPwrRebootIsRequired() will return true.

If you want to do all of this in your application as a matter of routine at every boot then you need to read the RATs and decide whether they need to be changed or not. If you always want just a single RAT then, as you suggest, it is pretty simple: read out the RAT at rank 1 (i.e. the second one) using uCellCfgGetRatRank(), if it is not U_CELL_NET_RAT_UNKNOWN_OR_NOT_USED (0) then call uCellCfgSetRat() to set the single RAT that you want and reboot, job done.

@RobMeades
Copy link
Contributor

To be clear, If it were me I wouldn't try to implement my own version of the ubxlib internal static function getRatSaraRx(), I would use the uCellCfg APIs as presented; that way you are using the APIs of the library of code that is ubxlib as intended, in a tested/thread-safe way with clear boundaries, and you will always be able to update to later ubxlib versions without getting tangled up with our internal changes.

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 29, 2024 via email •
edited by RobMeades
Loading

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 30, 2024 via email •
edited by RobMeades
Loading

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 30, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

RobMeades commented Jan 30, 2024 •
edited
Loading

Thats fine if it works for you: in the example, the bit after //------------------ CONFIGURATION ENDS ----------------- is there to read out what you have set and perform a network scan to demonstrate that what went before worked, networks are visible. You don't need these things in your application, though they shouldn't stop anything working, just introduce a delay.

On the original issue, I hadn't spotted that you had:

AT+UHTTP=0,7,0

...i.e. the timeout is being set to zero seconds: the pattern used in the http_main.c example is to always begin by assigning your uHttpClientConnection_t structure to U_HTTP_CLIENT_CONNECTION_DEFAULT, which will set the response timeout to U_HTTP_CLIENT_RESPONSE_WAIT_SECONDS (30). The uCellHttpOpen() function, which uHttpClientOpen() ultimately calls, says that "the timeout in seconds when waiting for a response from the HTTP server, must be at least U_CELL_HTTP_TIMEOUT_SECONDS_MIN"; I will update the description of uHttpClientOpen() to mention that pConnection should be initially assigned to U_HTTP_CLIENT_CONNECTION_DEFAULT and I will also modify uCellHttpOpen() to reject a zero value for the timeout to make this clearer

Thanks for highlighting this!

@jamal-mouline
Copy link
Author

jamal-mouline commented Jan 30, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

Good stuff, I'm going to close this issue now; please feel free to re-open it, or open another one, as required.

@jamal-mouline
Copy link
Author

jamal-mouline commented Feb 2, 2024 via email •
edited by RobMeades
Loading

@RobMeades
Copy link
Contributor

Hi: yes, please open a new issue to discuss this. We are aware of the Thingstream SDK but no-one on the ubxlib side has experience of actively using it, though we do know the right people to contact; we can involve them as necessary.

Whether you can use the uDeviceOpen()/uDeviceClose() APIs for this or not will depend upon whether the Thingstream SDK needs to react to URCs emitted by the cellular module: the uDeviceOpen()/uDeviceClose() APIs will start a ubxlib AT client on the UART, which will be the thing reacting to URCs from the module and the two will likely clash. If the Thingstream SDK does not need to react to URCs then this won't matter; if it does then you will need to drop down to lower-level ubxlib APIs instead and things will be trickier.

Regarding protection against simultaneity, I suspect you will have to do that at application level as ubxlib will not be aware of anyone else using the same transport as it. Basically, if you're doing Thingstream things, don't call ubxlib APIs.

When you open your issue, can you clarify if your aim, at application level, is to have Thingstream stuff that just happens to use the ubxlib porting layer for convenience, or do you actually want to use the ubxlib APIs as well as doing Thingstream stuff? The former is trivially easy, the latter will be complex.

Note: FYI, when you reply to posts here I think you are doing it via e-mail and the e-mail you are responding to gets pasted on the end of your post (I've been deleting that bit from your posts); if you can, it is better to respond in the web interface dialogue boxes here.

@jamal-mouline
Copy link
Author

jamal-mouline commented Feb 2, 2024 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@RobMeades @jamal-mouline