APRS Meteor Scatter Email System
50.62 MHz ?

Bob Bruninga, WB4APR, US Naval Academy Satellite Lab, Annapolis, MD


This MS Email page is a new direction from the original APRS meteor Scatter documentation.

PROJECT OBJECTIVE: The operational scenario for this project is a minimal email capability out of an area for First Responders back to the internet. . Maximum wait times on the order of a minute or less should be possible. . This capability would be available immediately before phone lines, internet, satellite, and other wireless infrastructure are re-established. An example would be mobile units enroute and arriving in the Katrina disaster area. This Meteor Scatter basic communications link would give them this low data rate, but reliable channel.

The self plotting of APRS packets and global connectivity of the APRS-Internet System (APRS-IS) makes it ideal for an Emergency Meteor Scatter Email System. . Using 100 Watt 6 Meter radios and standard AX.25 packet, it should be possible to send outgoing APRS short text-message Emails and position/status reports reliably. . There are several key factors making this possible.

  • Meteor Scatter is long term reliable for a few packets per minute average throughput
  • Meteor Scatter ranges provide good coverage between 500 to 1000 miles
  • 6 Meters is an ideal HAM band for Meteor Scatter
  • Meteors are continuous, but generally 3 times better at 8AM than PM, and 4 times better in July than Feb.
  • Surplus 100 watt 6m radios are readily available and innexpensive See stack of 100 of them
  • APRS Internet connected Gateways are found everywhere all over the USA
  • Adding a 6m receiver at many IGates would immediately provide the Email-Receive capability
  • MS paths are very spot specific, so multiple receivers greatly increases receipt probabilities
  • The Automatic Email delivery system (WU2Z) is built-in to the APRS system and reliable

    The map below only shows the receiver gain plots from 5 possible IGates, but it is easy to visualize how dozens of IGates with their own coverage areas could blanket the USA with Meteor Scatter Receive sites. . I only used five to keep the map from being too cluttered. Hopefully we would enlist dozens of 6m monitoring IGates. . It is this large distribution of receive sites that multiply the usually low probabilities of Meteor Scatter communication up into the useful range of a few packets per miunte. . This is an IDEAL APRS project beacuse the entire infrastructure exists already.

    ANTENNAS: . Although the meteor scatter path is long term reliable, the signals are weak when they do occur, so high gain antennas are desireable. . Fortunately, a high gain antenna (in one fixed direction) can be errected as easily as stringing a long wire antenna. . Some EZNEC models are shown below. The first plots are for a 200' piece of wire over perfect ground. . It is missleading because the AZ plot is showing the Main beam but it is up at 18 degrees which is not very good for MS. The gain lobe is really a cone around the wire.

    The next plots, the length is reduced to a more realistic 120 foot long wire and a real ground which absorbs energy. Also, in the next model, the backward wave is canceled with the terminating resistor. This resistor does not impact forward gain, but eliminates standing waves and the backward lobe making the tuning much easier. . This plot is also a lower elevation slice and so the two lobes of the cone are more visible.

    The wire is fed 1/4 wave from one end with a series 1/4 wave section of two 70 Ohm line lines to match the 400 ohm impedance of the long wire. One quarter wave from the far end, a 400 ohm resistor suitable for half the TX power is located to absorb energy in the unused direction making this a unidirectional wire. For stations in the middle of the country, the resistor is not needed since a bidirectional antenna would be desirable. But without the resistor, there are standing waves, and tuning is more critical.

    The map below shows why the use of a long wire antenna gain will work well for Meteor Scatter because we do not need gain exactly along the line between two stations, we just need their gain patterns to be illuminating the same part of the sky no matter where it is. . In this plot, the two major lobes show very clearly because this is taken at a 5 degree elevation slice.

    Radios: . Mike Chisena, KB2ZEV of the AMRAD club has found a source of 110 Watt radios and is painstakingly converting each one to 6 meters for possible use in this projct. Here is a photo of a complete radio set (and the stack it came from):


    Inside top view, Control Head, Inside bottom view, Inside PA view, and another inside top view

    The map below shows the successful reported packets during the 1995 persieds meteor shower. . Although meteor showers show improved performance, the plot below is for 2 meters, and the results on 6 meters is usually an order of magnitude more sucessful. This balances out well with routine meteor activity which is active 24/7/365. . By transmitting the outgoing email repeatedly over 10 minutes or so, the successful reception by an IGate somewhere is virtually guaranteed.

    If you want more proof that Meteor Scatter works for APRS and to see easy ways to monitor for packets, please see the original original APRS meteor Scatter documentation, and the original APRS METEOR.TXT file for details

    DEVELOPMENT PLAN: . Here is a possible course of action to develop this meteor scatter communications network.

  • First we need to add as many TNC and 6m receivers to IGates as we can muster up.
  • These will work as is with existing IGate software for getting Emails out. . Done!
  • We need some special IGate code to be able to transmit back messages to MS back to the area.
  • This code will receive APRS-IS messages, and then schedule each IGate to continuously transmit the message for 5 minutes or so.
  • We need to determine the optimum sheduling algorithm.
  • The original APRSdos was the typical 15 sec TX and 45 sec REC based on the quadrant of the country.

    EMAIL PROTOCOL: . The protocol for sending email via APRS is well established and operational. . This was developed by the Sproul Brothers and runs on a computer at Rutgers University that monitors the global APRS internet channel and pulls out any messages addressed to EMAIL. It wraps them in a standard internet mail protocol and injects them into the normal Email system. The format is simply:

    WB4APR>APRSxx::EMAIL____:XXXXXX@YYYYYY.ZZZZ text goes here, any length (max one line)...

    This is a standard APRS message format, except the destination field simply contains the word EMAIL padded to 9 spaces and the first word of the message body is an email address. . This format works well. A packet transmitted anywhere in the world in this format on any APRS channel including the satellite channel will result in an email to the intended XXXXX@YYYY.ZZZ recepient. See the Satellite Emergency Email System.

    IMPROVED MS PROTOTOL: . Since brevity is paramount in MS packets, the above format can be improved slightly for better efficiency. The following ideas are proposed to improve Email efficiency. Lets assume a 64 byte text message. The original format then takes 25 bytes of overhead and 18 bytes of Eaddress for an efficiency of 60%.

  • Change APRSxx to APMAIL and eliminate the nine EMAIL____ bytes. (a 9% improvement to 65%)
  • Change APRSxx to APARRL or APJUNO or APASAT to partly eliminate some addressing bytes (25% improvement to 75%)

    This format signals the Email engine to capture these unique APARRL, APJUNO, APASAT formatted APRS messages as EMAILS, and to also then preload any of the most commmonly used ham radio Email addresses or aliases. In this case, the first word of the text message now only contains the unique part of the email address and not the common part of it. . Here is an example:

    WB4APR>APARRL::W3XY text:goes here, any length (max one line)...

    Notice that the two colons (:) still bracket the first 9 bytes of the APRS message format to keep it compatible with the rest of the APRS message system and all existing client software and radio firmware. . But now this special MS Email engine converts the special APARRL to W3XY@ARRL.NET and the rest of the format is the message text (ignoring the required colon in the 10th byte position). . With this improvement, all redundant bytes are eliminated and the only overhead is 4 bytes or so plus the sender and receivers calls.

    Other specialized keyword APXXXX's could be designated as needed. . That's pretty efficient. . The total length of this packet at 1200 baud is just 0.63 seconds, which is quite practical for 6m Meteor scatter.

    RETURN MESSAGING: . The above formats are standard APRS message formats supported by the existing APRS system, and IGate infrastructure. . It full fills the original objective to get an emeregency Email out of a disaster area as long as the transmitting station transmits the packet repeatedly for X minutes to get a high probabiliy of receipt by any one of the dozens of country wide APRS receiving IGates... But this part of the system has no mechanism for getting a response back into the affected area. . That response system will take specialized software.

    To get a message back into the affected area, the IGates must have new firmware to be able to capture an APRS message from the APRS-Internet system and to then schedule it for transmission back via MS. . Here is my proposal for that process.

  • New speical MS IGate sofware
  • All MS IGates capture the message and schedule it for trasnsmission
  • Each IGate transmits using the usual 15 second window for its area
  • The four USA quadrants NE, SE, SW, NW transmit at the 00, 15, 30 and 45 seconds of each minute
  • IGates are configured to be aware of other IGates in their general quadrant.
  • For multiple IGates in the same general area, they too will stagger/share the TX window
  • This process is repeated for say 15 minutes to give a 95% probability of delivery.

    Further, if there is no MS traffic pending, these IGates will still periodically key up with a PILOT packet say once every hour for X minutes as a test packet. This IGate will monitor the APRS-IS for its own successes, and use this average value to determine the amount of time to transmit traffic to get the 97% average success rate or so... This data will also be a way of performance monitoring of the entire APRS Meteor Scatter system!

    PERFORMANCE MONITORING: . Imagine the data we can learn using this self test feature of the APRS MS system. With this system running 24/7, we will learn very quickly the value of this system and have dynamic proof of its probabiliites. . This can be fun!

    WB4APR, Bob


    You are visitor number Since 19 Dec 2007.

    Return to the APRS HOMEPAGE


    The Naval Academy is a registered user of APRS and WinAPRS. The purpose of this web page is to show several applications currently in use at this site and should not be considered as an advertisement or an endorsement of any commercial product.