Welcome to the 10th issue of WyrePak Newsletter. It's becoming increasingly difficult to fill the pages with interesting topics on the subject of Packet Radio these days, which is why we appreciate it so much when we receive articles from members. I have mentioned this before! This edition is still four pages long, thanks largely to Paula and Richard, and whilst I promise to try to keep to our thrice-yearly publication dates, you may find that to keep the content relevant, the newsletter may be a bit shorter than previously. Any suggestions, articles or simply requests for information around which we can construct an article, are always very welcome.
I am very grateful to Paula G8PZT and Richard G0EWH for their comprehensive contributions to this issue.
Meetings are being held on the third Tuesday of every second month. The February 17th meeting didn't go ahead, and the dates for the rest of 2004 will therefore be 20 April, 15 June, 17 August, 21 September (AGM) and 16 November. These are subject to change, but a reminder will be broadcast via the List Server to all members in advance of each meeting to confirm.
In order to minimise costs and improve service, members are encouraged to advise the Secretary of their e-mail address in order that the Newsletter can be distributed by electronic means. Currently, members receiving their Newsletter through the post only get a monochrome copy, to save printing costs, but it is available in glorious Technicolor by e-mail. A text-only version is usually available on the KDARS website at www.kidder.thersgb.net
Nothing to report this time. The February meeting didn't go ahead and the April meeting won't have taken place by the time you read this! The decision to revert to bi-monthly meetings reflects the relatively quiet period in the history of GB7PZT and the network.
The intention of this section of the Newsletter is to summarise the relevant information, which is made available at the WyrePak meetings. I have tried to avoid duplication and to omit items which are out-of-date, whilst providing readers with a good impression of what happens in a typical three or four month period. Contributions to the Newsletter are still invited, please contact G4SPZ @ GB7PZT or g4spz[at]aol.com
Service has been restored on 4 metres using a replacement antenna, and signals are reported to be very strong in Highley and Stourbridge. 4 metres offers excellent access to the node and BBS as the band is so quiet locally.
The BBS threw a wobbler in the early hours of 3rd February, started calling Paula "Gerd", refusing to let anyone change their details, and asking everyone what their names were. It purged its 'white pages' database, and took a while to fix as Paula tried to reconstruct the evidence trail to try and find out what happened. Paula had a bad dose of flu at the time and didn't feel much like doing stuff. So she closed the BBS down temporarily, as she needed to keep people off the BBS for a while to prevent any more damage being done to it and to prevent user accounts getting mixed up any further.
The full details of the fault still aren't known but the system was out of action for two days while Paula frantically worked to restore service. Thanks to those who were patient! There was a problem with John G1STL timing out. The reports were too vague so Paula couldn't make a proper diagnosis, and the only thing she could do was double the timeout to 10 minutes, which hopefully has cured the problem.
Paula G8PZT has sent the following report:
"Since I finished working on the BBS, all I can remember doing is trying to solve obscure XRouter crash problems for other people. Stability has been my top priority.
The link to ABDON hadn't been working since last summer, because it wasn't hearing my transmissions. After many experiments I found that ABDON's receiver was way off frequency. It emerged that Steve G4FPV had tweaked the radio during a routine visit! His equipment must be inaccurate. Luckily my rig is rather strange, and I was able to de-tune the TX relative to the RX, so the link is working again.
Over the last couple of days the link between KIDDER and GLOS has been converted to use FEC - Forward error correction. I think I've spoken about this before (I gave a lecture about it at last years Packet conference www.fourpak.org.uk/fourpak/pk2003/minutes.htm). FEC is a technique which reduces packet loss, reduces the retry rate and improves throughput on an AX25 packet channel. It is used primarily on inter-node links, where corruption of packets may occur due to noise, fading, static or low signal strength. [We reported on this last time - see the Winter 2003 WyrePak Newsletter for more technical details - Ed]. It's not working as well as expected, so we probably need to do some work on the radio equipment too. We hope to upgrade to 2k4 on that link soon.
I'm still working hard to improve the links and the network, but there's nothing much to see for it at the moment...!"
Paula has updated the Fourpak network map and lots of other things. Go to www.fourpak.org.uk for full details.
Got a WAP-enabled mobile phone? Access the BBS! A reminder that the website address for this service is http://g8pzt.ath.cx/bbs/cgi-bin/wap/menu.pz
A tentative plan is being developed to set up a DX Cluster at GB7PZT. Many local users connect to the Cluster but the traffic has to go via the Fourpak network. A local Cluster fed via the broadband Internet connection would both speed up the process for users, and reduce packet network traffic. Any regular DX Cluster users are requested to contact Paula to express their interest.
If you're interested, the next Packet Conference will be on Saturday, 15th May 2004 at the Poacher's Pocket, Warndon, Worcester. Anyone can come. Ask Paula for times etc.
Richard G0EWH can provide further information on the 'KEY' ex-PMR radios for Packet which seem to be successfully convertible, and Paula G8PZT can supply EPROMS suitably blown for the amateur bands.
Richard has also kindly supplied a list of articles, published over the last few years, on the conversion of specific PMR rigs to amateur frequencies. Ask G4SPZ for details. If you know what you're doing, this can provide some very capable radios for general purpose use, but as many of these sets have relatively few channels, they are more suited to dedicated tasks such as packet and repeater use.
Richard Newton, G0EWH writes:-
"I don't have much to report in this issue. Winpack V6.80 is still performing well at my QTH."
"Although I normally use a TNC, if there are any RF problems, or a user moves QTH and does not have their station set up for example, then it is still possible for the user to gain access to a BBS such as GB7PZT by using the TELNET option, if the user has an Internet connection. The file TELNET.TXT, which can be found in the user's /WINPACK/TEXT/ folder, gives details of how to set up this facility. It is normally necessary for the user to be allocated a password by the BBS Sysop."
"As Winpack users will know, the script file BBS.TXT is the file used to connect to the BBS when in AutoBBS session or when using the F2 key. I have several different files, such as BBS-RF.TXT (for normal radio access), BBS-TNET.TXT (for Telnet access) and BBSMODEM.TXT (for the odd use via telephone), these also act as a backup for the current BBS.TXT file in use. I use the Winpack editor to open (edit script option) the file I wish to use and then use "Save As" to BBS.TXT, overwriting the current one in use, it is then necessary to edit the Comms Setup to change the settings as required. The only difference is for use with a telephone modem, when it is necessary to start Winpack with a different command line; see Help if needed."
Richard Newton, G0EWH continues:-
"Packet Users will be using many types of PC's, from 286s (or earlier) up to modern fast machines and therefore running various operating systems, from DOS to XP (and others). Some users will be using a dedicated PC for Packet, while others will be using their main PC together with many other programs, depending on the type of equipment they use and their operating practice."
"There are some thoughts that I can give to anyone who may be thinking of either upgrading their Packet PC to Windows XP, or replacing a PC with a new one that will no doubt have XP as standard. Users upgrading to XP may find that existing peripheral equipment, such as printer, scanners or Packet modems may not work under XP. Whilst XP will have many drivers built in, new drivers may be available from manufacturers' web sites so that their old equipment can continue to be used, but some items may not have new drivers and therefore cannot be used under XP. While I have not had any problems with printers, my previous scanner would not work, although the manufacturer's site suggested using the Windows NT drivers. In the end I replaced the scanner." [I have had exactly the same problem with an Epson GT5000 scanner not working under XP, despite finding on the Web a so-called driver that was claimed to work. It didn't - Ed]
"Regarding Packet, I don't have full details of what will, or will not work under XP, but Winpack, although a 16 bit program, will run very well under XP when using a TNC, Host mode, AGW Packet Engine or Telnet. However, if a user is using AGW PE with a Baycom type modem, then this is where the problems can occur. The current freeware version of AGW Packet Engine is 2003.308 and this does not yet support some modems such as Baycom when running under XP, although TNC's in KISS mode and soundcards will work. SV2AGW has done a complete rewrite of AGW as AGW PRO, but this only gives 30 days free use without registering, and a charge if made for this process. This new program has new features, such as Live Updates, easier setup (with sound cards, for example) and the current version dated October 2003 does support Baycom in a limited way. A Newsgroup posting in November by George, SV2AGW, did advise of a problem with Baycom when used with Advanced Configuration and Power Interface (ACPI) ports, although ports on PCI cards are ok. These problems can mean that a user may have to consider alternate means of running their packet station."
"That's all for this issue. 73 de Richard G0EWH"
Paula, G8PZT writes:-
"The biggest challenge in Packet Radio networking recently has been the attempt to integrate it seamlessly with the Internet. Some people don't want this to happen at all, believing the Packet network should be entirely radio-based."
"But the sad fact is the Packet network can no longer survive without the Internet. We have lost large chunks of our radio network, for various reasons. Ordinary sysops have drifted away to pursue other interests, and many hilltop sites have fallen into the hands of profit-motivated organisations who evict Amateur systems. The MOD, allegedly with the co-operation of RSGB's Data Communications Committee, are hammering the final nail in the coffin by refusing to licence any more 70cms links. 70cms was our best linking band, providing acceptable path losses in conjunction with useful antenna gains, and many other engineering benefits. Licensing in this band had always been slow and difficult, but is now impossible. I know of several links that could be implemented, but for this embargo."
"Many Packet groups have disbanded, and their networks have fallen apart. Luckily, some parts such as the Fourpak network are still intact. See the map at http://fourpak.org.uk/netmap.htm for details of the local network, with its many robust full duplex links. But contrast it with the UK as a whole, shown at http://fourpak.org.uk/ukmap.htm and you will notice how fragmented the radio network is."
"Over the last few years I have been developing software which enables sysops invisibly to bridge the gaps between isolated sections of the network using the Internet as a virtual radio channel, and this has been a huge success. Areas once difficult or impossible to reach via Packet are now less than 1/2 second away and the connections are a lot more reliable. This is a major improvement on what we used to have."
"In some places, Packet had died some years ago, when their radio links to the rest of the network disappeared. They are now being brought back to life, thanks to Internet linking. As a result, people are dusting off their long-forgotten TNCs, talking about Packet, experimenting, and rejoining the Packet community. So, far from killing Packet Radio, the Internet is actually revitalising it. Admittedly it's not pure radio, but it's the best we can do in the circumstances. The hobby has evolved, and we must move with the times. There will always be some radio involved - between the remaining hilltop sites and between the access points and the end users for instance. But the very success of Internet inter-node linking, and the ease with which it can be implemented, is throwing up new challenges for sysops and software designers to solve. A few examples would be the size of nodes tables, the amount of routing information exchanged, the choice and control of routing metrics, and network security."
"The nodes table is the heart of any node, using a lot of resources, and dictating its ability to connect with the rest of the network. In the old days, when the network was defined by relatively slow and line-of-sight radio links we had nodes tables containing around 100 to 150 nodes, which was all the software could manage. And most importantly, the further away a node, the less chance of it appearing in the table. The network could easily be mapped; none of the links were more than a few tens of kilometres in length."
"Nowadays, with the better connectivity provided by the Internet, nodes tables could easily exceed 2000 nodes, and that figure is growing rapidly! The network can no longer be properly mapped, because the Internet links aren't limited by geography. A table of 2000 nodes not only makes huge demands on the software, but exchanging all the routing information uses a lot of link bandwidth. That's not too much of a problem on the Internet links (although some people are exceeding their monthly Internet bandwidth quotas), but there's no way we could exchange that information over the RF links. So if we have huge nodes tables we have to somehow control the quantity of information we exchange with RF-based neighbour nodes."
"Large node tables are not appreciated by users. 2000 nodes occupy 20 screenfuls, and would take around 14 minutes to download on an average user link. This is enough to deter anyone from trying to view the nodes list! It is my view that users can not cope with tables that exceed 100 nodes. For several reasons, therefore, it is desirable to limit the size of node tables, but how? If we choose the 100 "best" nodes, based either on "route quality" or round-trip-time, we find the tables full of Internet nodes, a good proportion of which are overseas, and generally of less interest. This can be alleviated somewhat by downgrading the "quality" metric of overseas nodes, but this is not foolproof."
"Limiting by hop count is also unreliable. Whichever routing metric is chosen, the Internet nodes, with their fast response times and higher reliability, are always going to rank higher than radio ones, with the result that some of the radio-based sections of network, being lower quality, become excluded from the table, rendering those parts invisible. There doesn't seem to be an easy solution to this problem. The Netrom protocols, used by all the major node systems, were designed in the mid-1980s for a completely radio-based network where each node had only a handful of neighbours. They can not cope properly with networks containing so many links of such varying distances. For the moment we are stuck with these protocols, but it is my view that we need a radically new approach."
"We will certainly need, at least in the short term, to limit the number of Internet neighbours each node has, and co-ordinate them better. Then we must move away from today's anarchic mesh network topology, towards a more hierarchical and structured one. This will require more co-operation that we use at present. The Internet-connected nodes will need to sit astride and interconnect two completely different types of network. On the radio side they would still be NetRom compatible, but on the Internet side they would use new technology, which wouldn't use nodes tables at all."
"In summary, the growth of Internet linking over the last few years has brought many benefits for users, but it has also highlighted the weaknesses in the existing software and protocols, and things don't always work as well as we'd like. As a result, we are actively developing better protocols and the software to use them. It was originally called the "Packet Radio Experiment", and that label is still valid after nearly 20 years."
"(c) G8PZT, 14th April 2004"
I hope you've found this tenth issue informative. I would appreciate feedback from readers!
Before closing, can any BayCom user suggest a cure for my latest problem? After over a year of satisfactory service, my Toshiba 486 laptop running DOS 6.22 has suddenly stopped running BayCom. More specifically, L2 doesn't run, the white block does not flash, the terminal screen doesn't appear and the PC freezes as L2 starts, locking the keyboard. AUTOEXEC.BAT is set to run BayCom from boot-up, and I have tried to boot from the machine's system disk on floppy, but get the same problem, hence I can't edit AUTOEXEC.BAT to prevent BayCom starting! The action immediately prior to this fault occurring was simply to issue a command to make the system write incoming text to a file (:W INCOMING.TXT) which I have done many times before without problems.
Any suggestions would be welcome!
73 for now and I hope to see some of you at future meetings and events.
Phil Harris, G4SPZ
WyrePak Chairman and Secretary
This edition (c) G4SPZ 18 April 2004