Tools constructed by radio amateurs

2.6Tools constructed by radio amateurs

It is true, on the other hand, that Hams may have been, at some point, developing our hypothetic ‘ideal radio technology’. Doing the minute work of trying out multiple possibilities within the realm of the respective radio propagation approach, the Ham community would have perfected the technology up to a point where it is not that interesting for them, but its easiness of use would make it suitable for the public domain. That suitability may not be entire, the public domain may adopt on a large scale just the reception part: cheap, easy to install radio receivers. In fact, as we have seen, the various bands pioneered by Hams, followed exactly this path, pioneering research was finished, technologies got perfected and transferred into the public domain.

By considering the ideal radio technology, we have contemplated an artefact that the radio amateurs would not be interested in. What then, are radio and non-radio artefacts created by Ham, and why were they created? What is it that constitutes for Hams an appropriate tool? What is it that helps them in the their quest for new and improved radio communication? How are these tools created? How are they disseminated inside the community? What is, in HCI jargon, their design rationale?

Once we have learned a bit about members’ motivation for radio work, looking at the design of several Ham artefacts can serve our interest in design for amateur communities, as we examine how the members’ motivations translate into designing tools and technologies. In this section we will consider the design rationale of tools that were developed by the radio amateurs.

An interesting question can be raised on why these tools and technologies (and not others that were proposed) achieved ‘critical mass’ within the community. Critical mass is an old theme in CSCW in relation to the adoption of new applications by a ‘mass’ of users large enough for the application implementation to succeed (e.g. Grudin 1988). A possible answer to this question can already be given in terms of what we learned so far: as any contribution, tools, technologies and other solutions are reviewed by other community members in a continuous research-like, experimentation process. If a Ham operator decides that a new tool that he or she learns about deserves experimentation (usually by local emulation of the respective contribution, followed by tests), that is already a sign of ‘good review’, which will improve further as experiments succeed according to the Ham performance criteria (good transmission quality, low power used, etc).

2.6.1SSB

SSB is a prototypic example of responding to community concerns via design. Fundamental concerns of Hams are addressed: sparing of emission power to achieve high performance, sparing of bandwidth to achieve a large number of communication channels in the band. SSB also offers an example of technology that will probably never reach the public domain (another example is EME). Since it distorts the voice a bit, SSB is not suitable for public radio or general-purpose communication; some exercise in listening to SSB is needed. SSB was, though, adopted by other radio services such as in the marine, due to its efficient transmission.

The rationale of SSB is obvious in the light of community values. When looking, with SSB as reference, at other transmission techniques, we will have to resort to more subtle examination in order to understand their rationale.

2.6.2Connection opportunity notification tools

2.6.2.1Beacons

Beacons are radio automatons that keep transmitting a certain message on a fixed frequency. When a remote beacon is heard, operators know that there is a good propagation in that direction and that if they start making calls on that frequency, they may achieve high performance QSOs.

Like repeaters, beacons are used in non-Ham areas as well. Hams have their own frequencies so they need to install their own repeaters to ‘re-transmit’ them. This is not necessary for beacons: if a beacon is heard on a certain frequency, it is enough to infer that there is good propagation on Ham frequencies close to the beacon’s. This is yet another example of Hams using public resources to achieve their goals.

2.6.2.2DX cluster

DX cluster is a software tool employed by the DX operators to find out about the possibility to communicate with the rare destinations. The DX cluster is an Internet server where operators connect to register a DX connection that was just achieved. All other connected users are notified by a beep and, if their conditions are similar to those of the announcing Ham, they can choose to attempt a connection with the operator located in the rare or remote country. Thus the DX cluster helps the task of “announcing as many operators as one can” about the potential of realising remarkable connections.

Before Internet service providers were available, connection to the DX cluster was made via Packet Radio (a data transmission mode developed by Hams). Nowadays connecting to the DX cluster may involve no radio at all; simple remote connection software can be enough.

2.6.3Artefacts for traffic support

Besides notification tools, a number of other artefacts are employed by Hams to support their core activity: work on radio traffic.

2.6.3.1Specialized maps

We have already encountered maps centred in the operator location, which help orientate the antenna with more precision. Such maps are mostly used in SW traffic. Other maps used are used to look up the encoded Ham locators which were designed to convey fast and precisely one’s location.

2.6.3.2Lists and websites

Many operators possess a list of addresses of operators from their country. When hearing a call sign, they may choose to look it up to find out more about the name and location of the designated radio amateur.

The paper-based lists are gradually replaced by web pages. While waiting for a connection opportunity, some of the informants used to browse the Web and to look for the call signs heard. Finding which country a call sign comes from is much easier on the Web. The websites also have the advantage that they are dynamically updated. They also contain more information that can be of importance in high-performance traffic. For example, we found out that the operator heard from the Balearic Islands was working in the local airport, and was originally from USA. It is more motivating to have a QSO with a high performance operator, so the possibility offered by the Web to find out about the achievements of a possible connection peer is important.

2.6.3.3Moon-following software

EME operators employ various Ham-made or public domain software for finding out where the moon is. Such software tells whether the moon is up, when it will be up, on which direction and on what angle should the antenna be orientated on the vertical plane, in order to beam to the moon. Certain software made for education in astronomy fits well for this job. During EME traffic, such software is consulted regularly to see if the antenna is well-orientated or if it needs a bit of rotation.

2.6.4Combination of technological means for amateur radio ends

As seen also in the communication media discussion, none of the artefacts encountered performs a task that would automate an operation that is too close to the operators’ main challenge of exploring connection-related possibilities¹¹. In fact, when such automation can be made reliably, radio communication in the respective domain will probably not be of interest for Hams any more. On the contrary, when traffic still depends on the weather, on the uncertainty of a new principle’s experimental character, on the chance of finding a DX opportunity, the interest remains, and no tool can be constructed to address such uncertainties.

Instead of addressing these uncertainties, most of the tools we have discussed are supporting the operators, easing work of secondary importance. It would be cumbersome for an EME operator to compute the moon orbit every time the signal from the moon fades and the antenna needs re-orientation. In a similar manner, using a world map available in a geographical atlas instead of a Ham-specific map would give distorted angles for antenna rotation, requiring complicated corrections.

We are thus seeing a clear delimitation between contingencies that are kept for the members to address (and which can hardly be addressed by machines anyway) and contingencies related to human error in domains that are not of interest (geographical calculus) or contingencies related to lack of information or lack of memory about call signs, etc. This suggests that such delimitations can become important when designing artefacts for amateur settings.

Download 0.67 Mb.

Share with your friends: