4th UK Amateur Packet Radio Conference

List of Delegates

Apologies

G0FTD, G0TWN, G1KQH, G1YGY, G3LDI, G4DIE, GM4LNH, G4WYW, G6HJP, G7NBP, M1CUK

1. Opening Address

Proceedings began at 10:15am with a few words from Paula G8PZT, the conference organiser, who welcomed everyone and invited nominations for the posts of chairman and minutes secretary. There being no nominations, Steve G4FPV agreed to be chairman, and Paula volunteered to take the minutes.

2. UK Network Update

Representatives from various parts of the UK were invited to give a short summary of the current state of packet radio in their area.

2.1 Sunpac Area

G0WKL, chairman of SUNPAC in Dorset, explained that the group currently ran 3 nodes serving 3 BBS's and a DX cluster. The system was almost totally RF-based, and all nodes had been working well over the last year. The network mainly used Xrouter software, with which they were satisfied. Although they had a few Internet links, the group was keen to maintain an RF network. The main uses were BBS forwarding and DX cluster access. All the access ports were getting plenty of use. In Richard's opinion, packet radio in the SUNPAC area was stable, and certainly not in decline. There was a shortage of volunteers.

2.2 Gloucestershire Repeater Group Area

G0LGS, treasurer of GRG, felt things in Gloucestershire and surrounding areas were going downhill. The number of users had declined, and consequently, some systems had been turned off. Rental costs for 2 of the sites had quadrupled over the last 2 years, and the group planned to close them, as they no longer had the users to support the expenditure. There were still some DX cluster users, but the inter-cluster traffic was now carried on the Internet.

G4FPV wished to reassure everyone that they were not removing user access altogether. The policy had previously been to provide lots of local coverage sites, but was now to provide a smaller number of wide coverage ports. This saved rental costs and maintenance effort.

2.3 Maxpak Area

G0CNG, chairman of MAXPAK, reported on the status of the network in the Black Country and North Birmingham. The GB7MAX BBS and BLOX node had both Internet and RF connections. In addition, the group operated two major node sites, one using Xrouter on a 386 laptop, and the other running X1J. There were RF links to Newcastle, Corley and Kidderminster. GB7MAX had around 40 regular users, and GB7WAL had around 27. MAXPAK group membership had declined slightly over the last few years to 36, and the members were more local.

2.4 Kent IP Group Area

G4ZXI was one of the two remaining members of the Kent IP Group, which had disbanded 2 years earlier. Together with John G8JAD he had been keeping a couple of nodes running in Kent. These ran both IP and Net/Rom, and there was a link to GB7CIP in Caterham. This was now an Internet link, as all the intervening radio links had been lost. Their coverage area was the central Weald of Kent, and the north Kent / south Essex coasts. There was only one active user on 9k6 in central Kent, but they were picking up some new users in the north Kent area. Nick also ran the Sutton Valance Net/Rom nodes, which were heavily used for DX cluster. Activity in Kent had declined, but they were trying to promote it. UI-View was operating at Nick's QTH in Headcorn, and at Sutton Valance. Nick was also about to start an Echolink VOIP gateway. There used to be a very active user base in Kent, but it had declined with the arrival of broadband.

2.5 Coventry Area

G3ZFR reported that the Coventry node and BBS were still going strong, but many of the surrounding nodes had closed. The LANPAC group had folded a few years back, and much of the equipment was still available if anyone was interested in carrying things on.

There were still around 10 RF ports on his system. There were 3 user ports on 4 metres, 2 metres, and 70 centimetres. 4m didn't get much use, but 2m and 70cm did. There were links on 70cm to Wolverhampton, 23cm to Lickey Hills, and 70cm 9k6 to Jim G3OJI in Napton. Jim used to provide the main trunk to the southeast, but no longer had any links in that direction. Several people had expressed an interest in linking to him, but nothing had so far happened.

Roger's system had about a dozen regular users, plus a few casuals. The majority of the operation was users going in on 70cm RF ports and sitting on DX clusters all day long.

Roger indicated that within the next year the Marconi site in Coventry was going to relocate a few hundred yards away. Roger did not intend to relocate the packet nodes to the new site, so they would close.

3. UK Network Maps

Bryan G0SYR presented some maps of the UK NetRom system, which he had compiled by crawling the network. The maps omitted any IP or FlexNet sections, and any nodes that were deliberately hidden.

The first map showed only the RF links. There were extensive sections of RF network in Scotland, the SUNPAC area, the Midlands and the Severn Valley. There wasn't much in the south-west, although there might soon be, as there was a new BBS GB7COW, which was radio linked via G0RQL to south Wales. There was some RF linking around GB7LDI in Norfolk.

The second map showed both the RF and Internet links. Since last year there hadn't been a great deal of change, perhaps 5 percent. Some of the Scottish nodes were now linked by the Internet, instead of radio.

Bryan explained that the network had built up in 3 phases. The original radio links had, in the second phase, been added to by the IP network, originally centred on Internet gateways at universities and the BBC. Netrom was carried over the IP network between those gateways. The third phase happened when XRouter and broadband arrived, making it easy to link via the Internet without having to run Linux, so there was a huge expansion of Internet linking. Around half the nodes were now Xrouter.

It was noted that, without the Internet links, some of the RF sections of the network would be completely isolated, and probably unsustainable. Also noted was the fact that most DX cluster interlinking now took place on the Internet.

Anthony M1FDE pointed out that in Essex there were several RF nodes, typically TheNet X1J, set up on high spots by Raynet, which didn't have any fixed links at all.

In a recent automated network survey, Bryan had found that, on average, about 80 percent of attempted connections to the 200 nodes in his table were successful.

4. UK Network Management Forum

4.1. RF Node Network Issues

G1PLT reported that the north of Devon was quite well served by the NHTOR node, used mainly for DX cluster access. Users were not interested in extending the networks.

G1PLT expressed concern that emergency planners were installing hilltop nodes in amateur bands, without proper planning. These were hearing France, but not local traffic. He felt this forum should try to co-ordinate that network, and that council grants may be available for such a purpose.

On behalf of someone else, G8PZT asked if anyone could link NAPTON to the southeast. There were no replies.

Someone complained about obscure NetRom aliases, which gave no clue to the node's location.

G4FPV asked sysops not to formally relinquish 70cm frequencies because, once lost, they couldn't be regained. Some frequencies could legally be re-used for other purposes.

4.2. AXUDP Routing Issues

G8PZT was concerned that the proliferation of uncoordinated AXUDP linking was creating a lot of unnecessary routing information traffic, and wondered if we should try to limit the number of links and create a more geographically relevant topology? Although it was mainly Internet bandwidth that was being wasted, some people were charged by the megabyte, often with a premium rate for overseas traffic. The chaotic topology meant that traffic between UK nodes often went via overseas nodes.

G3ZFR felt that it was the route qualities that needed co-ordinating. If just one sysop used the wrong qualities, it would upset the whole network.

M1FDE suggested changing the software to make all Internet links dynamic, thus there would be no formal network. G8PZT replied that she was already implementing this within XRouter, but the concept might not be popular with sysops. In the short term however, we needed to make the existing network function as best we could.

G0SYR did not feel that the proliferation of links was a problem. He suggested that all UK AXUDP links should use a standard route quality of 100. This would limit a node's visibility to around 3 hops, and most of the country could be reached within 3 Internet hops. Links to other countries should use much lower values, so we would see the links but not the networks beyond them. If everyone used the same values, traffic would simply use the shortest number of hops.

G8PZT felt that 100 for a reliable link was too low, there being many atrocious RF links with assigned qualities of 150 or more. Setting the AXUDP quality too low would cause the AXUDP links to be ignored.

This sparked the RF vs Internet debate. On the one hand were those who believed that traffic should always use RF, no matter how poor the service. On the other were those who believed that, from the end user's point of view, quality of service (i.e. speed and reliability) was more important than the choice of transport medium.

G8PZT pointed out that, in some areas, the debate was irrelevant - either there was no broadband available, or there were no RF links because we had been priced off the good sites. In these cases we had to use whatever medium was available. Ours was necessarily a hybrid network, and our job was to make it work seamlessly, whilst providing the best possible quality of service.

G6KUI asked why users would need to connect over long distances anyway? G8PZT replied that it was mainly for real time chat, direct mail delivery, and accessing one's home mailbox whilst roaming. With the loss of BBS's, many users were now forced to make long distance connections to reach their nearest BBS.

A wide range of qualities was suggested. If the qualities were set too high, the node tables would be top-heavy with Internet nodes, but if they were set too low, perfectly good Internet links would be ignored in favour of slower and less reliable RF links. After much debate, the consensus was that a route quality somewhere in the middle of the range should be used, and a value of 120 was agreed.

However, this raised the problem of node table sizes. Some sysops had been using low route qualities to limit their table size. G8PZT stressed that we should stick to the agreed figure, otherwise, if anyone made a change, everyone else would be forever adjusting qualities to maintain table sizes.

BPQ and TheNet X1J node tables could not hold more than about 150 nodes. Xrouter could hold more, but large tables were impractical anyway. Long ago this wasn't an issue, as there weren't enough usable nodes, but nowadays we needed to limit table sizes. Some sysops were using MAXNODES to "cap" the tables, but this was not good practice. Some were using route qualities to adjust table sizes, but because we were advocating a standard route quality, it was necessary to use MINQUAL instead. G8PZT and G0SYR pointed out that it may not be possible to fit all the UK nodes into a reasonably sized table.

It was noted that the size of nodes broadcasts from XRouter to X1J or BPQ nodes could be limited by the MINTXQUAL parameter.

The recommendation for route qualities of overseas neighbours was 10. Such nodes should not take space in tables beyond their immediate peers.

Some people felt that AXUDP linking should be organised geographically, like in the RF-only days. Others felt that wasn't necessary.

Although large sections of the network could now use temporal metrics (i.e. round trip times), it was important to get the NetRom qualities correct, because some nodes can't use or propagate temporal metrics.

4.3. BBS Issues

G6URM asked if there was anyone interested in helping to establish an RF-linked BBS in the Plymouth area. G1PLT replied that a 23cm link with the existing network in Exeter may be possible. G1URM should contact G1PLT or G8GON if interested.

G4FPV felt that the hitherto structured mail forwarding system was breaking down because sysops were using the Internet to forward traffic over long distances. We were losing mail even though the links were largely still in place. Were we forwarding traffic correctly? Someone pointed out that a recent, and typical case of lost mail had been traced to a BBS closing down, and another sysop not noticing that fact.

5. A Voice Over Packet Radio Experiment

G8PZT described her recent experiments with transmitting voice via packet radio. Firstly, she outlined the basic principles involved in digital audio, e.g. sampling, analogue to digital and digital to analogue conversion etc. She then discussed the choice of sampling rate and quantisation levels, and their effect on audio bandwidth, distortion, dynamic range and digital data rate. She showed that it wasn't possible to transmit digital audio of sufficient quality over a 9k6 link without serious data compression.

There were several existing powerful speech coder-decoder (codec) algorithms, but most of them required a good understanding of mathematics, and a lot of computing power. G8PZT went back to basics and considered the physics of speech production. A single oscillator, namely the vocal cords, exited a resonant filter multi-pole filter system comprising chest, throat, oral and nasal cavities, plus head sinuses. The excitation frequency, amplitude, and the filter characteristics were under muscular control to form speech. Muscles couldn't move quickly, so over short intervals such as 10 ms, nothing would change much, and the whole system could be represented for that interval by just a few coefficients. It was only necessary to send the coefficients, not the whole waveform. The receiver could use the coefficients to synthesise an approximation of the original waveform.

There were many ways to decompose a speech signal into a few coefficients, and Paula outlined a few of them. The exciter-filter method was too complex, so for her experiments she chose to perform a short-term spectral analysis of the signal in 16ms blocks, the transmitted coefficients representing the amplitudes and phases of the 8 most relevant spectral components. At the receiver, the decoded coefficients were used to control the frequencies, amplitudes and phases of 8 software oscillators, whose outputs were added to synthesise an approximation of the original waveform.

Each 16ms audio sample was represented by 28 bits, giving a data rate of 8000 bps. 15 such blocks were assembled into 240 byte UI packets for transmission via a 9600 baud TNC. Unconnected mode was used because it would minimise the effect of lost frames.

G8PZT then played some audio clips showing typical QSO's, using a variety of voices, recorded via the system. The speech had a robotic quality, and there was an intrusive "babbling" sound in the background. Despite this, the speech was reasonably intelligible, and surprisingly the speaker's identity could easily be recognised.

The algorithms were very crude and could easily be improved in several ways. It should ultimately be possible to transmit intelligible (but not telephone quality) speech over 1200 baud links.

Finally, G8PZT explained that the experiment was purely for interest, and a desire to do something radically different with packet radio. However, with a little imagination, it would be possible to develop new applications, such as a trunked voice network in which the peers were digital and 100% wireless.

6. Living with a Radio Amateur

By way of light relief, Glynis Wilsden gave a humorous talk about what it was like to live with a radio amateur. The talk was Illustrated by various visual aids, and showed how strange our hobby sometimes looked to those on the outside.

Examples were the gobbledegook we talked, the bits and bobs which took over the house, the antenna experiments, and the way that groups of amateurs would go to a hill and squash into a small concrete box full of equipment, whilst the partner wandered around outside.

Glynis ended her talk by revealing her own callsign M3OAC, and saying that, if you ended up living with a radio amateur, it was best to join in and enjoy this wonderful hobby!

7. XRouter Developments

Paula G8PZT, the author of XRouter, gave a short talk outlining the work that had taken place on this project over the past year. Some minor bugs had been fixed, but the main change was the addition of a new "remote host" interface.

This allowed a wide range of packet radio and TCP/IP applications to be hosted by XRouter, not necessarily on the same machine. For example, a BBS could appear to be integral to the node, whilst actually being hosted on a completely different machine, at a separate site if desired.

Like the AGW host interface, this one used a TCP/IP connection between Xrouter and the application, but whereas AGW's protocol only handled connected-mode AX25, XRouter's used a socket paradigm, which could handle many other protocols, and was extendible. The project was in the testing phase, and hadn't yet been released.

8. The Future of Packet Radio

After a congenial lunch break, the delegates reassembled to discuss the future of packet radio. Was packet radio in decline, and if so, what were the reasons, and what could be done to ensure its continuance? As this was a long and involved debate, only the conclusions are summarised here.

The consensus was that packet as a whole had declined since its heyday, but was now more or less stable, with interest waxing and waning periodically. Some places were experiencing a slight revival, whilst in others there was little activity.

Mobile phones and the Internet, especially broadband, were felt to be the main causes the decline, because they occupied people's hobby time and increased the choice of communication modes (people who used to rely on Packet for communicating with their friends were now using email, Echolink, Skype, MSN etc). The Internet offered a greater choice of content, and was much faster than packet radio. Consequently, the amount of content on the BBS network had declined, because most amateur radio discussion now took place on the Internet! With fewer bulletins, there was nothing to interest the users, and with fewer users there were even fewer bulletins.

Another factor contributing to the decline was the high cost of site rental, which had forced many linking and access nodes to close. This in turn had been a factor leading to the closure of many BBSs, and without access to a BBS, many users had simply given up.

Systems and software had stagnated, leaving nothing new for sysops and users to experiment with. The basic BBS, node and client model had remained unchanged for 20 years. Once you'd got it working, there was little else to do. Sysops and users got bored, and left to pursue new challenges.

Attention spans were short nowadays. We had global chat systems, but they were underused because people were logging in, seeing nothing happening, and logging straight out again. They hadn't the patience to say something, or wait for activity.

There was a lack of publicity and up to date information about packet. Few people knew of its existence, or what could be done with it. Potential users hadn't a clue how to set up and use a packet station. Potential new sysops couldn't find the information to help them set up complex software. The RadCom data column tended to concentrate on the plethora of newer data modes, and the Practical Wireless packet column was to be discontinued.

In the old days many sysops started by running an unattended PMS, then gaining experience by using BBS software as a PMS. It was then a short step to running a full BBS. Nowadays, licensing restrictions discouraged people from running unattended systems, so fewer "users" became sysops. This and the lack of help had led to a dearth of new lifeblood.

It was agreed that packet radio in this country was worth preserving. In order to do so, sysops and users alike must take positive action, and not leave it to others.

Despite its shortcomings, packet had many selling points, upon which we needed to capitalise. For instance, Packet was like email and newsgroups, but purely for radio amateurs. There was no spam, no bad language, and it was totally free of charge. It was available in locations where no landline existed. It could be operated in noisy environments where speech would be difficult, and in very quiet environments where speech would disturb others, such as in the wee small hours when the family were asleep. The written word allowed one to re-read and re-compose the communications. And it was ideal for the microphone-shy!

Better publicity was required, to let people know that packet existed, and better education to show them how to get started, and help them progress. Delegates were urged to give talks at radio clubs and lectures at the Donnington rally, to write articles for radio journals, to put on demonstration stations, and to create web sites about packet. They should also offer their services as mentors.

To entice new users, and keep them hooked, packet needed to offer a wider range of services, plus new hardware, software and protocols to experiment with. The systems must be improved to increase the speed and reliability of connections, and a major improvement could be effected by the use of full duplex access points. We needed to get away from the single-stream "pull" model, and make more use of multiple concurrent streams, "push" and multicast, with links that were "always on".

Some possible new services suggested were real time weather data, propagation information, thunderstorm data, Echolink chat, email, DX alerts, and multi-user dungeons.

We needed a wider variety of innovative and intuitive packet clients for the latest versions of Windows, with fresh ideas such as a graphical interface to the node and BBS network. A degree of plug and play was required, whilst at the same time allowing experimentation.

Finally, everyone could do his or her bit to increase the content level by sending a bulletin from time to time, gating traffic to and from Internet-based special interest groups, and re-issuing some of the original packet content which hadn't been seen by new users.

In order to tackle these issues, it was resolved to set up a "Packet Development Task Force". The "datacomms-uk" Yahoo group would be used to keep in touch, and the information would be gated to packet.

9. Any Other Business

9.1. WiFi Packet

There was some discussion about the use of 2.4GHz "WiFi" devices for amateur data communication, which had recently become easier due to the availability of new hardware. The lower 7 channels of this system were within the amateur 13cm allocation, and quite respectable distances could be covered using the higher powers and high gain aerials available to radio amateurs.

G1PLT reported that he was using up to 70 watts, and could reach an access point 18 miles away under wet band ducting conditions. He also said that USB "dongles" could be mounted at the top of a mast, using the new 25-metre USB extension cables, and a wok could be used as a parabolic reflector.

G8PZT could appreciate that it was AMATEUR radio, but to her it didn't seem like PACKET radio? It was just wireless networking with more oomph. Someone pointed out that the amateur callsign is converted into a MAC address and used for security purposes.

Someone posed the question, "Does someone have to be licensed in order to read bulletins?" G1PLT replied that amateurs were not allowed to transmit to unlicensed stations. Versions 802.11b and 802.11g were much easier to control than the original 802.11a, and there were plenty of interesting tools for Linux machines.

G6KUI suggested, with reference to the earlier discussion about full duplex, using 2.3GHz WiFi as an output, with input on 2 metres at a slower speed.

M1FDE complained about the requirement for amateurs to ID their WiFi systems in Morse or speech. It would be nice to be allowed to ID in ASCII. Paula asked how one would do CWID on a spread spectrum system such as WiFi? G1PLT said that it should ID on the centre frequency of the channel, but it was very difficult.

The Flight Refuelling ARS website was mentioned as a good source of information on WiFi networking.

10. Closing Address

It being almost 5:30 PM, the chairman thanked everyone for coming, especially those who had travelled great distances, and wished everyone a safe journey home. He observed that everyone had enjoyed chatting over coffee and dinner, and said he hoped it had been a successful day.

Geoff G4AFJ thanked Steve and the Fourpak team for organising the conference, pointing out that these events didn't just happen. A spontaneous round of applause followed, and the delegates gradually departed after further informal chat.

Copyright (c) 2006 G8PZT