I was reading through the code. After this line:
https://github.com/slaclab/rogue/blob/master/src/rogue/protocols/srp/SrpV3.cpp#L200
I feel like we can use the inbound transaction information about a transaction to reset the transaction timers of the of any out standing transactions

delTransaction(tran->id());
   for(i=0;i<tranMap_.size;i++){
      // Check for IDs ahead in time in the queue
      if ( (id - tranMap_[i]->id()) > 0x80000000) resetTransactionTimer(tranMap_[i]);
   }

This would still detected dropped transactions and prevent false timeouts (due to varying register transaction latency) by feed backing accept frame ID the transaction IDs still in the queue (edited)

Ryan Herbst [8:28 PM]
Interesting.
Let me think about that a bit

Larry Ruckman [8:34 PM]
If the SRPv3 transactions stopped, we would still get timeout errors as before. If a SRPv3 transaction got dropped, would would eventually get the timeout once the transaction pipeline gets to the dropped transaction (maybe a little bit longer before the actually timeout due to transaction ID feedbacking) (edited)
The feedback would take advantage of the fact that transactions are still flowing through the pipeline and not based a (communication latency + "ave" register transaction latency) assumption (edited)

Ryan Herbst [8:37 PM]
Yeah makes sense.

Larry Ruckman [8:37 PM]
as long as transactions are flowing, there are no reason to timeout of any transaction ID ahead in time with respect to the transaction frame received

Ryan Herbst [8:38 PM]
I could also start the timer when the transaction hits the srp level

Larry Ruckman [8:38 PM]
This would allow our DAQ to be adaptive to long transactions (like I2C)

Ryan Herbst [8:39 PM]
but there is still a backup potential