Surfaced while working #31 (branch fix/j1939tp-timers-abort-codes), out of that branch's scope by the working agreement.
What happens
J1939TpOptions.Th (default 50 ms) is documented and used as the minimum hold-off between two consecutive BAM TP.DT frames — the 50..200 ms spacing of J1939-21 §5.10.3. The standard's Th (§5.10.2.4, 500 ms) is something else: the holding time, the maximum gap between two CTS(0) "hold connection open" messages a responder sends. That timer is not implemented — the receiver never emits CTS(0), and the originator's side of it is T4.
A reader who knows the standard reads Th = 50 ms as a wrong default for the holding time; a reader who trusts the name looks for the BAM spacing elsewhere.
Suggested fix
Rename the option to what it is (e.g. BamPacketSpacing) with a ! commit under ADR-0001, and keep the standard's name free for the holding time if CTS(0) support is ever added. The README paragraph on timers (added by #31's branch) should then drop Th from the list of J1939-21 timers.
Surfaced while working #31 (branch
fix/j1939tp-timers-abort-codes), out of that branch's scope by the working agreement.What happens
J1939TpOptions.Th(default 50 ms) is documented and used as the minimum hold-off between two consecutive BAM TP.DT frames — the 50..200 ms spacing of J1939-21 §5.10.3. The standard's Th (§5.10.2.4, 500 ms) is something else: the holding time, the maximum gap between two CTS(0) "hold connection open" messages a responder sends. That timer is not implemented — the receiver never emits CTS(0), and the originator's side of it isT4.A reader who knows the standard reads
Th = 50 msas a wrong default for the holding time; a reader who trusts the name looks for the BAM spacing elsewhere.Suggested fix
Rename the option to what it is (e.g.
BamPacketSpacing) with a!commit under ADR-0001, and keep the standard's name free for the holding time if CTS(0) support is ever added. The README paragraph on timers (added by #31's branch) should then dropThfrom the list of J1939-21 timers.