CONTENTS:WyrePAK meeting dates for the rest of the year
17 Jul Cancelled due to holidays 21 Aug Technical Meeting 18 Sep Annual General Meeting (*date TBC) 16 Oct Open Meeting 20 Nov Technical Meeting 18 Dec Committee Meeting Recent meetings have not been well attended by members. Any reasons why? Your views are welcome and essential for the Group to understand the members' needs. What would YOU like to be discussed at the meetings? Could the format, date, time, frequency, venue or anything else be made more convenient for you? Please contact any Committee member.
Contributions to the WyrePAK Newsletter
It would be nice to receive articles or other items for me to include in the Newsletter, so please let me have your contributions, no matter how small, preferably by e-mail to wyrepak@aol.com, or via Packet to G4SPZ @ GB7PZT. I can read most formats so anything from ASCII upwards is OK.
In future, a copy will also be sent to Andy Talbot, the editor of the 'Data' column in RadCom. Did you see WyrePak mentioned in the April 2001 RadCom?
PHIL, G4SPZ
WyrePak SecretaryIn the absence of any other suggestions, the default title "WyrePak Newsletter" will have to do for now! Any alternative bright ideas would be welcome.
Chairman: Jim Crucefix G0HTF Treasurer: Richard Newton G0EWH Secretary/Newsletter: Phil Harris G4SPZ System Operator: Paula G8PZT Technical Topics - AFSK Levels
A recent problem at G4SPZ highlighted the importance of ensuring the correct deviation for Packet transmissions when using FM on VHF or UHF. It was noticed that Packet signals received from a station some 10 miles away were much weaker than ordinary FM voice signals from the same station on the same band. Exhaustive tests revealed that the same power was being transmitted on both modes, yet Packet was received at S1 whilst voice signals were S5! What could produce these symptoms?
The answer lies in the deviation. Have you ever tried listening to wide band broadcast FM on a NBFM receiver? Often, nothing will be heard other than "quiet" passages such as pauses in speech. The moment any decent modulation occurs, the signal vanishes. Frequency modulation produces sidebands which extend either side of the carrier frequency, and the louder the modulating signal, the wider the sidebands extend. However, with FM, the transmitted power is constant, so if the signal is spread over a wide frequency range, the power has to be distributed over the whole signal bandwidth.
As a consequence, the apparent carrier level at the receiver is reduced as the transmitted signal bandwidth is increased. In the case in question, listening on an FM receiver close to the transmitting station gave a clue - the transmitted Packet data sounded much louder than other Packet signals on the channel. The PK232MBX data controller in use at the station is equipped with a handy rear-panel mounted control called "AFSK LEVEL", and when this was adjusted to reduce the level of audio going to the transmitter (nothing scientific; it was adjusted till the transmitted signal sounded similar in loudness to others on channel) the problem was solved! Received Packet signals returned to S5 strength.
Ideally we should be aiming for a deviation around 2.5kHz which keeps the spread of the FM sidebands well within the 12.5kHz channel width used on 2 metres. In the case in question, the transceiver was fitted with a "data input" socket on the rear panel, and signals via this route may not be limited in amplitude in the same manner as signals applied via the microphone socket.
However, without the right test gear, setting the deviation can be achieved by careful adjustment "by ear" until the signal is the same loudness as other decodable signals on the channel. Many Packet users mute the received audio, but it can be useful, and enlightening, to monitor the audio on the channel, enabling interference and out-of-spec Packet signals to be identified.
This is where you can post your questions, in the hope that another reader will have the answer! No questions this time round, but please feel free to pose them. Even if you know the answer yourself, it may well interest someone else. Questions (and answers!) to G4SPZ please.
KIDDER/GB7PZT News - June 2001
Contributed by Paula, G8PZT
Antenna News: The 48 element yagi linking KIDDER with MLVN (Malvern) failed in the spring, so the link was swapped onto the 5 element yagi, normally used to link to GLOS. The latter link is now provided by a temporary yagi balancing precariously in the loft. Both links are working acceptably, but not as well as before the failure. High antenna gain is required because the Pye 460 link equipment is 40 years old and not as sensitive as modern radios. The 5 element yagi doesn't provide enough gain to MLVN and the loft antenna suffers from attenuation through the roof tiles, which seem to be of an RF-unfriendly composition!
The plan is to replace the old 48 element yagi with a potentially more reliable 9 element Tonna during the antenna maintenance session. This will help reduce the wind loading on the pole, which has long been a source of worry. (More information on the antenna project will be distributed via the List Server shortly... Ed)
Skeleton slot fed yagis, such as the "multibeam" type, often have several joints in the driven element and reflector. Over time, these corrode, degrading performance, and therefore need maintenance every few years. In contrast, the 9 element Tonna has no joints and a well sealed feedpoint, and has been found to be extremely consistent and reliable.
Link with BRUM: The link with BRUM and thence to GB7BHM is not currently operating because BRUM is dismantled pending installation at Turner's hill. When the move is completed, hopefully in July or August, this will greatly improve connectivity to the North and with MAXPAK's systems. Meanwhile, KIDDER's port 12 temporarily links directly to the WODEN node/GB7BHM mailbox system in Wednesbury.
APRS Port: A new port (port 13) has been added to KIDDER, bringing the total to 14. This port functions as an APRS digipeater on 144.800 MHz, 1200 bauds, and it is hoped that it will aid APRS / UI-VIEW activity in this area. You cannot "connect" to KIDDER on this port, as the frequency is meant for unconnected use only.
The software implements all types of generic digipeating, but currently only RELAY is enabled, as I don't want to upset the existing APRS network. Further modes and facilities may be enabled as more experience is gained. One of the future ideas I'm working on is "trunking" the APRS data via the network to give wider and more reliable coverage.
The command "MH 13" will show all the APRS stations heard on port 13, along with their positions, distances and bearings, and the new "DX" command will show the best APRS DX heard across all ports.
Mail Beacon: Following a request from Phil G4SPZ, I have re-instated the long forgotten "Mail For:" beacon, which was disabled around 7 years ago (for reasons I can't remember!). The interval between beacons is currently 15 minutes, but if that's too frequent please tell me. (It could be every 5 minutes, which would save us BayCom users scrolling back so far... Ed)
Performance Improvements: I have been doing a lot of programming on both the router and the BBS, most of which has been laying the foundations for future interesting Packet developments which I want to keep quiet for now. However, a lot of effort has been put into squeezing the best possible performance out of both user <> node and inter-node links, so you should have noticed an improvement in throughput, providing your own system is set up reasonably well. The most significant improvement as far as the user is concerned is "adaptive layer 2 parameters", something I've been itching to implement ever since I first started running a node!
With conventional nodes, the choice of Maxframe and Paclen on user ports is always a poor compromise. Large values give good throughput for users with good links to the node, but poor performance to users with more tenuous connections, and it gets worse on congested channels due to excessive retries. Smaller values improve the throughput for distant stations, but penalise the users who have good links. The usual compromise of Paclen=120, Maxframe=2 means that only 240 (2*120) characters can be sent in one transmission, i.e. only 3 lines every 6 seconds or so. On a"perfect" and clear channel it would take the best part of a minute to receive a full screen (25 lines) of text.
Instead of one compromise setting for everyone, my innovation is to maintain separate layer 2 parameters for every user, and to automatically "tweak" the settings to maintain best throughput for the prevailing channel conditions. If a link experiences a lot of retries and rejects, the maxframe and paclen settings are reduced, but if there are very few rejects and retries the settings are increased. This means that someone with a good link can now receive up to 1792 (256*7) characters (over 22 lines of text) in one transmission, which is the limit imposed by the AX25 protocol.
I have also changed the way "rejects" work. If a user misses a frame, the original protocol dictates that he should send a
frame, and the node should then re-send all the outstanding frames. In practice however, I've observed that users sometimes have trouble receiving one particular frame (usually due to a combination of bad radio/tnc interfacing and the actual frame contents, or a slow tx to rx transition), and this would cause several frames to be sent over and over, the first one being rejected each time. This causes unnecessary channel pollution. KIDDER now re-sends only the rejected frame, and will only move on when that frame has been accepted, thus saving a lot of airtime and resulting in better throughput for everyone. Another improvement which will pay off as more routers are upgraded to my software is "Modulo-128". This is an extension of AX25, allowing MAXFRAMEs up to 63 instead of the usual 7, which can result in far better performance on inter-node links.
There are various other aspects of AX25 which have been tweaked, but they're too complex to describe here.
Internet Connection: Earlier this year, KIDDER (IP address: 44.131.91.245) and GB7PZT (IP address: 44.131.91.2) were reachable from the internet, using a suitable browser or Telnet client, and GB7PZT gained a few distant users whose local BBS's had closed down. The permanent internet connection was located at Telford, to which KIDDER links by radio.
However, as soon as I announced the facility, it suddenly ceased to function! The official story is that a system near Coventry had failed, cutting off the routing to Telford. Despite numerous pleas to get it sorted, it has remained non-functional for several months, and the sysop of the failed system refuses to release control of the routing. I'm told it will be back on soon, but I've heard all that before!
If it ever does get sorted, and you want to try connecting from the internet, open a DOS window and simply type "Telnet 44.131.91.245". A telnet client should appear, and in a couple of seconds you should find yourself connected to KIDDER.
As there are systems world-wide which have expressed a desire to link directly with KIDDER, and users who wish to use GB7PZT via the net, I am seriously considering getting a permanent internet connection of my own if the situation doesn't get resolved soon. The main obstacle is the cost (£25 per month) of an "always-on" connection, which is out of my reach unless I can make substantial savings.
Internet/Packet Convergence: Like it or not, the Packet and Internet worlds are moving closer together. Nodes, BBS's, converse servers, repeaters and APRS are all being linked via the internet, Winpack now has a Telnet facility, and much amateur radio content is now exclusively on the web. Many of our network nodes are now fully IP-capable, allowing seamless interconnection with the internet.
From the outset, GB7PZT was designed to be accessible via as many modes as possible - e.g. direct AX25, via the node network, via the telephone port, and using TCP/IP. Over the past few years I have been working towards making the BBS accessible with standard Windows Internet tools, such as Internet Explorer and Outlook Express.
Telnet, SMTP and FTP are already fully operational, and the latest upgrade (POP3) now allows personal packet mail to be collected from and delivered to the BBS using your normal email client (Pegasus, Outlook Express, Eudora etc.), providing you have permission to do so. There are a couple of teething problems still to be sorted, but nothing serious. The next phase will be NNTP (Network News Transfer Protocol), allowing bulletins to be exchanged too.
The intention is not to replace packet radio, but to combine the best of both worlds. Radio will always be the medium of choice for those who have no internet connection, as well as mobile, portable and temporary stations. But instead of having to learn to operate clumsy packet radio programs, everything will be possible with just a couple of standard (and much better written) tools. The user would have the choice of using a TNC and radio or a modem to make the connection.
(Thanks Paula. It's good to see that Packet is still capable of development despite being around for nearly 20 years. More news next time... Ed)
If any WyrePAK members are interested in attending a Fourpak meeting, please contact Paula G8PZT, Richard G0EWH or Phil G4SPZ as it may be possible to share a car and travelling expenses to Upton. It would also be a good thing for WyrePAK to be represented at Fourpak by a group of active local members, particularly as we have been granted financial and practical assistance towards the repairs to the KIDDER node's antennas...
Fourpak meets on the fourth Wednesday of each month. Forthcoming meetings are on 25th July, 22nd August, 26th September, 24th October and 28th November 2001.
Thanks to WyrePak members' generosity, 'Paula's List' has now shrunk to the following:
- 24 no. 12 volt power plugs and sockets, Bulgin type or similar
- 12 no. good quality in-line fuse holders
- RS232 cables 1 metre long, 9 pin female to 9 pin female
- RS232 cables 1 metre long, 9 pin female to 25 pin male
- RS232 null modem cables, 9 pin female to 9 pin female
- 1 no. RF patch lead UR43 500mm long, N plug male to N plug male
- 1 no. RF patch lead UR43 500mm long, N plug male to BNC male
- 1 no. TNC lead 1 metre long, 5 pin DIN male to 5 pin DIN male, screened
- Structural repairs to steel mast (details to follow... Ed)
- PVC downspouts to act as cable conduits
- 20ft aluminium pole
(I have also managed to obtain a large - and heavy - quantity of new 25mm solid copper earth tape... Ed)
We are delighted to report that founder member Derek Billingham G3KFD is now fully recovered from his recent operation and back in action on Packet, Hellschreiber and PSK31 as well as the more usual voice modes.
Thanks to everyone who contributed in any way to this edition of the WyrePAK Newsletter, particularly to Paula G8PZT for much of the technical content. My appeal at the start of this issue still stands... please let me have any items for inclusion in the next edition, due for publication before Christmas, by the end of November 2001 please.
Finally, thank you for reading this!
WyrePAK Newsletter is compiled and published by Phil Harris G4SPZ 01299 403025. E-mail: g4spz@aol.com AX25: G4SPZ @ GB7PZT (where else?)
©G4SPZ 2001
=> [ Main Index ] [ Newsletter index ] [ Top of page ]