I was not at the meeting and I have not seen a log file (one has been requested) so unlike a lot of other people here I don't feel I can state anything definitive.

The only definite hardware issue I am aware of is, as stated, if they were using an old 16 bit (Windows 3.1) application with Windows 2000, XP, etc and using low level hardware access, e.g transponders. This is a known recipe for intermittent hardware access problems.

The point I was trying to make is that we cannot assume that because we use AMB transponders and so do F1 that we can expect the same reliability.

However, AMBrc is a huge leap forward from any earlier system. I have examined many log files and the reliability of the AMBrc hardware is high. I have seen many meeting, over months, without even one missed lap. With sequence numbering, data re-requesting and data logging, etc, etc, it can be proven beyond reasonable doubt where any problem occurs, in either the trackside of the decoder (usually the loop) or computer side of the decoder (cable, port, computer or software) and with some further work even more can be found.

Of course, even if a definitive answer is found via a log file, e.g. that the problem was the loop, and that is backed up by sending the info to AMB, it doesn't mean that RC people here would even believe it, as has been shown.