Ham Radio Station W3JJJ

How EMWIN Works
How data is collected.	How data is distributed.	How local data is received.	How GOES data is received.	How data is retransmitted.	ByteBlaster works.

EMWIN began as a quest for an inexpensive method to distribute weather information directly from the National Weather Service to schools in the Washington D.C. area. The NWS had just completed a touch-screen weather display for Congressional Representatives and thought that it should be possible to direct the same data stream to personal computers via a wireless system. Wireless data delivery was desirable since budgetary constraints of most inner-city schools precluded the delivery of data via telephone connections due to the recurring monthly charges to maintain a telephone line.

In March of 1994 an NWS representative visited my business, Maryland Radio Center, Inc., an Amateur Radio equipment store and service center in Laurel, Maryland. He was aware that Amateur Radio Operators were transferring data from computer to computer using packet radio, had monitored packet radio and other Amateur Radio data signals, and thought it might be possible to adapt Amateur Radio equipment to the task. He discussed his needs with me and I agreed that it might be possible to utilize Amateur Radio equipment but that it did not allow for the broadcast of interrupt-based one way data. I agreed to look into developing a system and he left me with the following list of requirements:

The system should:

1. Be inexpensive due to the minimal budget available to the target users.
2. Transfer up to 10 Mbytes of data in a period of 24 hours.
3. Deliver near real-time severe weather information.
4. Serve an area within a radius of 50 miles of Washington D.C.
5. Transfer text, graphics, images, and other computer data to be defined.
6. Broadcast to an unlimited number of users in the service area.

After considering all of the requirements, I developed the necessary hardware to demonstrate the feasibility of transferring raw binary data over VHF radio. The hardware was connected to a transmitter and receiver, and software to send small blocks of data was developed. This proof-of-concept system was demonstrated to the NWS at my Laurel, Maryland location in April of 1994. Following the successful demonstration of the proof-of-concept system, I was invited to meet with the NWS at their headquarters. At this meeting it was agreed that I should continue to develop the system.

In May, 1994 I delivered test equipment and very preliminary software and a test signal was put on the air on 163.350 MHz from the NWS headquarters building in Silver Spring, Md. The test transmitter was monitored at many locations in the Washington, D.C. area with excellent results and I began developing a system that would fulfill all of the requirements outlined at our first meeting.

To keep the system inexpensive and still allow the transfer of 10 Mbytes of data in a period of 24 hours, the system was designed to operate at 1200 baud. This allowed a simple demodulator to be connected to the speaker of any receiver or scanner. At baud rates above 1200 baud, it would have been necessary to modify the receiver to provide specific signal levels and characteristics, making the system unnecessarily expensive for the end user.

The necessity of transferring large files at 1200 baud presented a very real possibility that a warning message would be delayed while a large file was being transferred. For this reason, I developed the Quick Block Transfer (QBT) protocol that divided messages into small segments for transmission. By creating a multiple precedence transmission system, I was able to interrupt large, low priority files to insert high priority messages, then continue the transmission of the large file. The transmission system also included the ability to compress files before transmission effectively making the maximum data transfer in 24 hours more than 20 Mbytes.

To ingest data from the NWS Gateway and WeatherWire systems, it was necessary to develop applications to monitor RS-232 ports for incoming data, assign DOS-friendly filenames to the incoming data, and place it in the queue for transmission based on precedence.

Shortly after reception tests proved successful, the preliminary transmission software was completed. Many revisions were accomplished during the initial years of testing and the system was christened the Wireless Weather Information Network (WWIN).

Since the system was useless without software to receive the data, I developed a simple WWIN receive program that was made available at no charge to anyone within range of the transmitter.

Eventually the WWIN acronym was dropped in favor of the Emergency Managers Weather Information Network (EMWIN).

The following modules were developed during the initial seven years of EMWIN system evolution:

The QBT Protocol

This protocol is what makes EMWIN work. It establishes the method for dividing messages into small pieces to allow the interruption of large, low priority messages by messages of a more immediate nature. The use of this protocol insures timely notification of impending severe weather events, even at a very low data rate.

Gateway Engine

The Gateway Engine captures messages from the NWSTG and makes them available for processing by the EMWIN Housekeeper. This module and derivatives of this module feed the EMWIN system and populate the NWS IWIN web site.

EMWIN Housekeeper

Messages that are intercepted for transmission on the EMWIN system are prioritized and scheduled for transmission by this module.

EMWIN Transmit

The EMWIN Transmit module formats messages for transmission on the EMWIN system. This is the module that allows the interruption of large files by high priority files thereby decreasing notification time for warning and watch messages.

Zipfile Creator

The Zipfile creator makes periodic compressed files containing selected products and makes them available for download via FTP by EMWIN users on the Internet.

Satellite Image Processor

The Satellite Image Processor was written to allow the capture and retransmission of GOES satellite images.

WWIN Receive

This program was written early in the EMWIN evloution when it was still known as the Wireless Weather Information Network (WWIN) and was used to provide a simple client program for the monitoring of the WWIN system.

Web Grabber

This program captures graphic files and makes them available for transmission on the EMWIN system. Without this module, no graphic files would be available on the EMWIN system.

WeatherWire Engine

The WeatherWire Engine captures messages from the NWWS and makes them available for processing by the EMWIN Housekeeper. This module and derivatives of this module feed the EMWIN system and populate the NWS IWIN web site.

EMWIN Retransmit (16 bit)

This three level precedence driven retransmit program monitors the GOES EMWIN feed and allows the selection of specific messages for retransmission. This program is used by many retransmit stations to provide a low-speed, localized, data set for a specific area.

EMWIN Retransmit (32 bit)

This ten level precedence driven retransmit program monitors the GOES EMWIN feed or the EMWIN ByteBlaster feed and allows the selection of specific messages for retransmission. It is used by many retransmit stations to provide a low-speed, localized, data set for a specific area.

ByteBlaster Hostmaster

This program communicates with ByteBlaster servers and orders the list of servers so that system loading is shared among all servers. This program makes EMWIN available via the Internet using streaming sockets. The ByteBlaster system is a unique method of delivering streaming data that was developed specifically for EMWIN.

ByteBlaster Server

The ByteBlaster server accepts connections from EMWIN users on the Internet and provides a stream of data identical to the GOES EMWIN feed. A server can stream data directly from a satellite downlink, or from data ingested by a ByteBlaster Client.

ByteBlaster Client

The ByteBlaster client connects to ByteBlaster Servers, receives a stream of data identical to the GOES EMWIN feed, and stores it on the end-user computer.

Eventually, 2400 then 9600 baud data speed was added to the system, primarily for increased data capability on the GOES satellites. Terrestrial retransmission remains at 1200 baud to accommodate inexpensive receivers.

So that I could pursue other interests, in July, 2001 I sold all source code and rights to the NWS and stopped development of the EMWIN system. The system continues to broadcast via satellite, local rebroadcast, and the internet via FTP and ByteBlaster.

I retain all rights and source code for the receive system called WeatherNode. Fore more information see w3jjj.com/weathernode.html

The official Government EMWIN site is http://www.nws.noaa.gov/emwin.