Move to GNSS library returns different result on getFixType()

[cyclops1982]

Subject of the issue

getFixType() returns 20.

Your workbench

• RAK4630 with RAK12500 module.
• Powered with USB or battery (doesn't matter)

Steps to reproduce

Upgraded from SparkFun_u-blox_Arduino_library to the GNSS verison.

Expected behavior

Most code that is in examples looks like this:

  byte gpsFixType = 0;
  while (gpsFixType < 3)
    {
      gpsFixType = g_GNSS.getFixType(); // Get the fix type
      Serial.print(F("Fix: ")); // Print it
      Serial.print(gpsFixType);
      if (gpsFixType == 0)
        Serial.print(F(" = No fix"));
      else if (gpsFixType == 1)
        Serial.print(F(" = Dead reckoning"));
      else if (gpsFixType == 2)
        Serial.print(F(" = 2D"));
      else if (gpsFixType == 3)
        Serial.print(F(" = 3D"));
      else if (gpsFixType == 4)
        Serial.print(F(" = GNSS + Dead reckoning"));
      else if (gpsFixType == 5)
        Serial.print(F(" = Time only"));
      Serial.println();
    }

In my case, g_GNSS.getFixType() returns 20, while with the old library it return 0.

Actual behavior

I'm not sure why it returns 20 now, and what that could mean. .h files don't mention a 20 coming back from getFixType(). The example here also doesn't seem to cater for anything <0 or > 5.

[PaulZC]

Hello Ruben (@cyclops1982 ),

Can you please take a photo of the ZOE-M8Q on your RAK12500 - and post it here? I would like to see the version codes on the chip itself. It is tricky to get the lighting correct, but it should look like this:

Thank you, Paul

[cyclops1982]

Thanks for looking at this Paul!

I think it says:

ZOEM8Q
E4110
24 1CF

[PaulZC]

Hi Ruben,

OK - thanks! It will be difficult for me to reproduce your hardware set-up completely. The best I can do is to test these two products together:

https://www.sparkfun.com/products/15025 https://www.sparkfun.com/products/15193

I will try to do that later today.

Best wishes, Paul

[PaulZC]

Hi Ruben (@cyclops1982 ),

Are you using the I2C interface - or the Serial TX and RX interface - to communicate with the ZOE? It looks like RAK supports both.

Thanks, Paul

[cyclops1982]

The RAK does support both.

I haven't actually specified it, so i'm assuming it's I2C in this case. My initialization is just:

SFE_UBLOX_GNSS g_GNSS;
// Setup/start the wire that we use for the Sensor.
  Wire.begin();

  // Start up stuff
  pinMode(WB_IO2, OUTPUT);
  digitalWrite(WB_IO2, LOW);
  delay(100);
  digitalWrite(WB_IO2, HIGH);
  delay(100);
  // Sleep mode interrupt pins
  pinMode(VAL_RXM_PMREQ_WAKEUPSOURCE_UARTRX, OUTPUT);
  digitalWrite(VAL_RXM_PMREQ_WAKEUPSOURCE_UARTRX, LOW);

  if (g_GNSS.begin() == false)
  {
    SERIAL_LOG("Ublox GPS not detected at default I2C address. Please check wiring. Halting.");
  }

[cyclops1982]

So - i think this is not related to the library now!

My code is here: https://github.com/cyclops1982/RAKTracker/tree/RAK12500

If i move

    uint16_t distance = getDistance();
    uint16_t vbat_mv = BatteryHelper::readVBAT();

from here to here, then i get weird results.

Both the distance sensor and the gps use the Wire stuff, so i guess something is going wrong there!

[PaulZC]

The VL53L0 uses address 0x52, the GNSS uses address 0x42. So if you get one bit error in your I2C addressing, you could end up talking to the wrong device.

It could be pull-up related. It's not easy to see from the RAK schematics if they have pull-ups on the I2C bus.

I'd recommend using a logic analyzer or oscilloscope to check the I2C bus, to make sure the signals are clean.

I won't do any hardware tests until I hear back from you.

[cyclops1982]

Thanks @PaulZC !

I'll try to figure it out what it is. I don't think this is the library at all. I've been struggling understanding the schema and details as well!

[PaulZC]

If you have access to the I2C SCL and SDA pins, try adding 2K2 (or 4K7) resistors from each line to 3.3V. It may help.