**** Awake now,
First MF uses a queued mechanism for interrupts. When a hardware interrupts, MF creates an interrupt event and puts it on a queue. The interrupt events are then processed by an internal interrupt processing thread, which calls your interrupt handler.
Depending upon what is going on, there can be a variable delay between the time when the hardware interrupt occurred and when your handler sees it. This explains why using DateTime.Now to time interrupts can cause significant jitter.
When you use an InterruptPort object, the event handler gets a relative timestamp for the interrupt as one of its parameters. This is the timestamp you should use for timing purpose.
Reading an IO Port’s value in an interrupt handler, expecting it to be the value that was present at the time of the interrupt is also a no-no for I hope obvious reasons.
The link below explains this further:
Let us know if this works in your application.