They needed to fire the pulse on the edge of the card's port within 50ns of a pre-determined GPS time. However they originally wanted this pulse to originate in the Kernel. I told them that would never happen on time and between bus jitter and kernel scheduling we could never pull this off.

I dug deeper and found that the application could figure out 5ms in advance the GPS time code of when it needed to fire, With that in mind what they really needed was the ability for the firmware to have a time trigger that was programmable through the device driver from the application. That way the dedicated board would fire the pulse exactly when the application wanted it fired.

Basically I turned their logic on it's head and it fixed the problem. The firmware guys and I met, we developed a protocol a couple days later they gave me a new board and I had already written the driver changes and a sample client.

I guess the underlying point of the story is just because someone asks you to do something impossible doesn't mean the problem isn't solvable. They may be coming at you with incomplete information and you need to push to better understand the problem. Once we were all on the same page it took a firmware rev and some small changes to their application and it was a success.