uBlox Library

Updated the API for this library to (hopefully) make it more useful, updated to Arduino 1.5 format, and pushed to be added to the library manager. The library now is Arduino generic, rather than requiring a Teensy. Planning on adding configuration methods in a future update.
 
Hi Chris,
Have a question for you on the UBLOX library. When setting CFG-RATE you are currently just setting the Measurement period or rate, think its res0?. Then you also set para0 = 0x01, para1 = 0x0, para2 = 0x01 and para3 = 0x0. Would these correspond to the navigation rate and frequency? What would have to get changed to set the navigation rate and navigation cycles. Think only Para0 would be affected. So if I wanted 5 para0 would be 0x05?

Thanks
Mike
 
Ok. I changed your setRate function to include the navRate. Think its right at for now.
Code:
// UBX-CFG-RATE (0x06 0x08)  Set Navigation/Measurement Rate Settings (100ms=10.00Hz, 200ms=5.00Hz, 1000ms=1.00Hz, Etc)
// Generate the configuration command's syntax
void UBLOX::SetRATE(uint16_t measRate, uint16_t navRate, bool printACK) {
  bool Supported = false;
  if ( printACK == true ) {
    Serial.print("Setting CFG-RATE (0x06 0x08) Navigation/Measurement Rate ");
    _pACK_RATE = true; // print ACK to USB
  }
  // Possible Configurations
  // _______________________________________________________________
  // 60ms    16.67Hz <-- | 192ms    5.21Hz     | 600ms    1.67Hz
  // 64ms    15.63Hz <-- | 200ms    5.00Hz <-- | 625ms    1.60Hz
  // 72ms    13.89Hz <-- | 225ms    4.44Hz     | 640ms    1.56Hz
  // 75ms    13.33Hz <-- | 240ms    4.17Hz     | 720ms    1.39Hz
  // 80ms    12.50Hz <-- | 250ms    4.00Hz <-- | 750ms    1.33Hz
  // 90ms    11.11Hz     | 288ms    3.47Hz     | 800ms    1.25Hz <--
  // 96ms    10.42Hz     | 300ms    3.33Hz     | 900ms    1.11Hz
  // 100ms   10.00Hz <-- | 320ms    3.13Hz     | 960ms    1.04Hz
  // 120ms    8.33Hz     | 360ms    2.78Hz     | 1000ms   1.00Hz <--
  // 125ms    8.00Hz <-- | 375ms    2.67Hz     | 2000ms   0.50Hz <--
  // 128ms    7.81Hz     | 400ms    2.50Hz <-- | 4000ms   0.25Hz <--
  // 144ms    6.94Hz     | 450ms    2.22Hz     | 10000ms  0.10Hz <--
  // 150ms    6.67Hz     | 480ms    2.08Hz     | 20000ms  0.05Hz <--
  // 160ms    6.25Hz     | 500ms    2.00Hz <-- | 50000ms  0.02Hz <--
  // 180ms    5.56Hz     | 576ms    1.74Hz     |
  // NOTE: Only rate settings marked with arrows are the implemented configuration.
  switch (measRate) {
    case 60:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("60ms 16.67Hz");
      }
      break;
    case 64:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("64ms 15.63Hz");
      }
      break;
    case 72:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("72ms 13.89Hz");
      }
      break;
    case 80:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("80ms 12.50Hz");
      }
      break;
    case 100:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("100ms 10.00Hz");
      }
      break;
    case 125:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("125ms 8.00Hz");
      }
      break;
    case 200:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("200ms 5.00Hz");
      }
      break;
    case 250:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("250ms 4.00Hz");
      }
      break;
    case 400:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("400ms 2.50Hz");
      }
      break;
    case 500:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("500ms 2.00Hz");
      }
      break;
    case 800:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("800ms 1.25Hz");
      }
      break;
    case 1000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("1000ms 1.00Hz");
      }
      break;
    case 2000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("2000ms 0.50Hz");
      }
      break;
    case 4000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("4000ms 0.25Hz");
      }
      break;
    case 10000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("10000ms 0.10Hz");
      }
      break;
    case 20000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("20000ms 0.05Hz");
      }
      break;
    case 50000:
      Supported = true;
      if ( printACK == true ) {
        Serial.println("50000ms 0.02Hz");
      }
      break;
    default:
      Supported = false;
      _pACK_RATE = false;
      Serial.print("\tNot Supported :"), Serial.println(measRate), Serial.println("\tPossible Configurations");
      Serial.println("\t60=16.67Hz 64=15.63Hz 72=13.89Hz 80=12.50Hz 100=10.00Hz 125=8.00Hz 200=5.00Hz 250=4.00Hz 500=2.00Hz");
      Serial.println("\t800=1.25Hz 1000=1.00Hz 2000=0.50Hz 4000=0.25Hz 10000=0.10Hz 20000=0.05Hz 50000=0.02Hz "), Serial.println();
      break;
  }
  if ( Supported == true ) {
    // Splitting an uint16_t measRate
    // Identifier & res0 - 16bit Parameter defines the rate. e.g. 100ms => 10Hz, 1000ms => 1Hz, 10000ms => 0.1Hz.
    uint8_t res0 = ((measRate & 0xFF00) >> 8);
    uint8_t Identifier =  (measRate & 0x00FF);
    uint8_t CLASS = 0x06, ID = 0x08, Length0 = 0x06, Length1 = 0x00;
    uint8_t Par0 = navRate, Par1 = 0x00, Par2 = 0x01, Par3 = 0x00; // navRate and timeRef Parameters.
    uint32_t P32t0 = 0, P32t1 = 0; // not used for this command
    writeCommand(CLASS, ID, Length0, Length1, Identifier, res0, Par0, Par1, Par2, Par3, P32t0, P32t1);
  }
}
 
HI Mike
Yes that looks almost correct the navRate and timeRef was hard coded in. Looking in the u-blox manual Receiver Description PDF the UBX-CFG-RATE (0x06 0x08) and navRate note: This parameter is ignored and the navRate is fixed to 1 in protocol versions less than 18.
Edit: @ that time I was playing with u-blox 7 GPS
Void UBLOX::SetRATE(uint16_t measRate, uint16_t navRate, bool printACK)...... navRate 16bit
Uint8_t Par0 = navRate,..... 8bit

In UBLOX.cpp writeCommand(....) loop about line 210.
Code:
      // ID CFG-RATE (0x08)
      if (ID == 0x08) { // ID CFG-RATE (0x06 0x08) Navigation/Measurement Rate Settings, e.g. 100ms => 10Hz, 1000ms => 1Hz, 10000ms => 0.1Hz
        if (Bit16PayloadLen == 0x06) { // Length (Bytes) DEC 6
          DATA [0] = Identifier;     // 0  U2 - measRate ms
          DATA [1] = reserved0;      //    U2 - measRate
          DATA [2] = Par0;           // [COLOR="#FF0000"]2  U2 - navRate[/COLOR]
          DATA [3] = Par1;           //    [COLOR="#FF0000"]U2 - navRate[/COLOR]
          DATA [4] = Par2;           // 4  U2 - timeRef
          DATA [5] = Par3;           //    U2 - timeRef
        }
      } // end UBX-CFG-RATE (0x06 0x08)
 
Hi Chris,
So basically I have to setup Par0 and Par1 like you did with measRate
Code:
    uint8_t res0 = ((measRate & 0xFF00) >> 8);
    uint8_t Identifier =  (measRate & 0x00FF);
like this:

Code:
    uint8_t Par1= ((navRate& 0xFF00) >> 8);
    uint8_t par0=  (navRate& 0x00FF);

Mike
 
Yeah but the funny part is navRate:

The ratio between the number of
measurements and the number of navigation
solutions, e.g. 5 means five measurements for
every navigation solution. Max. value is 127. ;)
 
Yep. But hopefully the nav solution is a little more accurate. It has the effect of slowing down the output :)
 
Chris O,
Where might I get your latest updates on Brian's UBlox Library? I'm doing some RTK GPS testing using Brian's library, and I'm thinking some of your mods would be very helpful. I'm wanting to configure the RTK base station via arduino (vs using u-center), so am looking for additional config commanding capability, and the ability to access some additional parameters (like the 3D accuracy parameter).

Thanks! Don
 
Mike,
I took a look at the examples. In the Ublox2 example, were you all experimenting with reading multiple ubx messages concurrently? I know Brian's library was originally intended to just read the UBX-NAV-PVT message. Don
 
Don,
Never really tried polling the NAV_ATT or NAV_POSLLH but as long as you enable it you should be able get the associated data elements.

Mike
 
Mike,
Thx. For RTK operations, there's a "high precision" UBX message (UBX-NAV-HPPOSECEF) that I want to parse, in addition to the info that's in the regular (UBX-NAV-PVT) message. So I'll likely mod the library to read the high precision message, and it's cool that I can likely listen for both with this library as the starting point.

By the way, I've been flying my RTK package (M8Ts with RTK code running on an SBC) on UAVs for a UAV firm. Have got a new package running now using the M8P-02, and this M8P-02 is really just a place-holder until my F9Ps arrive. For the locations we're flying, there is no available NTRIP castors so I provide my own base stations as well.

Don
 
Mike,
Thx. For RTK operations, there's a "high precision" UBX message (UBX-NAV-HPPOSECEF) that I want to parse, in addition to the info that's in the regular (UBX-NAV-PVT) message. So I'll likely mod the library to read the high precision message, and it's cool that I can likely listen for both with this library as the starting point.

By the way, I've been flying my RTK package (M8Ts with RTK code running on an SBC) on UAVs for a UAV firm. Have got a new package running now using the M8P-02, and this M8P-02 is really just a place-holder until my F9Ps arrive. For the locations we're flying, there is no available NTRIP castors so I provide my own base stations as well.

Don

Hey Don,

Where are you getting your F9P's from? I'm waiting for eval boards from uBlox, but I saw that CSG Shop has some for sale:
https://www.csgshop.com/product.php?id_product=263

Also, feel free to pull request any updates to the UBLOX library, I can merge them in and hopefully we can get this library working well for the new F9 receivers.

Brian
 
Hi Brian,
I ordered two from CSG several weeks ago, and about two weeks ago I got a message they were getting ready to ship. Not sure what it meant, so I guess I'm unsure if they've shipped or if I'm just in the queue.

One recent batch of M8Ps took about 5 weeks to make it here from CSG. And there's not a way to really get any tracking info from them as best I can tell.

If I get the high precision UBX message parsing I'll share the code. We'll need it for the F9Ps... and hopefully they'll not change the UBX structures too much.

Don
 
Hi Don,
I saw the F9P from CSG and wasn't crazy about the fact that they didn't have a break out for plain headers - I hate those JST SH connectors, can never get dupont headers on them correctly :). Anyway just came across this product which looks interesting called ardusimple: https://www.ardusimple.com/simplertk2b/. Supposedly it will be 159euros which is really reasonable.

Any, the real reason I was that I can find the receiver spec for the F9P. I thought I read somewhere that there are differences in the message formats between the F9P and M8. Have you seen it?

Mike
 
Has anyone tried to use Brian's ublox library to parse UBX-NAV-PVT via I2C? I'm using the I2C interface to the SparkFun RTK (M8P) board with its nice Qwiic I2C interface. The SparkFun_Ublox_Arduino_Library works great for pulling NMEA via I2C, but I haven't been able to figure out how to pull UBX-NAV-PVT with it. My thought was to pull the UBX message with the SparkFun library and then parse it with Brian's UBLOX library. Any suggestions or thoughts? Guessing there may be an easier way, or I may be doing something dumb since I'm not the greatest with interfaces...
 
Hi Don
Is this what you're looking for?
Yep that's it - for some reason I couldn't find it. Hope you had a good Christmas. Btw - I ordered two of those Ardusimple boards - site said deliveries start in January :)

Has anyone tried to use Brian's ublox library to parse UBX-NAV-PVT via I2C?
As for this question, nope - haven't tried to modify it for use with I2C.

Thanks again for the reference
Mike
 
Has anyone tried to use Brian's ublox library to parse UBX-NAV-PVT via I2C? I'm using the I2C interface to the SparkFun RTK (M8P) board with its nice Qwiic I2C interface. The SparkFun_Ublox_Arduino_Library works great for pulling NMEA via I2C, but I haven't been able to figure out how to pull UBX-NAV-PVT with it. My thought was to pull the UBX message with the SparkFun library and then parse it with Brian's UBLOX library. Any suggestions or thoughts? Guessing there may be an easier way, or I may be doing something dumb since I'm not the greatest with interfaces...

Not yet, but it's on my long term "to do" list. My goal is to incorporate it by overloading the class declaration, like:
* Serial: UBLOX ubx(Serial1, 115200);
* I2C: UBLOX ubx(Wire, 0x48);

The rest of the methods would remain the same.
 
Brian,
That sounds perfect. Will be glad to volunteer to help test or debug it! Think this will be really useful for M8P and F9P RTK ops, as I can see where we may want to send UART RTCM3 data to the autopilot but still display status using I2C UBX binary (or possibly even both using I2C). Cool!
Don
 
Hi Don - Brian,
Does that mean the library will be updated for RTCM3 messages as well?

Mike
 
Back
Top