The 2005 Kure Dxpedition K7C will make use of a team of Relay Stations. This document is a brief description of the Relay Station and what it will do.

The Relay Station is similar to the classic Pilot Station. The Pilots were invented by John ON4UN to assist with managing the information flow between individual DXers and the DXpedition team. The Pilot acts as a center of attraction, and a filter. The Pilot has access (through prior arrangement, say private unannounced frequencies) to the DXpedition, and DXers look to the Pilot for the latest information on the operations, well-being, and plans of the team. Most large DXpeditions now assemble a small team of Pilots, and in some cases the Pilots have been extremely valuable in making the DXpedition a success by avoiding duplication and interference.

For Kure K7C, we are developing a new tool, the web application DXA. In the simplest approximation this is a website that will provide quasi-real-time information about the DXpedition of interest and value to the DXer. For instance, the DXer would like to know if he is in the log, and on what bandmodes. He would like to know what bands are currently active, which area of the world is being worked currently, what other stations have recently been logged, etc. DXA will provide this and similar information on a website that is seen with any browser—no software needs to be downloaded or installed. The following shows a typical screenshot of DXA in operation.

The various modules on this screen are generated from data stored in the central DXA website databases. In this screen we present the last callsign logged, the total number of QSOs logged by the Dxpedition so far, the last 10 stations logged, the bandmodes currently active at the DXpedition, and a table of bandmodes for the individual DXer (who is logged in as VE7CT here). The bandmode table shows a green square for each valid entry in the K7C log, thus giving the DXer an immediate visual representation of his entries in the K7C log.

The information on this screen can be updated within seconds, under the control of the DXpedition or the DXA central site administrator. Thus, what the DXer VE7CT will see is an initially blank table. Very shortly (less than a minute) after he makes a QSO with K7C, one of the green lights goes on. This requires no action on the part of the DXer—the light is turned on remotely by DXA.

Here is another screenshot of DXA:



This is a “media” screen, providing a slideshow, audio tracks, and video clips. Some, or all, of these can run automatically, without request or intervention by the DXer. Alternatively, this content can be set to require a trigger (click) before running. Note that the same bandmode tables seen on the previous screen are present on this one as well. The thumbnails on the left side are navigational links, providing the DXer with the ability to choose a screen that contains mostly information of a kind of interest to him. Each DXer will be able to log in separately, and will see a set of screens that he can choose, and to some extent, interact with, control, and modify.

The media content are supplied to the central DXA site for serving to DXer clients. Some of the content is prepared before the DXpedition, and some will be generated during the DXpedition.

Here is a pair of screens showing the angular intervals to the main continental areas.

This (preliminary) screen shows an azimuthal-equidistant plot centered on Kure. The graph shows the number of logged QSOs for each of the seven major continental regions. The plot and the graph change automatically as the information is updated. The DXer can click on various areas to select options. For instance, clicking on the continental maps above will shift the graphic to a picture of the globe showing the grayline, and further clicking will select other options.

The graphs may be generated from real-time data (such as the bandmodes currently active, the operators, the signal strength of the NCDXA beacons at Kure, etc.), or it might be quasi-real-time (such as the QSO rate averaged over the past 5 minutes, or the distributions of QSOs in call area, etc.), or it might be partially archival (number of logged QSOs compared with number of licensed amateurs, etc).

The data and other content might be generated directly from Kure (such as the callsigns as they are logged, the beacon strengths, etc.), or it might be generated and archived prior to the DXpedition (such as a video interview with a team member, a photograph, etc.), or it might be generated during the DXpedition (such as a video clip of anyone actually working K7C from their home QTH), or it might be some combination.

Here is another screen:



Here you see the azimuthal equi-distant projection of the Earth, together with the last 100 callsigns logged. The callsigns of the last 10 stations logged are placed near their (presumed) QTH, together with a line connecting them to Kure (above image is a draft that is not yet properly displayed). The areas of best signal from Kure are shown color-coded (red the strongest, etc0. This chart is updated as fast as we log stations, and the signal plots change with the hour.

The purpose in showing all these screen of DXA is to suggest that what we display is entirely up to us—we control the display in real time, and we can use any content we can generate, before, during, or even after the event. Here are the central criteria for the content:

1. We should avoid generating content that requires a high-bandwidth upload of lots of data from the K7C site, because we can’t afford the satellite time. Instead, we can design schemes in which a minimum amount of data is uploaded and used as a key to trigger the distribution of large content. For instance, about a month ago I sent out a description of a scheme in which the Kure site sends a key to arrange for an on-air interview on a secret frequency. The Relay station does the interview and records it, then sends the audio file to the DXA central site by normal internet. The webmeister then puts it into the right place in the DXA site, and it is automatically served to clients when they log into the DXA site.

2. We should concentrate on delivering information that is of most interest to the DXers. This includes the current status and logging data, but it might also include interviews with team members, advertising, and other content that the DXer will find interesting. In other words, we need to think carefully about what we want to capture and generate, in relation to what we think the DXers will want.

3. The Relay Stations will need to have some capability to capture or create data in presentable format. Presumably this means an audio recorder to get on-air audio tracks. It might mean graphics-generating capability (plotting, graphing, image processing, etc) to prepare material for dropping into the DXA server ready to be served. The more the Relay knows about websites the better, but it’s not essential to be a web programmer.

4. There will need to be considerable organization/oversight for the Relay team. It will fail if the relay isn’t prepared to generate material. He can find the material on air, or by analysis of data plus graphing, or by telephone or video interviews. Recording a video clip of someone working the K7C pileup would be interesting. But every Relay team member needs to “get it” about what he will do. I would recommend everyone give the team leader (VE7CT) a short run-down on their individual capabilities, understanding of what is to be done, etc.

5. There is considerable value in having the Relays spread over the areas of BEST propagation, not necessarily the areas of most population and certainly not a democratic distribution of the world’s zones. If you look on the last image above (and see it live on the DXA website), you will see that the areas of best signal are generally around the Pacific rim (not surprisingly). Europe (as we already know) is weak, so it would be less desirable for a Relay stations. So let me say again, the relays should be in areas that are most likely to have good signal strength, to enable us to implement actions like the on-air/off frequency interview. Detailed study of the propagation predictions will show the areas most useful for the relays. That said, it is still useful to have relays ANYWHERE, so I would not turn anyone down who wanted to do it. In fact, in Europe, it would certainly be good to have several, since we know very well that southern Italy and Northern Sweden are worlds apart, radiowise.

In summary, here is a set of steps for the Relays:

1. Understand clearly the purpose of DXA, and what kind of content we want to show on it.

2. Imagine that you are tasked with generating some of the content. Do you know what to do and how to do it?

3. Try some little practice runs. Go after some content you think would be of the kind that DXA will want. Capture or generate it, and forward it. Generally chunks of 1 MB or smaller are preferable. A 100MB video file will be unworkable. As much preparation, editing, cleaning, etc. as the relay can do before forwarding it will be wise, since we expect the webmeister to be swamped during the battle.

Any question, suggestions, etc. contact VE7CT