a few pointers: what happens when one of the modules in the middle of the train breaks? You will need to either have a sort of tracert function to count the number of "hops" back the info stops coming... OR place them on a bus that runs the entire length of the train - that each module is capacitively coupled to. If the output driver in one module fails, and it is DC coupled to the bus, you'll loose communications with the entire chain. Rather than query each car... why not just have them all come on at regular intervals and ID... reemmeber, any car that hears something on one serial port will rexmit it on the other port.... if each is connected to it's neighbor.... then there is little chance for a lost packet due to collision. The thing that makes this work is that it is very unlikely that any two cars will be turned on at the same time... and if each one keeps some sort of counter going... it could be used to generate a pseudo rand num that ca be used to calculate ID intervals +/- some number of seconds. now in dealing with collisions(packets, not trains)... consider that a packet could be travelling in EITHER direction... and the next car in line must be ready to accept this packet. SO some scheme of "hey are you there" and wait for a "yes" before actually forwarding the packet. make sure that each serial port (the front and rear serialports) have different delays, and different back off calculations for retries. each car can generate a busy ACK on one of its serial ports when its other serial port is busy. the engine behaves just like any othe car.... but has 3 serial ports. one up and downstream, and one to copy all bus activity to. in addition to random id's, each car must carry a query packet from one port to another... each packet should have a time to live word (64k counts). that way the engine(s) can send out queries with various TTL's and wait for them to return. At 01:11 PM 10/12/99 -0400, you wrote: > Thanks for all the input. Of course I realized that I had made some >assumpions that I did not put in the last letter and might make things a >little clearer. > >1) There is only one Engine. Contrary to real trains, the Engine may be in >the middle of the train. But that is really just spliting the chain into >two and performing the dame operations on both sides of it. > >2) The caboose is no different from the rest of the cars. It just happens >to be on the end. The reply timeout that Alan mentioned was what I was >planning on doing. > >3) I am trying to do this with as few connections as posible. I think that >the more pins, the more error is possible. > >4) The Engine is already defined as such. It knows it's the master and the >cars know they are slaves. Wes kd4rdb@usa.net Stupidity should be painful __________________________________________ NetZero - Defenders of the Free World Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html