The price of copper has risen by 300 percent over the last two years. Other metals have also risen in value. According to GB2RS News, this is making radio amateurs targets for copper thieves. An amateur in Yorkshire had all his cabling stolen including the coax and ladder line for his G5RV antenna.
I presume the action of an irate neighbour fed up with receiving TVI has been ruled out. The RSGB is encouraging amateurs to make sure access to cables is restricted and that their installations are as secure as possible. Looks like another benefit of stealth operation and attic antennas!
Monday, February 28, 2011
Sunday, February 27, 2011
Back to the drawing board
The weather forecast wasn't promising, even though the morning was fine. But I was keen to get out on the fells. Yesterday I spent a couple of hours making an antenna specifically for Wainwrights On The Air operating and I wanted to try it out. So I headed for Broom Fell, LDW-169.
I'd had the idea for this antenna for a couple of years but hadn't got around to making it. I was going to call it the WOTA Pole. As, for reasons I will come to, I'm unlikely to be publishing a detailed description of it, I'll give you the outline of it now. It's a Slim Jim made from 300 ohm flat ribbon cable, housed in a tube made of white UPVC electrical conduit. The tube breaks down into four sections for easy carrying using UPVC jointing pieces. It's a similar idea to the SOTA Beams MFD except that is a half wave dipole and has a T piece with a coaxial balun and can be used vertically or horizontally. The Slim Jim should theoretically have some gain over the dipole but it can't be used horizontally, which is no disadvantage as 99% of WOTA activating is done on FM.
One reason I haven't used the MFD very much is the difficulty in deploying it. The antenna is provided with two velcro straps so it can be attached to a convenient fence post. Unfortunately our hilltops don't often have convenient fence posts on the summit. My intention with the WOTA Pole had been to stuff the antenna in my rucksack for support so the radiating element would be above head height. Unfortunately UPVC jointing pieces aren't very strong and it's impossible to lift a rucksack onto your back whilst keeping a 2 metre long antenna perfectly vertical to minimize the strain on the joins. As I lifted it up I heard a crack and the antenna fell to pieces!
I didn't see any damage. It was quite windy up there and I thought the culprit was the wind, plus perhaps I hadn't pushed the jointing pieces tightly enough together. So instead I decided to strap the antenna to a convenient fence post which fortunately Broom Fell just happened to be equipped with right by the summit cairn. You can see the result in the photo. Lords Seat is the fell on the right in middle distance, with the Skiddaw range further away on the left.
Sunday lunchtime is not the best time to go WOTA activating. I think many chasers are busy filling themselves with roast beef and yorkshire pudding and nowhere near their radios. However Colin 2E0XSD was on frequency having been following my progress via APRS. He gave me a 59 plus report on the new antenna. After a couple of fruitless CQs I started to think that was going to be the lot, then Geoff GM4WHA came up, followed by Malcolm M0XAT. Then no-one. As the wind was bending the WOTA Pole rather a lot I took it down. I then tried a couple more calls using a helical antenna and got Mark MM1MPB and Tony G1OAE. Finally Colin 2E0XSD came up again to say I was only 4 by 3 on the helical antenna. The WOTA Pole had made a huge difference. It's just a pity there hadn't been anyone further afield listening at the time.
I walked down the hill a short way to get out of the wind and have the sandwiches and coffee that Olga had made for me. While I was down there I thought I would have another try at hoisting the antenna on to my back in the rucksack. Then I noticed that one of the UPVC jointing pieces - the one at the top of the lowest tube that takes most of the strain - had cracked. When I tried to get it aloft a piece broke away completely and the antenna fell to the ground. Another idea bites the dust. Literally!
On the way down I was pondering what I could do to make this idea work. Clearly the Slim Jim itself performed very well. In fact if anything it worked a bit too well on receive. The VX-8GR receiver exhibited clear signs of overload. I'd noticed this before when I'd used that radio with the MFD. I should really use the Motorola GP-300. Ironic that a radio that cost me £1 at a rally works better than a fancy Yaesu costing more than £300!
The problem with my WOTA Pole idea is the mechanical design. If I'd made the tube two one metre pieces instead of four 50cm lengths it would be stronger. But having something sticking 50cm above the top of my rucksack would be a nuisance when walking under low branches or ducking under fallen trees as I actually had to do on this walk.
Perhaps I should give up the idea entirely and try to make a rucksack mount for BNC fitting antennas. Then I could use the telescopic 5/8 wave that I usually use on less windy days fitted directly to the radio. What do you think?
I'd had the idea for this antenna for a couple of years but hadn't got around to making it. I was going to call it the WOTA Pole. As, for reasons I will come to, I'm unlikely to be publishing a detailed description of it, I'll give you the outline of it now. It's a Slim Jim made from 300 ohm flat ribbon cable, housed in a tube made of white UPVC electrical conduit. The tube breaks down into four sections for easy carrying using UPVC jointing pieces. It's a similar idea to the SOTA Beams MFD except that is a half wave dipole and has a T piece with a coaxial balun and can be used vertically or horizontally. The Slim Jim should theoretically have some gain over the dipole but it can't be used horizontally, which is no disadvantage as 99% of WOTA activating is done on FM.
One reason I haven't used the MFD very much is the difficulty in deploying it. The antenna is provided with two velcro straps so it can be attached to a convenient fence post. Unfortunately our hilltops don't often have convenient fence posts on the summit. My intention with the WOTA Pole had been to stuff the antenna in my rucksack for support so the radiating element would be above head height. Unfortunately UPVC jointing pieces aren't very strong and it's impossible to lift a rucksack onto your back whilst keeping a 2 metre long antenna perfectly vertical to minimize the strain on the joins. As I lifted it up I heard a crack and the antenna fell to pieces!
I didn't see any damage. It was quite windy up there and I thought the culprit was the wind, plus perhaps I hadn't pushed the jointing pieces tightly enough together. So instead I decided to strap the antenna to a convenient fence post which fortunately Broom Fell just happened to be equipped with right by the summit cairn. You can see the result in the photo. Lords Seat is the fell on the right in middle distance, with the Skiddaw range further away on the left.
Sunday lunchtime is not the best time to go WOTA activating. I think many chasers are busy filling themselves with roast beef and yorkshire pudding and nowhere near their radios. However Colin 2E0XSD was on frequency having been following my progress via APRS. He gave me a 59 plus report on the new antenna. After a couple of fruitless CQs I started to think that was going to be the lot, then Geoff GM4WHA came up, followed by Malcolm M0XAT. Then no-one. As the wind was bending the WOTA Pole rather a lot I took it down. I then tried a couple more calls using a helical antenna and got Mark MM1MPB and Tony G1OAE. Finally Colin 2E0XSD came up again to say I was only 4 by 3 on the helical antenna. The WOTA Pole had made a huge difference. It's just a pity there hadn't been anyone further afield listening at the time.
I walked down the hill a short way to get out of the wind and have the sandwiches and coffee that Olga had made for me. While I was down there I thought I would have another try at hoisting the antenna on to my back in the rucksack. Then I noticed that one of the UPVC jointing pieces - the one at the top of the lowest tube that takes most of the strain - had cracked. When I tried to get it aloft a piece broke away completely and the antenna fell to the ground. Another idea bites the dust. Literally!
On the way down I was pondering what I could do to make this idea work. Clearly the Slim Jim itself performed very well. In fact if anything it worked a bit too well on receive. The VX-8GR receiver exhibited clear signs of overload. I'd noticed this before when I'd used that radio with the MFD. I should really use the Motorola GP-300. Ironic that a radio that cost me £1 at a rally works better than a fancy Yaesu costing more than £300!
The problem with my WOTA Pole idea is the mechanical design. If I'd made the tube two one metre pieces instead of four 50cm lengths it would be stronger. But having something sticking 50cm above the top of my rucksack would be a nuisance when walking under low branches or ducking under fallen trees as I actually had to do on this walk.
Perhaps I should give up the idea entirely and try to make a rucksack mount for BNC fitting antennas. Then I could use the telescopic 5/8 wave that I usually use on less windy days fitted directly to the radio. What do you think?
Friday, February 25, 2011
An FM/AM/SSB handheld for 10 and 12m
I love handheld radios. The "holy grail" for me is to make long distance contacts using a handheld radio with attached antenna. Ten metres is probably the best band to achieve this. Six metres might give stronger signals when conditions are right but it is open too rarely. Lower frequencies are open more often but a practical hand-held antenna is too short and inefficient for voice contacts using low power to be possible. You can put up a ground mounted vertical or hang a dipole in the trees but then it isn't portable.
Last year I got an Intek H-520 which I used on 10m FM but although I did make some nice contacts with it I was disappointed with the radio itself. It was very power-hungry for 6 NiMH AA cells to the extent that the radio would shut down when used on maximum power unless the batteries had just been charged up. There is another problem with 10m FM in general which is that there are not all that many channels. There is a lot of QRM when the band is open, you are competing with people running a lot more than 4W to a whip antenna and in the FM mode "capture effect" means the strongest signal wipes out all others. So when I saw that a multimode handheld including SSB and covering both the 10m and 12m amateur bands was available, I decided that this was the toy for the forthcoming summer months. SSB offers the chance for some exciting handheld contacts.
The Albrecht AE2990AFS is a multimode multi-standard CB handheld radio that is readily configurable for amateur band use. There are instructions on the web and even a YouTube video on how to do the modification but the supplier included a printed copy in the box. Briefly, you pull out the rubber PTT cover which reveals five contacts next to the PTT switch. Using a soldering iron and solder wick you remove a bridge between two contacts (preferably without touching the hot solder wick on the case and melting it like I did!) then you short out two other contacts while turning the radio on. You can then choose various channel options including three for hams: Code 0 (10m + 12m switching between them using the CH9 button), Code 1 (10m band only with home frequencies 29.300 and 29.600 selected using CH9) and Code 2 (12m band only.) I chose Code 0 to get the benefit of two amateur bands.
No batteries are supplied and no charger either. The lack of a charger is a bit annoying as the charger socket is a fairly small barrel type that isn't easily obtainable (even after you've guessed the dimensions.) The battery pack takes 9 NiMH AA cells and has contacts on the bottom. A drop-in charger is available as an optional extra. I will probably make one as I did for the old TH-205E. But first I have to establish what the charging voltage is. The box the radio came in suggests the charger/DC socket on the side of the battery pack takes 12V. You can certainly run the radio off that, but when it is switched off it draws no current. It looks as if you would have to crank the voltage up to about 18V to charge 2400mAH NiMH cells at 240mA, which would probably have dire consequences if you switched the radio on with the charger connected. But with the lack of propagation on 10 and 12 metres I probably have a few weeks to figure it out.
The antenna supplied is about 8 inches long. I checked it using my antenna analyzer and was pleased to find that it was resonant on 28.5MHz with quite a sharp SWR curve. However such a small antenna is probably little better than useless for making contacts over more than a few miles. I have a 45in telescopic 10m antenna and that is what I plan to use with this radio.
The Albrecht AE2990AFS is ready for the new European harmonized CB frequency allocation (which the UK wants to opt out of) so the output is rated at 4W on FM and 4W PEP on SSB. The actual power measured on 10m FM from this radio was only 2.13W. This is similar to what I found with the Intek H-520. With the Intek I was able to get inside, find the power adjuster and tweak it up to 4W. That's when I discovered why it had been set lower in the factory - the current draw at 4W is just too high for many AA rechargeables to sustain. Most CB users would never know their radio was giving less power than claimed because they have nothing to measure it with, so they would never complain. If it cut out whenever they press the PTT then they would. We hams complain that our radios are expensive but they are built to a higher standard than CB radios. You get what you pay for.
With its 9 cell battery pack the Albrecht doesn't need to draw so much current as the Intek for the same power. While it was on the bench power supply I measured the current draw on FM "high power" (2W) as 800mA. On the low power position which is meant to be 1W but was actually 0.51W the draw was 500mA. Unlike the Intek there is a "warranty is void if you remove this" sticker over the two halves of the case so I can't delve inside undetected. As I have heard of people who bought similar radios under other brand names which broke and had to be returned under warranty I don't want to void it, so I'll have to live with 2W output, at least until next year.
On SSB the modulation out of the box was almost nonexistent. This is dependent on the mic gain setting, which can be adjusted from the front panel. After increasing it the SSB modulation was much improved and although I don't have a peak reading meter the average level gave me to believe I was getting 4W PEP.
The audio on SSB sounded clean but if you increase the mic gain in order to get reasonable talk power there is noticeable frequency modulation on the signal. I am guessing that the battery voltage sags a bit on speech peaks and this pulls the local oscillator. I had read about this issue in some forums discussing the other incarnations of this radio and someone stated that in the Albrecht versions this problem had been fixed. It appears this may not be the case. I doubt that the fault would make the audio unreadable but I would expect to receive comments about it.
I recorded a number of audio samples at different mic gain settings for comparison. You can hear the FM increase on voice peaks as the mic gain increases.
There are five memory channels which store frequency and mode, so you can switch quickly between FM and SSB calling frequencies for example. You can select a shift or offset of up to 990kHz for repeater use. There is also a CTCSS tone for repeater access, but the manual implies it is a fixed 88.5Hz tone which (apparently) is used by 10m repeaters in the USA. This is straight from the manual - I can't vouch for it.
With the lack of any propagation on 10 or 12 metres I obviously haven't had a chance make any contacts with the radio or evaluate the receiver sensitivity. The RF gain and squelch sensitivity can also be adjusted from the front panel in the same way as the mic gain. There is even a roger beep!
So there you have it. The below-specification power and FM-y SSB audio are fairly major faults, all things considered. But the Albrecht AE2990AFS is the only true handheld SSB-capable radio for any amateur band currently available. If that's what you want, it's your only option.
Last year I got an Intek H-520 which I used on 10m FM but although I did make some nice contacts with it I was disappointed with the radio itself. It was very power-hungry for 6 NiMH AA cells to the extent that the radio would shut down when used on maximum power unless the batteries had just been charged up. There is another problem with 10m FM in general which is that there are not all that many channels. There is a lot of QRM when the band is open, you are competing with people running a lot more than 4W to a whip antenna and in the FM mode "capture effect" means the strongest signal wipes out all others. So when I saw that a multimode handheld including SSB and covering both the 10m and 12m amateur bands was available, I decided that this was the toy for the forthcoming summer months. SSB offers the chance for some exciting handheld contacts.
No batteries are supplied and no charger either. The lack of a charger is a bit annoying as the charger socket is a fairly small barrel type that isn't easily obtainable (even after you've guessed the dimensions.) The battery pack takes 9 NiMH AA cells and has contacts on the bottom. A drop-in charger is available as an optional extra. I will probably make one as I did for the old TH-205E. But first I have to establish what the charging voltage is. The box the radio came in suggests the charger/DC socket on the side of the battery pack takes 12V. You can certainly run the radio off that, but when it is switched off it draws no current. It looks as if you would have to crank the voltage up to about 18V to charge 2400mAH NiMH cells at 240mA, which would probably have dire consequences if you switched the radio on with the charger connected. But with the lack of propagation on 10 and 12 metres I probably have a few weeks to figure it out.
The antenna supplied is about 8 inches long. I checked it using my antenna analyzer and was pleased to find that it was resonant on 28.5MHz with quite a sharp SWR curve. However such a small antenna is probably little better than useless for making contacts over more than a few miles. I have a 45in telescopic 10m antenna and that is what I plan to use with this radio.
The Albrecht AE2990AFS is ready for the new European harmonized CB frequency allocation (which the UK wants to opt out of) so the output is rated at 4W on FM and 4W PEP on SSB. The actual power measured on 10m FM from this radio was only 2.13W. This is similar to what I found with the Intek H-520. With the Intek I was able to get inside, find the power adjuster and tweak it up to 4W. That's when I discovered why it had been set lower in the factory - the current draw at 4W is just too high for many AA rechargeables to sustain. Most CB users would never know their radio was giving less power than claimed because they have nothing to measure it with, so they would never complain. If it cut out whenever they press the PTT then they would. We hams complain that our radios are expensive but they are built to a higher standard than CB radios. You get what you pay for.
With its 9 cell battery pack the Albrecht doesn't need to draw so much current as the Intek for the same power. While it was on the bench power supply I measured the current draw on FM "high power" (2W) as 800mA. On the low power position which is meant to be 1W but was actually 0.51W the draw was 500mA. Unlike the Intek there is a "warranty is void if you remove this" sticker over the two halves of the case so I can't delve inside undetected. As I have heard of people who bought similar radios under other brand names which broke and had to be returned under warranty I don't want to void it, so I'll have to live with 2W output, at least until next year.
On SSB the modulation out of the box was almost nonexistent. This is dependent on the mic gain setting, which can be adjusted from the front panel. After increasing it the SSB modulation was much improved and although I don't have a peak reading meter the average level gave me to believe I was getting 4W PEP.
The audio on SSB sounded clean but if you increase the mic gain in order to get reasonable talk power there is noticeable frequency modulation on the signal. I am guessing that the battery voltage sags a bit on speech peaks and this pulls the local oscillator. I had read about this issue in some forums discussing the other incarnations of this radio and someone stated that in the Albrecht versions this problem had been fixed. It appears this may not be the case. I doubt that the fault would make the audio unreadable but I would expect to receive comments about it.
I recorded a number of audio samples at different mic gain settings for comparison. You can hear the FM increase on voice peaks as the mic gain increases.
- Albrecht AE2990AFS SSB audio - mic gain 7
- Albrecht AE2990AFS SSB audio - mic gain 8
- Albrecht AE2990AFS SSB audio - mic gain 9
- Albrecht AE2990AFS SSB audio - mic gain 10
- FT-817 audio (for comparison)
There are five memory channels which store frequency and mode, so you can switch quickly between FM and SSB calling frequencies for example. You can select a shift or offset of up to 990kHz for repeater use. There is also a CTCSS tone for repeater access, but the manual implies it is a fixed 88.5Hz tone which (apparently) is used by 10m repeaters in the USA. This is straight from the manual - I can't vouch for it.
With the lack of any propagation on 10 or 12 metres I obviously haven't had a chance make any contacts with the radio or evaluate the receiver sensitivity. The RF gain and squelch sensitivity can also be adjusted from the front panel in the same way as the mic gain. There is even a roger beep!
So there you have it. The below-specification power and FM-y SSB audio are fairly major faults, all things considered. But the Albrecht AE2990AFS is the only true handheld SSB-capable radio for any amateur band currently available. If that's what you want, it's your only option.
Unreliable connection
The webmaster of Summits On The Air kindly gave me permission to access the SOTA Spots RSS feed from the Wainwrights On The Air website so that spots for SOTA summits that are also Wainwright summits can automagically appear in the WOTA system. I started work on that the day before yesterday. I also noticed that APRS objects for the position of Mads, M/LA1TPA/P, were not appearing because the length of his call exceeded the maximum length of an APRS object name. I implemented a fix for that by lopping off the /P if the name would exceed 9 characters. Yesterday morning I did not receive any SOTA alerts over APRS at all so I wondered if I had broken something.
It didn't help that I had trouble accessing aprs.fi to see whether the APRS spots were getting out. That might have given me a clue as to where the problem lay. As it was, it took quite a lot of time before I realized that the problem was my internet connection. Although the ADSL was up and working, I was having trouble connecting to various sites including the APRS-IS Tier 2 servers and packets were being lost along the way.
This forced me to address another problem. Currently all the APRS packets are sent by the WOTA website calling a file on a web server running on a network attached storage (NAS) backup device running in G4ILO's shack which is actually a little Linux computer that runs Apache. This server hosts the script that sends the packet to the APRS network. I had tried running the script on the WOTA web server itself but it hadn't worked and I didn't know why so I decided to go for the path of least resistance since life is too short for making computers work the way I want them to.
Apart from the problem of connectivity with this solution there is also one of continuity. I don't like to run computers 24/7 because it adds a significant amount to an electricity bill that is already high due to the fact that there are two people using even more computers and equipment home all day. Also, Olga is not happy about leaving any equipment running when we go away. Whilst it is unlikely that anyone will activate summits in the middle of the night they are certainly going to do so while we are on holiday. So I really need to send the APRS alerts entirely from the web server.
After another couple of hours of getting nowhere I filed a support ticket with the web hos. They replied that they block port 8080 which is the one used to post APRS packets to the network using HTTP. When you are paying $8 a month for web hosting there is a limit to the amount of help you can expect particularly when it comes to changing the configuration of the server (which no doubt hosts hundreds of sites) just for my convenience. The last reply said "please try now" but I did and it still didn't work. So it looks as if I might have to live with having APRS spot functionality that goes QRT when we are on holiday.
Meanwhile I am waiting for someone to activate a SOTA summit in the Lake District so I can see whether my script to check the SOTA spots RSS file is doing what it supposed to.
It didn't help that I had trouble accessing aprs.fi to see whether the APRS spots were getting out. That might have given me a clue as to where the problem lay. As it was, it took quite a lot of time before I realized that the problem was my internet connection. Although the ADSL was up and working, I was having trouble connecting to various sites including the APRS-IS Tier 2 servers and packets were being lost along the way.
This forced me to address another problem. Currently all the APRS packets are sent by the WOTA website calling a file on a web server running on a network attached storage (NAS) backup device running in G4ILO's shack which is actually a little Linux computer that runs Apache. This server hosts the script that sends the packet to the APRS network. I had tried running the script on the WOTA web server itself but it hadn't worked and I didn't know why so I decided to go for the path of least resistance since life is too short for making computers work the way I want them to.
Apart from the problem of connectivity with this solution there is also one of continuity. I don't like to run computers 24/7 because it adds a significant amount to an electricity bill that is already high due to the fact that there are two people using even more computers and equipment home all day. Also, Olga is not happy about leaving any equipment running when we go away. Whilst it is unlikely that anyone will activate summits in the middle of the night they are certainly going to do so while we are on holiday. So I really need to send the APRS alerts entirely from the web server.
After another couple of hours of getting nowhere I filed a support ticket with the web hos. They replied that they block port 8080 which is the one used to post APRS packets to the network using HTTP. When you are paying $8 a month for web hosting there is a limit to the amount of help you can expect particularly when it comes to changing the configuration of the server (which no doubt hosts hundreds of sites) just for my convenience. The last reply said "please try now" but I did and it still didn't work. So it looks as if I might have to live with having APRS spot functionality that goes QRT when we are on holiday.
Meanwhile I am waiting for someone to activate a SOTA summit in the Lake District so I can see whether my script to check the SOTA spots RSS file is doing what it supposed to.
Wednesday, February 23, 2011
Another Notcom opt-out
A few weeks ago the European Union's Frequency Management Working Group agreed a harmonized specification for Citizens' Band Radio across Europe to include AM, FM and SSB modes. It will now go to public consultation before being passed to national governments to become law. However Ofcom, the radio regulatory authority in the UK, is expected to live up to its nickname of Notcom by saying "no" to allowing AM and SSB, claiming there is a potential for harmful interference to other services. How absurd!
Now some readers may be wondering why a ham radio blog is concerning itself with whether CB users should be allowed to use the AM and SSB modes. After all, if they want to use those modes they could just get a ham radio license, surely? The test is so easy even a child could pass it, and many do. So what's to complain about?
But that isn't the point. The point is this is one more example of how we in Britain always seem to get the mucky end of the stick when it comes to European legislation. We're told we can't opt out of European human rights law that seems to attach more importance to the rights of criminals, rapists, murderers and paedophiles than their victims. But when it comes to something as unimportant as giving a few hobbyists the right to use the same modes as their counterparts across the North Sea, opt out we can. Are we in Europe or aren't we?
If allowing CBers the use of AM and SSB isn't a problem for the rest of Europe then it isn't going to be a problem in the UK. If there was "a potential for harmful interference to other services" then that would surely have been proven by now, since there are plenty of people illegally using SSB on 27MHz already. How many people have been caught and prosecuted for using SSB on 27MHz? Hint: it's a very round number. And if there is a risk of harmful interference to other services from allowing people to use 12W of SSB on 27MHz, why is there no risk from allowing hams to use 400W a few hundred kHz higher?
There is no sound basis for preventing British CBers from enjoying the same frequencies and modes as their counterparts in the rest of Europe, just as there is no sound basis for restricting the use by British radio amateurs of digipeaters and internet connected nodes. It is about time we had a more open regulatory system in this country so that radio users cannot be denied something for false or risible reasons.
Now some readers may be wondering why a ham radio blog is concerning itself with whether CB users should be allowed to use the AM and SSB modes. After all, if they want to use those modes they could just get a ham radio license, surely? The test is so easy even a child could pass it, and many do. So what's to complain about?
But that isn't the point. The point is this is one more example of how we in Britain always seem to get the mucky end of the stick when it comes to European legislation. We're told we can't opt out of European human rights law that seems to attach more importance to the rights of criminals, rapists, murderers and paedophiles than their victims. But when it comes to something as unimportant as giving a few hobbyists the right to use the same modes as their counterparts across the North Sea, opt out we can. Are we in Europe or aren't we?
If allowing CBers the use of AM and SSB isn't a problem for the rest of Europe then it isn't going to be a problem in the UK. If there was "a potential for harmful interference to other services" then that would surely have been proven by now, since there are plenty of people illegally using SSB on 27MHz already. How many people have been caught and prosecuted for using SSB on 27MHz? Hint: it's a very round number. And if there is a risk of harmful interference to other services from allowing people to use 12W of SSB on 27MHz, why is there no risk from allowing hams to use 400W a few hundred kHz higher?
There is no sound basis for preventing British CBers from enjoying the same frequencies and modes as their counterparts in the rest of Europe, just as there is no sound basis for restricting the use by British radio amateurs of digipeaters and internet connected nodes. It is about time we had a more open regulatory system in this country so that radio users cannot be denied something for false or risible reasons.
Free Windows sound recorder needed
Here's a question for you software experts out there. Do you know of a free, simple, no-frills sound recorder application that can record audio from any sound card?
Windows Sound Recorder has the simplicity I need, but it can only record from the default recording device. If I want to record from the radio I have to change the default input device to whatever sound card is attached to that radio. This usually results in hours of head-scratching later on after I forget to switch the default sound card back.
Audacity is the sound recorder application most people recommend. It is free, and it can record from any sound card, but the user interface is so complicated I can't figure out how to use it.
So I have decided to ask you, my readers. I imagine this is something that many hams have tried to do. What do you use?
Windows Sound Recorder has the simplicity I need, but it can only record from the default recording device. If I want to record from the radio I have to change the default input device to whatever sound card is attached to that radio. This usually results in hours of head-scratching later on after I forget to switch the default sound card back.
Audacity is the sound recorder application most people recommend. It is free, and it can record from any sound card, but the user interface is so complicated I can't figure out how to use it.
So I have decided to ask you, my readers. I imagine this is something that many hams have tried to do. What do you use?
Tuesday, February 22, 2011
WX-1 baud rate fix
On Thursday I wrote about how my WX-1 APRS weather station was not being received by my TH-D72 and the PIC TNC because the baud rate was slightly fast, and of my unsuccessful attempt to fix it. Glenn W9IQ offered to take a look at the PIC source code and see if there was an easy fix. I sent him a link to the code and a day later I got a reply back. Glenn's suggestion solved the problem perfectly. But he didn't just tell me what to change, he explained what the code did and how it worked. I thought that his explanation would be of interest to anyone trying to understand how packet tones are generated using a PIC, so with his permission I am copying it here.
"The baud rate is determined by an interrupt service routine. The interrupt is driven by Timer 0 (TMR0) that is configured to use the instruction clock as its input (frequency of Y1 divided by 4). The input of TMR0 is also initialized to have a divide by 32 prescaler (the code comment says 16 but that is wrong). So at this point the timer is being driven by the frequency of Y1 divided by 128 or (20 MHz / 128) = 156.25 kHZ or a period of 6.4 uS.
Now the math and routines get a little more complicated. The interrupt is serviced by the code in the "packet" file. This code sets the TMR0 count to start at a value of 127. This TMR0 count will tick up one count every 6.2 uS (the clock from the output of the prescaler). When the timer count rolls over from 255 to 0, the interrupt is triggered.
At first glance, it would appear that this would generate an interrupt every 129 counts or 825.6 uS (6.4 uS * 129). That would seem to put the interrupt at roughly 1211 Hertz ( 1/825.6 uS). But this is not correct due to the way the author wrote the interrupt routine plus a small nuance of how a PIC handles the reset of the prescaled interrupt timer.
The interrupt service routine in "packet" executes 6 instructions before resetting the interrupt timer to a value of 127. Each instruction takes 4 clock cycles so this adds another 1.2 uS to the time between interrupts. In addition, when the prescaled interrupt timer register is written, there are another 4 instruction cycles of delay before the timer starts to run again. This is another 0.8 uS added to the interrupt time. So we now have an interrupt cycle of 825.6 uS + 1.2 uS + 0.8 uS totaling 827.6 uS or 1208 Hz. I believe this is what you measured as the current baud rate from your board.
Improving this is fairly straight forward. The interrupt goal is 1200 Hz or 833.3 uS. If we change the TMR0 count to 126 instead of 127, this will add another 6.4 uS to the interrupt period. This would give us 827.6 uS + 6.4 uS = 834 uS. Then if we eliminate one instruction in the interrupt routine, we eliminate a 0.2 uS delay for a total interrupt time of 834 uS - 0.2 uS = 833.8 uS or 1199.3 Hz.
This change is effected in the code located in the "packet" file. Look for the following code fragment:
Change this code fragment to read like this:
Recompile everything and reload the processor and you should see the baud rate drop as described."
When I ran the modified code the baud rate dropped from 1207/8 baud to 1198/9 baud which is pretty much just as Glenn predicted. The weather station is now being received by the Kenwood TH-D72 as well as my other APRS radios. It can also now be received using the PIC TNC though the level of the receiver audio is critical and unfortunately not the same as that needed to decode the VX-8R. I think that is because the maximum deviation I can get out of the Radiometrix transmitter module is a bit on the low side.
I had an anxious couple of minutes when I found that although the D72 was decoding the packets it was rejecting them as invalid. This turned out to be because the position co-ordinates had a lower case n for North and w for west: In my haste to see what effect the changed code had I had entered the settings carelessly, though the other radios didn't seem to mind. That was soon fixed.
The WX-1 weather station is now back in position beaconing the temperature, humidity and pressure as G4ILO-5. I would like once again to express my thanks to Glenn W9IQ for acting in the finest spirit of ham radio and helping me out with this.
"The baud rate is determined by an interrupt service routine. The interrupt is driven by Timer 0 (TMR0) that is configured to use the instruction clock as its input (frequency of Y1 divided by 4). The input of TMR0 is also initialized to have a divide by 32 prescaler (the code comment says 16 but that is wrong). So at this point the timer is being driven by the frequency of Y1 divided by 128 or (20 MHz / 128) = 156.25 kHZ or a period of 6.4 uS.
Now the math and routines get a little more complicated. The interrupt is serviced by the code in the "packet" file. This code sets the TMR0 count to start at a value of 127. This TMR0 count will tick up one count every 6.2 uS (the clock from the output of the prescaler). When the timer count rolls over from 255 to 0, the interrupt is triggered.
At first glance, it would appear that this would generate an interrupt every 129 counts or 825.6 uS (6.4 uS * 129). That would seem to put the interrupt at roughly 1211 Hertz ( 1/825.6 uS). But this is not correct due to the way the author wrote the interrupt routine plus a small nuance of how a PIC handles the reset of the prescaled interrupt timer.
The interrupt service routine in "packet" executes 6 instructions before resetting the interrupt timer to a value of 127. Each instruction takes 4 clock cycles so this adds another 1.2 uS to the time between interrupts. In addition, when the prescaled interrupt timer register is written, there are another 4 instruction cycles of delay before the timer starts to run again. This is another 0.8 uS added to the interrupt time. So we now have an interrupt cycle of 825.6 uS + 1.2 uS + 0.8 uS totaling 827.6 uS or 1208 Hz. I believe this is what you measured as the current baud rate from your board.
Improving this is fairly straight forward. The interrupt goal is 1200 Hz or 833.3 uS. If we change the TMR0 count to 126 instead of 127, this will add another 6.4 uS to the interrupt period. This would give us 827.6 uS + 6.4 uS = 834 uS. Then if we eliminate one instruction in the interrupt routine, we eliminate a 0.2 uS delay for a total interrupt time of 834 uS - 0.2 uS = 833.8 uS or 1199.3 Hz.
This change is effected in the code located in the "packet" file. Look for the following code fragment:
movlw 0x80 ; 128 decimal
sublw 0xFF ; subtract 128 from 255 to get TMR0
movwf TMR0 ; move it to the TMR0 register
Change this code fragment to read like this:
movlw 0x7E ; 126 decimal
movwf TMR0 ; move it into the TMR0 register
Recompile everything and reload the processor and you should see the baud rate drop as described."
When I ran the modified code the baud rate dropped from 1207/8 baud to 1198/9 baud which is pretty much just as Glenn predicted. The weather station is now being received by the Kenwood TH-D72 as well as my other APRS radios. It can also now be received using the PIC TNC though the level of the receiver audio is critical and unfortunately not the same as that needed to decode the VX-8R. I think that is because the maximum deviation I can get out of the Radiometrix transmitter module is a bit on the low side.
I had an anxious couple of minutes when I found that although the D72 was decoding the packets it was rejecting them as invalid. This turned out to be because the position co-ordinates had a lower case n for North and w for west: In my haste to see what effect the changed code had I had entered the settings carelessly, though the other radios didn't seem to mind. That was soon fixed.
The WX-1 weather station is now back in position beaconing the temperature, humidity and pressure as G4ILO-5. I would like once again to express my thanks to Glenn W9IQ for acting in the finest spirit of ham radio and helping me out with this.
Sunday, February 20, 2011
Longlands Fell, LDW-179
Today Geoff GM4WHA became the first Wainwrights On The Air (WOTA) chaser to claim a certificate. He worked me on Longlands Fell (LDW-179) thereby completing Wainwright's Northern Fells having made contacts with stations operating from each of the fells in that book.
Noticing that a few chasers were just a few fells short of completing a book, I suggested in the WOTA forum that chasers should post the fells they need, which might motivate some activators to go out and activate them. Geoff duly posted, and Longlands Fell was one of the ones he needed. As it is only about 20 minutes drive from here and an easy walk, I thought it would be a good idea to blow away the cobwebs of more than two months of slothful inactivity by activating it. So I did.
Despite an early start (for me) I was lucky to find a place to park at Longlands near the Uldale Common track. The ascent is quite easy up a grass path, but due to the long period of inactivity (and having put on a couple of kilos since Christmas) I had to stop for a breather rather a lot. The photo shows the view from the top with the summit cairn in the foreground, Over Water in the middle distance and the often visited summit of Binsey (LDW-190) in the background. What it doesn't show was the bitingly cold strong wind which numbed my fingers and made it too difficult to use the 5/8 telescopic antenna.
Despite using a 7in. helical antenna (which tests have shown to perform comparably to a 19in. quarter wave whip and much better than the dummy load supplied with the handheld rig) I made 9 contacts from the summit including the all-important one with Geoff, which is good going from such a summit which is well screened to the south.
I have probably said this too often, but WOTA keeps on getting more and more popular. I'm hearing new chasers all the time - the latest recruit is Steve, M6CDX - and even people who originally said they were getting too decrepit to climb the fells have been heard operating from some of the lower ones. So far this year I have worked 50 different summits and made 72 WOTA contacts from home, not far short of my total for the whole of 2010, and we're only a bit over half way through the second month. I'm sure others have also noticed the greatly increased activity.
There is great camaraderie among all the participants, too, many of whom feel like old friends even though most of us have never met. I think it is fair to say that the success of WOTA has exceeded my wildest expectations. Combining two of my favourite activities - walking in our wonderful mountains and making contacts on the radio - it doesn't get much better than this!
Noticing that a few chasers were just a few fells short of completing a book, I suggested in the WOTA forum that chasers should post the fells they need, which might motivate some activators to go out and activate them. Geoff duly posted, and Longlands Fell was one of the ones he needed. As it is only about 20 minutes drive from here and an easy walk, I thought it would be a good idea to blow away the cobwebs of more than two months of slothful inactivity by activating it. So I did.
Despite an early start (for me) I was lucky to find a place to park at Longlands near the Uldale Common track. The ascent is quite easy up a grass path, but due to the long period of inactivity (and having put on a couple of kilos since Christmas) I had to stop for a breather rather a lot. The photo shows the view from the top with the summit cairn in the foreground, Over Water in the middle distance and the often visited summit of Binsey (LDW-190) in the background. What it doesn't show was the bitingly cold strong wind which numbed my fingers and made it too difficult to use the 5/8 telescopic antenna.
Despite using a 7in. helical antenna (which tests have shown to perform comparably to a 19in. quarter wave whip and much better than the dummy load supplied with the handheld rig) I made 9 contacts from the summit including the all-important one with Geoff, which is good going from such a summit which is well screened to the south.
I have probably said this too often, but WOTA keeps on getting more and more popular. I'm hearing new chasers all the time - the latest recruit is Steve, M6CDX - and even people who originally said they were getting too decrepit to climb the fells have been heard operating from some of the lower ones. So far this year I have worked 50 different summits and made 72 WOTA contacts from home, not far short of my total for the whole of 2010, and we're only a bit over half way through the second month. I'm sure others have also noticed the greatly increased activity.
There is great camaraderie among all the participants, too, many of whom feel like old friends even though most of us have never met. I think it is fair to say that the success of WOTA has exceeded my wildest expectations. Combining two of my favourite activities - walking in our wonderful mountains and making contacts on the radio - it doesn't get much better than this!
Saturday, February 19, 2011
APRS aggro
I like to think APRS is a haven from the aggravation often found on the rest of the bands, but unfortunately we have our problems too. This afternoon an APRS message appeared on my screen from G1ZRN-10 that clearly had been addressed to ALL.
It obviously wasn't intended for me personally. I don't gate from one band to another. In fact at the weekend I leave my HF IGate receive-only because I don't want to add to the mayhem. But there is a lot of traffic gated from VHF to HF by stations in the south of France. It serves no useful purpose for me in the UK to receive information about French repeaters or French radio club meetings nor is there any point in gating position beacons from French VHF stations on to 30m. But what can you do?
I don't think getting your blood pressure up and acting like a band policeman will solve the problem. Unfortunately the language barrier doesn't help here. Because of that there are no common forums where European APRS users meet, where an approach could be worked out. A direct approach to the offenders would need to be made by a native speaker who could gauge the individual's attitude, find out why they are doing this, and tactfully dissuade them from it. Blunt emails in capitals and in English could easily have the opposite of the desired effect.
I think it is one of those things we just have to live with. Actually I'm not sure the effect is really that bad. I'm running just 10W to a magnetic loop in the attic and my beacons are reliably gated throughout most of the day by stations in Germany. When European HF mobiles are about I often gate them, so the network still works. But it would be nice to have a blacklist function in my IGate software so that I can refuse to pass traffic for the offending stations. If everyone did that, it might get them to mend their ways or get off the air.
Some folks have set up an alternative APRS network on 20 metres called Net14. I don't think that's the answer. Sure, you get away from the idiotic VHF to HF gateways, but you get away from all the other activity too. I tried it a couple of times and it was even more boring than VHF is here most of the time.
If anyone has any serious suggestions as to how to solve the problem of cross-band gating on 30m I'd be glad to hear them. Or even non-serious ones. Right, I'm off to bid for a GPS-guided missile on eBay!
Enough of yahoos
What is it about ham radio that encourages boorish behaviour? Or is it just the internet? Whenever you post in any forum or specialist group suggesting that something about a particular radio is not a very good design and could be improved you will usually get several responses that amount to "I don't think there is anything wrong, so there can't be anything wrong." If you attempt to defend your statement you will eventually end up on the receiving end of insults. Yahoo groups are aptly named it seems.
If you want a VHF radio that can be used simultaneously as an APRS gateway and for voice there aren't a lot of choices. The Kenwood TM-D710 is really the only option given that Yaesu's FTM-350 doesn't have an accessible TNC. Like most radios capable of 50W output the TM-D710 has a fan. Unfortunately Kenwood's fan logic is dumb. The fan comes on the instant the transmitter starts, no matter how long you transmit for or what the power level, and runs for about two minutes. This means that it runs for two minutes out of ten, triggered by my one second five watt APRS beacons. This is completely unnecessary as no significant heat is generated by such a short transmission. The noise is an annoyance - it's significantly louder than the computer, or my K3's fans - but more importantly this must also reduce the working life of the fan unnecessarily. One day the fan will fail when it is needed because of all the times it ran when it wasn't.
When somebody complained in the Kenwood D710 group about the fan noise because he was using the D710 in his quiet living room, I agreed, saying it was just cheapskate engineering for Kenwood not to have incorporated a thermostatic fan controller. This upset the yahoos. I was told that it was better for the fan to run than for it not to run, that if there was a bad antenna mismatch the fan running in those first few seconds could save the PA transistors, that it was necessary for the fan to run all the time because some users install the radios in tight spaces in vehicles where the temperature reaches over 100 degrees F, that group members had equipment with other fans that were even noisier, and so on. None of which, if true, actually invalidated the argument that a thermostatically controlled fan would be an improvement over the present dumb logic. It was just "It isn't a problem for me, therefore there is no problem."
It was also suggested that a thermostatic control would add $10 to $40 to the cost of the radio. I'm not an electronics engineer but I doubt that it would add more than a couple of dollars to the manufacturing cost, which would not make a significant difference to the retail price given these aren't cheap radios to begin with. Even my power supply, which cost a third the price of the Kenwood, has a thermostatically controlled fan. If Diamond could fit one without making the price of the product uncompetitive I'm sure Kenwood could have done.
Sadly, online groups have ceased to be a place where you can intelligently discuss the strengths and weaknesses of various products due to the activities of the yahoos who will brook no criticism of the thing they have purchased. I could regale you with another recent encounter, this time on the Elecraft reflector, over the stupidity of having the K3 change mode to the one last used on a band when a program sends a change frequency command, overriding the mode set by the program so you may end up in USB in the CW part of the band or vice versa. Needless to say, the Elecraft Way is The One True Way and it is the developers who won't modify their programs that are wrong, even though by making this one change Elecraft could enable the K3 to work properly with N3FJP and several other programs whose developers won't change them just to suit Elecraft. In fairness I should point out that Elecraft didn't refuse to make the suggested change (they didn't respond to the thread) it was the fanboys who defended the status quo as usual.
Frankly I'm getting tired of engaging with hams over any subject at the moment. So I have decided to unsubscribe from the majority of ham radio groups and will restrict myself to posting my thoughts here in future. I'm sure that will please many people who don't like seeing points of view they don't agree with. Commenters to my blog are welcome to disagree, as long as they do so intelligently and politely. Boorish comments that amount to "I don't agree, therefore you're wrong" without providing any supporting evidence as to why I might be wrong will be unceremoniously deleted.
If you want a VHF radio that can be used simultaneously as an APRS gateway and for voice there aren't a lot of choices. The Kenwood TM-D710 is really the only option given that Yaesu's FTM-350 doesn't have an accessible TNC. Like most radios capable of 50W output the TM-D710 has a fan. Unfortunately Kenwood's fan logic is dumb. The fan comes on the instant the transmitter starts, no matter how long you transmit for or what the power level, and runs for about two minutes. This means that it runs for two minutes out of ten, triggered by my one second five watt APRS beacons. This is completely unnecessary as no significant heat is generated by such a short transmission. The noise is an annoyance - it's significantly louder than the computer, or my K3's fans - but more importantly this must also reduce the working life of the fan unnecessarily. One day the fan will fail when it is needed because of all the times it ran when it wasn't.
When somebody complained in the Kenwood D710 group about the fan noise because he was using the D710 in his quiet living room, I agreed, saying it was just cheapskate engineering for Kenwood not to have incorporated a thermostatic fan controller. This upset the yahoos. I was told that it was better for the fan to run than for it not to run, that if there was a bad antenna mismatch the fan running in those first few seconds could save the PA transistors, that it was necessary for the fan to run all the time because some users install the radios in tight spaces in vehicles where the temperature reaches over 100 degrees F, that group members had equipment with other fans that were even noisier, and so on. None of which, if true, actually invalidated the argument that a thermostatically controlled fan would be an improvement over the present dumb logic. It was just "It isn't a problem for me, therefore there is no problem."
It was also suggested that a thermostatic control would add $10 to $40 to the cost of the radio. I'm not an electronics engineer but I doubt that it would add more than a couple of dollars to the manufacturing cost, which would not make a significant difference to the retail price given these aren't cheap radios to begin with. Even my power supply, which cost a third the price of the Kenwood, has a thermostatically controlled fan. If Diamond could fit one without making the price of the product uncompetitive I'm sure Kenwood could have done.
Sadly, online groups have ceased to be a place where you can intelligently discuss the strengths and weaknesses of various products due to the activities of the yahoos who will brook no criticism of the thing they have purchased. I could regale you with another recent encounter, this time on the Elecraft reflector, over the stupidity of having the K3 change mode to the one last used on a band when a program sends a change frequency command, overriding the mode set by the program so you may end up in USB in the CW part of the band or vice versa. Needless to say, the Elecraft Way is The One True Way and it is the developers who won't modify their programs that are wrong, even though by making this one change Elecraft could enable the K3 to work properly with N3FJP and several other programs whose developers won't change them just to suit Elecraft. In fairness I should point out that Elecraft didn't refuse to make the suggested change (they didn't respond to the thread) it was the fanboys who defended the status quo as usual.
Frankly I'm getting tired of engaging with hams over any subject at the moment. So I have decided to unsubscribe from the majority of ham radio groups and will restrict myself to posting my thoughts here in future. I'm sure that will please many people who don't like seeing points of view they don't agree with. Commenters to my blog are welcome to disagree, as long as they do so intelligently and politely. Boorish comments that amount to "I don't agree, therefore you're wrong" without providing any supporting evidence as to why I might be wrong will be unceremoniously deleted.
Friday, February 18, 2011
On the tiles
The best APRS client just keeps getting better. The latest treat for beta testers of APRSISCE/32, the APRS client for Windows desktops and Windows Mobile (which also runs under wine on Linux) is configurable map tile servers. This feature allows users to switch between a variety of different map servers to use a range of different maps in addition to the default OSM mapping.
Probably the most useful for most users will be the Mapquest OSM mapping which is a high contrast map similar in appearance to a road atlas. Mapquest also has a set of satellite view tiles, shown above in a screenshot from my 30m APRS gateway. These tiles don't unfortunately let you get closer than about 10,000 metres so you can't zoom in on somebody's house like you can with Google mapping.
For UK users especially those of us in hilly areas the ability to use the UK specific Freemap mapping is a massive benefit. These OSM based maps show topographical detail (contours) as well as footpaths and walkers' routes as illustrated by the screenshot below centered on a recent SOTA activation in the Lake District.
The ability to seamlessly pan and zoom around an area as well as switch map types with a couple of mouse clicks puts APRSISCE/32 miles ahead of UI-View. This new feature is another example of the amazing dedication and support given by Lynn, KJ4ERJ, to his program. Only last weekend while Lynn was on a trip to Spain a handful of us were discovering and sharing details of alternative map sources and hand-editing them into the configuration files so use the maps with the software. On his return the suggestion was made that it would be nice to be able to switch between map sources from within the program. Four days later, we're testing the new feature. It's like Christmas every day when you're an APRSISCE/32 user!
Probably the most useful for most users will be the Mapquest OSM mapping which is a high contrast map similar in appearance to a road atlas. Mapquest also has a set of satellite view tiles, shown above in a screenshot from my 30m APRS gateway. These tiles don't unfortunately let you get closer than about 10,000 metres so you can't zoom in on somebody's house like you can with Google mapping.
For UK users especially those of us in hilly areas the ability to use the UK specific Freemap mapping is a massive benefit. These OSM based maps show topographical detail (contours) as well as footpaths and walkers' routes as illustrated by the screenshot below centered on a recent SOTA activation in the Lake District.
The ability to seamlessly pan and zoom around an area as well as switch map types with a couple of mouse clicks puts APRSISCE/32 miles ahead of UI-View. This new feature is another example of the amazing dedication and support given by Lynn, KJ4ERJ, to his program. Only last weekend while Lynn was on a trip to Spain a handful of us were discovering and sharing details of alternative map sources and hand-editing them into the configuration files so use the maps with the software. On his return the suggestion was made that it would be nice to be able to switch between map sources from within the program. Four days later, we're testing the new feature. It's like Christmas every day when you're an APRSISCE/32 user!
Thursday, February 17, 2011
Baud with microcontrollers
My homebrew WX-1 weather station, which transmits data directly on 144.800MHz APRS using a PIC based packet modulator and a 10mW VHF transmitter module, is decoded by my VX-8GR and my Kenwood TM-D710 but not my TH-D72 or my homebrew TNC. This is annoying. A week ago I looked at the packet modulation from various devices and found that the tone frequencies of the WX-1 were about 50Hz too high. So I thought I would try to fix it.
The PIC source code for the weather station is available for download. The program code that generates the packet modulation is a bit beyond me, but I think it works by executing a loop and pushing binary values out of 4 ports which are connected to 1K0, 2K0, 3K9 and 5K1 value resistors in such a way as to produce a stepwise approximation of a sine wave. It seemed to me that to lower the tone frequencies I needed to slow the loop down a tad. After a bit of trial and error inserting a nop (no-operation) instruction in various likely-looking places I managed to get the tones nicely symmetrically positioned around the 1200Hz/2200Hz nominal frequencies for 1200baud packet. But the TH-D72 and homebrew TNC still refused to decode any packets!
Wondering what to try next, it occurred to me that the tone frequencies were not the only parameters of a packet signal. There is also the baud rate. I also remembered that the MixW sound card software prints out the measured baud rate next to each decoded packet. So I hooked MixW up to a transceiver and sound card and gave it a selection of signals to decode. I found that whilst my two Kenwood transceivers and the Yaesu VX-8GR all measured 1200 or 1199baud, the WX-1 recorded a value of 1208 baud. That had to be the cause of the problem.
Unfortunately I can't find a solution. I thought that slowing down the PIC processor's clock might make the necessary adjustment, so borrowing an idea from a PIC frequency counter circuit I replaced one of the fixed capacitors on the oscillator crystal with a variable one. This made a whole 1 baud of difference! Clearly that approach isn't going to get me anywhere unless I get myself a 19.867MHz crystal. If I'd done the math in the first place I'd have realized I wasn't going to pull the oscillator that far with a trimmer.
The solution, if there is one, has to be in the code. But I don't understand it nor can I find any comments that would point to a routine or value that affects the baud rate. Give me a circuit with discrete components any day. If this is the future of electronic experimentation I don't think there's a place for me in it.
The PIC source code for the weather station is available for download. The program code that generates the packet modulation is a bit beyond me, but I think it works by executing a loop and pushing binary values out of 4 ports which are connected to 1K0, 2K0, 3K9 and 5K1 value resistors in such a way as to produce a stepwise approximation of a sine wave. It seemed to me that to lower the tone frequencies I needed to slow the loop down a tad. After a bit of trial and error inserting a nop (no-operation) instruction in various likely-looking places I managed to get the tones nicely symmetrically positioned around the 1200Hz/2200Hz nominal frequencies for 1200baud packet. But the TH-D72 and homebrew TNC still refused to decode any packets!
Wondering what to try next, it occurred to me that the tone frequencies were not the only parameters of a packet signal. There is also the baud rate. I also remembered that the MixW sound card software prints out the measured baud rate next to each decoded packet. So I hooked MixW up to a transceiver and sound card and gave it a selection of signals to decode. I found that whilst my two Kenwood transceivers and the Yaesu VX-8GR all measured 1200 or 1199baud, the WX-1 recorded a value of 1208 baud. That had to be the cause of the problem.
Unfortunately I can't find a solution. I thought that slowing down the PIC processor's clock might make the necessary adjustment, so borrowing an idea from a PIC frequency counter circuit I replaced one of the fixed capacitors on the oscillator crystal with a variable one. This made a whole 1 baud of difference! Clearly that approach isn't going to get me anywhere unless I get myself a 19.867MHz crystal. If I'd done the math in the first place I'd have realized I wasn't going to pull the oscillator that far with a trimmer.
The solution, if there is one, has to be in the code. But I don't understand it nor can I find any comments that would point to a routine or value that affects the baud rate. Give me a circuit with discrete components any day. If this is the future of electronic experimentation I don't think there's a place for me in it.
Wednesday, February 16, 2011
Platform for progress
One of the things at the back of my mind when I was writing that the magic of ham radio wasn't in high technology was the feeling that anyone who got into the hobby out of a mania for high-tech toys was soon likely to be disappointed. I've seen it happen when people who are new to the hobby and don't yet know much about it get an enthusiasm for APRS or Echolink. They get disappointed that the network coverage is patchy or nonexistent compared to cellphone coverage because they don't realize that it depends on hams to provide the infrastructure and where there are few hams - or none interested in these particular aspects of the hobby - there are no repeaters and no gateways.
I've seen the same people criticize the latest VX-8, TH-D72 and Icom D-Star radios as being overpriced and unimpressive. They don't like the geeky "walkie talkie" look or the plain 1990s LCD display. They can't believe that APRS radios don't support predictive text entry like the cheapest mobile has for more than a decade. And why can't they have a colour screen and a scrolling map display?
It's easy to dismiss these criticisms as coming from people who don't understand that ham radio is a specialized niche market and that amateur HTs don't benefit from the economies of scale which allow vastly more R&D to be spent on a smartphone costing a similar amount of money. But then I realized that perhaps the critics had a valid case. Manufacturers of smartphones don't completely reinvent the wheel whenever they release a new model. They just design the hardware. But the hardware is a platform. On it runs a standard OS and various apps, a few of which may be customized to the manufacturer or phone but most of which are generic. Given that software development is one of the most time consuming and expensive parts of any new technology product development, wouldn't that be a huge saving?
Why can't top of the range hand-held radios use a similar hardware architecture to cellphones? Instead of a custom design the radio would be a computer running embedded Linux. The RF side could be SDR or it could use conventional technology - it wouldn't matter, that would simply depend on what is most cost effective and delivers the best battery endurance. But all the control functions, together with transmit and receive audio, would be accessible through an API to software. The user interface would be an app.
Since the radio is a computer the interface would be endlessly customizable and all kinds of things not possible with existing radios could be feasible. Instead of entering local repeater frequencies into memories you could install an app that gets your position from the built-in GPS and shows you the nearest repeaters. One click and you're listening on it.
Instead of a plain LCD display showing distance and bearing your APRS capable radio could show a full map display just like APRSISCE currently provides on Windows smartphones. You wouldn't need packet modem hardware in the radio because packet generation and decoding could be done in software. In fact there would be no such thing as an APRS capable radio. The platform would be the same - if you wanted APRS you would just install the APRS application. If you wanted Echolink you could add the Echolink application. If you wanted D-Star you could buy the D-Star app from Icom. If you wanted to work satellites then I'm sure someone would write an app that would keep track of where the satellites are and even control the radio frequencies taking account of doppler.
You could power this hypothetical next generation radio using cellphone battery packs, which are a lot cheaper than the custom battery packs for traditional ham radios. You could even use standard cellphone accessories.
So why won't this happen? I guess the reason for that is that Yaesu, Icom, Kenwood and the rest don't make cellphones. Their business is making radios that are intended to be as dumb as most of their users. Ham radio is just an offshoot. The market just isn't big enough to justify developing what for them would be a completely different and unique hardware platform. So I guess for the foreseeable future we'll be stuck with our geeky walkie talkies and the cool stuff will all be on cellphones.
It's easy to dismiss these criticisms as coming from people who don't understand that ham radio is a specialized niche market and that amateur HTs don't benefit from the economies of scale which allow vastly more R&D to be spent on a smartphone costing a similar amount of money. But then I realized that perhaps the critics had a valid case. Manufacturers of smartphones don't completely reinvent the wheel whenever they release a new model. They just design the hardware. But the hardware is a platform. On it runs a standard OS and various apps, a few of which may be customized to the manufacturer or phone but most of which are generic. Given that software development is one of the most time consuming and expensive parts of any new technology product development, wouldn't that be a huge saving?
Why can't top of the range hand-held radios use a similar hardware architecture to cellphones? Instead of a custom design the radio would be a computer running embedded Linux. The RF side could be SDR or it could use conventional technology - it wouldn't matter, that would simply depend on what is most cost effective and delivers the best battery endurance. But all the control functions, together with transmit and receive audio, would be accessible through an API to software. The user interface would be an app.
Since the radio is a computer the interface would be endlessly customizable and all kinds of things not possible with existing radios could be feasible. Instead of entering local repeater frequencies into memories you could install an app that gets your position from the built-in GPS and shows you the nearest repeaters. One click and you're listening on it.
Instead of a plain LCD display showing distance and bearing your APRS capable radio could show a full map display just like APRSISCE currently provides on Windows smartphones. You wouldn't need packet modem hardware in the radio because packet generation and decoding could be done in software. In fact there would be no such thing as an APRS capable radio. The platform would be the same - if you wanted APRS you would just install the APRS application. If you wanted Echolink you could add the Echolink application. If you wanted D-Star you could buy the D-Star app from Icom. If you wanted to work satellites then I'm sure someone would write an app that would keep track of where the satellites are and even control the radio frequencies taking account of doppler.
You could power this hypothetical next generation radio using cellphone battery packs, which are a lot cheaper than the custom battery packs for traditional ham radios. You could even use standard cellphone accessories.
So why won't this happen? I guess the reason for that is that Yaesu, Icom, Kenwood and the rest don't make cellphones. Their business is making radios that are intended to be as dumb as most of their users. Ham radio is just an offshoot. The market just isn't big enough to justify developing what for them would be a completely different and unique hardware platform. So I guess for the foreseeable future we'll be stuck with our geeky walkie talkies and the cool stuff will all be on cellphones.
Beacon failure
ChangeDetection.com once again alerted me to a change in the NCDXF/IARU International Beacon Project status page so that I can manually update the beacon status file for VOAProp. I think it is worth a comment on the fact that 7 out of the 18 beacons appear currently to be off the air. This is the most I can recall being off at the same time. Some have been off for months. If you rely on the beacons to see whether a band is open, you may think conditions are worse than they really are. I hope all the beacons are soon restored to full operation.
Tuesday, February 15, 2011
Is technology good for ham radio?
Several ham radio blogs have linked to the Wired article Why Ham Radio Endures in a World of Tweets. "What is it about a simple microphone, a transmitter-receiver and the seductive freedom of the open radio spectrum that’s turned a low-tech anachronism into an enduring and deeply engaging global hobby?" the author asks. He goes on to describe the thrill of establishing a direct, person to person long distance contact and exchanging QSL cards, which he contrasts with "a world of taken-for-granted torrents of e-mails, instant messages and Skype video-chats." It's a point of view that QRP enthusiasts and many others will identify with.
In the comments to the article many have been keen to say that ham radio is not low tech, citing "VoIP Radio" and digital techniques as examples. They may be true, but I'm afraid the commenters miss the point. The more high-tech ham radio becomes, the less magic there is. Developments like D-Star are about as far from the concept of a simple transceiver and the freedom of the open radio spectrum as it is possible to get. It isn't simple, it isn't free (since it depends on a network controlled by someone else) and it isn't open. Which is why it is anathema to many of us.
There is a danger that the pursuit of technology could turn ham radio into a poor copy of existing communications networks. Ham radio has endured because it has held on to its traditions involving relatively simple technology that most hams can understand and even build for themselves. If we ever lose sight of that the hobby is as good as dead.
In the comments to the article many have been keen to say that ham radio is not low tech, citing "VoIP Radio" and digital techniques as examples. They may be true, but I'm afraid the commenters miss the point. The more high-tech ham radio becomes, the less magic there is. Developments like D-Star are about as far from the concept of a simple transceiver and the freedom of the open radio spectrum as it is possible to get. It isn't simple, it isn't free (since it depends on a network controlled by someone else) and it isn't open. Which is why it is anathema to many of us.
There is a danger that the pursuit of technology could turn ham radio into a poor copy of existing communications networks. Ham radio has endured because it has held on to its traditions involving relatively simple technology that most hams can understand and even build for themselves. If we ever lose sight of that the hobby is as good as dead.
Monday, February 14, 2011
Simple Sideband Transceiver for 10m
Roger G3XBM has started a new project: a simple sideband transceiver for the 10m band. Roger's projects are always interesting so this page will be one to keep an eye on. If it can be made small enough to fit into a hand held case this could make a great portable radio capable of DX contacts during the sporadic-E conditions during the summer.
Regular readers will know that last year I worked the Czech Republic using a hand-held Intek H-520 FM transceiver with a telescopic whip. The Intek, despite being a nice looking radio, is actually a horrible piece of kit with a PA that sucks the power out of the rig's batteries, especially if the antenna presents anything other than a perfect SWR. And the trouble with 10m FM in the summer is that too many people are trying to use too few frequencies so there is terrible QRM and the "capture effect" means that only the strongest station is heard.
A little double-sideband rig, even with only a couple of watts output, ought to work much better. I shall be following Roger's project with interest and intend to make this my next radio project too.
Regular readers will know that last year I worked the Czech Republic using a hand-held Intek H-520 FM transceiver with a telescopic whip. The Intek, despite being a nice looking radio, is actually a horrible piece of kit with a PA that sucks the power out of the rig's batteries, especially if the antenna presents anything other than a perfect SWR. And the trouble with 10m FM in the summer is that too many people are trying to use too few frequencies so there is terrible QRM and the "capture effect" means that only the strongest station is heard.
A little double-sideband rig, even with only a couple of watts output, ought to work much better. I shall be following Roger's project with interest and intend to make this my next radio project too.
Thursday, February 10, 2011
Braap analysis
One problem I have noticed with the PIC TNC I recently built is that it is less tolerant of different packet signals than any of my radios. It decodes my two Kenwood transceivers just fine but it will only decode the VX-8G at a specific audio level that is impossible to set when using the fixed output of many radios. And it won't decode my WX-1 weather station at all.
My Kenwood TH-D72 won't decode the weather station either. However it is the VX-8GR I am more concerned about. With the volume of the packet channel turned up, it's braaps sound a bit thin and weedy compared to those of the Kenwoods and other radios I hear over the air. I thought that I would try to analyze the signals to see if this would give me an idea of what was causing the problem.
I used Spectran, the only free software I know that will do audio spectrum analysis. The receiver was the old Kenwood TH-205E, which being over 25 years old had IF filtering wide enough not to cause any deviation limiting. Each capture was made at the same volume level so the signal levels shown should represent the relative signal deviation.
Because packet bursts are fleeting it took a few attempts to capture the screen at just the right moment. But eventually I obtained plots for each of four radios, including the weather station. Incidentally I am puzzled that the spectrograms show a comb of frequencies. I thought 1200 baud packet was FSK using two frequencies, 1200Hz and 2200Hz. I have seen this before when using sound card decoder software for packet but I have always been puzzled by it.
The top two plots are for the two Kenwood radios. They look pretty near identical. In the absence of any test equipment to actually measure the deviation levels I have to assume that these two radios were correctly set up at the factory and represent the ideal signal to aim for. It is interesting that the highest frequency which I would have assumed to be 2200Hz actually peaks at about 2235Hz. The peak closest to the lower frequency of 1200Hz is actually 1185Hz. But there are six peaks at intervals of about 150Hz between the two and some spaced the same distance going below the lower frequency. I'm sure there's a reason for it.
If you look at the plot for the VX-8G the top peak is at about 2230Hz and 5dB weaker than the corresponding peak of the Kenwood traces. The other peaks are lower still with the one at about 1180Hz around 8dB lower than that from the Kenwood. Some VX-8 users have complained about low packet deviation of the radio but have been told by Yaesu that it is within specification. As far as I know there is no adjustment to increase it. You would have thought from this that I would need to increase the audio level to get reliable decoding of the VX-8 compared to the Kenwoods. In fact, I have usually had to reduce it a little. As previously stated, the volume setting at which the PIC TNC will decode the VX-8G is quite critical, whereas the Kenwood signals would decode over quite a wide range of audio input levels.
When you look at the signal from my WX-1 weather station, which is modulating a Radiometrix VHF transmitter module, the peak signal levels are close to that of the Kenwoods. The lower frequency components are in fact a couple of dB stronger. However, it's clear that the frequencies are too high. The top peak, which should be 2200Hz, is about 2290Hz. And the one closest to 1200Hz is about 1230Hz. When setting up my FoxTrak APRS tracker I had to set the frequencies using the PIC calibration routine as low as they would go before my TH-D710 would decide it, so clearly it is the frequency offset that is responsible for the packets not being decoded. The WX-1 firmware unfortunately does not have a calibration procedure. Either the PIC clock crystal needs to be slowed down a bit or I need to make a change in the source code to shift the frequencies and recompile the firmware.
But it's the VX-8G that most bothers me most. I wish there was a way to boost the level of its packet modulation and make it more like the Kenwoods.
My Kenwood TH-D72 won't decode the weather station either. However it is the VX-8GR I am more concerned about. With the volume of the packet channel turned up, it's braaps sound a bit thin and weedy compared to those of the Kenwoods and other radios I hear over the air. I thought that I would try to analyze the signals to see if this would give me an idea of what was causing the problem.
I used Spectran, the only free software I know that will do audio spectrum analysis. The receiver was the old Kenwood TH-205E, which being over 25 years old had IF filtering wide enough not to cause any deviation limiting. Each capture was made at the same volume level so the signal levels shown should represent the relative signal deviation.
Because packet bursts are fleeting it took a few attempts to capture the screen at just the right moment. But eventually I obtained plots for each of four radios, including the weather station. Incidentally I am puzzled that the spectrograms show a comb of frequencies. I thought 1200 baud packet was FSK using two frequencies, 1200Hz and 2200Hz. I have seen this before when using sound card decoder software for packet but I have always been puzzled by it.
The top two plots are for the two Kenwood radios. They look pretty near identical. In the absence of any test equipment to actually measure the deviation levels I have to assume that these two radios were correctly set up at the factory and represent the ideal signal to aim for. It is interesting that the highest frequency which I would have assumed to be 2200Hz actually peaks at about 2235Hz. The peak closest to the lower frequency of 1200Hz is actually 1185Hz. But there are six peaks at intervals of about 150Hz between the two and some spaced the same distance going below the lower frequency. I'm sure there's a reason for it.
If you look at the plot for the VX-8G the top peak is at about 2230Hz and 5dB weaker than the corresponding peak of the Kenwood traces. The other peaks are lower still with the one at about 1180Hz around 8dB lower than that from the Kenwood. Some VX-8 users have complained about low packet deviation of the radio but have been told by Yaesu that it is within specification. As far as I know there is no adjustment to increase it. You would have thought from this that I would need to increase the audio level to get reliable decoding of the VX-8 compared to the Kenwoods. In fact, I have usually had to reduce it a little. As previously stated, the volume setting at which the PIC TNC will decode the VX-8G is quite critical, whereas the Kenwood signals would decode over quite a wide range of audio input levels.
When you look at the signal from my WX-1 weather station, which is modulating a Radiometrix VHF transmitter module, the peak signal levels are close to that of the Kenwoods. The lower frequency components are in fact a couple of dB stronger. However, it's clear that the frequencies are too high. The top peak, which should be 2200Hz, is about 2290Hz. And the one closest to 1200Hz is about 1230Hz. When setting up my FoxTrak APRS tracker I had to set the frequencies using the PIC calibration routine as low as they would go before my TH-D710 would decide it, so clearly it is the frequency offset that is responsible for the packets not being decoded. The WX-1 firmware unfortunately does not have a calibration procedure. Either the PIC clock crystal needs to be slowed down a bit or I need to make a change in the source code to shift the frequencies and recompile the firmware.
But it's the VX-8G that most bothers me most. I wish there was a way to boost the level of its packet modulation and make it more like the Kenwoods.
Wednesday, February 09, 2011
Screaming for help
I wonder if readers could help me locate a couple of software utilities I need for current projects?
Screamer 1.7 PIC boot loader (or successor.) This was developed by or for Sparkfun, who have version 1.6 on their website. Unfortunately it only allows serial ports COM1 - COM6, which is not convenient for me due to all the COM ports dedicated to radios and TNCs on my shack computer. Forum posts mention a version 1.7 that lets you enter larger COM port numbers but the links to it are now dead. The version 1.6 download includes VB6 source code so I could fix the problem myself except that I only have VB.NET which is totally incompatible with it (don't you just love Microsoft?) So does anyone know where I can find a copy of Screamer 1.7 or later?
Programming software for Friendcom FC-201SA UHF Transceiver Module. I purchased one of these a few months ago but have only just got round to using it. However it is operating on its default frequency of 430.000MHz. There is a serial interface that can be used to set the frequency in each of the 16 channels and also set the channel. The manual describes the module's command set but I don't really want to spend days writing a program for it. The manual also mentions programming software but it was not supplied when I purchased the module from Elcom Research and their website is now defunct. I can't find the utility on the download page of the Friendcom website and the email I sent to Friendcom did not receive an answer. Does anyone know where I can find a copy of this software?
In case anyone has what I'm looking for and is thinking of emailing software to me, please contact me first. Google doesn't just block executable attachments, it blocks the entire email so I'd never even know you'd written. The trick is to put it into a zip file and then change the file extension to something other than zip.
Screamer 1.7 PIC boot loader (or successor.) This was developed by or for Sparkfun, who have version 1.6 on their website. Unfortunately it only allows serial ports COM1 - COM6, which is not convenient for me due to all the COM ports dedicated to radios and TNCs on my shack computer. Forum posts mention a version 1.7 that lets you enter larger COM port numbers but the links to it are now dead. The version 1.6 download includes VB6 source code so I could fix the problem myself except that I only have VB.NET which is totally incompatible with it (don't you just love Microsoft?) So does anyone know where I can find a copy of Screamer 1.7 or later?
Programming software for Friendcom FC-201SA UHF Transceiver Module. I purchased one of these a few months ago but have only just got round to using it. However it is operating on its default frequency of 430.000MHz. There is a serial interface that can be used to set the frequency in each of the 16 channels and also set the channel. The manual describes the module's command set but I don't really want to spend days writing a program for it. The manual also mentions programming software but it was not supplied when I purchased the module from Elcom Research and their website is now defunct. I can't find the utility on the download page of the Friendcom website and the email I sent to Friendcom did not receive an answer. Does anyone know where I can find a copy of this software?
In case anyone has what I'm looking for and is thinking of emailing software to me, please contact me first. Google doesn't just block executable attachments, it blocks the entire email so I'd never even know you'd written. The trick is to put it into a zip file and then change the file extension to something other than zip.
Monday, February 07, 2011
USB technology du jour
Getting a radio to communicate reliably with a computer proves to be a difficult task for some people. The trouble seems to be caused by USB to serial adapters that corrupt the data when used with certain software or at certain speeds. Whenever these problems are discussed in amateur forums inevitably the question of why radio manufacturers don't build USB interfaces into their radios (as Icom and Kenwood have started to do) is raised. I think this is a very short sighted view that really does nothing to solve the problem.
To begin, let's deal with the argument that goes "why force users to buy a serial to USB adapter when serial ports have been obsolete for years." Users have to use something to connect the radio to the computer and the only physical difference between a serial to USB adapter and a serial cable is that one end of the former is a bit fatter to accommodate the USB electronics. There is little difference in cost between the two cables. Furthermore, just because PCs don't come with serial ports doesn't mean that they are obsolete. My shack PC has four - soon hopefully to be increased to six if I can get it to accept the two port board I removed when I upgraded to four as an addition - and installing them is easily within the capabilities of any radio amateur. If you use a laptop you don't have that choice, true enough, but why force a change on everybody because some people choose shack PCs that have limited expandability?
But the main reason why I think building USB into the radio isn't the solution is that it doesn't address the problem. It's USB - either the hardware or its drivers - that is causing the connectivity problems in the first place. If an external adapter cable is used, users can try a different type if the one they have is not working correctly. If the USB hardware is built into the radio then they are stuck with it and reliant on finding a software solution. That might be a matter of getting the manufacturer to fix its drivers, which is not so easy.
Another reason why building USB into the radio is a bad idea is that it limits choices for users. If you want to connect your radio anything other than a PC, something like a MicroHam controller or a remote control over internet device for example, then you're stuffed if you've got a USB port. Some owners of Kenwood's new TH-D72 APRS handheld have already found that Kenwood's decision to provide a USB rather than a serial interface to the radio's internal TNC means they can't use Bluetooth to link it to APRS software on another mobile device.
Whenever I argue that switching to USB is a bad thing someone always counters the argument by saying USB can provide a wide bandwidth connection that can handle other things such as audio. As somebody who has sometimes had three USB sound devices attached to my PC I can certainly see how a one cable interface between rig and computer might seem attractive, especially to those who believe that sound card modes need something like a RigBlaster. And I would agree that a fast interface would be a nice thing to have if it was one that was a true universal standard like, say, Ethernet.
But if we are talking about USB, most of my arguments still apply. Built-in USB limits choices. An analogue audio input and output lets you interface audio with other things such as digital voice recorders, TNCs and VOIP devices for remote control over the internet. We're hams, we're supposed to be able to handle technical stuff, do we really need plug and play interfaces for our radios?
USB is a technology du jour. It keeps changing, whereas RS-232 and analogue audio are permanent standards. USB 1.0 devices seem still to work with USB 2.0 but now USB 3.0 is starting to appear and it remains to be seen how backwards compatible that will be with older USB devices. Who knows what the computers of 10 or 15 years time will be equipped with? It may not be USB anything but something completely different.
Finally there is the fact that USB depends on software to work: drivers that are operating system dependent. Most serial to USB hardware is at least supported by operating systems other than Windows "out of the box." I don't have the experience to know whether that is true for USB interfaces that carry audio or other information. Is anyone using their IC-7600 or TS-590 under Mac OS or Linux?
Even if the manufacturer-supplied drivers work for Windows today, will they work on the latest version of Windows in 10 or 15 years time? If not, will the manufacturer of the radio provide new drivers once the radio is an obsolete model? I'll bet a perfect but unusable as no longer supported scanner that they won't. I'm equally sure that I'll still be able to interface my K3's RS-232 serial port and analogue line input/output to whatever computing hardware and operating system I'm using then.
To begin, let's deal with the argument that goes "why force users to buy a serial to USB adapter when serial ports have been obsolete for years." Users have to use something to connect the radio to the computer and the only physical difference between a serial to USB adapter and a serial cable is that one end of the former is a bit fatter to accommodate the USB electronics. There is little difference in cost between the two cables. Furthermore, just because PCs don't come with serial ports doesn't mean that they are obsolete. My shack PC has four - soon hopefully to be increased to six if I can get it to accept the two port board I removed when I upgraded to four as an addition - and installing them is easily within the capabilities of any radio amateur. If you use a laptop you don't have that choice, true enough, but why force a change on everybody because some people choose shack PCs that have limited expandability?
But the main reason why I think building USB into the radio isn't the solution is that it doesn't address the problem. It's USB - either the hardware or its drivers - that is causing the connectivity problems in the first place. If an external adapter cable is used, users can try a different type if the one they have is not working correctly. If the USB hardware is built into the radio then they are stuck with it and reliant on finding a software solution. That might be a matter of getting the manufacturer to fix its drivers, which is not so easy.
Another reason why building USB into the radio is a bad idea is that it limits choices for users. If you want to connect your radio anything other than a PC, something like a MicroHam controller or a remote control over internet device for example, then you're stuffed if you've got a USB port. Some owners of Kenwood's new TH-D72 APRS handheld have already found that Kenwood's decision to provide a USB rather than a serial interface to the radio's internal TNC means they can't use Bluetooth to link it to APRS software on another mobile device.
Whenever I argue that switching to USB is a bad thing someone always counters the argument by saying USB can provide a wide bandwidth connection that can handle other things such as audio. As somebody who has sometimes had three USB sound devices attached to my PC I can certainly see how a one cable interface between rig and computer might seem attractive, especially to those who believe that sound card modes need something like a RigBlaster. And I would agree that a fast interface would be a nice thing to have if it was one that was a true universal standard like, say, Ethernet.
But if we are talking about USB, most of my arguments still apply. Built-in USB limits choices. An analogue audio input and output lets you interface audio with other things such as digital voice recorders, TNCs and VOIP devices for remote control over the internet. We're hams, we're supposed to be able to handle technical stuff, do we really need plug and play interfaces for our radios?
USB is a technology du jour. It keeps changing, whereas RS-232 and analogue audio are permanent standards. USB 1.0 devices seem still to work with USB 2.0 but now USB 3.0 is starting to appear and it remains to be seen how backwards compatible that will be with older USB devices. Who knows what the computers of 10 or 15 years time will be equipped with? It may not be USB anything but something completely different.
Finally there is the fact that USB depends on software to work: drivers that are operating system dependent. Most serial to USB hardware is at least supported by operating systems other than Windows "out of the box." I don't have the experience to know whether that is true for USB interfaces that carry audio or other information. Is anyone using their IC-7600 or TS-590 under Mac OS or Linux?
Even if the manufacturer-supplied drivers work for Windows today, will they work on the latest version of Windows in 10 or 15 years time? If not, will the manufacturer of the radio provide new drivers once the radio is an obsolete model? I'll bet a perfect but unusable as no longer supported scanner that they won't. I'm equally sure that I'll still be able to interface my K3's RS-232 serial port and analogue line input/output to whatever computing hardware and operating system I'm using then.
Thursday, February 03, 2011
PIC TNC problem
I have been playing around some more with the WB8WGA PIC TNC that I built. While it was quite fun to see what it managed to decode and have it working as a digipeater, I eventually wanted to get it talking to some real software. UI-View is supposed to be able to work with TNCs in Converse mode, so that was going to be the easiest thing to try. But in order to do that I needed to solve the problem of the firmware expecting a linefeed to terminate a command.
That problem turned out to be fairly easy to solve, though I ran into some problems by trying to make some other changes. The trouble with working with microcontrollers, at least when using assembler, is not just that they don't have much memory but it isn't an a seamless block and you have to take care of memory management. Consequently I found that adding one line of code could make the difference between the program compiling and getting an error on the lines of "you are writing to a location that has already been written to." I'm a high level language kind of guy who expects the compiler to take care of all this for me. I suspect that major modifications to the code like adding KISS support is going to be beyond me.
Anyway, I managed to get it so that UI-View could make its various settings and put the TNC into Converse mode. I had to get rid of the message that comes up on entering Converse mode because it often clashed with UI-View sending a beacon. I then set some IS to RF gating options to generate a lot of traffic and found that the TNC kept going back into command mode. This appeared to be due to the timeout timer that throws you back into command mode if you start to type something and don't hit Enter. This was a pretty annoying feature, quite apart from interfering with reliable operation, so I had to take that out, too.
It seemed like the TNC was ready to go. But although it would transmit beacons from UI-View perfectly well, the program would not display any received stations. I could see the decoded packets in UI-View's Terminal window, but they never appeared on the map anywhere. I did some searching and found one complaint about this in the Fox Delta Yahoo! group (the Fox Delta Mini TNC is apparently based on the same firmware) but no solution.
There did not seem to be anything wrong with the packets and I spent a couple of hours trying various things to see if I could establish what the problem was. Eventually I hooked UI-View up to my Kenwood TM-D710 in packet mode and watched what happened. Packets were received and displayed as expected. So then I connected a terminal program to try to see what the received packets looked like. (This is Windows HyperTerminal with a special Terminal-Hex font that shows the hex value of non-printable characters.)
This is what the output from the Kenwood TNC looked like:
and this is the output from the PIC TNC:
As you can see, the only difference (apart from the fact that the PIC TNC is displaying the packets as it digipeated them while the Kenwood heard both the original and the digipeated versions) is the text UI or UI R in angle brackets before the colon that marks the start of the payload part of the packet. It doesn't look like something significant enough to make UI-View ignore the packet. It isn't something that appears in the raw packets listings at aprs.fi. I don't know what it means or how to generate it in the output from my TNC. So I'm stumped at the moment and am hoping that someone who knows the answer will read this and point me in the direction of a solution.
That problem turned out to be fairly easy to solve, though I ran into some problems by trying to make some other changes. The trouble with working with microcontrollers, at least when using assembler, is not just that they don't have much memory but it isn't an a seamless block and you have to take care of memory management. Consequently I found that adding one line of code could make the difference between the program compiling and getting an error on the lines of "you are writing to a location that has already been written to." I'm a high level language kind of guy who expects the compiler to take care of all this for me. I suspect that major modifications to the code like adding KISS support is going to be beyond me.
Anyway, I managed to get it so that UI-View could make its various settings and put the TNC into Converse mode. I had to get rid of the message that comes up on entering Converse mode because it often clashed with UI-View sending a beacon. I then set some IS to RF gating options to generate a lot of traffic and found that the TNC kept going back into command mode. This appeared to be due to the timeout timer that throws you back into command mode if you start to type something and don't hit Enter. This was a pretty annoying feature, quite apart from interfering with reliable operation, so I had to take that out, too.
It seemed like the TNC was ready to go. But although it would transmit beacons from UI-View perfectly well, the program would not display any received stations. I could see the decoded packets in UI-View's Terminal window, but they never appeared on the map anywhere. I did some searching and found one complaint about this in the Fox Delta Yahoo! group (the Fox Delta Mini TNC is apparently based on the same firmware) but no solution.
There did not seem to be anything wrong with the packets and I spent a couple of hours trying various things to see if I could establish what the problem was. Eventually I hooked UI-View up to my Kenwood TM-D710 in packet mode and watched what happened. Packets were received and displayed as expected. So then I connected a terminal program to try to see what the received packets looked like. (This is Windows HyperTerminal with a special Terminal-Hex font that shows the hex value of non-printable characters.)
This is what the output from the Kenwood TNC looked like:
and this is the output from the PIC TNC:
Wednesday, February 02, 2011
PIC16F88 TNC
I have mentioned before that when I'm not in the shack I like to run a little program called aprsg to gate all the local APRS activity to a UHF frequency so I can see what is going on in the local APRS world using an APRS-capable HT. I have set up a system using sound card software, a USB sound device and my FT-817ND to do this. But I would like to make a standalone box for this. The first step in this project is to find a simple, cheap TNC.
There are products that would fit the bill from Byonics and Argent Data. Unfortunately they are not available in the UK and the cost of importing these kits from the US makes them less than cheap. I looked at the Fox Delta Mini TNC. But that is not a KISS TNC, as was confirmed by an email to Dinesh, the proprietor of Fox Delta.
Whilst searching around for possible solutions I came across a design for a TNC using a PIC16F88 microcontroller by WB8WGA that was originally published several years ago as an article in the ARRL experimenter magazine QEX. It has been modified by DJ7OO and ZL3AME, who had developed a stripboard layout for it. I had all the bits apart from the microcontroller and the clock crystal, which were quickly sourced on eBay. So I thought it would be an interesting project to build and experiment with.
ZL3AME's stripboard layout results in some quite lengthy signal paths. Despite this, the TNC worked first time, with just a minor glitch caused by my mis-wiring the PTT connection on the transceiver connector. (I have a standardized interface that I use on all my projects, with an 8-pin mini-DIN connector for audio and PTT to the transceiver, and a 6-pin mini-DIN connector for serial and GPS connections. I can then have a standard set of cables to hook the projects up to any radio, connect to the computer or a GPS, etc.)
With all the bits of APRS kit I have it was easy to generate some test signals and I soon had packets being decoded on the terminal screen. I wondered how sensitive the TNC would be as it uses the PIC16F88 to do the decoding instead of a modem chip like the MX614. I have not seen any DX packets decoded yet, but it does seem that decoding success is dependent on the audio level into the TNC. All of my APRS generators were decoded with the exception of my weather station, which has rather low deviation. When using the old Kenwood TH-205E as a receiver I could increase the volume so the weather station was decoded, at the expense of reliable decoding of the other radios. That was not even an option when using the DATA output of a radio, which has a fixed level. I suspect that performance could be improved if you could add an audio ALC on the input.
The TNC can also send APRS beacons and work as a fill-in digipeater. To send a fixed position you can simply encode the position co-ordinates into the beacon text. There are also a couple of jumpers that allow you to connect a GPS to the serial port, which would allow the TNC to work as a standalone tracker. I haven't tried that, since I already have a standalone tracker. There are no Connect or Disconnect commands so it cannot be used as it stands for packet radio.
This is not a KISS TNC, so it can't be used with APRSIS32 or aprsg or any of the software I use. I installed UI-View which apparently has the ability to use a TNC for APRS in Converse mode, but it doesn't work with that either. I think that is due to the fact that the TNC expects CR/LF at the end of each command instead of just CR, so fixing that will be the task of my first attempt at modifying the firmware. Other things I would like to try are making it work at 300baud (for HF packet) instead of 1200baud, and implementing KISS mode. In KISS mode the PC software provides the complete packet and the TNC just has to add a CRC and send it. So in theory it should be simpler to implement than the existing code which has to construct an AX.25 packet from the information entered plus parameters previously set in the configuration. We shall see. The TNC source code is written in assembler, and trying to understand assembler code is to me like not being able to see the wood for the trees. But it will be a good incentive for me to look "under the hood" at how APRS, packet and AX.25 really work.
Many of the links to original information about this project seem now to be dead and I had to do quite a lot of searching to collect the information I have. For the benefit of anyone else who would like to try building one of these TNCs I have assembled all the files and information I found into a zip file which you can download here.
There are products that would fit the bill from Byonics and Argent Data. Unfortunately they are not available in the UK and the cost of importing these kits from the US makes them less than cheap. I looked at the Fox Delta Mini TNC. But that is not a KISS TNC, as was confirmed by an email to Dinesh, the proprietor of Fox Delta.
Whilst searching around for possible solutions I came across a design for a TNC using a PIC16F88 microcontroller by WB8WGA that was originally published several years ago as an article in the ARRL experimenter magazine QEX. It has been modified by DJ7OO and ZL3AME, who had developed a stripboard layout for it. I had all the bits apart from the microcontroller and the clock crystal, which were quickly sourced on eBay. So I thought it would be an interesting project to build and experiment with.
With all the bits of APRS kit I have it was easy to generate some test signals and I soon had packets being decoded on the terminal screen. I wondered how sensitive the TNC would be as it uses the PIC16F88 to do the decoding instead of a modem chip like the MX614. I have not seen any DX packets decoded yet, but it does seem that decoding success is dependent on the audio level into the TNC. All of my APRS generators were decoded with the exception of my weather station, which has rather low deviation. When using the old Kenwood TH-205E as a receiver I could increase the volume so the weather station was decoded, at the expense of reliable decoding of the other radios. That was not even an option when using the DATA output of a radio, which has a fixed level. I suspect that performance could be improved if you could add an audio ALC on the input.
The TNC can also send APRS beacons and work as a fill-in digipeater. To send a fixed position you can simply encode the position co-ordinates into the beacon text. There are also a couple of jumpers that allow you to connect a GPS to the serial port, which would allow the TNC to work as a standalone tracker. I haven't tried that, since I already have a standalone tracker. There are no Connect or Disconnect commands so it cannot be used as it stands for packet radio.
This is not a KISS TNC, so it can't be used with APRSIS32 or aprsg or any of the software I use. I installed UI-View which apparently has the ability to use a TNC for APRS in Converse mode, but it doesn't work with that either. I think that is due to the fact that the TNC expects CR/LF at the end of each command instead of just CR, so fixing that will be the task of my first attempt at modifying the firmware. Other things I would like to try are making it work at 300baud (for HF packet) instead of 1200baud, and implementing KISS mode. In KISS mode the PC software provides the complete packet and the TNC just has to add a CRC and send it. So in theory it should be simpler to implement than the existing code which has to construct an AX.25 packet from the information entered plus parameters previously set in the configuration. We shall see. The TNC source code is written in assembler, and trying to understand assembler code is to me like not being able to see the wood for the trees. But it will be a good incentive for me to look "under the hood" at how APRS, packet and AX.25 really work.
Many of the links to original information about this project seem now to be dead and I had to do quite a lot of searching to collect the information I have. For the benefit of anyone else who would like to try building one of these TNCs I have assembled all the files and information I found into a zip file which you can download here.