12-22-2002, 01:25 AM
Emergency Digital Communications - Another Angle
- by Charles Brabham, N5PVL -
- U.S. Packet Net -
In the last decade or so, amateurs have been treated to hundreds of excellent new programs and protocols that have greatly expanded our capabilities. APRS, CLOVER, PSK31, PACTOR II, FlexNet, and AGWPE immediately come to mind. So many new ideas have been presented in this way, it is inevitable that sooner or later, something really great would end up being overlooked. This has been the case with RadioMirror, the Terrestrial Multicast protocol/software package developed several years ago by John Hansen, W2FS.
RadioMirror works much like the familiar EMWIN (http://iwin.nws.noaa.gov/emwin/index.htm) weather data and alert broadcasts provided by the National Weather Service. One transmitting station provides information to an unlimited number of recieving stations simultaneously by means of a digital broadcast to many stations at once, called a multicast.
Before reading about applying RadioMirror and its multicast protocol to digital emergency communcations, you can get a better idea of what RadioMirror is and what it does at the RadioMirror Home Page, as John can do a much better job of describing his work than I can. Here I will quote the major points of the system, from his pages:
RadioMirror Web Site (http://www.tapr.org/~wa0ptv/)
-------------------------------------------------------------------
RadioMirror is a new file server designed by John Hansen, W2FS (ex-WA0PTV), to use a broadcast protocol in packet radio. The current version runs under Windows 95/98. This results in relatively high speed file transfers from a central server to many client computers at once. Key features of this software include:
Packets are transmitted in unconnected mode so they can be received by an unlimited number of stations at the same time.
File transfers are faster than on traditional connected packet connections because the server need not wait for acknowledgment packets from the clients. Data streams out of the server without interruption.
The system does not require users to purchase any new hardware. It is capable of transferring up to 20 MB of data per day (assuming 50% compression) at a transmission rate of 1200 baud.
The client software saves partial files that are received with holes and fills in the holes as the file is retransmitted.
The client software keeps track of the file modification dates and will update files that have been modified, but ignore files that it has already received and have not been updated.
Unlike the PACSAT broadcast protocol, the filenames on the clients are exactly the same as they appear on the server, making this an excellent mechanism for distributing HTML files.
Entire directories and directory structures that reside on the server can be replicated exactly on the clients, making this an ideal way, for xample, for transferring files that have been downloaded from the PACSATs, so that stations that do not have satellite groundstations can still use groundstation programs like WiSP to access satellite files.
Hooks are built into the server to allow other programs, such as packet bulletin boards, to kick off server file transfers.
Files can be specified to be transmitted once, or on a continuous loop.
-------------------------------------------------------------------
In practice, the RadioMirror distribution file gives you a copy of both the RadioMirror server, and the client software that picks up and decodes the data being sent by the servers' multicast transmissions. RadioMirror is designed to work with Win95/98, and both client and server programs require a KISS TNC.
What RadioMirror sends is files. Not only files, but directories can be transmitted by this versatile software to any number of recieving stations. Any kind of file can be sent, but HTML and text files may be the most useful for emergency communications.
RadioMirror and Emergency Communications
Obviously, there are dozens of potential uses for a supercharged amateur radio version of EMWIN.
I believe that RadioMirror can be especially useful for distributing information to non-hams that we work with such as Law Enforcement entities, the Red Cross, National Weather Service centers, Hospitals, and Government offices. Very few of these persons can be depended upon to learn how to use special software or radios, but they all know how to use an Internet browser.
All of these offices, along with local ARES/RACES groups and anyone else who is interested can be continuously kept up to date by a single RadioMirror server located in your community.
The RadioMirror clients at each location would require an old 486 or better computer to run Win95/98 and RadioMirror Client, the built-in IE browser set up with links to the files you wish to display, and a 2 meter FM reciever (any kind) capable of picking up the broadcast information. An old scanner, or ham rig that doesn't transmit any more would do fine. A TNC capable of KISS mode operation is also required for each location.
Once a RadioMirror client is set up, let's say at the Sherriffs office for example, an amateur radio operator is not required in order for the people there to use it. The client system does not transmit, it only recieves amateur radio transmissions and anybody can legally do that.
Radiomirror can simultaneously distribute the information you provide to any number of such client locations, freeing up your local RACES/ARES hams for more interesting and useful work. Most of the present setups, both digital and voice, require a ham at each location served so this is a significant advantage for small groups, struggling to do a lot with just a few active members in the field.
http://www.uspacket.net/rm01.jpg
Note that most locations shown have backup power/generators.
Once you have set up your server, start putting together a few client stations. You will want at least one of them right away, of course, to test the server. After that, assemble clients ( as you can afford to ) for the various non-ham agencies and entities that you have arrainged to serve.
Set the client machines for non-hams up so that when the power is flipped on, the computer automatically loads RadioMirror Client, and then the Internet browser with its pre-loaded links to the relevant file names in the client computer's directory. Create an internal HTML page with those links in the client computers' hard drive, and set that as the browser's default startup page.
If you power the reciever and TNC from the computer's power supply, they will automatically come up too, making it a single-button operation to bring up the entire system. This makes it easy to start over if things go wrong. You could even put the receiver and TNC in the computer's case, to keep things uncluttered and simple. The idea is to make it simple, easy to deal with during the course of an emergency, and obviously useful. A turn-key system.
Updating the Data on the Server
RadioMirror has no provision for remotely updating the information it will send. If you change the contents of the "continuous" or "one-time" directories, RadioMirror will send the updated files immediately. It is up to you though, to figure out how to update those files, residing in a computer at a node site. Probably the best solution is to run a copy of FBB BBS in the same machine, because of the extensive remote SYSOP controls and great security FBB offers. You can remotely do most regular DOS chores, and FBB handles YAPP and BinHex file transfers, another good feature for effective remote control of the RadioMirror server.
The BBS should have one radio port for control purposes, and be configured for high security (password access) along with minimal function as a BBS. If you want to use it as a regular BBS with additional radio ports, be sure your computer is up to the load that this will present while RadioMirror runs in the background! The BBS function is optional though, as you are primarily using FBB as a file transfer and remote disk control for RadioMirror.
Any other packet program that allows remote control of the disk, has good security and handles packet radio file transfers will do just as well, maybe better. I'm used to FBB, so that's what I tried.
You decide who gets the password and can update which files. FBB makes it easy to do this, too, with private directories. Once a file is updated, the updated version goes out over RadioMirror and that updates all of the RadioMirror client systems listening.
For example, hams at the National Weather Service E.O.C. could have control of a text file in a private directory in the BBS. In the RadioMirror server, you would have it send that file continuously, along with the files it sends from other sources. That way, whenever the NWS updates the text file, the updated version immediately gets out to the police, city hall and the TV station, and all other client systems that are operating within effective range of the server's transmitter.
Files can be created for each source of information, including amateurs in the field. They could either carry along a portable packet station, or relay thier reports over a voice repeater to a home station with both voice and packet capability nearby.
The RadioMirror server itself, it must be noted, requires a transmitter but no reciever. The transmitter must be rated for continuous duty, as it is only unkeyed very briefly and spends over 95% of its time keyed up. Reduce power, or get a pretty tough transmitter and set it up with a cooling fan. It will need it. If you start off with a 100 watt transmitter and tune it down to 20 watts or so, that would be a good starting point. Don't burn up your transmitter!
Going over the main advantages to this setup, they are:
A turnkey system for providing important data to non-hams and hams alike.
Frees up amateurs from babysitting voice or regular packet systems at non-ham sites, so they can do more in the field.
Is generally inexpensive, uses existing equipment and even equipment that is no good for anything else. (2meter rigs with no TX , no tone boards, and so on..)
Anybody with a TNC and a VHF reciever can recieve the multicasts.
Between Emergencies
To keep your system ready, the server should operate at all times, ready to be used for testing client systems at non-ham locations around the city. The clients will only see the files that you specify on their system's default HTML pages, so in-between emergencies, your group could transmit other general information of interest to amateurs, including "Ham Home Pages" for individuals and clubs, located at the server.
John Hansen describes some of these everyday ways to utilize a RadioMirror server at his web site, along with detailed information about the protocol, and the commendable philosophy behind this system. When an emergency arises, tell the system to only send the most vital files, so that it will cycle through them and update quickly.
Note: I haven't mentioned RadioMirror as replacing current voice and packet emergency communications systems because I think it works best when used to enhance them, not replace them. All of our ham emergency communications methods have a place in the hobby, and I believe RadioMirror really ought to be in there with the others because of the unique capability it offers to amateur radio emergency communicators.
Charles Brabham, Webmaster, U.S. Packet Net
U.S. Packet Net
http://www.uspacket.net/
- by Charles Brabham, N5PVL -
- U.S. Packet Net -
In the last decade or so, amateurs have been treated to hundreds of excellent new programs and protocols that have greatly expanded our capabilities. APRS, CLOVER, PSK31, PACTOR II, FlexNet, and AGWPE immediately come to mind. So many new ideas have been presented in this way, it is inevitable that sooner or later, something really great would end up being overlooked. This has been the case with RadioMirror, the Terrestrial Multicast protocol/software package developed several years ago by John Hansen, W2FS.
RadioMirror works much like the familiar EMWIN (http://iwin.nws.noaa.gov/emwin/index.htm) weather data and alert broadcasts provided by the National Weather Service. One transmitting station provides information to an unlimited number of recieving stations simultaneously by means of a digital broadcast to many stations at once, called a multicast.
Before reading about applying RadioMirror and its multicast protocol to digital emergency communcations, you can get a better idea of what RadioMirror is and what it does at the RadioMirror Home Page, as John can do a much better job of describing his work than I can. Here I will quote the major points of the system, from his pages:
RadioMirror Web Site (http://www.tapr.org/~wa0ptv/)
-------------------------------------------------------------------
RadioMirror is a new file server designed by John Hansen, W2FS (ex-WA0PTV), to use a broadcast protocol in packet radio. The current version runs under Windows 95/98. This results in relatively high speed file transfers from a central server to many client computers at once. Key features of this software include:
Packets are transmitted in unconnected mode so they can be received by an unlimited number of stations at the same time.
File transfers are faster than on traditional connected packet connections because the server need not wait for acknowledgment packets from the clients. Data streams out of the server without interruption.
The system does not require users to purchase any new hardware. It is capable of transferring up to 20 MB of data per day (assuming 50% compression) at a transmission rate of 1200 baud.
The client software saves partial files that are received with holes and fills in the holes as the file is retransmitted.
The client software keeps track of the file modification dates and will update files that have been modified, but ignore files that it has already received and have not been updated.
Unlike the PACSAT broadcast protocol, the filenames on the clients are exactly the same as they appear on the server, making this an excellent mechanism for distributing HTML files.
Entire directories and directory structures that reside on the server can be replicated exactly on the clients, making this an ideal way, for xample, for transferring files that have been downloaded from the PACSATs, so that stations that do not have satellite groundstations can still use groundstation programs like WiSP to access satellite files.
Hooks are built into the server to allow other programs, such as packet bulletin boards, to kick off server file transfers.
Files can be specified to be transmitted once, or on a continuous loop.
-------------------------------------------------------------------
In practice, the RadioMirror distribution file gives you a copy of both the RadioMirror server, and the client software that picks up and decodes the data being sent by the servers' multicast transmissions. RadioMirror is designed to work with Win95/98, and both client and server programs require a KISS TNC.
What RadioMirror sends is files. Not only files, but directories can be transmitted by this versatile software to any number of recieving stations. Any kind of file can be sent, but HTML and text files may be the most useful for emergency communications.
RadioMirror and Emergency Communications
Obviously, there are dozens of potential uses for a supercharged amateur radio version of EMWIN.
I believe that RadioMirror can be especially useful for distributing information to non-hams that we work with such as Law Enforcement entities, the Red Cross, National Weather Service centers, Hospitals, and Government offices. Very few of these persons can be depended upon to learn how to use special software or radios, but they all know how to use an Internet browser.
All of these offices, along with local ARES/RACES groups and anyone else who is interested can be continuously kept up to date by a single RadioMirror server located in your community.
The RadioMirror clients at each location would require an old 486 or better computer to run Win95/98 and RadioMirror Client, the built-in IE browser set up with links to the files you wish to display, and a 2 meter FM reciever (any kind) capable of picking up the broadcast information. An old scanner, or ham rig that doesn't transmit any more would do fine. A TNC capable of KISS mode operation is also required for each location.
Once a RadioMirror client is set up, let's say at the Sherriffs office for example, an amateur radio operator is not required in order for the people there to use it. The client system does not transmit, it only recieves amateur radio transmissions and anybody can legally do that.
Radiomirror can simultaneously distribute the information you provide to any number of such client locations, freeing up your local RACES/ARES hams for more interesting and useful work. Most of the present setups, both digital and voice, require a ham at each location served so this is a significant advantage for small groups, struggling to do a lot with just a few active members in the field.
http://www.uspacket.net/rm01.jpg
Note that most locations shown have backup power/generators.
Once you have set up your server, start putting together a few client stations. You will want at least one of them right away, of course, to test the server. After that, assemble clients ( as you can afford to ) for the various non-ham agencies and entities that you have arrainged to serve.
Set the client machines for non-hams up so that when the power is flipped on, the computer automatically loads RadioMirror Client, and then the Internet browser with its pre-loaded links to the relevant file names in the client computer's directory. Create an internal HTML page with those links in the client computers' hard drive, and set that as the browser's default startup page.
If you power the reciever and TNC from the computer's power supply, they will automatically come up too, making it a single-button operation to bring up the entire system. This makes it easy to start over if things go wrong. You could even put the receiver and TNC in the computer's case, to keep things uncluttered and simple. The idea is to make it simple, easy to deal with during the course of an emergency, and obviously useful. A turn-key system.
Updating the Data on the Server
RadioMirror has no provision for remotely updating the information it will send. If you change the contents of the "continuous" or "one-time" directories, RadioMirror will send the updated files immediately. It is up to you though, to figure out how to update those files, residing in a computer at a node site. Probably the best solution is to run a copy of FBB BBS in the same machine, because of the extensive remote SYSOP controls and great security FBB offers. You can remotely do most regular DOS chores, and FBB handles YAPP and BinHex file transfers, another good feature for effective remote control of the RadioMirror server.
The BBS should have one radio port for control purposes, and be configured for high security (password access) along with minimal function as a BBS. If you want to use it as a regular BBS with additional radio ports, be sure your computer is up to the load that this will present while RadioMirror runs in the background! The BBS function is optional though, as you are primarily using FBB as a file transfer and remote disk control for RadioMirror.
Any other packet program that allows remote control of the disk, has good security and handles packet radio file transfers will do just as well, maybe better. I'm used to FBB, so that's what I tried.
You decide who gets the password and can update which files. FBB makes it easy to do this, too, with private directories. Once a file is updated, the updated version goes out over RadioMirror and that updates all of the RadioMirror client systems listening.
For example, hams at the National Weather Service E.O.C. could have control of a text file in a private directory in the BBS. In the RadioMirror server, you would have it send that file continuously, along with the files it sends from other sources. That way, whenever the NWS updates the text file, the updated version immediately gets out to the police, city hall and the TV station, and all other client systems that are operating within effective range of the server's transmitter.
Files can be created for each source of information, including amateurs in the field. They could either carry along a portable packet station, or relay thier reports over a voice repeater to a home station with both voice and packet capability nearby.
The RadioMirror server itself, it must be noted, requires a transmitter but no reciever. The transmitter must be rated for continuous duty, as it is only unkeyed very briefly and spends over 95% of its time keyed up. Reduce power, or get a pretty tough transmitter and set it up with a cooling fan. It will need it. If you start off with a 100 watt transmitter and tune it down to 20 watts or so, that would be a good starting point. Don't burn up your transmitter!
Going over the main advantages to this setup, they are:
A turnkey system for providing important data to non-hams and hams alike.
Frees up amateurs from babysitting voice or regular packet systems at non-ham sites, so they can do more in the field.
Is generally inexpensive, uses existing equipment and even equipment that is no good for anything else. (2meter rigs with no TX , no tone boards, and so on..)
Anybody with a TNC and a VHF reciever can recieve the multicasts.
Between Emergencies
To keep your system ready, the server should operate at all times, ready to be used for testing client systems at non-ham locations around the city. The clients will only see the files that you specify on their system's default HTML pages, so in-between emergencies, your group could transmit other general information of interest to amateurs, including "Ham Home Pages" for individuals and clubs, located at the server.
John Hansen describes some of these everyday ways to utilize a RadioMirror server at his web site, along with detailed information about the protocol, and the commendable philosophy behind this system. When an emergency arises, tell the system to only send the most vital files, so that it will cycle through them and update quickly.
Note: I haven't mentioned RadioMirror as replacing current voice and packet emergency communications systems because I think it works best when used to enhance them, not replace them. All of our ham emergency communications methods have a place in the hobby, and I believe RadioMirror really ought to be in there with the others because of the unique capability it offers to amateur radio emergency communicators.
Charles Brabham, Webmaster, U.S. Packet Net
U.S. Packet Net
http://www.uspacket.net/