MMS: can the GPIO pin-change signal be logged to flash alongside sensor fusion?

[GeorgiBDev]

Hi — capability question about MetaMotionS (MMS) firmware, not a bug report.

Goal

I need to timestamp an external digital event on the same timebase as
orientation data, with no host-side clock alignment anywhere in the path.

The intended setup: an impact/contact transducer is conditioned to a clean 1.8 V
digital edge and fed into an MMS GPIO pad. Both the pin-change events and the
orientation data are then logged to onboard flash in the same session, so
they share the same tick counter and can be compared directly after download.

Questions

1. Is logging the GPIO pin-monitor signal supported on current MMS firmware,
   concurrently with a sensor-fusion signal being logged? It looks
   structurally supported — the logging Add Trigger register accepts
   (module 0x05, register 0x0A) as a source, and gpio.cpp generates a
   pin-monitor[<pin>] logger URI — but I couldn't find anyone who has actually
   done it, so I'd like to confirm before committing to the hardware.

2. Do both loggers share the same tick counter? I.e. can I take a pin-change
   entry's tick and a quaternion entry's tick and compare them directly, with the
   48/32768 s (~1.465 ms) granularity as the only quantization term?

3. Are there documented rate or debounce limits on pin monitoring? The source
   is a piezo transducer, so one physical event can ring and produce several
   edges within a few ms. I'll add hardware hysteresis plus a blanking window,
   but I'd like to know whether the firmware itself drops or coalesces fast
   successive edges.

Already checked, so you don't have to repeat it

• GPIO API: mbl_mw_gpio_set_pull_mode, mbl_mw_gpio_set_pin_change_type
  (RISING/FALLING/ANY), mbl_mw_gpio_get_pin_monitor_data_signal,
  mbl_mw_gpio_start_pin_monitoring.
• MMS GPIO is 1.8 V logic (VIH 1.3–1.8 V, abs max VDD+0.3 V) — the comparator
  will be powered from the V1V8 pad, and the transducer is clamped ahead of it.
• Planning to use D0 (P0.04) or D1 (P0.05), avoiding D5/A5 (battery monitor).
• Aware of the recommended concurrency envelope (≈1 fusion element + 1–2 data
  signals) and of the MMS NAND semantics (flush_page before download,
  post-clear GC window).

Secondary question

The store page lists a 400 Hz max logging rate while the docs/forum mention up
to 800 Hz. Which is correct for MMS? It matters because sensor fusion is fixed
at 100 Hz, so I may log raw gyro at a higher ODR and run fusion offline to get
orientation resolution finer than the 10 ms fusion grid.

Note on the Swift SDK

In MetaWear-API-Swift, MWGPIOPinChange currently conforms to MWStreamable
but not MWLoggable. If onboard logging of pin changes is supported at the
protocol level, is there a supported route to it from the Swift SDK today
(raw/key-based logger?), or would that need an SDK addition?

Thanks!