With respect to everybody concerned, I've looked only slightly at Ultibo and so far I don't recall seeing anything about a *guaranteed* interrupt latency.
If it's as bare as claimed, and
if it allows the programmer to set a timer, and
if that timer can trigger an interrupt,
that the programmer can set the vector to point at his code,
then I would expect sub microsecond latency. I'd prefer to code this part in assembler but not a killer if it isn't. (And I'm not familiar with ARM assembly language and don't want to be unless pressed). Ultibo does support inline assembler.
Paired with that I'd want to know what other interrupts are being serviced, for what reason and if there is a priority scheme. Can I get the highest priority interrupt? I won't be in there that long. Promise!
IAC it would appear to have far lower latency risk than Linux, which rumour has it is not an RTOS. Not sure where I heard that.
You misunderstand. Correct me it I'm wrong, but I don't believe that the DoD give out calibration certificates or guarantees of service level.
You're quite correct. They don't. But it's irrelevant.
US DOD provide the clocks in orbit and monitor them on a four hour cycle against a ground based truth (the 4 hour policy may have changed over the years). They are very accurate. Beyond the signal leaving the satellite, the DOD's interest in the matter ends (other than for its government clients). So first off we trust the US DOD on this. (No point here in discussing 'what if's' on this IMO.)
Receiver manufacturers derive the 1 PPS (I've forgotten the exact method) in hardware, but it is not difficult to do and it is definitely easy to verify against standards at those labs that have them (depending on the accuracy required)). It is derived from the signal but the s/w in the receiver has to gate it on once the receiver has sufficient signal from space [number of sats needed depends on the application - a ground station that is accurately surveyed could do with a single satellite, I believe; an aircraft would need 4]. The manufacturers declare in their spec how accurate their 1 PPS signal is for the operating conditions of the spec. So you trust (and perhaps verify) the accuracy of the device as it is marketed.
Just re-reading the spec sheet for the first device coming in:
60 ns, 99% of the time.
(This is marketed as "Professional grade". Not sure but seems to be everything that isn't consumer or automotive. Certainly can't include commercial aviation.)
Further, a pin can be programmed to any rate between 10 MHz down to 4 seconds based on that. With such I could set up an interrupt at whatever rate convenient to the project...
So we trust and perhaps verify.
I read the report, and it appeared that the pilots- at least one of whom wasn't exactly the sharpest knife in the rack- had made absolutely no attempt to refer to GPS to deduce their altitude or rate of ascent/descent. And the report- which was of course French- didn't seem to think that was in any way out of the ordinary.
GPS is not a source of altitude info, to begin with, in normal flight operations. That particular A-340 almost certainly did not have a GPS with VNAV capability (it would be passing PVT to the INS of course). There is no cockpit indication at all of altitude from GPS other than (possibly) diving into the FMS (to the INS).
Finally, IIRC, the crew merely had to cross check left and right sources and that should have been enough to have them at least suspect they were losing altitude quickly .... also IIRC the left side pitot/static system was the culprit (and there was an airworthiness directive open on that model that Air France hadn't gotten around to sorting out yet...)
Link to the report - je lis le français tres bien ....
Meanwhile, I'm still trying to sort out some aspects of the gpiod stuff, and am rebuilding my WPi to help out with that. It's the usual sort of Linux problem: sometimes you need to map from a named device in /dev to a more detailed description in /sys, and that can be tedious.
But so far the interface units I posted don't look too bad.
I'll wait until the weekend to get to that....