Direwolf is a very popular software for APRS. It's been a game-changer that's allowed a lot of hams to get on APRS, and even set up gateways/digipeaters. It's easy to set up, and it runs on Mac OS X, Linux, and Windows XP. It can operate as a soundcard modem, which is acceptable as a replacement for a "real" TNC, and used in conjunction with other APRS clients.
In simple terms, Direwolf takes those audio "squawks" from your radio and "translates" them into text that your computer (and APRS client) can understand. And it does the same thing in reverse: it takes the text you want to transmit, and converts it into an audio signal that can be sent over your radio. This is why it's called a "modem" instead of a true TNC. The Mobilinkd TNC is also actually a modem, too. Both of these go beyond merely "translating", however, and control many aspects of what and how signals are handled. The lines between modems and "real" TNCs are blurring all of the time. But that's another discussion.
More importantly, though, Direwolf can also act as a standalone APRS station. Using Direwolf on a computer connected to a radio, you can run a gateway or a digipeater without any other hardware or software. That makes it very powerful. And the documentation provided guides a user through the most difficult parts. Hardware TNCs, such as the Kantronics KPC-3 and Microsat WX-3-in-1 often puzzle operators, or cause misconfigurations that create frustrations.
While I don't actually use Direwolf, I've looked at the user guide and have seen config files others use. The explanations provided in the configuration file help an inexperienced user avoid most of the common pitfalls, even providing helpful examples of proper setup parameters. The user guide tackles a broad array of potential applications, though I've found some critical aspects to be... lacking.
Audio levels
Any modem needs some way to set the audio levels for both transmit and receive. Especially if you are running a digipeater, you need to make sure that you aren't destroying the packets you handle by using an improper audio level. Likewise, an I-Gate will be rendered useless if the receive audio is set too low or too high, and the packets it transmits will also be unreadable.
Even an operator who wants to run a simple station, rather than a gateway or digipeater, needs to set the RX/TX audio levels properly. If they don't, they are just generating unreadable noise with their transmissions, and failing to receive most (if not all) traffic.
There's an even deeper issue with audio levels: the level of the individual tones you transmit. APRS uses two tones -- 1200 Hz and 2200 Hz -- to modulate the signal. These are the "low" and "high" tones, and each radio has a different audio characteristic. There is no "one size fits all" audio curve for radios. Generally, the level of each individual tone needs to set separately to ensure readability by other stations.
The user guide reveals that Direwolf uses an "automatic gain control" that analyzes the audio level of received signals. This assumes that other stations around you have their levels properly set.
Dire Wolf has an automatic gain control and can handle a very wide range of audio signal levels. Other systems are not as forgiving. A station using Dire Wolf can monitor the audio levels and advice those which are significantly different than most others.
I applaud the developers for trying to find a simple solution to a complex problem. I'll concede it often works well enough. If it doesn't, an operator can simply adjust the audio levels of their sound card, though that's often not very granular. The audio level is adjusted until the "automatic gain control" can work its magic and packets become readable.
Personally, I very much prefer the graphical signal displays other software packages use.
For transmit levels, the following instructions are given:
This is laughable. It's basically saying, "Don't screw it up". How does one know what the "average" is? Again, this assumes that other stations are properly set up. And, since so many stations use Direwolf, it creates a circular loop. In environments where there are few stations, that "average" could be wildly off. And there is no provision to adjust the level of each individual tone to account for the audio cutoff curve of your particular radio. If there's any other solution offered, I didn't find it by looking through the user guide.
The Mobilinkd TNC has a reasonable solution to this fairly complex problem. No "test equipment" is required to set the "deviation level". You need a second receiver (an HT, SDR, or scanner, etc.), however. The operator selects one of the tones for the transmitting radio, and starts with the lowest setting. The level is then increased until the tone is not heard in the separate receiver as being louder than the last incremental adjustment. The other tone is then adjusted in the same way.
Since there isn't any capability to adjust individual tone levels -- at least that I could find -- an operator could maybe try the same approach with Direwolf adjusting both tones at the same time. Still, I didn't find any revealing advice on setting the transmit audio level at all.
No messaging
There's a simple work-around for this, though. You use Direwolf as the TNC, and use a separate client (YAAC, APRSIS32, UI-View) to handle messaging. The user guide explains how to do this.
A potential problem is that other operators can't message you if your gateway or digipeater has issues. If you choose this option, you should include your email in your comment text, or at the very least provide an email address on QRZ.com. We have some local operators that fail this simple test. Another option would be to run a separate -IS only station on your phone (or tablet, laptop, etc.) that others could use to contact you.
If you consider the potential audio level issues I've mentioned, it seems unwise to unleash a problematic station on your local area, while using a "talk to the hand' strategy for anyone willing to inform you of the situation.
I also don't see any capability to create objects in the standalone software configuration. And, without messaging capability, bulletins and announcements can't be seen or sent.
MYCALL
In the configuration, the instructions do say that the MYCALL field should contain "call sign and SSID for your station", but this is placed at the beginning of the config file.
By the time the operator gets down to the "CHANNEL 0 PROPERTIES", this detail is forgotten, and the callsign itself is entered -- without the SSID. This often creates a conflict between the IGLOGIN field (who the APRS-IS server thinks you are), and the MYCALL field (who you are saying you are).
A simple reminder in the PROPERTIES area could avoid this problem. It's not a "blame" issue. But it's something that people who intend to use Direwolf for a gateway or digipeater should be more keenly aware of. To many, "MYCALL" means your callsign, and the SSID is not seen as part of your callsign.
The SSID is the number after the callsign, distinguishing your station from others using the same callsign. For example, you may use KL0WN-10 for your gateway, KL0WN-9 for your mobile, and KL0WN-7 for your phone.
No comments:
Post a Comment