Web-TV Demo Truck with Satellite Linkver 0.1 - 2000.06.19 - dkzh |
Project Summary The concept is to provide a mobile demo platform that can be driven to venues, to show off Web-TV products. The satellite link is suggested to free us from the problem of scheduling appearances far enough in advance as to allow the temporary installation (and testing, etc.) of high-capacity network links to connect the demo units with the Web-TV Service Network.
|
Trailer Remote Operations In the case that the truck is ordered, and the equipment is deployed, I can see a need for the capability to remotely configure the equipment in the truck. In the 'normal' configuration, the satellite link would be the primary network path, and with the judicious use of some network gear, we can add a great deal of remote configuration support to the trailer. Presumptions:
|
Electronic Program Guides The truck will appear in different time zones, from time to time. Do we want to consider using a ZIP code from a low-population-density area from each of the time zones, so that the hour-to-hour programming maps correctly? Using a small, RV-style TV antenna, it's possible that we could pick up one or more 'local' off-air channels wherever the trailer is, and use Channel Processors to put them onto specific channels. Some canned content could come from DVD players on-board the trailer. Once the satellites are acquired, we might be able to derive channels and turn them into analog channels on the trailer, to highlight partner networks (MSNBC, etc.) |
Network and Head End It is likely that the network equipment (including satellite modems) will need to share the operations area with the video head-end equipment. Advantages to this arrangement include;
|
Bench Demo Network The Network portion is provided by the WNI network connections at Silicon Valley Campus, where a 10 Mbps connection is made to the "Network" router (router 2 in this diagram). The EIA-530 serial cable link connects the router to the "Network" satellite modem, an SPL/ACT SkyLane SL-512 modem. The output of the modem is a 70 MHz IF stream. The input is adjustable, in the 950-1200 MHz ("L-Band") range. On the test bench, the 70 MHz IF goes into a Cross Technologies model 2005 Test Upconverter, which allows us to set the frequency for the carrier that will be sent to the receiver on the "Trailer" modem.
The "Trailer" end of the link has a matching modem, connected to another router. On the test bench, this is connected directly to the Ascend NAS via a CAT-5 crossover ethernet cable. The connection between the Ascend NAS and the Gordon Kapes System 930 Telephony Simulator is a standard CAT-5 ethernet cable, but the signaling is actually an ISDN PRI (1.5 Mbps) link. The G.K. box is basically a very small Central Office in this configuration. We will attach up to four set-top boxes directly to the G.K., using RJ-11 phone cables. The device can support 48 lines, but the additional lines would need to come from 24-port patch panels (connected via 50-pin AMP/Cinch connectors). |
Satellite Truck Considerations Much of the network equipment in the network diagram (shown at left) has asynchronous serial console ports to aid in configuration. (In the case of network gear, the serial port might be the only way to configure the equipment if the network interface is misconfigured.) One suggestion is to use a router with multiple async serial ports, which are capable of supporting Reverse Telnet access. (A Cisco 2511 provides 16 async ports, in addition to the high-speed serial link for the satellite modem.) You could also consider a stand-alone terminal server, instead of a router-and-terminal server combination. There should be a PC on-board, configured to perform diagnostics on the network and equipment. This device should have a scriptable application environment, so that custom scripting can be built to perform high- and low-level diagnostics of the equipment. This could include a built-in modem, that could test-dial in through the telephony simulator, and test connections to the Ascend NAS. If the link back to the network fails, there are a number of tests that could be performed. Do you want a human to do that testing, or do you want a computer to do the testing, and report the results (maybe even suggesting possible resolutions to the problems)? The serial data output from the GPS receiver can be split, so that it goes to both the device controlling the pointing of the satellite dish(es), as well as to a terminal server port. This way, once the link is up, the network operations center can get access to the Lat./Long. data, if that information would be useful for plotting the location of the trailer in a mapping application. (It's conceivable that the same GPS could be used for computer-aided navigation for the truck driver.) If any of the set-top boxes have diagnostic ports on them, it's possible that they can be connected to the terminal server, allowing on-site developers to use the diagnostics machine to monitor the output. (Developers back at SVC might also be able to watch the output of those ports.) The diagnostics PC could also be the documentation repository (HTML pages for text and images), using Front Page to remotely update the documentation as needed, or simply bringing a floppy and/or CD media for physically updating the machine. What about adding a web-cam capability, so we can see the lights on the equipment? |
On-board Diagnostics PC This is just some brainstorming...what could we do, hypothetically speaking, with the diagnostics PC on the trailer.
|