Welcome to the seventh issue of WyrePak Newsletter. This is yet another bumper edition, and I hope that you will again find something to interest you! Many thanks to those kind members who contributed to this edition - we've got contributions from Richard G0EWH, Eric G8BKL, and Paula G8PZT of course - and to those who said they enjoyed the last issue too.
It is likely that we will meet on a less regular basis from now on. When the Group was first set up, monthly meetings were required but this is probably not necessary now and since late 2002 we have met every six weeks to two months. Future dates are agreed at each meeting and are publicised via the List Server and the Newsletter where appropriate. The AGM is in September every year, and there is even a tentative plan to hold a virtual meeting on the Chat Server!
Plenty of activity since the last Newsletter...
January 2003
March 2003 - technical discussions again and preparation for the Group's demonstration to KDARS of APRS, UI-VIEW and IP over 9,600 baud Packet Radio featured prominently. The plan is to connect to and surf the Internet, using nothing more than a 9k6 radio link from the KDARS HQ. Paula reported an intermittent fault with the Ethernet cable which is an elderly length of coax, and it Richard agreed to obtain a new cable at a forthcoming rally. Fitting the replacement will be undertaken by Paula in early spring.
April 2003 - by the time you read this, the demonstration to KDARS members on 1st April should have been a success! The plan is to demonstrate TCP/IP access to the Internet using a conventional web browser but using 9600 baud Packet on 70cms and the KIDDER node's link to the web, instead of a conventional phone line. The equipment comprises, at the KDARS end, an FT100 with integral 9600 packet capability working into a 70cms Yagi, plus a TNC2-H, laptop PC and data projector display. Software will probably be Internet Explorer. At the node, a Tate 500 transceiver and Yagi plus 9600 baud TNC form the 70cms port, the TCP/IP node software providing the route to the Internet via Paula's broadband connection. At around one-fifth the speed of a typical 56k dial-up modem, there may be a slight world-wide wait, but it will demonstrate the principle of IP over Packet and vice versa.
The intention of this section of the Newsletter is to summarise the relevent 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 - generally quite a lot! - Ed.
Difficulties with access to the 4 metre user port on 70.4875MHz are proving difficult to trace as the fault is intermittent, although it is still thought to be an antenna or feeder problem at G8PZT. G3PWJ, G4EQR and G8BKL are thought to be the only users but since the last Newsletter no problems have been reported.
Also, since adjustments were made in January the 2 metre user port on 144.850MHz has had very few troubles, with distant stations reporting no access problems. The check on 20th January revealed that the transmit deviation had dropped and adjustments were made. It seems to be working OK now. Richard is setting up a new Bosch radio and TNC combination prior to trials on site. Some individual stations experience high retry rates while others have virtually error-free contacts, and it was suggested that tone imbalance could be the problem. This was covered in an earlier edition of the Newsletter in Technical Topics - mark and space tones should ideally be of equal amplitude before being passed to the TNC or modem. TNC's and Baycom modems seem more tolerant of variations in received signal level and quality than PC sound card and AGW systems. When TNCs and Baycom systems were the norm these problems went mainly un-noticed, but AGW is more critical.
One of our member's station has been monitored and seems to be using Protocol 1 despite being a recent AGW system. See Technical Topics for more details.
Help information has now been restored to the CHAT server. Type "/H" for the help menu.
The List Server failed, for some reason, to distribute G4SPZ's usual reminder of the January meeting to subscribers. The March reminder went out as usual, and while Paula is investigating please remember to check that your subscription has not expired. To re-subscribe, free of charge, send a private message addressed to LSTSRV with the words SUBSCRIBE WYRPAK on a single line. For a list of subscribers, send REVIEW WYRPAK instead.
Intermittent BBS access may be due to a fault in the Ethernet cable which runs externally at G8PZT. This cable will be replaced in the spring.
Some Level 4 links were timing-out due to a bug in the latest version of the node software, which has now been fixed. The standard time-out times for the system are 15 minutes for the KIDDER node and 2 minutes for the GB7PZT BBS, the latter short time originally being made necessary to combat the effects of deliberate hacking and jamming attempts. Paula will consider increasing this. Essentially, to maintain a connect to the BBS it is necessary to send a line of text or a carriage return character at least every two minutes - slow typists take note! If you are towards the end of sending a message and the XYL calls you with a cup of tea, let the tea go cold - at least until you've sent that vital 'CTRL-Z', otherwise the whole message may be lost. [I speak from bitter experience here - Ed]
The 23cms link from KIDDER to WV12 at Wolverhampton, which carries DX Cluster traffic as well as forwarded mail, is now working again, most probably due to leaf drop which can reduce path attenuation on such frequencies in the winter. The replacement 23cms antenna which is optimised for the frequencies in use is now available and should restore the link's performance.
A new antenna has been obtained, together with brackets, and this is due to be fitted to improve the quality of the link to Malvern.
Much inter-node traffic now flows over the Internet, relieving some of the RF paths of congestion. New Internet links have been created between KIDDER and certain other key UK nodes in Petersfield, Essex, Yorkshire, Bristol and Corley, as well as to G7BUG in Shropshire and G6TJZ in the West Country. Connects to these nodes are virtually instantaneous.
Derek G3KFD pointed out that MB7UIW, a Maxpak APRS node, is broadcasting huge amounts of useless (to UK stations) APRS data from US stations obtained from its Internet link. Phil G4SPZ will write to Chris G0CNG, Chairman of Maxpak, to ask that this data is filtered properly to prevent 144.800MHz becoming clogged. Unfiltered APRS data from the Internet should not be automatically digipeated, as the essence of the system is for only useful local information to be relayed. On APRS, Mike G1ZRN is putting out UI-VIEW 'objects' for the local voice repeaters GB3KR and GB3BY, but the locations are both believed to be considerably in error. G4SPZ will notify him by Packet.
Try connecting to MB7UYL, Paula's additional APRS digipeater callsign, which as we reported in the Winter Newsletter is connected temporarily to a mirror of the BBS being created on a Pentium 100 PC with a 1GB hard disk. At some future stage, the entire BBS will be transferred to the new computer, but in the meantime MB7UYL contains just bulletins and no private mail or file areas. Paula has asked users to note that MB7UYL is not on-air 24 hours.
The http interface is now operational, providing connectivity to KIDDER and GB7PZT 24 hours a day via the Internet. From your usual browser, go to http://g8pzt.ath.cx and you will be presented with options to go into the node, BBS, WyrePak website, Fourpack website and others. This service will enable registered amateur stations to access the Packet network, mail and bulletins from their home, office or hotel where a radio link may be inconvenient or unavailable. It will also tend to make the telephone BBS link less valuable, other than to Packet users not having Internet access.
Access to KIDDER and GB7PZT via the non-radio Internet route at www.g8pzt.ath.cx has been restricted by the addition of a password requirement, to prevent non-licenced persons from accessing the RF ports and also to prevent malicious use of the BBS and packet system. If you would like a password, please request one from Paula by e-mail or some similar secure method. It had been found that access was not possible from computers running the Windows NT4 operating system. This was due to the NT4 OS not being able to run the Java client applet, and Paula has fixed this by providing a choice of Telnet or Java formats for the connection. In addition, computer systems in offices and other 'public' areas like the public libraries operate through a firewall, which blocks Telnet traffic from Port 23 but not for some reason that from Port 80, and Paula has fixed this too. No problems have been reported from home systems running any OS [including Windows 3.1 - Ed]
No answers have been forthcoming to the queries in the last issue, so here goes again with another appeal for help and advice...
The soft-disconnect command for BayCom is //Q, but does anyone know the command which causes the DOS-based Paket 6 to soft-disconnect? Answer to G4SPZ @ GB7PZT, please.
Graphic Packet requires to run in DOS on a PC which does not have Windows (any version) installed on its hard drive, otherwise it makes the PC clock run fast by about 20 minutes in every 2 hours! If anyone knows why, G8BKL @ GB7PZT would appreciate it.
G4SPZ has been trying to get an old AST Premium Exec 386SX/20 laptop running Packet. BayCom 1.60 won't work (the terminal program runs on the screen and decodes incoming packets, but transmitted packets are corrupt) and Graphic Packet crashes, with COM error messages again coming up. However, G7JJF's "WinTNC" runs OK (well, sort of) with the same BayCom modem! Any ideas would be welcome, as G4SPZ has two of these otherwise useless machines, in perfect working order, just crying out to be used as portable Packet stations.
The Group has about 15 paid-up members who contribute a mixture of money, time and expertise to help maintain the systems that we all benefit from. However, in an average month, about 45 separate stations use the node, BBS or both. Paula has always been opposed to any form of compulsion, and has preferred to use persuasion when trying to encourage amateurs to part with a few pence to support the system. A gentle reminder will be added to the welcome text to remind users that their support would be welcome! WyrePak members can also help by mentioning the Group and its work to any packet operators they know who use the system regularly. The Secretary will happily e-mail a copy of the latest Newsletter to anyone interested if they send a note with their e-mail address to G4SPZ @ GB7PZT.
Due to pressure of work, Richard's regular column has had to be held over to the next issue - Ed
Whilst monitoring connects from a local packet station, Paula noticed that the station was operating Protocol 1. This was the first AX25 Packet protocol to be developed and has now largely been superseded by, not unsurprisingly, Protocol 2. In Protocol 1, once a packet connection has been established the sending station transmits a data packet (an information or I-frame) and waits for an acknowledgement from the receiving station. If no acknowledgement is received after a predetermined time, the sending station assumes that the last packet was not received and re-transmits the same I-frame. I-frames can be long, up to 255 bytes, and thus take up a considerable amount of airtime on a busy channel, adding to the noise, clutter and packet collisions and hence slowing down the channel for all users. Protocol 2 improves on this by only transmitting a short polling packet (a P-frame) which simply invites the receiving station to acknowledge receipt or request a re-send. The receiving station replies with an ACK (ready to receive next I-frame) if it received the previous packet correctly or a REJ (previous packet not decoded correctly, send it again pse OM). The overall result is improved channel throughput. Further investigation is needed into why a recent version of AGW is operating under Protocol 1.
The effects of co-channel interference are fairly obvious in an analogue transmission system, but in a digital environment the effects can be more dramatic and haphazard. Packet radio is a digital system and such systems tend to work perfectly, or not at all. Packet presents us with a third option, a digital system which sometimes works perfectly but sometimes doesn't! A recent case of 'now you see it, now you don't' was investigated and involved the 'capture effect' of an FM receiving system.
Most FM operators are aware that one of the benefits of FM for relatively short-range working is that a single frequency may be re-used many times, as long as each individual QSO involves stations that are in strong signal contact with each other. The capture effect of FM effectively mutes the audio from the weaker stations, and is quite a powerful effect on the wideband FM broadcast band II but less so on narrow-band amateur signals. On a shared frequency such as 144.850MHz, which is occupied by several nodes, an well-sited amateur station will probably receive signals from several nodes but the strongest one, in RF s-meter points, will mute the audio from the competing nodes to the extent that reliable decoding can take place. A recent problem experienced by some WyrePak members on the fringe of KIDDER's 144.850MHz service area caused connections to slow right down or fail completely at times, whereas at other times, things were fine.
As mentioned earlier, some nodes seem to be transmitting at very high FM deviation, which not only produces a wide RF signal that can spread into adjacent channels, but produces very loud receiver audio when tuned in. KIDDER, with its 1.75kHz deviation, just couldn't compete against GB7BHM at the location concerned and, despite the capture effect, KIDDER's packets were getting corrupted. All that was required to restore satisfactory operation was a slight increase in the KIDDER 144MHz transmitter deviation. The real culprit, of course, is another group operating a Packet node that exceeds the deviation required by the IARU band plan, which, as we all know, is voluntary, not mandatory...
Paula G8PZT writes: "Sorry that I haven't been able to write an article on the chat server for this issue of the Newsletter. However, I shall be demonstrating the features of the chat server at the Kidderminster and District ARS meeting on 1st April."
In the second part of his article on portable packet operation, Eric G8BKL writes:
In my original offering on operation of Packet Radio from remote locations, I touched upon my experiences in working from West Wales and from Somerset. This may have encouraged others to try this mode of operation when on holiday etc. I can tell you from experience that it keeps the XYL happy when you want to operate whilst she is watching the TV in the caravan or the same room, as apart from the noise of the keyboard it's a silent mode !
Here are a few suggestions to make operation that much easier. I must stress that these pointers are drawn from my own experiences and others may have differing views.
Firstly, to explode a myth. Some operators seem to think that, once a connection has been made, it is like a telephone line with direct access. If you are connected via several nodes, each one will be carrying other traffic and each one has to acknowledge receipt of the packets with its neighbours. This can often lead to longish delays between your sending a line of text and its receipt at the other end. So in many cases one has to be patient. You can still keep sending your messages as long as you realise there might be a delay and questions and answers may get out of sequence.
When you intend to operate from a remote location, it helps to research the route before you go, and certainly try to establish that there IS a viable route. For instance, the route to the Bournmouth area from the Fourpack network is virtually non-existent due to the lack of suitable linking nodes (in the Wiltshire area I believe), so it pays to have a look at the probable route and try it out from home first. This can be done in several ways. A good starting point is the RSGB Yearbook and the Fourpack Handbook. From these you can establish if there are BBSs or Nodes near to your proposed location.
Look at the Node listing in your local node and see if any of the calls in your proposed location are listed. If not, locate a node nearer to your proposed location, connect to it via your local node and repeat the exercise. This can take some time but is worth it in the end. You can of course print out any node listings you get and take them with you. This is often very useful.
You may of course wait until you are at your proposed location and do the exercise in reverse, but this can be more frustrating! Alternatively there are some maps of various networks around the UK available, and Paula G8PZT may be able to help. However one word of warning - my own experience has shown that these maps often get out of date with nodes closing down. This often makes certain routes not viable, if alternative nodes have not been established.
Node-hopping is an interesting pastime, particularly from locations away from home. It consists of connecting to a local node, asking for its node table, then selecting a node which looks interesting, connecting to that node and then repeating the node table request and so on. (Some node alias's are misleading, though... I connected to ABDN thinking it might be in Aberdeen, but was disappointed to find it's at Abdon Burf in Herefordshire! - Ed) It's good way of finding your way around and new routes back to the home node or BBS can often be found.
When you are away from home you may not know what your local node is, or which frequency it may be on. Put your packet station together and scan the packet frequencies for any signs of activity. Alternatively, call a local station on FM or SSB and ask! Note that certain packet frequencies are reserved for certain purposes i.e. 144.900 MHz is reserved for DX Cluster User Access, 144.925 MHz is for TCPIP User Access, 144.9125 MHz is for ad-hoc packet i.e. one to one users etc. There are similar allocations on the other bands such as 70cm, 4m and 6m. Details may be had from various sources including the RSGB and local packet network User Groups.
Many nodes have several operating frequencies, often in other VHF bands. When connected to a node with which you are not familiar it is useful to send < ? > or < i > (information) or < p > (ports) or < r > (routes) to get more information on that node.
When operating from a remote location, access to stations back "home" may only be possible via a node network. In this case you may want to contact more than one station over the same route. Now you don't want to have to re-establish the link for each contact. To do this when you connect to the node you want, you can stay in that node by using the "stay" command... let's take an example. I have connected by some means to KIDDER and want to look for mail first and then, let's say, connect to G4YUD. My first command is therefore < c gb7pzt s > (space s being the "stay" command). When I have finished with the BBS the < b >command returns me to the node which responds with "Welcome back" and I can carry on with the next connect request. As long as you use the "stay" command you can do this as many times as necessary.
I hope these notes will be of use to someone,, and might even spark some discussion at the WyrePak meetings!
Eric G8BKL
Phil, G4SPZ adds: Thanks for the useful advice, Eric. My XYL and I will be in Scotland later this summer and I hope to operate mobile Packet from there so, in preparation, I put out a bulletin on the Packet network asking for information on Packet nodes in the far north of Scotland... replies included information from MacPak, which is a support group covering central Scotland, and HiPak, which operates nodes and BBSs in the Scottish Highlands. Apparently there are no nodes further north than Inverness (GB7INV) but there is a node, GB7SDY, on the Island of Sanday in the Orkneys. As we will be staying for a week on Orkney itself, there should be a route back to the Wyre Forest. I will, however, ask our helpful Sysop to contact GB7SDY's Sysop and set up an Internet link between the two, just in case...
Well, that seems to be your lot this time, guys and gal. Thank you for your continuing support for WyrePak, G8PZT/GB7PZT and your local Packet network. Thanks to our contributors and don't forget, we're always looking for comments and contributions for the WyrePak Newsletter... please contact the editor, Phil G4SPZ at g4spz@aol.com or G4SPZ @ GB7PZT, 01299 403025 or pnharris@iee.org.
WyrePak Newsletter is compiled, edited and published by Phil G4SPZ. This issue (c) 31.03.2003