by Ulrich Guenther, ZL1DDL/DL1NDB
Putting a packet radio node into a remote location can be a tricky exercise. We all know it's good fun having an old PC sitting next to you on the shack floor (ZL1DDL node is fulfilling this role nicely next to my feet here, awaiting its long-promised transfer into a 19-inch rack on casters, to be tucked away in the wardrobe).
Well, not every location is that cosy. Sites may be "difficult" in several aspects:
- they may be hard to get to, perhaps even inaccessible for part of the year (at least at amateur budget levels...)
- they may be co-sited with other services, such as telcos or security agencies, where big bucks or national security are at stake (you certainly wouldn't want to have the Russians invade the American Midwest just because your node jammed that all-important "they're coming at us" message? See).
- they may be easy to get to provided you live close by, but you don't.
Presuming you are a FlexNet convert (do I need to repeat here why you should be one) - which hardware platform should you choose?
My first advice would be to stay away from such sites. I know this isn't always possible, but packet radio (especially in a fast network environment) is a different ballgame altogether. When designing a classical voice repeater system, you go for high hilltops because of the coverage area you can achieve. As voice repeaters are a real-time application, linking is tricky and usually requires elaborate filtering and audio switching at the sites involved. The number of simultaneous users is generally low.
In a packet environment, this is generally NOT the case - a fact that is often overlooked. End users want to get to "their" favourite service (BBS, DX cluster, web server, etc.) without delay and want maximum throughput. Maximum throughput on a shared channel demands minimum user numbers.
So, from the functionality point of view, a node on a hilltop with an awesome panorama is a bad idea because it attracts every man and his modem in sight. To decrease user numbers in such a scenario, you could switch to multiple user ports - generally a costly option because they need filtering. Staying off the hilltop and replacing the single node by a number of linked local nodes is the better option, but comes at a cost in time and money. So, at the end of the day, what drives us up the hill? Two reasons:
1) cost
2) habit
While there's often not much one can do about the first, the second is definitely worth a thought or two. You'll definitely get a lot of customers being up a hill with a view, but will the savings in cost (that may be small as we shall see) outweigh the user aggro on a crowded system and the political battles you may have to fight to get into a premier site?
So you still look up the slopes of your favourite bump and think it's the perfect place for a node? Want to use FlexNet? Read on.
FlexNet was originally developed for a system called the "Rhein-Main-Network-Controller" or RMNC for short. This is a 19-inch rack-based system. In principle, it consists of a bus backplane in the rack, plus a "reset card" and a "bus monitor". This alone doesn't add any intelligence though.
For each radio port on the node, a RMNC3 channel controller card is added. This card, designed by Gunter DK7WJ, is a single-board computer running an HD68C09 CPU at a speed of 12 MHz. The first RMNC3 card acts as a master, the second and following ones act as slaves. Each RMNC3 card can take one modem (1k2 or 9k6) and a KISS interface.
RMNC nodes have gained a reputation for phenomenal stability - the record stands at 562 days continuous uptime. Even then it was an EPROM upgrade that necessitated the reboot. RMNC's offer only the most basic node functionality - about the same as PC/FlexNet with the digi module and no other modules running. So it isn't a good choice if you want to run a BBS, but I'd strongly suggest that you think twice before putting a BBS up an inaccessible hill anyway.
RMNC's certainly are a good choice for a rock-solid node at a remote location. However, you may find that they don't sell them at your local supermarket. Chances are you'll have to import the kits or PCB's from Germany.
From experience, this poses two problems:
1) you'll have to get the bits from a foreign country where "UPS" is pronounced "oops", credit cards are a sore point, and with two currencies and two languages involved, there's plenty that can go wrong. This is a general problem at an international level - my last attempt to import some spare parts from the US for a system here landed my club with more than twice the bill they'd expected, heaps of confusion, and no-one really to blame for. Just a misunderstanding that just so happened to upset the customs process etc. And all parties concerned spoke English... So you'll need patience and some breathing space in your budget.
2) foreign technology in your local environment. For starters, it means that YOU become the expert, which is great for you but a problem for your mates in case you should become unavailable - all your experience goes with you. You'll also want to keep a sizeable cache of spare bits to compensate for import delays.
While none of these problems are unsurmountable and some may eventually disappear if someone starts stocking RMNC's in your corner of the world, they do go into the engineering equation: an extra one-hour drive to a remote site may be the more convenient option compared to personally having to front up at customs to explain what those funny PCB's are good for (been there, done that!).
Enough ramble: you still want an RMNC? Great - go get one and enjoy! Stop reading here.
So you think a humble PC might just do the job? There are several aspects to consider:
1) reliability
2) interference to radio equipment, especially co-sited gear
3) interference from radio equipment
4) serviceability
5) flexibility and upgrade options
6) cost
The days when PC's were solely desktop machines that were turned on in the morning and turned off when their users went home are now well and truly over. For some years now, PC motherboard designers have had file and print servers, firewalls, and Linux/NT workstations in mind when designing motherboards. These services are supposed to run reliably around the clock. As a result, motherboards with "hangups" are now less common. In fact, even most 386's under DOS will run stable for many months if left undisturbed with only their copy of PC/FlexNet running.
Unfortunately, PC's consist of more than just motherboards. The increased use of high-quality connectors means that connections to RAM and any cards are likely to be relatively hassle-free. Even in a constantly humid environment with condensation and varying temperatures such as New Zealand, corrosion has not yet been an issue for us.
Moving parts - floppy and HD, perhaps CD. As any PC serviceman will tell you, PC harddrives usually fail either within the first few weeks or only after a long, long service life. Exceptions confirm the rule - ask PC people without an axe to grind (e.g., techos at your local college or unversity) which brand of HD's they'd warn against. Then choose one that has had a good few months in someone's PC until it got too small for them. FlexNet isn't too disk-intensive so unless you have additional applications running, chances are the HD won't be a headache.
Floppy drives: this is about the only problem area we have been able to identify so far - it's not the most dust- and vermin-proof technology ever invented. Try and shield from the elements as much as possible. Keep in mind that the only time you'll ever need a FD is during maintenance (unless for some strange reason you can't run your node off a HD). At less than US$20 a pop, you might as well carry a spare or two when visiting a site, so this may not be a big problem. We haven't tried CD's yet but I would caution against their use, for reasons of reliability as well as possible RF problems.
If you are lucky enough to be able to run your gear in a clean room at office temperatures, this shouldn't be a problem anyway. However, many sites that I have seen are gruffy and full of more or less appetizing creepy-crawlies. One site in VK I visited had hairy palm-sized huntsmen spiders all over the place - not necessarily the tenant I'd like to coax out of a FD with a short screwdriver just after lunch... Thus, making your node vermin-proof (at least to an extent) is likely to enhance its chances of survival.
Monitors and keyboards are usually fairly reliable, especially if they don't get used on a daily basis. We detach our keyboard and keep it in an insect-proof plastic box on site.
Power is another issue. After just having a major site all but fried courtesy of the local power company's efforts down the road, we're a bit sensitive to that. The power people first tried to talk their way out of it by blaming it on lightning etc. Thanks to FlexNet MH lists at remote nodes, however, we knew exactly when the node at the site had gone off air. Thanks to meteorological connections we were also able to verify that there wasn't a storm cloud, let alone a lightning, in sight anywhere in ZL on that day. However, we did notice the new power pole and transformer just outside the gate to our site...
Whatever power you use - protecting your node against overvoltage by a VDR (voltage dependent resistor) is a good idea. Similarly, a surge arrestor on the mains side of chargers isn't a stupid consideration either.
On a remote site, where the mains power supply is unreliable and you are running off a battery bank, supplying a PC becomes a bit tricky. You need +12V, +5V, and -12V, sometimes even -5V. While the first two voltages are easy to generate with voltage regulators, the latter two aren't (unless you invest into a second supply & small battery bank). The answer are 12V DC-to-DC computer switchmode power supplies. These used to be quite uncommon when we first built our node, but are now available from various sources here in Auckland at about US$150 each. I'd guess that someone in your neighbourhood will have them, too, but it might take a phone call or two to find out.
Note that most motherboards require a +5V "power good" signal - a line that isn't provided by some DC-DC power supplies. A quick and dirty hack is to have a time-delayed reset of a few seconds applied to the computer's reset line after power-up, and wire the "power good" input permanently to +5V.
If all your radio experience relates to a shack at home with only the TV to consider, you'll probably be in for a culture shock when talking to people that look after a radio site. Bad enough that you want to introduce a number of new radio transmitters at the site which will no doubt lead to endless intermod problems. Worse still, you're going to introduce a "gasp, shock horror!" COMPUTER to their well- groomed frequency park.
For "COMPUTER" read "wideband noise source" and you suddenly understand why some site managers react to the the prospect of hosting a PC as if you'd proposed to re-route a motorway through their living room.
There are serious issues here, though. For starters, many communication sites boast a multitude of hypersensitive receivers that could potentially be jammed. Note that "jammed" doesn't necessarily mean that the interfering signal has to be present at the output of the receiver affected. It's enough if the offending signal causes the first stage of the receiver to de-sense, thus preventing weak but desired signals from being heard.
A second problem is that there are often also a multitude of transmitters at a site. This in turn means that signals from the computer may mix with the TX signals in all sorts of places (including receivers). This has the potential to cause all sorts of hard-to-pin-down intermod problems.
For this reason, your PC needs to be as quiet as a headstone. A good test is to run your assembly next to a comms scanner and listen for whistles etc. while tuning across all bands. When you hit a whistle or hum, turn the PC off and see whether it disappears. If it's PC-related, see how far you need to remove the receiver to make it stop.
The good news is that this seems to be a far smaller problem in practice than in theory - most motherboards and cards now emit very little RF, thanks to low-current CMOS technology and improved shielding.
Prudence in construction is nevertheless advisable:
a) use a well-shielded case, and plenty of ground straps whereever convenient
b) avoid cables protruding from the case - they can act as aerials
c) use shielded cabling throughout, especially on audio and PTT lines etc.
d) where possible, use suppressor ferrites on cables. Sub-D connectors may be
available with built-in ferrites
e) configure your PC to boot without testing for a keyboard, and detach the
monitor during routine operation - these two items account for the bulk of the
RF emitted by a PC.
f) choose a low-noise power supply or UPS - it might just pay to ask before you
buy!
This could be more of a problem - especially when you have RF entering through your modem lines, causing your modem or SCC card etc. to behave strangely. This could be an issue especially if you are co-sited with a powerful broadcaster. Again, shielding cables and blocking RF through ferrites etc. is a good recipe.
Since your PC contains a fair number of "nonlinear devices" (this is an absolute understatement!), every cable going into the box could act as an antenna with an intermod source at its end. So even if it doesn't interrupt your packet flows, prudent construction with RF immunity in mind might just pay off.
With all the RF floating around, and the associated shielding to keep it in its proper place, it's easy to overlook that your node may need some maintenance at times. You may have to swap USCC cards and/or modems, or you may have to test different configurations of cards and modems.
The one big mistake I made in my first design was to give in to the interference hype - I designed a case that was triple-shielded just to keep the punters happy. Not only won't it let any RF in or out, it also steadfastly resists all attempts at changing any components without first disconnecting a myriad of screw-on connectors in hard-to-reach places. As a result, we have decided to embark on a redesign that will do away with a layer of (unnecessary) global shielding in favour of an easily accessible motherboard and spacious case.
Another reason for re-designing the node case in our project was the cramped conditions that exist in the present case. It's all great if you have a spare bus slot or two in your box - once you add the cables, it becomes clear that these are useless because there's no airspace left...
Obviously, as you upgrade, you may want to progressively replace motherboards with more recent types, and older drives and displays with more modern devices. For all these reasons, it's a good idea to opt for a large case.
This is a sore point for a lot of amateurs, especially in this corner of the world where incomes are low and dispensable income after buying the essentials is unheard of in many families. In countries where tech jobs are dime a dozen and companies run at an ample margin, both the spare cash and the quality of the junk are better. This often also goes along nicely with access to workshops and PCB prototyping labs.
The multimillionaires amongst the fraternity will probably be best off with an industrial PC - these come as 19-inch assemblies anyway and have all the features you could possibly ask for. Unfortunately, they'll make your top-of-the-line HF rig look cheap.
For the less fortunate rest of us I'd recommend keeping an eye open for suitable components at junk sales. Cases and monitors (from trustworthy sources) are good examples of items that can be gotten cheaply at junk sales from an ample supply. Keyboards are another example.
Buying drives and cards/motherboards/RAM at junk sales isn't a good idea unless they're surplus stock and from a trustworthy source. Specialist items such as SCC cards and modems or power supplies may have to be bought from a first-hand supplier anyway.
As a general rule, having a spare or two makes life a lot easier when it comes to testing.
Experiences with the Klondyke Node ZL1PKT and the ZL1DDL node
ZL1DDL node is a three-port node running PC/FlexNet on a 486 under DOS with two USCC cards, two 9600Bd ports, and one 1200Bd port, all simplex. This node runs straight off mains power and had its last reboot just over four months ago - it also serves as my experimental machine, and was used for experiments at about that time. While it sits in my shack, it has to cope with dust from the carpet, vibrations from the wooden floor, and temperatures between +10 and +30 deg C.
ZL1PKT node is located at a high point of Klondyke Road, a rural gravel road along a ridge about 80 km south of Auckland, 2 hours drive away from here and just under an hour for Bill ZL1TTH who does most of the leg work. It's the "remote" node we described above. It runs a bitregenerating 2m port, like a "repeater" where the received signals are retransmitted on the output in real time as a regenerated bit stream, as well as being received by the node itself.
This means that users only have to adjust their audio to one "partner" station - they always get the same audio no matter who transmits. They also have to meet the RX standards of the node only. This has led to a considerable reduction in complaints about what used to be a plain voice-style repeater. We also run a bitregenerating 70cm/9k6 port, and a currently unterminated 23cm 9k6 full duplex port which will hopefully link us to a FlexNet machine on Mt Egmont (300 km from Auckland, half-way to Wellington) soon. It'll help us find out whether there really is intelligent life south of the Bombay Hills (sri guys, ZL insider joke!).
It's now been up and running ever since the infamous power spike mentioned above, just over 50 days. We had it running continuously for 6 months between February and August last year. Even then the remote reboot was a diagnostic precaution to locate what turned out to be an RF fault. In general, the node has proved to be more reliable than any of the other pre-existing gear on site - microcontrollers, PA's, ...
Most node problems we had related to "finger trouble" - such as cables detached during maintenance that were not re-attached. RF problems on pre-existing equipment caused us some problems on the 2m port, this was fixed after using double-shielded cable on the RF side. We also had a case or two of TX lockups on user stations - not always easy to trace on a bitregenerating system. Some Linux versions of NOS seem to be a bit susceptible to this kind of behaviour.
The much-feared impairment of other services due to the arrival of the ZL1PKT node did not eventuate.
However, some of the other problems mentioned at the beginning of this article are showing up:
The excellent siting (408 m above sea level) has led to a large coverage area on the 2m/1200Bd user port. Our northernmost users are over 100 km from the site, our southernmost users about 200 km away. There are few users to the West - the site is only a few km from the Tasman Sea. To the East, we know of users that are over 100 km away.
Some of the users on the fringes of this de-facto coverage area get rather marginal service. While we never intended ZL1PKT node to be used by them, we don't want to exclude anyone either - after all, amateur radio is about having fun and making contacts, and we respect their enthusiasm. However, this adds to the channel load (especially when signals are marginal and retries are required) and hence decreases throughput for everyone. The availability of our service to users with good QTH's in faraway areas also proves to be a disincentive for packet development there. Why build your own node when you can piggyback on someone else's?
It also encourages the use of "crutches", such as stations digipeating into ZL1PKT node on our split 2m access - an absolute no-no. More often than not, a "quick fix" will help someone to get connected but turns out to be a problem in the long run. If one old codger far afield reads his packet mail at 3am in the morning once a week by direct digipeat through a station on our user port, hardly anyone will ever notice. However, if you permit his activity, it becomes harder to say no when his mates want to do the same. Drawing the line is often an ethical and political problem as much as an engineering one, and there are no simple answers. Diplomacy, sensitivity and political common sense as well as the ability to teach are helpful attributes if you're a sysop.
It also seems that the more people rely on crutches, the more difficult it becomes to make them move away from crutches for the greater good. For example, someone uses an outdated cluster program on a system with a weird hardware configuration that won't run under FlexNet. So your node can't really poll the cluster, which means they - and their users - prefer to stay on a single bitregenerating port rather than distributing themselves around the network. The problem is that while crutches may mean a big step forward for an individual ham, they're a small step backwards for the packet community as a whole.
Ulrich ZL1DDL / DL1NDB
ulrich@ihug.co.nz