A few months ago, I taped my TV remote onto the side of an acrylic rod and covered the connection in foil. Then I pointed one end of the rod at my TV and became one of only a handful of people worldwide to use intra-bedroom fiber optics to turn on The Late Show. This demonstrates a couple of things. First, that you know you need help with your tinkerer addiction when you just happen to have cast acrylic rod hanging around the house. Secondly, it showed that you can transmit data into the SIDE of a fiber optic media and have it be readable coming out the end.
In Ed Anderson’s PRT designs he uses “leaky-cable” to send and receive messages from the vehicles to a zone-controller. Leaky-cable is essentially coaxial cable with slits in the covering that lets radio signals “leak” in and out. This technology was originally used to communicate in mines but is increasingly being used to extend wireless “hot-spots” such as in hotels or dorms since running the cable down the hall is all that is required to give connectivity to the computers in all of the rooms on either side.
Unfortunately these products are designed to broadcast and receive over a wide area, usually up to 30 meters from the cable. That creates the issue is cross-talk. Inside of a PRT track, these products are shouting instead or whispering, since the signal only needs to extend a couple of centimeters. Putting a backup or any second cable won’t work, since each would broadcast and receive from the other. Anderson used time-division multiplexing to let vehicles take turns using the one cable. This is apparently a workable arrangement, but lets just say it is not exactly a modern LAN without some major tweaking. It certainly seems, in theory, that the “volume” could be turned way down and some kind of shielding might be used to enable a second cable (to get more bandwidth) but this is just speculation.
So I have been wondering about infrared. Have you seen “side glow” fiber optic cable? It looks like a flexible neon light. It is the direct optical equivalent to leaky cable. One thing about it is that there is no issue with cross-talk if the cables are shielded. It turns out that before RF wireless connectivity became the standard, there were quite a few infrared products out there for computer networking. Now I can’t really find any, although apparently it is sometimes used for financial and other confidential data because it cannot be hacked into from outside the room, since it relies on “line-of-site” between the transmitter and receiver.
There is one fundamental realization that got me thinking. Since an infrared transmitter, such as my TV remote, is essentially just an LED, (like a light bulb) why be bound to using just one? Why not have, say, 100 all blinking as one? It would be a bit like sending Morse code by plugging and unplugging a string of Christmas lights. Clearly this would be a simple way to broadcast over a wide area. What about the other direction? Can there be multiple, distributed receivers as well?
I am a bit out of my field here, but it seems to me that with Ethernet there is a designated wire from any computer to a router or switch. Could a track-based receiver(s) plug a passing vehicle into an LAN without the lengthy discovery protocol? After all, to the network, it wouldn’t be apparent that different passing vehicles were sending the data. I think the limit is 256 such nodes. I guess there are some Mac or IP address hurdles.
I have to say that this is a somewhat arbitrary exercise at this point. I probably should be starting with a fine-grained examination of exactly what needs to be communicated when and to whom. Speaking in generalities is just not cutting it. Form needs to follow function, not philosophy or “rules of thumb.” As far as rapid communication goes, it would be very rare indeed for it to involve many more than a dozen vehicles, and they are in a predictable positional relationship. (equidistant from a merge) Those positional relationships need to be the starting point for designing any network, as well as firmware and software. I’ll try and explore these more next time.
Tuesday, September 28, 2010
Monday, September 20, 2010
103> A little something...
Well folks, life is very good up here on the land, but not real good for working on PRT. Fact is, I haven’t even been answering emails. “Bear” with me, for I’ll only be at this for a few more weeks. In the meantime here is a picture I dug up that you might find interesting. It shows a forklift, overhead crane and elevator that could run on a PRT like operating system. Apparently similar devices are already used to warehouse frozen goods, saving forklift drivers from the cold.
They are closing the library now...Life without the internet...try it!
Saturday, September 11, 2010
102> The PRT Business Model
Hello from the “off the grid” New Hampshire! As some of you know, I often get away to my cabin here, where it is, to put it mildly, rustic. Well, it’s always something. Now the folks here say they can’t give me a license plate without a “911 address.” That takes 5 weeks. That means my car (with expired Kentucky tags) is illegal to drive, which means I can’t keep its battery well charged, (I have no AC on site) which means everything that runs AC or is rechargeable has to be kept to an absolute minimum. I am building a garage, you see, near the road, which will provide a gateway for such utilities. If you can call it a garage… Actually it is an experimental structure, sort of a pregnant “A-frame” with a curved roof. It relies on the strength of curves and of laminations, and can be built single-handedly, even by a 56 year old. (me) It should cost less than half of a traditional structure. Anyway, the point is that the computer I am writing this on is one such energy drain, and is competing with my rechargeable tools. So I might not be around a lot, blog-wise. I am currently at the library, but that an option best suited for rainy days, and it is beautiful outside today.
Now on to some thoughts on PRT. The real obstacle to PRT is, and has always been, the business model. Without a lot of political will, it is hard to get the government funds needed, and that political will cannot exist while there is fear, uncertainty and doubt. Two “Fortune 500” companies have abandoned PRT after sinking millions into it for that very reason.
It is not the track or the stations, for steel companies and builders would love the contracts. After all, they will get paid regardless. Vehicle builders would love it too, although they have a bigger, longer lasting stake. But building vehicles (warranties included) is what they do. Everybody, so far, is within their core competencies, and structuring a deal would be similar to what they do every day.
Not so control. This is a little manufacturing, a little maintenance, a long-term service…
Business-wise, it’s a real mess. PRT companies can stand up bravely all day long and explain how they will always be there, but no one is going to listen. Bankruptcies are just part of the game these days, and all that leaves a city with is a bunch of useless hardware.
It stands to reason then, that the matter should be attacked directly. What can be done to get a handle on this “vendor-dependency issue? What I have endeavored to do, as a first step, is to make the problem smaller. In my last post, I detailed a time-based control system that could reside largely in cyberspace. It could be hosted by almost anybody. It could handle most traffic management and fare collection, things that are not affected by the inherent latency of the internet. On the other end, I have strived to give more control to the vehicles themselves. After all, not bumping into each other seems like a task well suited for those vehicles directly involved.
I do not claim that a global internet-based traffic management system along with autonomous cars is all that is required. As traffic density increases, the ability of vehicles to act with any kind of autonomy will all but vanish, just as it does in auto traffic. The combination I have described is inadequate for the job of high speed, high density, minimal headway traffic. But this does not change the fact that predicating a control architecture on the health of an untested company is a serious, probably fatal, drawback. At least with the combination I suggest, if the PRT company goes under and no longer provides any parts, training or support, the system would still work. Just not optimally. This would give the city some breathing room while they search for a fix. After all, the problem with PRT companies is that they are irreplaceable.
So, to recap, my objective is to structure a PRT construction and control architecture that cannot leave a city stranded, or come as close to that objective as possible. This may not make for the prettiest software code or networking structure, but it is, in my view, the only way forward. At the very least, we should all be looking at exactly what can be done to structure the control aspect of PRT into simple, definable businesses with ordinary equipment requiring minimal special training. What equipment, where? How many people? Is there scheduled maintenance? Replacement? What communications gear does the track need? Who will install that? You get the point. If we can divide and conquer this stuff, we will be a long way ahead.
Now on to some thoughts on PRT. The real obstacle to PRT is, and has always been, the business model. Without a lot of political will, it is hard to get the government funds needed, and that political will cannot exist while there is fear, uncertainty and doubt. Two “Fortune 500” companies have abandoned PRT after sinking millions into it for that very reason.
It is not the track or the stations, for steel companies and builders would love the contracts. After all, they will get paid regardless. Vehicle builders would love it too, although they have a bigger, longer lasting stake. But building vehicles (warranties included) is what they do. Everybody, so far, is within their core competencies, and structuring a deal would be similar to what they do every day.
Not so control. This is a little manufacturing, a little maintenance, a long-term service…
Business-wise, it’s a real mess. PRT companies can stand up bravely all day long and explain how they will always be there, but no one is going to listen. Bankruptcies are just part of the game these days, and all that leaves a city with is a bunch of useless hardware.
It stands to reason then, that the matter should be attacked directly. What can be done to get a handle on this “vendor-dependency issue? What I have endeavored to do, as a first step, is to make the problem smaller. In my last post, I detailed a time-based control system that could reside largely in cyberspace. It could be hosted by almost anybody. It could handle most traffic management and fare collection, things that are not affected by the inherent latency of the internet. On the other end, I have strived to give more control to the vehicles themselves. After all, not bumping into each other seems like a task well suited for those vehicles directly involved.
I do not claim that a global internet-based traffic management system along with autonomous cars is all that is required. As traffic density increases, the ability of vehicles to act with any kind of autonomy will all but vanish, just as it does in auto traffic. The combination I have described is inadequate for the job of high speed, high density, minimal headway traffic. But this does not change the fact that predicating a control architecture on the health of an untested company is a serious, probably fatal, drawback. At least with the combination I suggest, if the PRT company goes under and no longer provides any parts, training or support, the system would still work. Just not optimally. This would give the city some breathing room while they search for a fix. After all, the problem with PRT companies is that they are irreplaceable.
So, to recap, my objective is to structure a PRT construction and control architecture that cannot leave a city stranded, or come as close to that objective as possible. This may not make for the prettiest software code or networking structure, but it is, in my view, the only way forward. At the very least, we should all be looking at exactly what can be done to structure the control aspect of PRT into simple, definable businesses with ordinary equipment requiring minimal special training. What equipment, where? How many people? Is there scheduled maintenance? Replacement? What communications gear does the track need? Who will install that? You get the point. If we can divide and conquer this stuff, we will be a long way ahead.
Subscribe to:
Posts (Atom)