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.

[RobMeades]

I now have something which should work for this, tested on ESP32, so you should be able to use it.

What GNSS module pin do you intend to use for TX-Ready? I ask because the mapping can be a little complex and I'd like to confirm that what I have will work for you, at least in theory, before I post a preview branch.

[cturvey]

Does it support UART or just SPI and DDC/I2C?
Also remember this is a PIO# not a pin number on the module
You can free them by disabling interfaces, ie CFG-I2C-ENABLED=0 frees PIO# for SCL/SDA
Review UBX-MON-HW(3) to see current usage/assignments
Some of the product docs have pin to PIO# relationship documented, others do not.

0x10510003 CFG-I2C-ENABLED

0x10A20001 CFG-TXREADY-ENABLED          0      FALSE
0x10A20002 CFG-TXREADY-POLARITY         0      FALSE
0x20A20003 CFG-TXREADY-PIN             00          0
0x30A20004 CFG-TXREADY-THRESHOLD     0000          0
0x20A20005 CFG-TXREADY-INTERFACE       00          0

CFG-TXREADY-INTERFACE = 0 // I2C
CFG-TXREADY-INTERFACE = 1 // SPI

I don't recall the M8's support UART either, then via UBX-CFG-PRT

[RobMeades]

Hi @cturvey: all three, and yes, we call the disables for interfaces that would otherwise conflict with the choice of pin.

Reason for asking what PIO @michaelboeding has chosen is that I can't test all of them so would like to at least eye-ball-confirm that what I have should work. Thankfully the MAX-M10S data sheet does list the PIOs.

EDIT: ubxlib will only support TX-Ready operation on M9 and later.
EDIT TO THE EDIT: sorry, obviously not all three, just I2C and SPI, since the M9 and later are limited that way.

[cturvey]

For UARTs one might consider the TIMEPULSE (1PPS), now there's some latency there, but you can control the pulse width such that the falling edge is an approximation. The UART also isn't flow controlled at any level, so the data just comes out, and you can catch the RXNE or FIFO related signals on your MCU

[RobMeades]

The UART also isn't flow controlled at any level, so the data just comes out,

Indeed, it can be done in other ways for UART.

[cturvey]

Yes, but sending query form commands for solutions can have significant latency, potentially over a second in particularly ill-timed interactions.

One might connect the TX pin to the MCU's GPIO/EXTI such that it wakes, and have a short, sacrificial message, that you can lose in the mean time whilst the MCU wakes and comes to it's senses. Some MCU have an LPUART that can be viable independently of the MCU viability.

[RobMeades]

Depends how sleepy you want your MCU to be I guess. From a ubxlib standpoint it could be set up to do nothing whatsoever until the UART interrupt fires, then whether an LPUART is used or something more complex is required we have to leave to the application.

[RobMeades]

@michaelboeding: the preview branch is passing testing on ESP-IDF so I've pushed it out here in case you have chance to try it: https://github.com/u-blox/ubxlib/tree/preview_feature_gnss_data_ready_rmea.

All you need to do is connect a pin of your MCU to a PIO of the GNSS device such as TIMEPULSE or EXTINT or one of the unused comms lines and then, in the structure you pass to uDeviceOpen() for the GNSS device, populate the pinDataReady field with the MCU pin number and the devicePioDataReady field with the PIO number of the GNSS device (see table 10 of the MAX-M10S data sheet for the PIO numbers). With that done, while waiting for a message, the ubxlib code will stop on a semaphore until the GNSS device sends TX-Ready high, allowing the RTOS to sleep, or you to do other things, etc.

TX-Ready only works if you are connected to the GNSS device over SPI or I2C (that is a limitation of the GNSS device).

I will be away for all of August so any feedback this week is welcomed, otherwise take your time.

[RobMeades]

@michaelboeding: turns out I've managed to complete testing on our other platforms also so this is now good to go from our end. I have put it in for review, hope to get it merged before I leave on hols mid next week. Feedback still welcomed until the end of this week probably.

[michaelboeding]

Hey Rob - sorry for the delay I will test this weekend!

[RobMeades]

@michaelboeding: since I have now received the relevant approvals and it has passed testing, the feature is now on master here, see commit 2896142. Feedback still welcomed of course, though it would probably be best to test master rather than the preview branch, which I will delete when I return from holiday at the very end of August.