Data Ready PIN

[michaelboeding]

Is the data ready pin usable? Meaning if I hooked this up in hardware for a MAXM10S would it notify me via an interrupt when new GPS data is available?

  //the gps device 
  uDeviceCfg_t gDeviceCfg = {
      .deviceType = U_DEVICE_TYPE_GNSS,
      .deviceCfg = {
          .cfgGnss = {
              .moduleType = U_GNSS_MODULE_TYPE_M10,
              .pinEnablePower = U_CFG_APP_PIN_GNSS_ENABLE_POWER,
              .pinDataReady = -1,
          },
      },
      .transportType = U_DEVICE_TRANSPORT_TYPE_UART,
      .transportCfg = {
          .cfgUart = {
              .uart = UART_NUM,
              .baudRate = BAUD_RATE,
              .pinTxd = TX_PIN,
              .pinRxd = RX_PIN,
              .pinCts = CTS_PIN,
              .pinRts = RTS_PIN,
              .pPrefix = NULL
          },
      },
  };`

[RobMeades]

HI Michael: we added that field for forwards compatibility only, unfortunately there is currently no functionality behind it. This is partly because I wasn't sure of the usage scenario: when ubxlib has asked the GNSS device for something it would likely just wait for an answer without monitoring a pin, if the ubxlib code is streaming stuff from the GNSS device likewise it would probably just be active all of the time. I guess that the main usage of such a pin would be for an MCU that wants to power-save while waiting, which would be done outside of ubxlib, so we could, as you say, maybe provide a callback in interrupt-context when the GNSS device sets its Data Ready pin, and then the application code could do something.

Can you see a use-case where ubxlib itself would take note of the pin? I had been thinking of streaming as a kind of continuous high-speed thing but I guess there is no good reason for that, a stream could be intermittent, in which case we might have the UART/I2C/SPI receive gate itself on the GNSS device's Data Ready pin when doing streaming location, i.e. wait for a Data Ready interrupt, read from the GNSS device until empty and then return to waiting on a Data Ready pin interrupt. Probably we could have the GNSS UART/I2C/SPI receive code wait [with a timeout] on a semaphore which is set in the interrupt, then whatever natural power-saving capability is configured for the RTOS would take over during the wait.

Would that make sense? And then if this works I guess we might was well apply it even to the "ubxlib has asked for something and is waiting for a response" case, though I'd need to check if the GNSS device's Data Ready pin works generically in all cases rather than being specific to the availability of a location fix (it is not a pin I have so far looked at in any detail).

[RobMeades]

Had a look into the code now and this seems quite do-able: when do you need it by?

[michaelboeding]

Hey Rob, I think my use case is more of the initial gps fix and whenever I send an initial gps request. It's not urgent but would be nice to have. I can get by with my application using the current methods, but it would be nice to have in maybe a month? And I guess the MAXM10S doesn't have geofences built into the module firmware but if it did we could use that pin for various other Wakeup Sources like that.

[RobMeades]

OK, I think it can be done transparently to the application, hope to get it done in a week or two, distractions permitting. Will update this issue when I have something for you to try.