The art of troubleshooting the digital world.

Foundations of Amateur Radio The lure of digital modes and the opportunities they bring are enough to tempt some amateurs to begin a journey into integrating their radio and computer to make a new world come to life. This isn't without pain or challenge, but the outcomes are so enticing that many embark on this adventure every day. As a person who has made this trip it's heart warming to see the joy writ large on the face of an amateur who makes their first FT8 contact on a home brew wire dipole rigged together on a Sunday afternoon to take advantage of the latest opening on the 10m band. On the flip side, it's heart breaking to see an amateur falter at the first hurdle, attempting to make their computer talk to their radio and giving up because it just won't work. At first this attitude bewildered me in a community of experimenters, but over time I've come to understand that sometimes an analogue approach isn't suited to the digital world. There isn't really a place where you can attach your multimeter and see why the serial connection isn't working, nor is there any universal document that can walk you through how to set things up. So, for you, if you're in a place where you've all but given up, let me see if I can find words to encourage you to keep trying. I'll skip the propaganda about going digital and move straight to making it work. This might come as a surprise, but in the digital world, things are built in complex layers of interdependence. Said in another way, using an analogy, to turn on a light you need flick a switch, which depends on power to the switch, which depends on power from the fuse box, which depends on power from the street, which depends on power from the substation and so-on. If you flick the switch and the light stays off, you need to figure out which part of the chain failed. Did it fail at the bulb or at the substation? If the street is dark, do you need to check the fuse box or the bulb? That's not to say that either, or even both, can also be faulty, but there's no point in checking until the street has power. From a fault finding perspective, the number of variables that you have control over, in the case of a light bulb not switching on, is strictly limited. You can control the bulb and the fuse and in most cases that's about it, the rest of the chain is outside your direct control. In attempting to make a computer talk to a radio you can be forgiven in thinking that the level of complexity associated with such a trivial task is just as direct and straightforward. Unfortunately, you'd be wrong. It's not your fault. A popular slogan "Plug and Play" made people think that computers were easy to use and control. The truth is a far darker reality. One of the hidden sources of frustration in the digital world is the extreme level of complexity. In our quest to standardise and simplify we have built a fragile Jenga tower of software that can collapse at any point. Most of the time this is completely invisible but that doesn't cause it to be any less real. Computers are simple, but only if you control the environment. And when I say control, I mean take ownership of each change. Updating the operating system? Installing a new application? Adding a new peripheral? Changing location? All these things, innocuous as they might seem, can fundamentally alter the behaviour of your environment. As an example, consider the location of your device. Let's say that you changed the location of your computer, either physically or via a preference. All of a sudden your Wi-Fi network stops working. The one that you used for years. Turns out that changing location changed the Wi-Fi driver to stop using a particular channel, not permitted in your new location. If you're curious, this happened to me last week. The point being that troubleshooting is about controlling change in that fragile environment. So, when you're trying to figure out how to make your serial connection work, you need to stop fiddling with everything all at once and change one thing at a time. Discovering the layers of dependency makes this difficult at times, but not impossible. For example, a working serial connection requires that both ends are physically connected, speaking the same language at the same speed. That depends on the radio being correctly configured, but it also depends on the computer having the right drivers installed. It also depends on the software you're using being configured correctly to talk to the right serial device and the operating system giving your software permission to do so. It depends on the software using the right radio mode and it depends on the radio being switched on. Now, imagine the serial connection "not working". Do you check the radio mode before you check if the radio is turned on? What about the physical connection? When you're troubleshooting, you cannot just look at the error message on the screen and follow that path. You need to ensure that all the underlying things are working first. You don't check the bulb until there's light in the street. Same thing. No need to worry about the error until you've discovered that the radio is on, the cable connected correctly, the driver installed correctly, the speeds set right and the mode configured properly. If and only if that's all correct, then look at the error. This becomes harder if it worked yesterday. What changed between then and now? Did your operating system do an update? Did your radio forget its settings? Did the cat jump on your desk and dislodge a cable overnight? Is there an earth fault that caused the serial connection to cease working? Sometimes, despite your best efforts, you cannot find the problem. At that point you need to take a step back and think about how to prove that something is working in the way that you think it is. Multimeter to a light bulb to check continuity - style. In the case of a serial connection, what can you use to test the link if your favourite tool doesn't work or stopped working suddenly? I've said this before, but it bears repeating, since it's not obvious. Troubleshooting is all about discovering and controlling change. Pick one thing to test, prove that it's correct, then pick the next. Eventually you'll come across a "Duh" moment. Don't sweat it, we've all been there. Now do it again! What's your best troubleshooting moment? I'm Onno VK6FLAB