u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
287 stars 82 forks source link

example to use token of location thing #248

Closed mos216 closed 2 weeks ago

mos216 commented 4 weeks ago

Hello, I was wondering if there is an example to use AssistNow service by token instead of Mqtt option in ubxlib ?

RobMeades commented 4 weeks ago

Hi: not sure I'm following your question. There is the assist_now_main.c example, which shows how to obtain assistance data from the AssistNow service, encoding the AssistNow request (including authentication token) into a buffer which is sent to the AssistNow server as an HTTP request. The data returned in the body of the HTTP response is then sent down to the GNSS device.

If that is not the kind of thing you meant, could you maybe rephrase your question?

mos216 commented 4 weeks ago

Thanks Rob, Actaully that is what I was looking for how to use AssistNow in ubxlib. However this assist_now_main.c demonstrates only an individual gnss modem connected directly to MCU. Is there an example to do same job but for built in Cellalur with gnss ?

RobMeades commented 4 weeks ago

Ah, good.

Is there an example to do same job but for built in cellular with GNSS?

It is pretty much the same, you would just open the cellular device (that contains the GNSS chip) first and then open a GNSS network on that cellular device, kind of like in the main_loc_gnss_cell.c example, like this:

    // Either use this configuration structure for GNSS or, in your case I think you would
    // use the device tree mechanism; there's nothing to set really, especially if you
    // decide to set U_GNSS_MODULE_TYPE_ANY
    static const uNetworkCfgGnss_t gNetworkCfgGnss = {
        .type = U_NETWORK_TYPE_GNSS,
        .moduleType = U_GNSS_MODULE_TYPE_M10,   // Set the correct GNSS module type here
        .devicePinPwr = -1,
        .devicePinDataReady = -1
    };

    returnCode = uDeviceOpen(&gHttpDeviceCfg, &httpDevHandle);
    if (returnCode == 0) {
        returnCode = uNetworkInterfaceUp(httpDevHandle, U_NETWORK_TYPE_GNSS, &gNetworkCfgGnss);
        if (returnCode == 0) {
            // From here you can call any of the ubxlib GNSS or location APIs using httpDevHandle
            // and it will know to use the GNSS chip inside the cellular module

            ...

        } else {
            printf("Unable to open GNSS network on cellular device (%d).\n", returnCode);
        }
    } else {
        printf("Unable to open cellular device (%d).\n", returnCode);
    }

HOWEVER there is a catch: when the GNSS chip built-into a cellular module is used there is a software entity inside the cellular module (we call it UPOS) which will also talk to the built-in GNSS chip. There is no way to stop it doing this. It will usually only do so when the GNSS chip is being initially powered up, so it may not be an issue for you, but the reason UPOS is doing all of this talking is so that you, actually, don't have to; all of the AssistNow etc. things can be managed by the UPOS entity in the cellular module on your behalf.

I try to explain this (probably badly!) at the top of the file u_cell_loc.h, the file which defines all of the APIs provided for managing location through cellular; for the AssistNow parts, see this section of the header file.

So you may find it easier to use the uCellLocXxx() APIs to configure AssistNow etc. rather than doing it "the long way" yourself. Note that you can do both: you can still talk to the GNSS chip directly, following the pattern above, and, probably beforehand, call the uCellLocXxx() APIs to get UPOS to manage the AssistNow stuff for you.

RobMeades commented 4 weeks ago

Gah, now that you just posted issue #249 and I've switched my brain on: you are using LENA-R8 and so we need to remember that LENA-R8 does not support access to the internal GNSS chip through CMUX, which is what all of our other modules do and it is how ubxlib accesses a GNSS chip inside a cellular module when you do as I have indicated above (i.e. when you call uNetworkInterfaceUp() for a GNSS network in a cellular device).

You can still do the above but, for LENA-R8, you would have to force ubxlib to use the AT+UGUBX polling mechanism to access the internal GNSS chip by defining U_NETWORK_GNSS_CFG_CELL_USE_AT_ONLY for your build, and then we're back to the same problem you had before in #241 with replies from the GNSS chip to UPOS commands ending up replacing the wanted replies to commands that you have sent to the GNSS chip.

So I think it is simpler if you ignore any mechanism via which the cellular module configures the internal GNSS chip for you, just leave the internal GNSS chip off as far as the cellular entity is concerned and do as you indicated in #241 and open the GNSS chip as an entirely separate device, talking to it over the dedicated and separate RXD_GNSS and TXD_GNSS pins. In other words, follow the assist_now_main.c example and nothing else.

Does that make sense?

RobMeades commented 2 weeks ago

@mos216: are you OK to close this one now?

mos216 commented 2 weeks ago

Hi Rob , yes sure thanks again!