This record of the proceedings of the above event has been compiled by Mike G7RAZ, to whom corrections should be sent (either by packet to G7RAZ@GB7WIS.#22.GBR.EU or by email to MikeWager[at]aol.com).
These minutes are not intended to be an exhaustive account of the proceedings, and readers who would like more details are asked to refer to the PowerPoint presentation files
Mike, G7RAZ (Minutes Secretary)
| G0CNG | Chris | |
| G0EWH | Richard | |
| G0OJR | Barry | |
| G0RDI | Iain | |
| G0SYR | Bryan | |
| G0TWN | David | |
| G0WCI | Mark | |
| G1DVU | Martin | |
| G1YGY | Chris | |
| G3OJI | Jim | |
| G3XVV | Malcolm | |
| G3ZFR | Roger | (Chairman) |
| G4APL | Paul | |
| G4DIE | Ian | |
| G4FPV | Steve | (Conference speaker - item 5) |
| G4LZV | Keith | |
| G4OAR | Neil | |
| G4ROA | Adrian | |
| G6KUI | Pete | |
| G6MJN | Debbie | |
| G7BNK | David | |
| G7RAZ | Mike | (Minutes Sec.) |
| G7VBJ | David | |
| G8PZT | Paula | (Conference speaker - item 2) |
| G8SFR | Steve | (Conference speaker - items 3/4) |
| M0PZT | Charlie | |
| M1FDE | Ant | (Conference speaker - items 1/6) |
| MI0BME | Pete |
EI3DIB, G1FEF, G1KQH, G1PLT, G1TLH, G1ZPU, G3LDI, G3ZYP, G6KHW, G6TJZ, G8HQJ, G8MNY, GM3YEW, M1CUK
The Conference began at 10.30am and Roger G3ZFR welcomed all present, expressing his thanks to those who had helped him convene the event, including the DCC for their contribution towards the associated costs.
Roger offered his services as Conference Chairman, and was duly elected as such. In similar vein, Mike G7RAZ was appointed Minutes Secretary.
Roger proceeded to invite the speakers and chair the debates.
The first presentation was a talk and demonstration by Ant, M1FDE of a project that combined two elements from last year's conference. He showed us how an item of hardware - the "Arkwright's Till" - had been built into a 1U case and set to run with XROUTER software - see last year's conference notes for further details on both.
The project is therefore effectively a large tnc, being an 8 Port TNC/Router, with 4 modems, an Ethernet interface, but with no fans or hard disk. He uses it as part of his combined radio and Internet LAN.
Ant described its advantages as having remote capability, running with low noise and on low power, being reliable, and having capacity for future experiments.
His design comprised a front panel with power & reset switches, a FDD drive (not necessary, but useful for testing), a Compact Flash card slot (for the system software and configuration settings), and LED's to indicate system and (eight) channel status.
His use of a Compact Flash card gives the equivalent of a bootable IDE disk, is very fast, uses low power, and is removable. With it, it is easy to load software and backup disk images (e.g. using "Gemulator Explorer" for Windows). CF to IDE adaptors are available at reasonable price from TAPR or online from linitx.com.
Ant went on to outline certain PSU requirements, Ethernet interface considerations and modem specifications (with 4 ports being data synchronous, and four being radio-ready), and spoke of the value of using XROUTER as the node/routing software.
The state of the project is quite advanced. The hardware is nearly all tested, the router works on air, and he can connect over LAN via telnet from WinPack. Future plans include testing G8PZT's support for Arkwright SCCs, and devising a control interface for RC748 transceivers.
Sketch schematics and Arkwright register maps are available on Ant's website (see below)
Internet resources:
| XROUTER | http://www.g8pzt.pwp.blueyonder.co.uk/ |
| Arkwright till | http://www.tvipug.org/arkwright/arkindex.html |
| Linitx web page | http://linitx.com/ |
| Chelmsford ARC | http://www.g0mwt.org.uk/ |
| M1FDE home page | http://homepage.ntlworld.com/mtn/ |
| Email address | m1fde @ g0mwt.org.uk/ |
Powerpoint presentation (780 KBytes)
The second presentation was a technical description of "Reed Solomon" Forward Error Correction as used in XROUTER, by the software author, Paula, G8PZT.
Introducing the usefulness of FEC in packet links, Paula observed that the UK packet network is performing nowhere near its theoretical capacity, with the major limiting factor being packet loss - typically 10%. The reasons for this are many - poor signal/noise ratio, fading, flutter, de-sense, QRM, etc - not counting media access errors.
Although packet protocols can work with this, it does represent serious loss of throughput, and datagram mode TCP/IP becomes unworkable at these rates. Simply raising speed will not help. The problem is that a single bit error causes the loss of a whole packet. Error correction by repetition is highly inefficient when bandwidth is so limited. However, by using FEC, an unusable link can be turned into a good one.
Just as the brain is able to decode words with minor spelling errors in them (by looking at their context), so FEC sends extra "contextual" information along with the packet data, allowing the packet to be reconstructed if it is damaged.
Paula outlined a variety of FEC methods, but highlighted the benefits of the "Reed-Solomon" method, whose theories are already in use in the field of CDs, DVDs and cellular phone technology. Although the method is computationally intensive, requiring intensive CPU activity or special hardware, it performs well in correcting data errors.
In Paula's XROUTER, the FEC works by encoding AX25 frames plus frame relay header into Reed-Solomon code words, giving an error correction capability of 8 symbols. Code words are encapsulated in normal HDLC for transmission on physical layer. Then, upon receive, HDLC CRC is ignored and the (possibly corrupt) codeword is decoded to an ax25 frame.
The improvement over non-encoded links was illustrated and shown to be the equivalent of an increase in signal-to-noise ratio. This improvement applied to both short and long packets.
Packet stations who are not running FEC will see the additional parity bytes as additional data, leading either to a failure to decode or possibly to corrupt node broadcasts or inaccurate APRS positioning. Therefore FEC should not ideally be used on a shared channel.
The additional packet contents do represent a protocol overhead (approaching 10%) but this bloating is fully justified given the considerable cost in bandwidth usage of retransmission of failed packets.
Those wishing to implement FEC would need the following soft/hardware: the Xrouter program, an SCC card, or YAM modem, or a TNC with modified BPQKISS firmware. Note that some TNCs using an RUH modem may require a squelching mod unless RS232 data rate is high. It would also be possible to use a Baycom modem provided their driver program was modified.
FEC has been tried over several poor RF links and on a link simulator. The conclusions of early tests have been positive. In every case the reduction in packet loss and improvement in link throughput has been quite dramatic. One notable example was that FEC enabled a TCP/IP link to run datagram-mode, where not even AX25 could get through.
Paula highlighted the protocol's limitations, most notably that not all link problems can be solved by software alone. FEC cannot correct heavy distortion, severe QRM, etc. Such engineering problems must be solved first. Also this version can't use BER worse than 1 in 100. Stronger FEC cannot be used, either, because of mis-framing problems. And G3RUH modems cannot be used without modification to the TNC.
However the author plans to develop the concept further. By using suitable hardware, it should be possible to dispense with HDLC framing and use embedded sync data. Stronger FEC should be possible, too, along with techniques such as concatenation, cross interleaving, etc. Adaptive coding is also envisaged - using stronger FEC methods when a link degrades and vice versa. Support may also be forthcoming for other L2 protocols, eg. Frame relay.
Powerpoint presentation (203 KBytes)
The third presentation was a talk about the process of applying for Internet Voice gateways - the means by which amateur voice communications can be linked over the Internet to gain wider coverage than the standard voice repeaters.
The talk was given by Steve, G8SFR (one of the DCC representatives present) who began by observing that Voice Internet linking - a recent phenomenon, having started around 2000 - had become more popular than he had ever dreamed. This increase in popularity had led to many applications from amateurs wanting to become "gateways".
Initially applications via e-mail had been the norm, but in response to the increasing number of applications, the DCC soon changed the application system to an online system (at http://www.dcc.rsgb.org). This had worked well for a couple of years, but applicants were often found to have misinterpreted the instructions and had become confused about which information was to go in which box. Steve wanted his talk to be an attempt to clarify the situation.
The first considerations to be addressed by any potential applicant - before making the application - were "Is there a need for my gateway?" "Can I share an existing frequency with another gateway on a time sharing basis (day/evening, etc)?" "Is the frequency I have applied for clear in my coverage area (have they listened on air)?"
Secondly, when filling in the online application form, applicants should take care to fill in all the required fields accurately. Particular care is needed with the blue boxes in which only numbers must be entered. Remember also that an accurate 6 figure NGR locator (eg. TQ628411) must be supplied.
The application is processed as follows: a copy of application is sent to the applicant's e-mail address as an initial check of validity. The DCC then looks at the application, checks it for accuracy, and for conflict with other gateways (often by simply checking with local maps). If there is another gateway within 35/40 kms of the applicant's station, then the application is rejected. Steve highlighted the problem of a user of one gateway being relayed by another gateway. If RF is received by two points then there will be double relaying - and if the two gateways have radically different systems then there will also be a delay in audio being relayed into the chat rooms. (This may be addressed one day and perhaps solved by use of CTCSS being made a condition, and thereby guaranteeing unique access).
The application, if approved, is then forwarded to the RA for further licence checks and final issue. If the application is rejected, the applicant is informed and the application is deleted from the system, pending a response from applicant. After 3 months the application is finally deleted, during which time appeals may be considered (eg. with further circumstances being offered for consideration).
Operators of gateways are requested to read all the schedule to the NoV. Further, they should ensure that their radiated power levels are within the ERP limit of the NoV, trying to use less power if possible. Deviation must be kept within the limits of the NoV, and operators must ensure they only operate the gateway when in attendance - defined by the RA as being within earshot of the station.
Steve mentioned certain considerations regarding the future of Internet linking, referring to a recently-held review whose outcomes are to be publicised in near future. In particular there has been concern expressed over people who get an NoV then sit on it. Steve indicated that it may become necessary to ask for all stations to re-apply for their NoVs, in order to clear out such unused applications.
On other matters, the guiding document will always be NoV not BR68, and unattended operation - whilst not ruled out entirely - is not expected in the foreseeable future for 70cms, given the block on applications for clearance within this band. It may be - as a consequence of this -that more other bands may become more commonly used (2m, 6m, 10m etc).
Finally Steve referred to an ongoing discussion about access to Echolink software, as well as to the fact that from the end of 2003, all packet applications will be done online - applications will be otherwise be sent to RSGB who will type it in for the applicant.
The fourth presentation took the form of Steve, G8SFR, remaining on his feet to update the conference about the 70cms situation.
At the beginning of July RA had said that the Primary User (the MoD) would process no further applications for clearance until further notice. The existing 12 radio amateur applications were halted and had now been returned to the applicants. The RA cannot comment on the "until further notice" clause...
With this block on applications in force, Steve said he would not be processing any new applications, and would be returning any 70cms applications to the applicant. The rest however will be dealt with in the normal way.
The 70cms position is still unclear, but Steve indicated that it is not only the amateur bands which are being caused havoc with - the RA were recently told that they will not be able to issue PMR frequencies in UHF band. Their processing time has increased considerably, and as a consequence radio amateurs will be lower down the priority list.
There is a possibility that we may no longer have access to 70cms on an unattended basis, but existing users should continue as they are, maintaining levels of usage.
Changes to existing 70cms clearance agreements is possible; administrative changes, such as changes of callsign or address may well go through without a hitch, but remember that the distance with which stations can be moved (without the need for new clearance) is short.
Also if you have an NoV (or are a station holding a letter of Clearance) you should be aware that in the event of your "B" callsign changing to an "A" callsign, your NoV (or Clearance) becomes invalid. In this circumstance you should contact the DCC, and a letter of authorisation will be issued.
After lunch, the fifth event was a talk by Steve, G4FPV, which in part followed on appropriately from Paula's FEC talk, as it dealt with error correction on trunk links (most notably full duplex 9k6 links) from a hardware point of view.
Steve reinforced Paula's point about the need for FEC, given the weaknesses implicit in AX25. In a link with Maxframe set to 7 and Paclen to 255 there can be a burst of some 14280 bits. Merely one error loses you the whole series, and all 7 frames may have to be re-transmitted. Normally an error figure of as low as 1 in 100,000 is required for satisfactory links.
Steve reiterated the theory of FEC - the addition of "parity" bits, the binary encoding of these bits, etc, - adding the reminder that such extra data thereby reduces the space for real data, but that the reduction in packet retransmissions outweighs this apparent loss of packet space.
An additional method of "interleaving" can be employed to combat bursts of errors caused (for example) by ignition noise. By this method, the data is loaded into a matrix row by row. Each row is then a complete FEC block, which is finally transmitted column by column.
At the receiving end, the received bits are stored in a matrix column by column. Up to 7 bits can be missed and there will still be only one error in each FEC block when the bits are read out row by row.
A hardware implementation of this method is at project stage currently, and there may be a possibility to develop this so that it becomes a physical replacement for an RUH board (e.g. on a disconnect header).
Powerpoint presentation (42 KBytes)
The sixth event was a report by Ant, M1FDE on the "Hinternet" (WiFi multimedia backbone) project, set up by the ARRL, which aims to provide an amateur version of the internet in the USA, meeting FCC rules and providing multi-mode QSOs, real-time communication, emergency communications, simultaneous voice, data & video QSOs Using the IEEE 802.11b standard, this ARRL task force wants to use it especially on 2.4GHz.
Using ARRL's own publicity presentation, Ant showed the aims as being the establishment of a High-Speed Multi-Media (HSMM) network, offering point to point contacts, multi-point contacts, live full motion (full duplex) colour video links, full duplex FM-quality voice, as well as remote control of amateur stations.
High-speed data exchanges are, of course, currently available over Internet in US as over here (voice over Internet protocol, Eqso, Ilink, Ecolink, IRLP, WIRES, etc, callsign lookup, DXcluster, APRS, etc) but the aim is to make the HSMM network radio-based. To this end, the ARRL have set up a project, covering an area of some 1.8 miles in Livingston County, Michigan, in which experiments with HSMM are currently underway.
The components required for participating in this experiment were outlined as; a PC or PDA, an RIC (our wireless LAN card) or access point, an optional amplifier, an antenna, a camera, a microphone, and speakers or headphones.
The PC could be of any type, running any OS, but having a microphone, and video interface (e.g. a web cam, a digital camera in live mode, a VCR/DVD, etc.)
Various items of usable hardware were also illustrated. For example, there was a HSMM "handheld" - a Dell Axim PocketPC, equipped with a Compact Flash Card and (Open Source H232) VideoPhone Application.
Similarly illustrated were a Cisco PMCIA card, a Dlink Access Point, amplifiers, and appropriate antennas such as a 24dbi parabolic reflector.
The channels used were outlined (from 2412 MHz through to 2442 MHz) and delegates were shown pictures of amateur uses of HSMM, such as remote control of radio balloons and amateur TV. The H323 software (available as open source) for both Windows and Linux was referred to - as was the feasibility of using such applications as "Net Meeting" and the like.
ARRL envisaged further deployment to include emergency applications, gaming (e.g. chess), satellite link-ups, AMSAT, amateur HDTV, etc. Additionally, an "HSMM over HF" project (10 and 6 metres) would hopefully be at a demo stage in 2004.
Powerpoint presentation (2.2 MBytes)
As a post-script to the talk, David G0TWN informed delegates that he was conducting tests using WiFi in Milton Keynes, and invited interested parties to find out more and follow his progress at the following web address:
http://www.taurus2.plus.com/gb7imk
The final talk to the conference was given by Phil, G4CFG, and centred on experiences and observations related to the ongoing "F1BIU" 23cm data transceiver project.
Further to the DCC appointing a hi-speed coordinator and commissioning research into associated hardware, Phil had been led to look into the F1BIU transceiver.
He outlined the sources of the various components, estimating that costs so far incurred totalled £365 - and a lot of work! Certain construction hints were passed on, relating to the size of box used, cutting of tracks, change of capacitor from the original design. Phil also outlined the methods for the transceiver's alignment.
In conclusion he observed that there was little urgent demand for high-speed radio links, now that permanent Internet connections are cheap, and that the F1BIU project had lain dormant for a while. Nonetheless he hoped that the presentation would rekindle some interest in the project.
Powerpoint presentation (20 KBytes)
The final section of the Conference was devoted to discussions of certain areas of topical interest, these being chaired by Roger G3ZFR.
By way of introduction, conference was reminded that international packet mail had traditionally been carried by a small group of (GB7) mailboxes, using a combination of HF and amateur satellites. The number of these BBS's had dwindled and there was now only one which used satellite, namely GB7LDI in Swardeston, Norfolk.
GB7LDI's sysop (Roger G3LDI, the sponsor of the discussion) reported two issues; firstly that his link with the rest of the UK was suffering difficulties because of an absence of suitable nodes, and secondly that the amount of personal mail had dropped off (probably due to BBS's now forwarding mail by internet). Although unable to attend the conference, he wanted the future of his satellite operation to be discussed.
Conference's discussion reflected the full range of views within the packet community. Support was expressed in strong terms for Roger G3LDI's commitment to keep using this aspect of amateur communications, but many felt that mail via satellite had had its day. It was clear that the number of BBS's wanting to establish overseas internet links would continue to grow, but it was hoped that sysops would continue to support radio-based links (notably over HF) given that RF communications should be our prime interest.
Some discussion turned to the urgency of messages' content. It was noted that some mail could take three days to get to the States - and that since satellites only passed over locations a few times a day (and had occasionally proved unreliable) it was possible that mail could suffer undesirable delays. Internet links, it was observed were faster and more reliable and users expect a network that works, and have little interest in the means of a message's delivery.
It was felt, however, that no messages sent over packet should be particularly time-sensitive and that small delays were not likely to worry the majority of users. However an apparent majority of delegates felt that a network that combined Internet and RF links was the best compromise solution for effective mail transfer.
Conference heard that G3LDI is currently investigating a better RF link across Norfolk, in order to establish better contact with the rest of the packet network, and delegates wished him success in this venture.
It was felt that data communications were to some extent moving towards real-time exchanges, (Eqso, VOIP, DXclusters, convers servers, etc) for which the Internet is a more suitable assistant, given the slowness and unreliability of the RF network links. The loss of hilltop sites, as well as other local factors, was cited as a reason for the poor state of the packet network.
There was significant support for the Internet as a means of linking where no realistic RF possibility existed. Although many amateurs are using it as a replacement for RF, Internet linking had meant that many others had been able to keep in touch with other amateurs via a combination of landline and RF - and therefore their interest in amateur radio had been sustained.
Support was also voiced for a new system of regional mail hubs - interlinked by internet-and-radio BBS's who would have these responsibility for further distribution. Mail could then be sent with more confidence to these regional hubs, which would be better informed as to how to reach the intended targets than sysops are currently.
This brief discussion centred on the possibility of contacting (GB7) mailboxes via commercially available ("WAP" enabled) mobile phones. G6KUI raised this, as such linking is theoretically possible, given that many BBS's currently have (landline) telnet access.
The problems centre around the nature of the commands sent from the mobile phones. The "WAP" commands are a form of HTML, but the commands are not completely compatible even with HTML/HTTP-enabled BBS's. Nonetheless, as these phones develop - and provided BBS's such as GB7PZT continue to offer HTTP access - amateurs may yet be able to keep in touch with their BBS via their mobile phone.
It was conceded that this use of mobile phones was not necessarily "amateur" radio, but that it did, however, offer amateur services (exclusively) to amateurs.
This discussion followed the keen debate on packet as to the right of sysops to send messages overseas that have been labelled as for GBR only.
Conference was reminded that GBR bulletins had historically been sent outside of mainland Britain - most notably to Eire and Malta - because of the well-established links between Britain and these two countries.
With the advent of Internet forwarding, the practice had developed of individual sysops also responding to requests from ex-pats (in Australia, New Zealand, USA, etc) asking for GBR bulletins to be forwarded to them. This request had been answered as a courtesy.
However, these bulletins were not remaining within the designated BBS's - instead they were then being forwarded to the rest of the world, thereby contravening the stated wishes of the bulletins' originators, and G6KUI wished conference to respond to the various concerns expressed by many about this.
Support was voiced for the right of overseas sysops to hold GBR bulletins provided they were not forwarded onwards. Regret was expressed that certain overseas sysops had shown themselves untrustworthy in this respect.
It was felt that ex-pats, whilst understandably wanting to follow GBR matters, would do better to log in to one of the increasing number of Internet-linked British BBS's.
Matters of copyright were considered, although the position was not clear. Some could not understand why such a restrictive readership was so important, while others felt that the wishes of the message sender should be observed.
Clearly if the content of the message would contravene the regulations of an overseas packet network, then it was important for restricted distributions to be adhered to. However it was observed that overseas restrictions were probably more lax than GB guidelines, and that message content was more of an issue for importing mailboxes in GBR, who should take great care to ensure that only appropriate content is put out onto the GBR network.
With few conclusions or resolutions being possible, given the nature of the meeting, the discussion was brought to a close, and Martin G1DVU advised that the RSGB bulletin GB2RS was now being sent @WW, except for local news bulletins which would remain @GBR.
Roger G3ZFR advised that the venue in Coventry is no longer to be available for future packet conferences. He expressed the hope that venues and volunteers would be forthcoming so that a PK2004 could still take place.
A vote of thanks was given to Roger G3ZFR for having organised the conference.
The conference ended soon after 5.00pm. Roger thanked all for coming, and was himself thanked for having organised the event. Hope was expressed that the success of PK2002 and PK2003 would be followed up in 2004 with a similar event.
Mike G7RAZ Minutes Secretary