Untethered Dead Reckoning and odometer use with cellular module integration about ubxlib HOT 11 OPEN

Hi, and thanks for posting. You are correct that (2) and (3) aren't explicitly mentioned in the ubxlib world, it is getting kind of specialist, but hopefully ubxlib gives you the tools you need to "DIY".

Your application would use the functions of the u_gnss_msg.h API, things like uGnssMsgSend(), uGnssMsgReceive(), uGnssMsgReceiveStart() etc. to exchange/read messages with the GNSS device, potentially along with the u_gnss_dec.h API, chiefly pUGnssDecAlloc(), should you find that approach of use.

pUGnssDecAlloc() won't "know" about all of the message types etc., you would need to refer to the interface manual for the NEO-M8 as you went in terms of understanding the required UBX message contents, so you don't have to use pUGnssDecAlloc(), only do so if you find it helpful; you can just "manually" decode the UBX messages yourself.

from ubxlib.

Alternatively, if you can think up the API that you might like in ubxlib we would be happy to implement it.

from ubxlib.

It would be nice if you could implement the odometer and UDR capabilities. I can already thing of a plethora of use-cases.

from ubxlib.

Now after following the main_loc_gnss_cell.c in the examples folder and adapting it to my use case. I run into errorcode -4 when I call uDeviceOpen. Upon debugging step by step I realize it is uDevicePrivateCellAdd in uDeviceOpen that is causing the error. Here is the configuration settings for the cellular device I am using

static const uDeviceCfg_t device_Cfg = {
    .deviceType = U_DEVICE_TYPE_CELL,
    .deviceCfg = {
        .cfgCell = {
            .moduleType = U_CELL_MODULE_TYPE_SARA_U201,
            .pSimPinCode = NULL,
            .pinEnablePower = -1,
            .pinPwrOn = pinPWROn, // GPIO01 pin of ESP32 chip
            .pinVInt = -1,
            .pinDtrPowerSaving = pinDTR, // GPIO16 pin of ESP32
        },
    },
    .transportType = U_DEVICE_TRANSPORT_TYPE_UART,
    .transportCfg = {
        .cfgUart = {.uart =  U_CFG_APP_CELL_UART, .baudRate = U_CELL_UART_BAUD_RATE, .pinTxd = pinTXD, .pinRxd = pinRXD, .pinCts = -1, .pinRts = -1, .pPrefix = NULL},
    },
};

The code is running as part of my own code written in esp-idf.

from ubxlib.

Error code -4 is U_ERROR_COMMON_NOT_SUPPORTED. I think this is likely because you have a pin set there for pinDtrPowerSaving and SARA-U201 does not support DTR power saving; from the AT commands manual, section 20.1.7, see the note for SARA-U2:

Set pinDtrPowerSaving to -1 and you should hopefully get further.

[Ooops, looks like I didn't press send on this]

from ubxlib.

It would be nice if you could implement the odometer and UDR capabilities. I can already thing of a plethora of use-cases.

Understood: the issue will be testing as we have no way at all to regression test this. I will think of what we can do.

from ubxlib.

Error code -4 is U_ERROR_COMMON_NOT_SUPPORTED. I think this is likely because you have a pin set there for pinDtrPowerSaving and SARA-U201 does not support DTR power saving; from the AT commands manual, section 20.1.7, see the note for SARA-U2:

Set pinDtrPowerSaving to -1 and you should hopefully get further.

[Ooops, looks like I didn't press send on this]

Right, that actually worked. But now running into another error code errorCode -257

from ubxlib.

Very good: following the guidance here you will see from the number that that is a cellular error code U_CELL_ERROR_NOT_CONFIGURED.

Searching the ubxlib code for that it occurs in only two places, both of which are in u_cell_pwr.c: one in uCellPwrOffHard(), which I guess is not what you're doing, which leaves us with moduleConfigure(); this sets all the static/initialisation things up with the module when it is powered-up or reset, likely one of those AT commands is failing.

Can you paste in here a log of the AT sequence emitted by ubxlib at power-up?

EDIT: I just realised you say above "that actually worked", so you're probably not seeing this errorCode -257 back from uDeviceOpen(), in which case please paste the AT sequence that leads up to the failure.

from ubxlib.

U_CELL: initialising with enable power pin not connected, PWR_ON pin 1 (0x01) (and is toggled from 1 to 0) and VInt pin not connected.
�[0;32mI (4271) gpio: GPIO[1]| InputEn: 0| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0 �[0m
AT

OK
U_CELL_PWR: powering on, module is already on.
ATE0

OK
AT+CMEE=2

OK
AT+UDCONF=1,0

OK
ATI9

23.60,A01.01

OK
AT&C1

OK
AT&D0

OK
AT&K0

OK
AT+UPSV=1,1300
U_CELL_PWR: power saving not supported.
AT+CPSMS?
AT+UGPRF?
AT+CFUN=0

This appears twice and it just hangs.

from ubxlib.

Thanks for that: as part of the power-on sequence the ubxlib code is asking the SARA-U201 module to enable UART power saving, which is what AT+UPSV=1,1300 does, but the SARA-U201 module is unresponsive after that.

How important is power saving in your application? If it is not particularly important you can define U_CFG_CELL_DISABLE_UART_POWER_SAVING when building ubxlib and ubxlib will not try to switch UART power saving on in the module.

If power saving is important the next thing to do is to put a monitor of some form (e.g. a Saleae probe) on the UART lines (i.e. TXD, RXD, CTS and RTS) to (a) confirm that the module really is unresponsive, rather than something else going wrong and (b) see if something like the state of the CTS output line from the module is somehow preventing the UART of your MCU sending things to it (seems unlikely, since the problem is a "lack of response from the module" problem).

from ubxlib.

Update: if UART power saving is important to you, I think I've found out what's up, hopefully no need to probe the UART lines.

The SARA-U201 integration manual says "on SARA-U2 modules, when the AT+UPSV=1 command is issued by the DTE, the UART is immediately disabled", i.e. it doesn't, sometimes, even respond with OK, it just stops dead as soon as the command enabling UART power saving arrives. This also means that the module is immediately in power-saving mode, it doesn't wait for the 6 seconds implied by the value 1300 to expire, which all our other module types do.

I have modified the ubxlib code to handle this little chicane on a preview branch that you can find here:

https://github.com/u-blox/ubxlib/tree/preview_fix_sara_u201_uart_power_saving_rmea

We haven't been testing SARA-U201 with UART power saving enabled so I've modified that to enable it and run the change through our testing; it seems to pass but it would be good if you could confirm this "for real".

EDIT: unfortunately there still seems to be a problem with writing files into the SARA-U201 module file system if UART power saving is enabled, and this is required for HTTPS to operate; the correct number of characters are written to file but reading the characters back shows that the file contents are garbage. I will try to find out if this is a known issue with SARA-U201 that might have a workaround.

from ubxlib.