Sound Card Packet  with AGWPE

Packet Bulletin Board Systems (BBS)

BBSs can still be found in many metropolitan areas on the VHF or UHF data frequencies.  In North America, you can also find the "Network 105" BBS on 14.105 MHz LSB.

To access a BBS, you connect to it using a terminal program.  Some of the more popular terminal programs that use AGWPE are WinPack, AGWTerm, and Hamscope. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.  That page also has links to explanations of how to configure those programs to work with AGWPE.

So what does a BBS offer? First, use the BBS menu that comes up when you first connect to the BBS to explore what's available on the BBS.

• A primary BBS function is to make available a variety of "general information" messages that relate to satellites, propagation, items "wanted" or "for sale", hamfest notices, and many more topics. Typically, you will scan the list of message topics and then ask the BBS to send you the full text of any message that interests you. These messages come to the BBS by radio (or internet) from other BBSs around the state, nation and world.
   
• Another important BBS function is messaging. When you first connect to a BBS, it will probably ask you some simple questions and then offer to be your "home" BBS and create a mail box for you using your callsign. This mailbox lets other users -- either locally or around the world -- send a message to you. You can then pick up the messages from your mailbox when you next log into the BBS. Likewise, you can send messages to other packet users around the world if you know their callsign and the routing to their home BBS. (Typically the addressing format goes like this: callsign@my home BBS.optional  region code.state code.county code.continent code or NM5RM@N5###.NM.USA.NOAM)
   
•  BBSs may also offer chat "rooms"/conferences; callsign lookup programs; internet access or gateways; and connections to other BBSs, either directly or through network nodes (relay stations).

For more basic information about BBS operations via radio, see the Further Reading links at the bottom of this page.

Direct 1-to-1 Conversations (keyboard-to-keyboard)

It is also possible for two stations to talk directly using packet, just as they might with RTTY or PSK31. Typically, they would do this by using terminal programs, such as WinPack, AGWTerm, Outpost and Hamscope. You can find out more about these programs under "terminal programs" on the Compatible Programs page on this website.

It is also possible to use an APRS program or UISS to conduct a conversation using unconnected packets. See the "APRS"  and "Satellite" (for UISS) sections on the Compatible Programs page on this website for such programs.

Normally one-to-one packet conversations are established by a pre-arranged schedule (a "sked"). You can also configure a beacon in your terminal program to send a "CQ" call periodically. Any station hearing your CQ could then try to connect to you.

Real-time conversations can be conducted either on HF or on VHF/UHF.  Consult the band plan for your region and use the digital/RTTY section of the band.

HF connections are a little more difficult since fine tuning is required and the packet frames are more susceptible to interference that could distort the packet frame and render it unreadable. Of course, packet's automatic repeat request (called ARQ) feature would result in a re-sending of the packet, but it might take several retries before the packet might arrive successfully. Other modes such as RTTY and PSK31 are often faster, although less accurate word-for-word. Nevertheless in those modes, even if part of the transmission is lost, some of the characters will still get through and the receiving station may be able to get a sense of the basic message. With packet, it's all or nothing at all. Read more information about HF packet activity.

On VHF or UHF, the average packet station can communicate directly with stations within 10-40 miles depending on local terrain, but this range can be extended either by a.) nearby digipeaters or b.) nearby network nodes (both are relay stations).

Real-time conversations are normally between just two stations. However, some DX cluster (discussed below) and BBS programs permit conferencing among multiple stations. Some nodes even have internet bridges which allow you to be part of a multi-station conversation based in a different continent! By connecting to different BBSs and nodes in your network, you can explore what services they offer.
 

Digipeater Station

Actually, being a digipeater station doesn't offer much fun since it's a passive role -- you don't actively do anything; you set your equipment to do it automatically.

Digipeaters (digital repeaters) are private stations that have been configured to relay (repeat) packet frames as a service to others. They simply retransmit any frame heard if it has their callsign in the frame's address. So a frame addressed from Station A to Station B via Station C (your station) would first be received at your station C, which would then automatically retransmit it to station B.

  Station A --->  Station C ----> Station B

In the early days of packet before networks matured, it was helpful to have every private station be able to act as a relay station. In fact, the digipeating logic was built into most TNCs. You would simply configure your TNC to permit digipeating and leave it running to automatically digipeat packets for others.

As networks matured and well-placed BBSs and nodes came on line, they took over the job of relaying with better results; these stations were usually in high places and running reliably 24 hours a day. Private digipeating became unnecessary, except in situations were you might digipeat for a friend who couldn't reach a BBS or node.

This didn't change much until APRS came along. APRS relies on an informal network of private digipeaters to relay packets to other stations. But as APRS matured, even this got worked out. Only a few well placed (high elevation) digipeaters (called WIDE digipeaters in APRS jargon) are needed. Most other stations were asked NOT to digipeat (too much of good thing can actually hurt the network).

So if there isn't much of a need for digipeating, why bring it up? The answer is that you should know the AGWPE's sound card mode can't digipeat on its own like a TNC can. It just doesn't include the logic for digipeating. But, AGWPE can link to compatible digipeater programs that can perform that function. You can get information about those programs in the "Digipeater" section on the Compatible Programs page on this website.

Would you ever need to run an AGWPE-compatible digipeater program? Maybe, but probably not. As I've said, there may be unusual situations where a digipeater might be needed, such as a friend in a black hole (a location with poor signal quality) who can't reach the BBS directly and needs a relay to the BBS; or in an emergency when a digipeater might help relay messages in the WinLink system or other packet messaging network. But this would be rare.

And you probably should NOT run a digipeater in the APRS network. Most APRS networks already have adequate digipeaters. However, there may be locales or emergency situations where a digipeater might fill in a gap and be helpful. You will only be able to decide if there is a need for this after you have gained experience by running APRS for a period of time and talking to other APRS users in your area. They can also help you with the proper settings and configuration for your digipeater software. And remember that an AGWPE digipeater needs a computer to be running constantly. A TNC might be a better choice in those situations.

Ham Radio Mail (or Store-and-Forward Messaging)

You can send a typed message to a mail drop (either an AGWPE-compatible software program or a TNC) which lets the recipient pick it up at his/her convenience. Think of it as ham radio email. As mentioned about, BBSs were commonlly used for this function.

Here are some other packet messaging techniques:

• WinLink - is a radio-to-internet-to-radio email system that started out as a service to amateur radio sailors. It has evolved into a communications system for any situation where a traditional wired link to the internet does not exist and a radio-link can bridge the gap. It's been used by doctors in remote jungle regions and by emergency responders working in disaster areas where wired internet services do not exist or have been lost. In fact, many emergency planners are now incorporating WinLink into their contingency plans.

WinLink uses PACTOR (not packet) and a new sound card-based mode called WINMOR for long-range, HF frequency connections to land-based WinLink relay sites with connections to the internet. But VHF packet to a WinLink relay site is an option for short-range situations.

You can read more about WinLink and download its AGWPE-compatible packet program, PacLink, from this site: http://www.winlink.org/  

Note: There is AGWPE configuration help within Paclink. Use the Paclink menu to call up "Help", and within the Help "Contents", look under "Configuration" where you will find topics on "AGW Engine Properties" and "Packet AGW Channel.
 

• NTS: In the United States, the National Traffic System, or NTS, is used to relay short "radiogram"  messages using amateur radio. Messages can range from high priority emergency traffic to routine birthday greetings. Several modes may be used to relay the message from the originating station to the recipient  -- Morse code, voice, and packet. The final step in the delivery of a message is usually a phone call to the message recipient.

NTS nets are held daily around the country. Messages for transfer are usually brought to the net by voice, but messages can also be originated by packet or relayed by packet using special NTS BBS nodes. Packet-based NTS messages can be relayed to the voice net or, if no one on the voice net is near the recipient, then the packet message can be left on the NTS BBS for handling at a later time. To access the NTS BBS and see these messages, you need a packet terminal program . such as WinPack, AGWTerm, and Hamscope, to connect to the BBS. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.

To learn about NTS in your area, first talk to experienced hams, who will probably know when the local NTS voice nets are held; or listen on local UHF or VHF repeaters for the voice nets, which are often held at 10:30 am, 7:30 pm and 10:30 pm. The net control operator (NCO) of the net will be glad to answer your questions about NTS and tell you if and how packet is used.

For additional information, you can also visit this web page which was written by Dave Streubel WB2FTX and describes NTS packet operations in New Jersey. The description Dave provides will probably work in other states.
 

• Personal Mail Boxes: In addition to the mailboxes found on BBSs, many TNCs (Terminal Node Controllers) offer personal mailboxes that allow other packet users to connect to your station and drop off messages for you or other users of your station.

AGWPE does not offer this feature by itself, but it can link to programs which can provide personal mailboxes. They include PMS (an external add-on for the WinPack program), HamServ, and Outpost. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.
 

TCP/IP Linking

Using the special TCP/IP Over Radio (TOR) feature found in AGWPE and PE Pro, two stations can exchange TCP/IP-based data by packet.

TOR is most frequently used as a way for a ham radio station without internet service to gain internet email service by working through a ham radio station with internet service. For this to work, both stations must be running AGWPE (or PE Pro). Note: There is a special fee payable it you want to run AGWPE's TOR feature (for Windows XP and earlier versions only) for more than 45 minutes. If you purchase PE Pro, TOR is included.

For applications needing fast transfer rates, such as high-content web browsing or audio and video streaming, TOR's relatively slow transfer rate will not be adequate.  But for other applications where high transfer rates are not required, such as email, ICQ, small file transfers, or simple web pages, this rate may be adequate.

For more information about TOR, see the TOR page on this website. 

Network Exploration

In the not too distant past, there were numerous packet networks in the US, Europe and other parts of the world. These networks consisted of  BBSs, packet nodes (relay stations/switches) and other links, all tied together. It was quite interesting to explore a network and discover the services available at the different BBSs and nodes. These included callsign lookups, reference file downloads, gateways to the internet, and gateways to conferences/chat rooms that were hosted in continents far away.

Additionally, these networks were developed to provide emergency messaging in the event regular telecommunications were lost. Some states or regions in the US may still have such networks including Florida, Michigan, Virginia, Northeast US, and Colorado (the "last revised" date for some of these websites suggests they may no longer be very robust. 

In general, with the decline of packet and with the appearance of WinLink and other digital messaging systems (such as NBEMS: Narrow-Band Emergency Message System ) that don't need traditional networks, it appears many packet networks are crumbling or outright disappearing.

To find out if there is a network in your area, you can try an internet search; you might try your area's (State, Province, Country) name and the words "packet radio network", "RACES", "digital", "NTS" and "ARES" as search terms.

But perhaps the best way to investigate networks is to do it by radio. Tune to your area's packet frequencies and listen for beacons and other packet traffic.  If you hear a beacon or traffic from a BBS, DX cluster or network node station, try to connect to it and then use its menu system to explore what it can do (use one of the "Terminal Programs" on the Compatible Programs page on this website.)

 

DX Packet Cluster

A DX packet cluster is a group (or cluster) of hams who have connected to a central  station running "cluster" management software to share reports of DX "spots", distant stations on the HF frequencies. When a participant notices a spot, he/she sends a notice by packet to the cluster with information about the spot's callsign, operating frequency, and perhaps a comment, such as "listening 5 down". The cluster software then relays this spot notice by packet to each of the other connected cluster participants. As you can imagine, a DX cluster can be a great tool for finding interesting or rare DX stations.

Some metropolitan areas may still have packet-based DX clusters, but many clusters have now stopped operating because there are internet websites that provide the same function more effectively (do a web search for "DX spotting").

To connect to a DX cluster, you would use a terminal programs such as WinPack, AGWTerm, and Hamscope. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.

 

Satellite Communications

With the advent of packet, a few satellites were launched with amateur radio packet stations, usually operating on the VHF and UHF frequencies, some using Single Side Band (SSB) modulation and some using FM. Some of these satellites had store-and-forward BBS message capabilities. Some even transmitted status reports or images by packet. Most or all of these early satellites are no longer operational.

More recent packet satellites have been mostly Low Elevation Orbit (LEO) satellites which have relatively quick pass times (10 minutes or less). Most LEOs are used primarily as digipeaters -- to relay a simple, unconnected packet to a distant station, a la APRS. (If a LEO satellite had a store-and-forward BBS, it would be difficult to use -- too many operators competing to access it; not enough pass time to complete the contact --but a  packet terminal program would be used for such a contact.)

A good program for sending an unconnected packet through a satellite is the UISS program. It is able to send UI (unconnected, beacon-style) packets; most terminal programs can not. Look for UISS download information under "Satellites" section on the  Compatible Programs page.

The current situation on packet satellites will fluctuate as new satellites get launched and older satellites stop operating. Of late (2015), the situation has not been good. The ISS (International Space Station or ARISS) has packet capability in the form of a Kenwood D700 with an integrated TNC (2 meter and 70 cm frequencies), but the crew also uses the radio for voice, SSTV, and crossband voice repeating.  If the radio's packet mode has been turned on, it provides digipeating services only -- no BBS services -- so use the UISS program to send unconnected packets.

A typical unconnected packet would have a target station of "CQ" and a VIA station of "RS0ISS", the packet callsign of the ISS. The message inside your packet might include your name and your grid square or other location information. A station hearing your CQ would digipeat a confirmation back through the ISS. You would reply with a confirmation of the other station's packet.

From time to time other satellites are launched with packet capabilities; some may even be in orbit now. To check on the current status of packet-capable satellites, visit the AMSAT website at http://www.amsat.org/amsat-new/satellites/status.php. The last column in the chart indicates if the satellite has packet capability. If it does, do further research on the satellite to learn its schedule for packet operation, type of operations (digipeater, mailbox, or both), its uplink and downlink frequencies,  and its overhead pass times for your area.

Note that most satellites use one frequency band for uplinks (receiving) and another for downlinks (transmitting). This means you must either have a dual band radio or use two different radios. Fortunately, the bands normally used are VHF (2 meter) and UHF (70 cm/440), and such radios are fairly common.

Jan PE0SAT has an interesting page about decoding 9600 baud AX25 packets from the STRaND-1 satellite.  

Meteor Scatter

Meteor scatter is similar to satellite use (above). Periodically you would send a short packet and hope that it bounces off the ionization trail of a incoming meteor/meteorite to a distant station.

In the past, there have been organized attempts to make 1200 baud packet contacts during heightened meteor activity/showers. (Here's a newsletter from 1984 with a meteor scatter report.)  From time to time, someone resurrects that idea, but there's generally not much enthusiasm, partly because there are other digital sound card modes better suited for it, such as FSK441.

If packet contacts were attempted via meteor scatter, it would probably work best with very short UI/Unconnected packets.  The UISS program would be good for this purpose.

Meteor scatter theory suggests the best bands to try are between 30 and 50 MHz. In fact, the 6 meter band has historically showed the most success.

If you are not interested in a confirmed contact from another station, another option is to use automated APRS meteor scatter. In this mode, you simply listen for APRS packets that may have arrived via meteor scatter. Here's what Bob Bruninga WB4APR suggests for doing this:

Let the 10,000 other APRS signals on the air be your test signals...

1) See if you can find a place with weak 144.39 MHz APRS signals (in the US), such as down in a valley where nearby surrounding city APRS traffic is hard to hear, but you can still see the sky down to about 20 degrees towards a really BIG APRS activity area about 500 miles to 800 miles away.  Keep your beam low (to minimize local QRM), but point it up about 10 to 20 degrees in the favored direction (actually, tilting it is not needed at all...  the point is to keep it LOW to the horizon)...

2. Run your APRS station on 144.39 MHz (in the US) all night.

3. In the morning, look at what packets/stations your software has captured, looking carefully at the PATH.  If you heard them direct and they are over 200 miles or so away, then it was most likely via meteor scatter (but perhaps tropospheric scatter ...).

You can also use one of the APRS data collection sites on the internet, findu.com or aprs.fi, to see if your raw packets were reported at a distant station, an indication that perhaps meteor scatter was at work.

The UI-View32 APRS program has a meteor scatter mode setting that is useful for sending  very short packet (with your grid square) at variable intervals suited for meteor scatter.