Pulse width constraints too tight?

[Neil-McK]

I've been looking at DCC signals and the performance of isolation circuits in connection with Arduinos. When decoding DCC in an Arduino, the measured half-pulse widths for a '1' bit, which is transmitted as exactly 58us, can vary between 49 and 68us or so, worst cases. I think that most of this variation probably comes from Arduino clock interrupts which, on the Uno and Mega, take around 7-8us and could delay a digital change interrupt by this amount. This interrupt latency would occur within the detector, and also in the DCC source if it is Arduino-based. I see that your decoder follows NMRA S-9.1 to the letter and requires a half-bit to be within 52-64us. The measurement is done uaing the micros() function which increments every 4us. Taking the 4us timer resolution, and the error of up to 8us caused by interrupt latency in the decoder, do you think that using the NMRA criteria literally is too strict? I know that not many packets are affected, and DCC sends a lot of retransmissions, so it won't make much difference, except when used in a sniffer. But taking the possible cumulative measurement error in the detector (4+8us) into account, perhaps a range of at least 40-76us would be more appropriate on the Arduino. N.B. The NmraDcc library uses a range 35-82us. I've also measured a few commercial loco decoders and they accept pulses of the order of 38-70us for 1 bits.