The trick would be loading/unloading the cars in a reliable and fast way. With a multi-cart train running in a loop, I probably wouldn't shoot for TCP/IP.
Something like T1 would be a lot easier to implement because it uses very straight forward time-division-mutiplexing (serial by nature). You could use a simplistic encoding method like AMI, but your frames would have to be much smaller. The simplest T1 carrier frame is 192 data bits with 1 signaling bit, so you're looking at a pretty massive train. Because the physical train itself could serve as the frame boundaries, you could use 16 cars and carry two bytes per trip.
The bit rate and latency are going to suck though ;)
The wonderful thing about nerd rage is that it gets stupid things done. I fully expect to see a response project of ACTUAL TCP/IP implementations via lego trains. Hell, multiple response projects, probably.
> I fully expect to see a response project of ACTUAL TCP/IP implementations via lego trains.
Here's hoping that they also work their way up the OSI stack. I'm looking forward to seeing what "418 I'm a teapot" looks like from the LEGO http server.
12 comments
[ 2.3 ms ] story [ 29.3 ms ] threadSomething like T1 would be a lot easier to implement because it uses very straight forward time-division-mutiplexing (serial by nature). You could use a simplistic encoding method like AMI, but your frames would have to be much smaller. The simplest T1 carrier frame is 192 data bits with 1 signaling bit, so you're looking at a pretty massive train. Because the physical train itself could serve as the frame boundaries, you could use 16 cars and carry two bytes per trip.
The bit rate and latency are going to suck though ;)
And then someone will do IPX/SPX just to be cute.
Here's hoping that they also work their way up the OSI stack. I'm looking forward to seeing what "418 I'm a teapot" looks like from the LEGO http server.