ubxlib: nrf52840dk stops reading location data momentarily ?

Hello,

I am trying to read location data from my drotek F9P using ubxlib and nrf52840dk. Here is the code below :

#include <string.h>
#include <stdio.h>
#include <time.h>

#include "ubxlib.h"


static size_t gPositionCount = 0;

static const uDeviceCfg_t gDeviceCfg = {
    .deviceType = U_DEVICE_TYPE_GNSS,
    .deviceCfg = {
        .cfgGnss = {
            .moduleType = U_GNSS_MODULE_TYPE_M9,  // This is the module type
            .pinEnablePower = -1,
            .pinDataReady = -1
        },
    },
    .transportType = U_DEVICE_TRANSPORT_TYPE_I2C,
    .transportCfg = {
        .cfgI2c = {
            .i2c = 1, // This is the I2C HW block - ubxlib knows nothing about the device tree so you need to tell it
            .pinSda = -1,
            .pinScl = -1
        },
    },
};



// Return longitude/latitude value as string
static char *locStr(int32_t loc)
{
    static char str[25];
    const char *sign = "";
    if (loc < 0) {
        loc = -loc;
        sign = "-";
    }
    snprintf(str, sizeof(str), "%s%d.%07d",
             sign, loc / 10000000, loc % 10000000);
    return str;
}


void main()
{
   
   uDeviceHandle_t devHandle = NULL;
    int32_t returnCode;
    int32_t errorCode=0;

    int32_t guardCount = 0;

    // Initialise the APIs we will need
    uPortInit();
    uPortI2cInit(); // You only need this if an I2C interface is used
    uDeviceInit();

    returnCode=uDeviceOpen(&gDeviceCfg, &devHandle);
 uLocation_t location;

while(1){
    if (returnCode == 0) {
        // Since we are not using the common APIs we do not need
        // to call uNetworkInteraceUp()/uNetworkInteraceDown().

        // Start to get position

       
        int tries=0;


                printf(".");
                errorCode = uLocationGet(devHandle, U_LOCATION_TYPE_GNSS,
                                        NULL, NULL, &location, NULL);


        printk("error code : %d",errorCode);
        if (errorCode == 0) {
                
                printf("Position: https://maps.google.com/?q=");
                printf("%s,", locStr(location.latitudeX1e7));
                printf("%s\n", locStr(location.longitudeX1e7));
                
                
            } else if (errorCode == U_ERROR_COMMON_TIMEOUT) {
                printf("* Timeout\n");
            }

    } else {
        uPortLog("Unable to open GNSS!\n");
    }
}

    // Close the device
    // Note: we don't power the device down here in order
    // to speed up testing; you may prefer to power it off
    // by setting the second parameter to true.
    uDeviceClose(devHandle, false);

    // Tidy up
    uDeviceDeinit();
    uPortSpiDeinit(); // You only need this if an SPI interface is used
    uPortDeinit();

    uPortLog("Done.\n");

}

At first I start getting data and all seems to work fine but sometimes I stop getting data for a couple of seconds and it resumes after.

Here is the last message I see in the console before it stops. error code : 0error code : 0error code : 0

I have configured my F9P rate to 10 hz. I don’t seem to have this problem with lower frequency, It would be much appreciated if you can help me with this.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 33 (19 by maintainers)

Most upvoted comments

Hello Rob, sorry for the late response.

Indeed I completely forgot about the header bytes, I was getting the correct data.

Thank you for the new branch it will be of great use to me.

Ah, thanks, I was looking at UBX-NAV-POSLLH and not UBX-NAV-HPPOSLLH, I see the fields now.

I will look at how we can properly add support for this.

The are I1s with lonHp and LatHp components in the HPPOS messages that you just add. these are scaled 1e-9 deg

@RobMeades there are secondary fields adding precision to both lat/lon and altitude. You have to unpack and add them. The 32-bit signed values don’t have enough digits of precision, beyond +/-180.xxxxxxx. Similarly don’t use 32-bit floats, they are worse. Use 64-bit double as these will maintain scope and precision.

See hpLon / hpLat fields, notably 8-bit +/-99 (or perhaps odd 100, if rounding/decomposition artifacts)

https://portal.u-blox.com/s/question/0D52p00008HKCkcCAH/high-precision-component-of-longitude-latitude-is-out-of-range https://portal.u-blox.com/s/question/0D52p00008HKDYyCAP/how-can-i-decode-the-raw-data-of-the-message-nav-hpposllh-and-nav-hpposecef-with-python https://portal.u-blox.com/s/question/0D52p00009OYjqgCAD/ubxnavrelposned-high-precision-component-out-of-range-9999

Alright Rob thank you again for helping me and saving me from Grimsby’s weather:-).