HTTP connectivity issue about ubxlib HOT 29 CLOSED

from ubxlib.

from ubxlib.

from ubxlib.

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

...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.

from ubxlib.

from ubxlib.

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.

from ubxlib.

from ubxlib.

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)?

from ubxlib.

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().

from ubxlib.

from ubxlib.

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.

from ubxlib.

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

from ubxlib.

from ubxlib.

from ubxlib.

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.

from ubxlib.

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

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...

from ubxlib.

from ubxlib.

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.

from ubxlib.

from ubxlib.

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().

from ubxlib.

from ubxlib.

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.

from ubxlib.

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.

from ubxlib.

from ubxlib.

from ubxlib.

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!

from ubxlib.

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

from ubxlib.

from ubxlib.

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.

from ubxlib.