Receiving your own Transmissions

[richsoft]

Unlike the AVR library, because of the way the receive/transmit task's state machine works, you don't receive your own transmissions to Loconet.

I have been experimenting with amending the code to add the bits into the receive byte buffer (lnCurrentRxByte), and shifting them as the receive code does, as they are put onto the bus.

When a byte has been transmitted, and the transmit task gets the next byte, process(lnCurrentRxByte) method is called, to build the message up the main Loconet message buffer as if it was receiving a byte normally.

In the case of a collision, the lnCurrentRxByte is cleared ready for either retrying transmission or receiving a byte from the bus.

My tests show this is working, and the notifyX functions get called as expected. So, for example, I can transmit a SwitchRequest message, get notified and act on it on the same ESP32.

I'm sure there are cases where this won't work, and I need to see what happens if a collision happens in the middle of a multi-byte message, where some bytes are already in the main Loconet message buffer (although I guess this can happen when receiving too, so this may not be a problem).

Thanks,

Richard

[devel-bobm]

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.

[richsoft]

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.