Heard Island Expedition 1997 (Planning Documents)

Bob Fabry N6EK

The logging setup

 The logging setup we have is based on there being at most six HF CW and SSB stations on the air at one time utilizing up to four FT-1000MP transceivers and up to three FT-900 transceivers. RTTY logging will be handled separately using the WF1B program. Satellite logging may or may not be a part of the main logging system. All the computers will be connected together using the CT loop network and all the radios will be connected to the logging computers to allow computer control of the radios. If you are bringing a transceiver that might be used in a pinch, please bring the cables and converters necessary to connect the transceiver to the computer using a standard 9-pin serial port connector.

 

We have five Compaq 410C computers and two Compaq 400C computers for logging. One of these is a spare. The 410C's are new from Don Greenbaum this year and the 400C's are ones that Bob Schmieder and Glenn Vinson bought last year and have made available. In addition, I have a 400C that I bought last year and which I will use for processing the logs. The 400C's are 33 MHz 486's and the 410C's are 50 MHz 486's. All have eight megabytes of main memory and 250 megabytes of disk. All run Windows 3.1, but will run CT under DOS while logging. There are six PC-card serial ports which plug into the computers to provide a second serial port.

 

Since the computers are not really designed to run in a hot RF environment, there is RF filtering on every lead coming into each of the logging computers. This includes the power input cable, the CT loop network cable, the rig control cable and CW keying cable. This scheme was tested on the February Wake Island trip and we had no RF interference to any computer while running the network at 9600 baud. There are six CT loop network cables, four rig control cables for the FT-1000MPís, three rig control cables for the FT-900ís and six keying cables. All of these cables are made up and tested.

 

According to the manufacturer, the only part of these computer that may be bothered by the grit in the air is the floppy disk drive. The keyboard and hard disk are sealed units. As insurance against a floppy disk drive failure, LapLink is installed on all computers and we have serial and parallel cables which allow transferring files between computers without using floppy disks in the event of a floppy disk drive failure.

 

Networking Considerations

 

We use a CT loop network which requires one serial port per machine for connecting the logging computers. This is an RS-232 network. We have over a thousand feet of four conductor wire to connect the three operating sites. There are six CT loop network cables, one of which plugs into the serial port on each computer; they include RF filtering and terminate in a barrier strip for connecting to the network wires.

 

We expect to run wires using RS-232 directly between the operating sites. we have two other options for these connections, however. One option is two pairs of RS-232 to RS-422 converters so we can run RS-422 between sites if we need to. These may help if the wires pick up too much RF or other noise. The other option is two pairs of 900MHz RF modems which can be used to run between sites without using wires at all. These may help if the sites are too far apart to run wires or if the wires are impractical due to wildlife or other hazards. I have tested both types of hardware and they work fine with the CT loop network. The main drawback of either is that they require power. Each time any operating site loses power, the whole network goes down. (Because the laptops each have an internal battery, the network will otherwise keep running even if an operating site loses power.)

 

When the CT network is running, all contacts are recorded on all machines. This provides us with redundancy in case a computer dies completely, gives each operator a feel for what the other operators are doing, and lets us communicate between the operating positions using the CT gab function.

 

To keep the CT network running, we must keep all the logging computers powered up and running CT at all times. If any computer is turned off or is not running CT, then messages can no longer be forwarded through it and the whole network becomes dysfunctional. If we have to power down a logging computer or leave CT momentarily, we must first unplug the network cable from the back of the computer and plug the cable into a loop-back plug to provide network continuity. There is a loop-back plug for each computer.

 

The batteries in the laptop computers can be depended on for about an hour of operation. If one of the operating site is going to have its power shut down for less than an hour or so, leave the computers running even if no one is using them so the network will continue to function and the computers can record all the contacts made by the other stations. If one of the operating site is going to have its power shut down for more than an hour or so, use the loop-back plugs to provide network continuity and put the computers in standby mode by pressing the power button once. In standby mode, the power-on (left) LED will blink quickly every five seconds. The battery is good for about a week in standby mode. To restart from standby mode, press the power button once more and the computer will restart exactly where it was. It will not be necessary to restart CT. Then remove the loop-back plug and reconnect the network cable to the back of the computer.

 

It is critical to remember to use the loop-back plugs. When someone forgets to use a loop-back plug, one of the operators from another tent will probably be the one who has problems as a result. This operator may have to stop operating and wander from tent to tent in the pitch black rainy night to find the cause. Not a happy thought!

 

If we need to use the RS-232 to RS-422 converters or the 900MHz RF modems for the network, then we will simply have to put up with network outages whenever any site has its power shut down, say for generator refueling. If a site is going to have its power shut down for an extended period and if it is not the middle of the three sites, then we can install a loop-back in the middle site to keep the other two sites working.

 

Logging Using CT

 

All logging will be done in real time using CT. All operators must be proficient with CT before we land. It is essential that everyone work very hard to be accurate loggers, both getting the call correct and changing bands and modes correctly.

 

Band and mode changes must be initiated from the computer rather than the radio. Changes made at the radio may not be noticed by the logging computer and can result in contacts being logged on the wrong band or mode. To minimize problems, the band and mode recorded by CT for all contacts will be compared to a paper record of log changes each day before the log information is sent off the island.

 

Even with 8 megabytes of memory, we can record only a few over 46,000 contacts in the log. We hope to make more contacts than that. We will truncate the logs once we have worked 46,000 contacts, and at that point we will not have information about previous contacts immediately available at the operating positions.

 

We will be running CT in 24-line mode and using special fonts which make the characters more readable. We will have the CT feature called super-check-partial enabled. This allows calls to be checked against a very good database of DXer calls that Peter Casier has prepared. I have tested the 33 MHz computers with 46,000 contacts in the log, the network running at full speed, super-check-partial running with Peter's full database and several people logging bogus calls as fast as they can, and everything works fine.

 

This won't normally come up during operation, but if you have to setup a computer for a new radio, the FT1000MP is on the CT menu, but the FT900 is not. Use the FT990 settings for a FT900.

 

Peter asked me to point out a feature related to super-check-partial that is not documented in the CT manual: If you enter a call using a question mark, as in SP?MGM or SP??GM, when you move the cursor back to a question mark, you are automatically switched to overstrike mode instead of the usual insert mode.

 

Paper Record

 

There will be a paper log associated with each computer that will be used to log all operator changes, band changes and mode changes as well as comments about operating conditions, equipment problems and so on. Each operator must make an entry at the start and the end of his shift and whenever he changes band or mode. This paper record will allow us to verify that all contacts have been logged on the correct band and mode before the computer logs are sent off the island by satellite and will allow resolving band and mode questions that come up during QSLing.

 

Each time you operate on a band during your shift you must note the time and date you start and the time you end as well as the number of contacts which had been logged on the band-mode before you started and the number of contacts that have been logged on the band-mode when you finish. For the band, use the information shown on the radio. For time, use the time shown on the computer screen. This number of contacts is shown on the computer in the summary window which you can toggle on and off with ALT-S. It consists of QSOs plus dupes, called Q and D in the summary. If there were 1034 QSOs and 56 dupes on your band, you should enter this as ì1034 + 56 = 1090î. This will let us correct your addition in case you were punchy and made a mistake. Note that you MUST use the numbers from the highlighted line for the band you are on and not the total for all bands, which would be useless. If you wish, you can also calculate the number of QSOs you made by finding the difference. If you donít, we will, because it is this number that will be compared to a summary of the log to help make sure all QSOs were logged on the correct band-mode. Warning: If you do not do this correctly, someone may have to wake you up to confirm the log before we can send the log off by satellite.

 

Collecting the Logs

 

Once each day we will collect the logs from all the computers, merge them together, eliminate dupes, and ship information about the new QSOs off to John Devoldere. John will combine these QSOs with the ones he has previously received and forward a complete log to each of the people who are managing a log server where people who work us can find out for sure that they are in the log. We will have log servers accessible via the World Wide Web, via internet e-mail and via HF packet e-mail.

 

Most of us don't have to be concerned about this process, but we need a few careful people with a fair amount of CT experience and/or computer experience to help. If you are interested, please speak up. The following is a somewhat more detailed version of what is involved written for people who have some background with CT and computers.

 

Once each day, we will make a copy of the BIN files from each of the logging computers. Until we have about 28,000 contacts, the uncompressed BIN file will fit on a single floppy disk and we can collect the files by inserting a floppy disk into each logging computer and using the CT command called savelog. I donít know whether the network will run in the background during a savelog or whether we will have to use the loop-back plug to keep the network running. In order to minimize confusion, the BIN file has a different name on each logging computer. At station two, for example, the log is called LOG2.BIN.

 

We must treat the log from each computer with care and assume that each computer will have at least a few contacts that were not transmitted to another computer. If we are successful in keeping the computers powered up and in using the loop-back plugs properly, there should only be a few contacts that are unique to each computer.

 

Once we have reached 28,000 contacts, we will need to use the loop-back plug and quit CT in order to copy the BIN file. PKZIP has been installed on all the logging computers, and when one has exited CT, one is still in the CT directory where the BIN file is stored. Thus the DOS command ìPKZIP A:LOG LOG2.BINî will place a copy of LOG2.BIN in A:LOG.ZIP. A zipped version of a 70,000 contact log will occupy about 600K bytes, thus we can save several logs onto a single floppy.

 

Once we have obtained copies of the log files from each of the six logging computers, they will be loaded on my computer. In addition, Arie may give us RTTY and Satellite logs to be combined with the main logs. Before processing these individual logs at all, an archive copy of this raw input is to be stored in zip files on one or more floppies. In some cases we may be able to simply save the floppies that the logs were brought in on, but please note that if you are trying to fill a floppy using the savelog feature of CT, savelog does not complain if the floppy becomes full! It simply truncates the BIN file and I am not sure whether subsequent processing will detect the problem or not.

 

The archive copies will be saved intact for reference. They will be put in a Ziploc bag as soon as possible to protect them from moisture and grit. Certain problems with subsequent processing can be resolved only by going back to these original logs, so consider these BIN files to be irreplaceable.

 

Once these files have been backed up, a merged version of the log is made using the CT merge program. This merged log is the starting point for further processing.

 

There will be a program for scanning the log data and summarizing the QSOs between band changes on each logging computer. The output of this program will be compared to the paper logs to validate the computer logs. I havenít written this program yet. I also hope to write a program to breakdown the US contacts on each band by call district, and maybe a few other programs to answer other interesting questions.

 

Once the merged log has been validated, a script will be run that strips out just the callsign, band and mode one QSO per line. The script then compares this data will to the same data from the previous day to isolate the new QSOs, and then sorts the new QSO information by band-mode so the band and mode information doesnít have to be included for each QSO. The script then combines this information with some more text explaining the time period represented by the log information and with certain obscure information which is used later to help detect modifications in transit. The result is a text file which we give to Arie for transmission back to civilization by amateur satellite, or if that fails by commercial satellite.

 

The file reaches civilization by being downloaded by Andre who sends it on to John Devoldere. John runs an unpacking script at his end which combines the information about the new QSOs with the data he has received previously to reform a complete log. The script produces a file called LOG.TXT which contains the QSO data and a file called MESSAGE.TXT which explains the time period represented by the log information and provides any other special information, and zips them into a single file called DIST1.ZIP the first time, DIST2.ZIP the second time and so on. John then sends this file via the internet to each of the people who are managing log servers for us. These people simply replace the older version of LOG.TXT and MESSAGE.TXT with the newer version.

 

The Details of Packing and Unpacking the Logs

 

It is not necessary for all operators to be familiar with the details of this process.

 

The logs need packing and unpacking because they are sent from Heard via satellite and the bandwidth is low over this path. For this reason, only the new contacts are sent each day, and they are sent in a way that requires on the average only three bytes of data per QSO (after compression.) On the Island, log packing starts with a complete log in CT BIN file format. A script is used to produce the data that is sent via satellite. When the data from the satellite arrives on the mainland, another script is used to produce a log of all the contacts to date and this log is then forwarded via the internet to all the log servers.

 

Although we refer to this information as a log, it is a little different from a normal log. It does not contain the time or date of any contact, only the fact that a contact did occur with a particular station on a particular band and mode. There are two reasons for this. First, it reduces the amount of information transmitted over the satellite. Second, since information on the satellite is public, including the time and date of each contact could encourage certain forms of cheating. Also, no duplicate contacts are included in the information sent over the satellite.

 

TXT format and QSO format

 

As the log comes in over the satellite, the contact information is in what I call TXT format:

 

10 CW:

EA1EGZ

EA1MC

JA0AZE

 

In TXT format the calls are sorted first by band and mode and the band and mode information is given only when there is a change. In addition, there is some header information at the beginning that may look this:

 

:1123324167241049

:This information includes all qsos logged before December 9, 1996 0500Z.

:This message is not based on the real Heard Island 1997 logs. We are testing

:our server with some bogus data partly from the ZA1A and AL7EL/KH9 logs.

 

The first line of header information is used for authentication. It is an attempt to detect changes that might have been made to the data by someone who does not understand the authentication scheme. The rest of the lines are the text message written on Heard that explains the log data. This explanation may be updated each time new log data is produced.

 

In QSO format, there is one line per contact. This is the format used as input to the log servers. Each line has the band, the mode and the callsign for one contact:

 

15 CW YU4ELS

15 CW ZC4BS

15 RTTY JA5CEX

15 SSB 3A2LF

15 SSB 4U1WB

 

General Processing Scheme

 

The overall processing of log information goes as follows: On the Island, a single CT BIN file is constructed which includes all of the contacts to date. In addition, there is a file called GENINF.TXT which contains any explanation needed for the log data. (In the example above, the third and fourth line of the header came from GENINF.TXT.)

 

This BIN file is converted to a text version called a RES file. The band, mode and call columns are selected from the RES file to produce a file in QSO format. The file is sorted by band and mode and duplicate lines (representing dupes) are eliminated. This file is called LOGn.ALL and is retained for processing the next BIN file to be sent off the Island. If this is not the first log file to be sent, lines representing contacts that have already been sent to the mainland, remembered in LOG(n-1).ALL, are eliminated. This information is converted to TXT format and the header information is appended. The resulting file is named LOGn.PAK, where n = 1 for the first log sent to the mainland, 2 for the second, etc. PAK is short for packed and indicates that three different kinds of information have been packed in one text file: log data, explanatory message and authentication information. Everything in this paragraph is handled on the island using a DOS script called PACK.

 

The LOGn.PAK file is sent to John Devoldere on the mainland via satellite and the internet.

 

The log in TXT format is extracted from the LOGn.PAK file and validated using the information in the header. The rest of the header information is written to a file called MESSAGE.TXT for transmitting to the log servers. The log is converted from TXT format to QSO format and combined with all the log information previously transmitted into files called LOGn.ALL and QSO.TXT. LOGn.ALL is retained for combining with the next batch of log data from the Island. MESSAGE.TXT and QSO.TXT are zipped together into a file called DISTn.PAK. Everything in this paragraph is handled by John using a DOS script called UNPACK.

 

John sends a copy of DISTn.PAK to each of the people managing a log server: Don, Lyndon, Rob, Etc.

 

Detailed Instructions for Using the Pack Script

 

If you donít have a directory called C:\TMP, create one. (If you will be using a drive other than C:, use that drive letter instead of C: in these instructions.) This directory will be used for temporary files during sorting.

 

Create a new directory called C:\PACK to be used for processing the logs.

 

Change into this directory.

 

Place the PACK.ZIP file, which I will have sent you, in this directory.

 

Unzip the contents of PACK.ZIP.

 

You are now ready to process the files called LOG1.BIN, LOG2.BIN, etc. to produce the files called LOG1.PAK, LOG2.PAK, etc. which you will send off the Island.

 

Combine all the BIN log files from the various stations including packet and satellite into a single log. This is done with the MERGE program that comes with CT. Note that when you execute ìMERGE A Bî, a new version of A.BIN is created which includes both the contacts for the original A.BIN and the original B.BIN. This is not currently automated with a script, but I may well produce such a script after a few days of doing the merging by hand, Name the combined log file LOG1.BIN the first time, LOG2.BIN the second time, etc. Note that although the largest BIN file we can log with is limited to 46K contacts, the BIN files created by MERGE can be as large as we need.

 

Figure out the time and date for which you can say you have all contacts up to then in your log. This may be simply the earliest last modified time and date for BIN files you merged, although you may have special information that will allow you to use a later date. For example, although the satellite log information hasnít changed in twelve hour, no satellite work has been done in that time.

 

Read the file GENINF.TXT and verify that its information is still correct. If it is not, edit it with a text editor. Try to limit the line length to about 70 characters so the lines will be suitable for the servers to include in e-mail.

 

Type PACK n. That is, if you want to turn LOG2.BIN into LOG2.PAK, you type ìPACK 2î. The script that runs will keep you informed about what it is doing and how many contacts are being processed at various steps. Possible planned error conditions:

 

ìYou didnít give a proper log number.î

The number you type after PACK needs to be 1, 2, 3, and so on.

 

Error: LOG2.BIN not found.

The number you typed didnít correspond to a BIN file number in PACK directory.

 

Error: LOG1.ALL not found.

Either you havenít processed LOG1.BIN yet or the file has been deleted. If the file has been deleted, simply execute PACK 1 again.

 

The script will prompt you to type the time and date you have decided upon above. I suggest a format like 10 January 1996 1243Z, but this is merely text and does not have to be in exactly the same form each time.

 

When the script finishes, the file LOGn.PAK should exist in the PACK directory. Copy this file to a floppy disk and give it to Arie for transmission to the mainland.

 

Your directory will slowly fill up with the LOGn.BIN, LOGn.PAK, and LOGn.ALL files. This is OK, but if you are running out of space, you can delete all but the latest LOGn.ALL file. All the other files created during processing should be deleted by the script.

 

Complicated Situations During Packing

 

If you are unable to collect log files from all of the stations, you can go ahead without the missing log files. Modify GENINF.TXT to explain the situation. For example, you might say, ìAn elephant seal is sitting on one of the SSB logging computers and we were not able to collect its log today. This means a few of the SSB contacts on 15 and 20 meters between 0400Z January 18th and 0800Z January 18th are not yet included in this data.î

 

Our computers have eight megabytes of memory, which means they can hold only about 46,000 contacts. When we get near 46,000 contacts, copy each bin file, STNn.BIN, to a floppy disk and also make a copy of it on the computer as OLDSTNn.BIN. Then truncate STNn.BIN using the CT truncate command which is called TRUNC_BI.EXE. TRUNC_BI.EXE is loaded in a directory called CTSTUFF on each computer. The truncate command removes all of the contacts from the log but leaves all of the settings intact. Then merge all of the collected STNn.BIN files into a file called PART1.BIN. Then each day when we merge everything together to form the LOGn.BIN file used as the start of the PACK process, PART1.BIN will be one of the BIN files merged. The resulting LOGn.BIN files will be too big to use while logging with CT on a computer with eight megabytes of memory, but the PACK and UNPACK scripts and CT's MERGE program handle them just fine. Note that this whole process is not that different from what we do every day to collect the logs, and the process can be done one computer at a time; it is not necessary to shut down the whole operation for consistency.

 

Testing the Pack script

 

I have tested the PACK script on the laptop we will be using on Heard for a set of four BIN files that represent one quarter, one half, three quarter and all of a BIN file with over 65,000 contacts made by combining the ZA1A log with the AL7EL/KH9 log.

 

I am sending Peter Casier a copy of PACK.ZIP and hope he will test it on the files from his recent 5X expedition.

 

Detailed Instructions for Using the Unpack Script

 

Create a new directory called UNPACK to be used for processing the logs.

 

Change into this directory.

 

Place the UNPACK.ZIP file, which I will have sent you, in this directory.

 

Unzip the contents of UNPACK.ZIP.

 

 

You are now ready to process the files called LOG1.PAK, LOG2.PAK, etc. that you receive.

 

When you receive one of these LOGn.PAK files, go into the UNPACK directory and copy the LOGn.PAK file into the directory also. Under normal operation, you must have processed LOG(n-1).PAK before processing LOGn.PAK. Your options when files are received out of order are described below.

 

Type UNPACK n. That is, if you want to unpack LOG2.PAK, you type ìUNPACK 2î. The script that runs will keep you informed about what it is doing and how many contacts are being processed at various steps. Possible planned error conditions:

 

You didn't give a proper log number.

The number you type after UNPACK needs to be 1, 2, 3, and so on.

 

Error: LOG2.PAK not found.

The number you typed didnít correspond to a PAK file number in UNPACK directory.

 

Error: LOG1.ALL not found.

Either you haven't processed LOG1.PAK yet or the file has been deleted. If the file has been deleted, simply execute UNPACK 1 again.

 

Data verification failed.

Original check information:

1123324167241049

Check information on received file:

2548593793572974

Hit ENTER to proceed.

Record both pieces of check information. Hit enter and proceed. Your options for using this data anyway are explained below.

 

The file DISTn.ZIP should now exist in the UNPACK directory. Extract the MESSAGE.TXT file from DISTn.ZIP and check that it makes sense. Send copies of DISTn.ZIP to all the people managing log servers. This list of people may change, but for now it is:

wb2dnd@pcix.com (Don Greenbaum)

lyndon@orthanc.com (Lyndon Nerenberg VE7TCP)

Rob.De.Wit@net.HCC.nl (PA3BXR)

 

Your directory will slowly fill up with the LOGn.PAK, DISTn.ZIP, and LOGn.ALL files. This is OK, but if you are running out of space, you can delete all but the latest LOGn.ALL file. All the other files created during processing should be deleted by the script.

 

Complicated Situations During Unpacking

 

There are several unusual situations which might arise during the unpacking and will call for good judgment to sort out. If the logs come in out of order, say you get LOG1.PAK, LOG2.PAK and then LOG4.PAK, what should you do? You can either simply hold up on the processing of LOG4.PAK or, if that seems painful for some reason, you can rename LOG4.PAK to be LOG3.PAK and go ahead and process it under that name. Before distributing a DIST3.ZIP made this way, you will want to extract MESSAGE.TXT from DIST3.ZIP, edit it to reflect what is happening, and update the ZIP file with the new version. If you rename the PAK file in this way, be sure and keep a copy of the original. When the real LOG3.PAK arrives, run the unpack script using the real one; this will overwrite the files for the interim version. Then process LOG4.PAK and send out DIST4.ZIP. Since each DISTn.ZIP file is complete in itself, the people running the log servers donít even have to be told what you are doing. They will simply install first the interim version and then the final version.

 

If you get a PAK file for which the verification fails, there is the possibility that someone has intercepted and modified the file while it was on the satellite. I have no idea how easy this is in practice, but if we believe all the error correction works, I canít see what else could cause a verification error. Send Andre back a copy of the PAK file which caused the problem and ask him to verify that it matches what he received from us. If Andre canít find a problem at his end, send us via e-mail both pieces of check information and a copy of the PAK file you received. This may help us to diagnose the problem. In any case, we will transmit the file to you again as soon as possible.

 

If something gets really screwed up, there is the option to retransmit the logs to you from scratch. I call this doing a ìresetî. In this case, create a new directory and unzip the programs in the new directory. Depending on how many contacts are in the log, we may have to retransmit the log as several pieces. You can send the new log information to the log servers in pieces or you can wait until you have received the whole thing. Which is better will depend on the circumstances.

 

Testing the Unpack script

 

I sent John copies of UNPACK.ZIP and four sequential test files: LOG1.PAK, LOG2.PAK, LOG3.PAK and LOG4.PAK. He can try processing these in order and sending the resulting DISTn.ZIP files, one at a time, to the people managing the various log servers. He can also send me copies to verify.

 

John can also pretend to receive LOG3.PAK late and practice working around not having it. He can send me the resulting DISTn.ZIP files and we can talk about what happens.

 

If John wants to see how a verification failure works, he can use a text editor to make any small change to the log data. (MESSAGE.TXT is not checked during verification. Maybe that is an error.)

NCDXF/IARU Beacon Tentative Transmission Schedule

As of September 9, 1996

W6ISQ and N6EK

This table gives the minute and second within each hour of the start of the first transmission of each of the new five-band beacons on each frequency. Transmissions currently being sent are indicated in bold. Each transmission is repeated every three minutes. A transmission consists of the callsign of the beacon sent at 22 words per minute followed by four one-second dashes. The callsign and the first dash are sent at 100 watts. The remaining dashes are sent at 10 watts, 1 watt and 0.1 watts. The actual starting time of each transmission is approximately twenty milliseconds after the nominal time due to the keying delay of the transmitter. Equipment used at each beacon site includes a Kenwood TS-50 transceiver, a Cushcraft R-5 vertical antenna, a Trimble Navigation Accutime GPS receiver, and a controller built by the NCDXF. For more information, contact the Northern California DX Foundation, Post Office Box 2368, Stanford, CA 94309 USA.

The current version of the table can be found at http://www.ncdxf.org/beacon.htm.

Country

Station

14.100

18.110

21.150

24.930

28.200

operator

status

1	United Nations**	4U1UN	00:00	00:10	00:20	00:30	00:40	UNRC	In New York 1
2	Canada	VE8AT	00:10	00:20	00:30	00:40	00:50	RAC	Ready to ship
3	USA	W6WX	00:20	*00:30	00:40	*00:50	01:00	NCDXF	On the air
4	Hawaii	KH6WO	00:30	*00:40	00:50	*01:00	01:10	UHRC	In Hawaii
5	New Zealand	ZLØ	00:40	00:50	01:00	01:10	01:20	NZART	Built, call?
6	Australia	VK6Ø	00:50	01:00	01:10	01:20	01:30	WIA	Built, call?
7	Japan**	JA2IGY	01:00	01:10	01:20	01:30	01:40	JARL	In Japan
8	Russia	UAØ	01:10	01:20	01:30	01:40	01:50	?	Locating site
9	China	BYØ	01:20	01:30	01:40	01:50	02:00	CRSA	Locating site
10	Sri Lanka	4S7B	01:30	01:40	01:50	02:00	02:10	RSSL	Shipped 9/96
11	South Africa	ZS6DN	01:40	01:50	02:00	02:10	02:20	ZS6DN	On the air
12	Kenya	5Z4B	01:50	02:00	02:10	02:20	02:30	RSK	In Kenya
13	Israel	4X6TU	02:00	02:10	02:20	02:30	02:40	U Tel Aviv	On the air
14	Finland	OH2B	02:10	02:20	02:30	02:40	02:50	U Helsinki	On the air
15	Madeira**	CS3B	02:20	02:30	02:40	02:50	00:00	ARRM	In Madeira
16	Argentina	LU4AA	02:30	02:40	02:50	00:00	00:10	RCA	On the air
17	Peru	OA4B	02:40	02:50	00:00	00:10	00:20	RCP	Ready to ship
18	Venezuela	YV5B	02:50	00:00	00:10	00:20	00:30	RCV	On the air

*The W6WX and KH6WO beacons are not yet licensed for 18.110 and 24.930 MHz operation.

**This beacon is still transmitting in the older format on 14.100 MHz.