Right, that's loopback.
i looked at an arduino LocoNet library on github. It looks like the code bit-bangs the interface, allowing it to check if the transmitted bit is correct on the Rx bit and immediately suspend transmission when it isn't which indicates another device is transmitting and asserting a zero on the bus
@gilshultz I'm using RS485, CMRI, no problems. Your comment
I spend many weeks with the RS484 and the only way I could get some reliability was for each node to monitor what it was sending. If it did not match waite a bit of time and try again. Each target had to acknowledge the message if the checksum was valid.
Reminds me of my early struggles. What I found was I had to ground the USB/485 converter of the computer, by connecting the USB metal shell to the ground of the DC power supply of my MAX485 units, and my problems disappeared. It's likely too late for you to try this.
The problem with CMRI, and RS485 half-duplex, is that a Master node must govern all communications. I've not seen a successful implementation yet where any node could asynchronously start talking. I have, however, seen successful implementations where, once asked, any node could send information that could be 'listened to' by all other nodes; it just takes a more sophisticated driver than the typical ones, which key on address info in every message to filter out all but 'their' traffic.
as i mentioned, NCE cabbus uses rs485. i built an NCE compatible controller which shared a ground because it was powered from the cabbus, but i also successfully interfaces my PC using 2-wire rs-485 adapter
doesn't a polled system require messages to have destination IDs so that only the addressed node accepts and responds to a message with its address?
and doesn't this also allow messaging between slave nodes once they are polled and allowed access?
but easily reliable
this is the argument for LCC, that the time to poll every node on very(?) large layouts with 100s of nodes takes too long. LCC also advocates inter-node communication rather than centralized control.
the Pacific Southern Railway has 22 nodes, some with as many as 64 input and output pins. it uses rd-422 which is duplex, but each node is polled
To answer your original question:
The short answer is: you can't.
The long answer is: you can with some additional restrictions on data transmission.
The start bit is simply defined as a High to Low transition. The only way to know that the transition was actually the beginning of a start bit, is to wait for 9 bit periods and check for a stop bit (Low to High transition).
Start and Stop bits have defined levels, not transitions. A 0xFF byte has only 2 transitions at the begin and end of the start bit.
@gcjr Please read my message completely, you'll find most/all of the answers were there.
what do you think i missed?
No, it has 4 transistions. Two for the START and two for the STOP
A 0x00 would only have two. One at the beginning of the start bit and one at the end of the stop bit
That's impossible. The stop bit level is the idle level of the line.
Back in the old days, this was called a "group poll" which was to a central control unit in an office and was perhaps the first 3 bits of a bite being the group number. A response would be a complete 8 bit address of the terminal with the message. Cumbersome, but effective.
sounds like if any "slave" address matched those bits, it was allowed to respond, but what if more than one slave needs to respond?
If a controller, the controller kept track of the individual terminals. NCR was an example. So was IBM terminals. No controller then first come, first served, as I recall. It's all on APPLE II diskettes, but no way to read them, now!
How will you determine when there is a time gap between some bytes?
Besides that there is not a significant delay within one message, I simply wait untill the message has arrived entirely.
Instead of just sending numerical byte values, I send a string with comma separated values which end with a '\n'. I use println() to 'encode' the numbers and sscanf() to 'decode' the numbers.
Time/performance wise it is ofcourse not the most efficient thing you can do. Messages are like 4x longer than strictly needed. But having with the communication human readable I can monitor the transmission with a USB <>485 dongle on the arduino monitor. And I can send messages of my own to interact with master & slaves. This made debugging total peanuts 
It is unfortunate that I lack the IO pins to drive RE and DE separately. I will most definately do some testing with this in the future.
I read online somewhere that somebody used an external interrupt coupled to Tx to trigger when a startbit was transmitted. He would then fire a timer ISR @100ms (for 9600BPS) and monitor the levels of Rx and Tx every 100ms. This seemingly was reliable to detect collision errors.
I have another question. Not sure if I need to start a new thread. For future projects the slave addresses aren't that important. The IO on the slaves are the things which need addresses. I would configure every slave individually and store IO information on EEPROM.
As it is now, slaves use a resistor deviders for address determintation. If I were to make 100% identical slaves, how can I auto-assign addresses. The one thing I can think of was to use random() and a floating analog pin somehow to prevent slaves from answering at the exact same moment in the first place. The XpressNet library does not use random() and I do not know the address determination is handled. Are there more ways besides random() to let auto addressing work?
Bas
What's the purpose of multiple slaves if you don't know which one does which job?
Each slave must have a known address and his specific job.
Good question. And I have a good answer ( I hope 
).
What I call a slave is a piece of electronics which can have servo's, switches, relais, feedback sensors etc. It are these things which have need for actual addresses.
For instance. If whatever thing issues a command for servo #621. I really do not care which address the node itself has. The node who has servo #621 just has to monitor broadcasts for servo #621. The advantage is that nobody doesn't need to know on which node servo #621 actually is.
Likewise if a node has feedback sensors, the node must transmitt the addresses and states of activated sensors. And some other node may or may not be interested in that transmission.
So whatever address the node itself has on a communication bus like 485 is really not of any interest. The addresses are merely there to keep the bus up and running.
The mentioned XpressNet bus (polled 485 bus) works similar. Anything you plug in the bus like a hand controller, get's 'some' address asigned and than.. it just works. Whatever that address is you cannot even see and cannot know. The handcontrollers do need their addresses because that is simply how XpressNet works under the hood. But users don't care about this, they simply use their handcontrollers to issue commands for trains en turnouts.
There is however a difference between manufactorers. There is one brand where you manually have to set an address via means of DIP switches where the other brands uses auto-addressing.
Bas
You are correct both 0xFF and 0x00 will only have two transitions
1 Like
This means that the node has to know the number of its servo . This is an individual information just as is its slave address.
so the address in the command is #621. but doesn't each slave need to know which devices (e.g. 621) it affects
i'm working on computer model railroad interface, C/MRI nodes which affect different signals. the EEPROM is programmed with a table specifying which nodes affect which signals.
you could either program a unique table into each of your nodes or you can program the same table into each node along with a node ID so that each node knows which device IDs it is responsible for and accept/process the commands for those devices