Unable to create HTTP instance! about ubxlib HOT 11 OPEN

Hi again: unfortunately ubxlib does not support HTTP on LENA-R8 (-4 is U_ERROR_COMMON_NOT_SUPPORTED). The LENA-R8 HTTP interface doesn't work the same way as every other u-blox module HTTP interface; for instance, should the HTTP server respond with a non-2xx error code, the module does not save the response to file (in fact it leaves any previous response file there, unchanged) and returns an error at the HTTP interface rather than success, which makes it impossible for ubxlib to determine the HTTP response code in any failure case.

There are more notes about the limitations of LENA-R8 here:

https://github.com/u-blox/ubxlib/releases/tag/v1.4.0

Sorry for the misdirection, I will add notes to the HTTP example and on the HTTP interfaces to say that they will not work with LENA-R8 in the hope of avoiding future confusion.

from ubxlib.

Hi thanks again for your reply. in this case what is the best way to get Assis-now working on LENA. currently I'm using mqtt with AWS IoT.

from ubxlib.

A few options:

1. Use the native Zephyr IP stack and its HTTP: to do this you would follow the instructions here; basically define U_CFG_PPP_ENABLE when compiling ubxlib, add a few flags to your prj.conf file and add a zephyr,ppp-uart entry to your .overlay file. With this done, after uNetworkInterfaceUp(), you should have native connectivity to the cellular network from within Zephyr. Ignore the caveats about usernames/passwords and CHAP authentication, 1NCE doesn't need those (we use 1NCE SIMs here in our test system).
2. Do the HTTP operation inside AWS and pass the results to an MQTT topic that the LENA-R8 MQTT client can subscribe to; I don't know whether you have enough capability at the AWS end to do this or not.
3. It might be possible to get the AssistNow information over MQTT; I'm still trying to bottom-out whether I've understood the answer I was given correctly, or whether the person being asked understood the question correctly. I will get back to you on this.

from ubxlib.

Right then, on (3): you have an AssistNow access token, and therefore a Thingstream account from which you obtained that. In the Thingstream account you will see a Data Flow Manager. Using this it is possible, and I quote, to set up "a flow with an assist now node which is deployed to a topic the device publishes to which then publishes the response to another MQTT topic that the device is subscribed to". What I think this means is that an MQTT publish will trigger, in the back-end, an HTTP request to AssistNow and you can subscribe to an MQTT topic to obtain the response.

I've never used the flow manager myself, but it is described here:

https://developer.thingstream.io/guides/location-services/assistnow-getting-started-guide

...including a video demo.

It might be that this way you can do everything you need over Thingstream MQTT.

from ubxlib.

Hopefully improved documentation of the limitations of LENA-R8 in ba0a0f1.

from ubxlib.

Hi Rob,
Thanks again for the info.
I started with first suggestion to implement zephyr IP stack but I got strange error regarding

uart2: uart-ppp@8000 {
	compatible = "u-blox,uart-ppp";
	reg = <0x8000  0x1000>;
	status = "okay";
};

I'm using nrf5340, so I'm not sure about the right configuration in dts.

devicetree error: Label 'uart2' appears on /soc/peripheral@50000000/uart@b000 and on /uart-ppp@8000

I didn't try the mqtt but I was wondering about IP stack first.

from ubxlib.

Another question regarding the second suggestion: after receiving the location data by mqtt, how can this data be transferred to GNSS since it is connected directly to the MCU?

from ubxlib.

devicetree error: Label 'uart2' appears on /soc/peripheral@50000000/uart@b000 and on /uart-ppp@8000

I think you just need to invent a label that doesn't appear anywhere else: in our case I used uart99. The label is only used in the chosen statement:

chosen {
        zephyr,ppp-uart = &uart99;
    };

...so you can use whatever you like, just not one that conflicts.

after receiving the location data by mqtt, how can this data be transferred to GNSS since it is connected directly to the MCU?

The data you get back from the AssistNow service is purely a set of pre-encoded UBX format binary messages that can just be fired at the GNSS chip with uGnssMgaResponseSend(). Whether this arrives in the body of an HTTP response or is brought down via MQTT doesn't matter, it is just a blob of binary data. See also the assist_now_main.c example.

from ubxlib.

Hi Rob, Finally, I could get PPP working in Zephyr, thanks to you, of course. But now I have two questions.

• In Cloud location or assist now, I thought that the device has to share its cell parameters with the cloud to narrow the data location before sending it to the device. otherwise cloud will send global location to all devices and won't take benefit of the cell location. my question here is, in case this cell location can be sent to the cloud, where can I find the cloud API regarding this one? In this case we can implement the HTTP requester on our cloud side and request cell info from each device through the Mqtt topic and send it to Assist now server.
• second question regarding Zephyr IP stack. Which one is more stable regarding ublox modems? to use IP stack of ubxlib or to use the zephyr one. I know that PPP layer is very slow when it comes to downloading big data (maybe it will not fit FOTA), but I want to make sure which choice we have to take; our application requires an MQTT connection, FOTA and cloud location services.

from ubxlib.

Phew! Some progress, that's good. One thing to keep in mind, if I've not said it already, is that since PPP is a framed protocol, and it will be running over CMUX, which is also a framed protocol, the UART link will be critically sensitive to data loss: i.e. if you lose one byte then an entire frame will go and the MCU may no longer be able to communicate with the module. So, in your final application, make sure to connect the UART flow control lines between the MCU and the module.

On your questions, Cloud Locate relies on cell parameters but AssistNow does not: when you use AssistNow you can see in our AT logs a pure HTTP GET request is assembled, along the lines of:

GetOnlineData.ashx?token=xxxxxxxxxxxx;gnss=gps;datatype=eph;latency=0;tacc=0

...to get the ephemeris data for GPS only. But yes, the Cloud Locate and Cell Locate services do require cell tower data that the UPOS entity within the cellular-side of the LENA-R8xxxM10 module obtains and sends to the u-blox server. However, those services don't require GNSS, the whole point is that they can work without it, though of course they will only give position to within the size of a cell (hundreds of metres) in that case. To use Cloud Locate/Cell Locate without GNSS you would need to call uCellLocSetGnssEnable() with false (once) before doing the Cloud Locate or Cell Locate position requests. We have probably not used ubxlib in this configuration before so, when you do this we should check the AT log to see if ubxlib hasn't snuck in a AT+UGPS=1,xxx command to power up the GNSS chip (which would cause UPOS to start chattering to it) as a side-effect.

On the IP stack, the Zephyr one is quite new and there are a lot of things that seem to need tuning in it, while the one inside the u-blox modem is quite old and relatively well tested. In terms of speed, difficult to say: usually the PPP approach is faster, since the AT interface is a bit of a ping-pong clunky kind of thing, but with the approach we have to take to make Zephyr work with PPP my guess (and it is only a guess) is that the AT interface is probably faster.

from ubxlib.