Receiving your own Transmissions about loconet2 HOT 2 CLOSED

Be aware that there are several different cases for "collision" detection:
a) Collision while "you" are transmitting a LocoNet message
b) Collision after "you" have completed a transmission of your message (for slow "collision" detectors, such as PCs)
c) Collision which occurs at a time unrelated to "your" transmissions.

All three of these ought to be triggers for informing "your" software. Some of them require informing "your" transmitter; all three of them "ought" to inform "your" receiver. Exactly what "your" code does with these will be system- and device-type dependant.

Exactly what "your" code does when a "collision" is seen after a fully-formed LocoNet message is up to you, since it is not obvious whether the collision relates to a previously received message or to one which your code had no knowledge of, due to the "collision" detection. An example would be a collision on the "OpCode" byte, resulting in a "parity error". If your hardware simply ignores such things, then you wouldn't know that the byte "happened". If some external hardware enforces the LocoNet "collision" protocol at the bit-level or the byte-level, then it would assert the LocoNet data line low, and no further bytes would be received for at least 15 bit-times. And depending on how the competing devices deal with "collisions", the transmit messages may or may not "continue" beyond that time.

Also note that some LocoNet hardware does not pay attention to ongoing LocoNet activity, and does not identify "collision" cases. This happens with what I consider to be "non-compliant equipment". For this equipment, a long message will simply be sent, in entirety, while (potentially) someone else issues the "collision" indication. Once the "collision" indicaition completes, the original data bits could be seen on LocoNet, as a one or more "corrupted" bytes followed by a string of additional bytes, none with the "most-significant" bit set (i.e. none as OpCode).

For the do-it-yourselfer, the best way to "inject" collisions may be to implement a second "do-it-yourself" LocoNet device, with programming to specifically trigger a transmit at some carefully-chosen time. I've done this kind of testing in the past with my own PIC-based LocoNet devices; I do not have any suggestions of how to do this with the MRRwA libraries.

from loconet2.

Thanks for your in-depth reply.

As far as I can tell, in this library, collision detection is done on a bit-by-bit basis when transmitting. If a collision is detected then it stops transmitting immediately and backs off.

I'll keep up my testing, but at the moment, it seems to be working for my own purposes.

from loconet2.