Need timestamp on ValueChanged event to decode PWM

[CodeChief]

Following on from issue #26 I'd like to officially request support for a timestamp in the ValueChanged event. It was nice to get the ValueChanged support at all in the Lightning provider, but unfortunately it has not yielded any benefit for PWM decoding, in fact made it worse. See my last post there for some sample results which demonstrate this degradation.

Please add a timestamp to the value changed event. It just needs to be any increasing value you like, perhaps the internal stopwatch value, but accurate to "some" microseconds as typical PWM protocols decode cycles of ~500-2500 microseconds.

If it were produced by the driver, then it would be really simple because they have direct access to a high accuracy timer without overhead. But even if changes are only allowed in the Lightning provider, that would still help because it runs at a higher priority (closer to the "fact"). Logically it makes absolutely no sense to make "after the fact" timings, the only sane thing to do is record a timestamp at/closest to where the event occurred. So 1st choice driver, 2nd choice your provider. Either would make me and anyone else needing to decode PWM in software with IoT very happy!

Without this, software PWM input (not dumb switching, real PWM = pulse WIDTH values) is simply not possible with the Windows IoT SDK.

[CodeChief]

No updates in months and other issues left unanswered. Is Lightning dead?

[IoTGirl]

Hi Mahmoud, Would you please review this feature request? @jessekaplan stated in #26

For the timestamp request, we would have to update the in-box APIs and so that can't be added as part of a github update. We do like that feature request though and are looking at options for implementing it and getting it out there

Sincere thanks, IoTGirl

[jordanrh1]

Look for Windows.Devices.Gpio.GpioChangeReader in the latest insider release SDK.

[IoTGirl]

Thanks Jordan! Closing this issue based on the latest response.