A few days ago I got the urge to build a memory keyer into my MFJ Cub. There isn't much of a practical reason for doing this as the noise level on 20m makes the band unusable without the MFJ Noise Canceler which is plumbed into my K3 and too much hassle to disconnect and use with anything else. But I thought it would be a fun thing to do.
I really wanted to use the SKC keyer that is in the DC20B transceiver as it has some nice features and is easy to use. It uses an Atmel ATTiny13 microcontroller. I happened to have a spare one in my parts box and I had managed to find a way to program it using a PICkit2 programmer designed for Microchip parts. Unfortunately my unorthodox programmer always fails trying to read the contents of the chip so I was unable to copy the code from the chip in the DC20B to my spare chip. Nor could I find a source or hex file for the SKC keyer or indeed any other keyer using an ATTiny13 chip. So I had to give that idea up.
I did find a couple of source files for Microchip PIC based keyers on K1EL's website so I decided I would have to go with that. A couple of years ago I had bought a MikroElektronika EasyPIC5 development system with the intention of experimenting with microchips. Unfortunately I found PIC programming too difficult so I gave up. However I could compile the K1EL keyer code and use the EasyPIC5 to program it into a chip, which I could then build into a keyer that would go in the Cub. Perhaps I could even understand enough of the code to modify it to work the way I wanted.
My first problem was compiling the code. The compiler seemed to object to a label called CONFIG in the source code which caused a fatal error. Eventually I had a lightbulb moment that perhaps CONFIG was a reserved word in the current version of the MPLAB compiler, so I changed the label and the reference to it to CONF. That overcame that problem.
The other problem was that numerous lines in the program produced a message 306, "Crossing page boundary - ensure page bits are set." I didn't have a clue what that meant, and although Google turned up a few pages that mentioned the message I didn't understand what I was supposed to do about it.
The keyer code on K1EL's website was written for the PIC12C509A chip so I had ordered a couple from PIC Projects on eBay. They arrived in the post this morning. That was when I discovered the second problem. The EasyPIC5 development board does not support PIC12C509A chips. In fact, it doesn't support any PICs that have C in the number, only ones that have F. It appears that the F chips have Flash memory and can be reprogrammed while the C chips can only be programmed once. So I have two 12C509A chips I can't use.
I have now ordered some 12F509 chips which are supposed to be compatible with the 12C509 and which my programmer is supposed to be able to program. In a few days time I will discover if that is true and whether message 306 means anything important.
Friday, December 31, 2010
Wednesday, December 29, 2010
Successful outcome
I finally solved the problem with the cable I was trying to make to interface my VX-8GR with the computer, as described in my last post. As I had begun to suspect, the trouble was caused by the 2.5mm jack plug not fitting properly in the VX-8GR data port socket.
As suggested by one of my readers, I tried the cable in the COM port of the TH-D72. Although I couldn't figure out how to make data appear on this port, I did see some output when turning the TNC on and off which suggested my cable did work.
I then tried it back on the VX-8GR and used my oscilloscope to look for anything digital. I didn't see anything. I then tried another 2.5mm jack with the sleeve off so I could get the 'scope probe on the solder tags and with a firm press it went in with a click. I now saw -5.6 V on the TX pin - clearly an RS-232 signal level.
The jack I originally used had a plastic sleeve or cover and the diameter of the base was just a bit too much to allow it to go all the way in. One with a metal sleeve had a slightly smaller diameter base. The metal sleeve itself interfered with inserting the jack, but I could put the plastic sleeve on that jack and it would still go in. So that, finally, is what I did, and I now have a VX-8GR PC cable that works. It also works with the COM port of the TH-D72 should I find a use for that.
As a ham and electronics enthusiast I don't believe in buying things I can make myself, but sometimes making it yourself can turn out to be more trouble than it is worth!
As suggested by one of my readers, I tried the cable in the COM port of the TH-D72. Although I couldn't figure out how to make data appear on this port, I did see some output when turning the TNC on and off which suggested my cable did work.
I then tried it back on the VX-8GR and used my oscilloscope to look for anything digital. I didn't see anything. I then tried another 2.5mm jack with the sleeve off so I could get the 'scope probe on the solder tags and with a firm press it went in with a click. I now saw -5.6 V on the TX pin - clearly an RS-232 signal level.
The jack I originally used had a plastic sleeve or cover and the diameter of the base was just a bit too much to allow it to go all the way in. One with a metal sleeve had a slightly smaller diameter base. The metal sleeve itself interfered with inserting the jack, but I could put the plastic sleeve on that jack and it would still go in. So that, finally, is what I did, and I now have a VX-8GR PC cable that works. It also works with the COM port of the TH-D72 should I find a use for that.
As a ham and electronics enthusiast I don't believe in buying things I can make myself, but sometimes making it yourself can turn out to be more trouble than it is worth!
Monday, December 27, 2010
Incommunicado
I have spent a frustrating couple of hours trying to make a PC cable to communicate with the VX-8GR. In the VX-8 Yahoo group it was stated that the cable is the same as for the Kenwood TH-D7AG a diagram of which is given in YO3HJV's blog. It was also pointed out to me that there is a diagram in the back of the manual - the one place I never thought to look!
It is easy enough to make up. No level shifting components needed. Just a 2.5mm stereo jack for the radio end and a 9-pin D plug for the PC end. But the damn thing refuses to work.
I have tried a Prolific USB to serial adapter and an FTDI one. I've tried the FTBVX8G software and I've tried a terminal program to see if I can detect any data. Nothing. Nada. Incommunicado. I know the cable is OK because if I short between tip and ring of the jack plug I can type in the terminal program and see the text I typed echoed back over the connection.
The only thing I can think of is that the standard 2.5mm stereo plugs I have here are a bit too short. It seems to me that the plug isn't locking firmly into place, more that the radio is trying to push it back out again. It's as if the tip needs to be a bit longer to get past the spring loaded contact in the socket. I measure 7/16in from the base of the plug to the tip of it. I had a similar problem trying to make a cable to send audio from my FoxTrak APRS tracker into my Motorola GP300. Then I had a plug from a speaker mic to compare it with and I could see that it needed to be longer.
Perhaps someone who has a VX-8G PC cable that works could measure the plug on theirs. Or perhaps someone will spot the stupid wiring mistake I've made from the photo I've posted.
It is easy enough to make up. No level shifting components needed. Just a 2.5mm stereo jack for the radio end and a 9-pin D plug for the PC end. But the damn thing refuses to work.
I have tried a Prolific USB to serial adapter and an FTDI one. I've tried the FTBVX8G software and I've tried a terminal program to see if I can detect any data. Nothing. Nada. Incommunicado. I know the cable is OK because if I short between tip and ring of the jack plug I can type in the terminal program and see the text I typed echoed back over the connection.
The only thing I can think of is that the standard 2.5mm stereo plugs I have here are a bit too short. It seems to me that the plug isn't locking firmly into place, more that the radio is trying to push it back out again. It's as if the tip needs to be a bit longer to get past the spring loaded contact in the socket. I measure 7/16in from the base of the plug to the tip of it. I had a similar problem trying to make a cable to send audio from my FoxTrak APRS tracker into my Motorola GP300. Then I had a plug from a speaker mic to compare it with and I could see that it needed to be longer.
Perhaps someone who has a VX-8G PC cable that works could measure the plug on theirs. Or perhaps someone will spot the stupid wiring mistake I've made from the photo I've posted.
Sunday, December 26, 2010
Underwhelming update
I see that on Christmas Day (though of course it wasn't Christmas Day in Ukraine) the developers of the MixW sound card digital modes software released the long awaited MixW version 3. I couldn't find much information on the website about what new features it contained. "MixW3 is a next step on the way to the upcoming multiplatform MixW project. It proposes a new Telnet dialog with talk over DxCluster support and a possibility to have a backup copies of your log on our server, dx.mixw.net." Nothing about what's new in the version available now. None of these "proposals" are things that I personally want, and I'm not even sure that chat over the DX Cluster will be welcomed by many users - there are enough non-spots cluttering it up already."
I decided to download the new version to see what I could find. As the screenshot above shows, it looks pretty much like MixW 2.19 which has been looking dated for years. I didn't see any new modes, nor support for RSID. What is even more disappointing, given the apparent lack of new features, is that this upgrade is not free. The website states "MixW3 upgrade is free for those who stay with us 10 years or more." I registered MixW a long time ago but not long enough, it seems. An upgrade to MixW3 will cost me the equivalent of $20 plus VAT.
At the time I paid for MixW It really was the premier digital modes software and I felt it was well worth the money. But after a few years it seemed as if MixW was neglected. In the intervening time new, more modern looking full featured competitors came on to the scene like Ham Radio Deluxe and Fldigi, which were also free. I switched to Fldigi a couple of years ago as MixW never properly supported the K3. And nothing I can see in the new version gives me any inclination to switch back, even if I could use the new version for free.
There is nothing wrong with charging for ham radio software. But charging for an upgrade in which the only apparent change is the version number and then expecting buyers to hang on patiently while new features are added won't work in a market where so many good products are free. Perhaps the multiplatform MixW 4 will be a must-have upgrade. I'm happy to wait and see.
I decided to download the new version to see what I could find. As the screenshot above shows, it looks pretty much like MixW 2.19 which has been looking dated for years. I didn't see any new modes, nor support for RSID. What is even more disappointing, given the apparent lack of new features, is that this upgrade is not free. The website states "MixW3 upgrade is free for those who stay with us 10 years or more." I registered MixW a long time ago but not long enough, it seems. An upgrade to MixW3 will cost me the equivalent of $20 plus VAT.
At the time I paid for MixW It really was the premier digital modes software and I felt it was well worth the money. But after a few years it seemed as if MixW was neglected. In the intervening time new, more modern looking full featured competitors came on to the scene like Ham Radio Deluxe and Fldigi, which were also free. I switched to Fldigi a couple of years ago as MixW never properly supported the K3. And nothing I can see in the new version gives me any inclination to switch back, even if I could use the new version for free.
There is nothing wrong with charging for ham radio software. But charging for an upgrade in which the only apparent change is the version number and then expecting buyers to hang on patiently while new features are added won't work in a market where so many good products are free. Perhaps the multiplatform MixW 4 will be a must-have upgrade. I'm happy to wait and see.
Thursday, December 23, 2010
Installing APRSISCE/32
I have just added a new article, Installing APRSISCE/32, to my website G4ILO's Shack. It is a pictorial tutorial showing how to install the APRS client written by KJ4ERJ and get it running.
Over the next couple of months I hope to add several more tutorials covering different aspects of using the program and connecting it to a radio, in the hope that they will encourage more people to get on to APRS or at least use the information that it can provide.
Over the next couple of months I hope to add several more tutorials covering different aspects of using the program and connecting it to a radio, in the hope that they will encourage more people to get on to APRS or at least use the information that it can provide.
Seasonal greetings
May I take this opportunity to wish all my readers
a Merry Christmas and a healthy, happy and successful
New Year 2011.
Wednesday, December 22, 2010
Changes to 2m gear
I have had a bit of a change round in the shack recently. Since getting the Kenwood TM-D710 which is used for 2m FM which is the vast majority of my VHF activity, the Icom IC-910H has really been under-utilized. 70cm is a dead band here and there isn't too much 2m SSB activity. Besides, I never really liked the Icom. So I decided to swap it for an old Spectrum Communications transverter that I have and sell it in the new year.
The Kenwood has been moved into the "second rig" operating position. And the desk mic I used with the Icom is now attached to the Kenwood. I had some CAT5 UTP network cables which are terminated in the same type of plug Kenwood uses for a mic connector, so I cut one in half and made up a cable for the desk mic. Despite being unshielded (UTP stands for Unshielded Twisted Pair) there doesn't seem to be any RFI even at 50W. And the reports I have had so far suggest that it sounds good.
The Spectrum transverter runs about 20W output. This is less than I would like for SSB. My plan was to set the transverter drive so the peak output was 5W and use it to drive a 50W linear amp that I have. But when I set the power to 5W, as soon as I put the cover on the case it dropped to 1.5W. So I thought that perhaps the whole thing needs realignment.
Unfortunately it did not go well. The transverter, which I bought umpteenth-hand in a private sale some time ago, had obviously suffered the depredations of the ham-fisted twiddler. Two of the ferrite tuning cores in the Toko coils were cracked and could neither be adjusted nor removed so they could be replaced. Despite this, the transverter receives pretty well.
However, while trying to realign the transmit side to solve the problem of changing power output when the case cover goes on, I noticed that there was often power out when the key was up. There was clearly some instability present. Although I could adjust the trimmers so there was no unwanted output, I could not eliminate the changing output as the case cover is put on. I do not have the test equipment (a spectrum analyzer) to be sure that the output is clean and I started to have doubts about the whole thing.
I did not want to risk wiping out the neighbour's TV reception whenever I use 2m SSB. So I decided to scrap the transverter and order an XV144 internal transverter module for my K3. It is on its way, and hopefully will arrive in the UK before the increase in VAT takes effect.
The Kenwood has been moved into the "second rig" operating position. And the desk mic I used with the Icom is now attached to the Kenwood. I had some CAT5 UTP network cables which are terminated in the same type of plug Kenwood uses for a mic connector, so I cut one in half and made up a cable for the desk mic. Despite being unshielded (UTP stands for Unshielded Twisted Pair) there doesn't seem to be any RFI even at 50W. And the reports I have had so far suggest that it sounds good.
The Spectrum transverter runs about 20W output. This is less than I would like for SSB. My plan was to set the transverter drive so the peak output was 5W and use it to drive a 50W linear amp that I have. But when I set the power to 5W, as soon as I put the cover on the case it dropped to 1.5W. So I thought that perhaps the whole thing needs realignment.
Unfortunately it did not go well. The transverter, which I bought umpteenth-hand in a private sale some time ago, had obviously suffered the depredations of the ham-fisted twiddler. Two of the ferrite tuning cores in the Toko coils were cracked and could neither be adjusted nor removed so they could be replaced. Despite this, the transverter receives pretty well.
However, while trying to realign the transmit side to solve the problem of changing power output when the case cover goes on, I noticed that there was often power out when the key was up. There was clearly some instability present. Although I could adjust the trimmers so there was no unwanted output, I could not eliminate the changing output as the case cover is put on. I do not have the test equipment (a spectrum analyzer) to be sure that the output is clean and I started to have doubts about the whole thing.
I did not want to risk wiping out the neighbour's TV reception whenever I use 2m SSB. So I decided to scrap the transverter and order an XV144 internal transverter module for my K3. It is on its way, and hopefully will arrive in the UK before the increase in VAT takes effect.
Earthquake in Cumbria
I started up my APRS gateway this morning and noticed an unusual symbol on the screen. I clicked on it and discovered that WE7U had posted an object to mark the epicentre of a minor earthquake measuring 3.6 on the Richter scale that occurred about 20 miles to the south of here at around 2300z last night.
It was felt in nearby Workington and even across the water in Dumfries and Galloway with some people describing it as "scary". We were completely unaware of it. But now I know what happened, I recall that just after we had gone to bed I heard a noise from the attic like someone was up there and stood heavily on the rafters. I said to Olga "did you hear that?" and she said she thought it was a heavy vehicle passing on the A66. So that was how the earth moved for us.
It was felt in nearby Workington and even across the water in Dumfries and Galloway with some people describing it as "scary". We were completely unaware of it. But now I know what happened, I recall that just after we had gone to bed I heard a noise from the attic like someone was up there and stood heavily on the rafters. I said to Olga "did you hear that?" and she said she thought it was a heavy vehicle passing on the A66. So that was how the earth moved for us.
Monday, December 20, 2010
Frequency check
In all the years I have been a ham and home constructor one item of test equipment I have never possessed is a frequency counter. Whenever I have needed to test if something is oscillating I have just stuck a bit of wire in the antenna socket of a receiver and listened for it, and if I have needed to tune an oscillator on frequency I have just tuned it for zero beat using a receiver that has been adjusted as best I could using WWV or similar.
Recently I decided that it would be useful to actually have a frequency counter, preferably a really accurate one. I know that it is possible to buy secondhand lab grade frequency counters on eBay. The trouble is that when your shack / workshop is the size of a broom cupboard there is no room for boat anchors. I didn't even have space for one of the inexpensive desktop frequency counters that are available. I decided that I would have to make do with a hand-held device. Farnell had one, but the price of £140 was rather too steep given the amount of use it was likely to get. I was about to give up when I came across the Yaege FC-1 being sold for about £30 on eBay.
My initial thought was that this was such a cheap device that it could not be very accurate and was probably not worth getting. The specification gives the time base accuracy as < 5ppm, which is worse than most ham radio transceivers. However, a bit of searching produced a PDF copy of the manual, which revealed that the TCXO module is user adjustable. I figured that I could get better than the quoted accuracy by regularly calibrating it using my rubidium frequency standard.
I ordered one from one of the Hong Kong traders and it came in just over a week. The antenna socket is a male SMA, similar to that used on the Chinese VHF/UHF hand-held radios and the opposite type to that commonly used by Japanese manufacturers. A short UHF rubber duck antenna is supplied with the counter. I ordered a BNC adapter so I could use my BNC whip antennas and also attach BNC terminated test cables.
I connected it up to my 10MHz rubidium frequency standard and found that it was already within a couple of Hz of the correct reading. The picture was taken before I set the gate time to 1 second which is necessary to get a reading down to 1Hz.
The time base oscillator adjustment is behind the battery compartment so you need to run the device from the charger while adjusting the frequency. You can see the adjuster in the picture on the right. Rather like adjusting the master oscillator in the Elecraft K2 the adjustment is incredibly touchy. The tiniest amount of movement can change the reading by a couple of Hz at 10MHz.
It turns out that it is not worth being so picky. The reading does slowly drift by a few Hz over a period of several minutes so you are never going to get absolute accuracy with a device like this. Nevertheless it is better than advertised and pretty good for the money, in my opinion.
One feature of the Yaege FC-1 that you don't get with most frequency counters is a signal strength reading calibrated in dBm, as you can see in the top photo taken while I was transmitting a carrier on 145.500MHz. I wasn't able to check how accurate the actual reading is but as a relative indicator the dB measurements seem quite accurate so this could be quite a useful tool for making antenna comparisons. It turns the frequency counter into a digital field strength meter.
Although it isn't a lab grade high accuracy frequency counter I think the Yaege FC-1 is a useful addition to my electronic test equipment and is extremely good value for money.
Recently I decided that it would be useful to actually have a frequency counter, preferably a really accurate one. I know that it is possible to buy secondhand lab grade frequency counters on eBay. The trouble is that when your shack / workshop is the size of a broom cupboard there is no room for boat anchors. I didn't even have space for one of the inexpensive desktop frequency counters that are available. I decided that I would have to make do with a hand-held device. Farnell had one, but the price of £140 was rather too steep given the amount of use it was likely to get. I was about to give up when I came across the Yaege FC-1 being sold for about £30 on eBay.
My initial thought was that this was such a cheap device that it could not be very accurate and was probably not worth getting. The specification gives the time base accuracy as < 5ppm, which is worse than most ham radio transceivers. However, a bit of searching produced a PDF copy of the manual, which revealed that the TCXO module is user adjustable. I figured that I could get better than the quoted accuracy by regularly calibrating it using my rubidium frequency standard.
I ordered one from one of the Hong Kong traders and it came in just over a week. The antenna socket is a male SMA, similar to that used on the Chinese VHF/UHF hand-held radios and the opposite type to that commonly used by Japanese manufacturers. A short UHF rubber duck antenna is supplied with the counter. I ordered a BNC adapter so I could use my BNC whip antennas and also attach BNC terminated test cables.
I connected it up to my 10MHz rubidium frequency standard and found that it was already within a couple of Hz of the correct reading. The picture was taken before I set the gate time to 1 second which is necessary to get a reading down to 1Hz.
The time base oscillator adjustment is behind the battery compartment so you need to run the device from the charger while adjusting the frequency. You can see the adjuster in the picture on the right. Rather like adjusting the master oscillator in the Elecraft K2 the adjustment is incredibly touchy. The tiniest amount of movement can change the reading by a couple of Hz at 10MHz.
It turns out that it is not worth being so picky. The reading does slowly drift by a few Hz over a period of several minutes so you are never going to get absolute accuracy with a device like this. Nevertheless it is better than advertised and pretty good for the money, in my opinion.
One feature of the Yaege FC-1 that you don't get with most frequency counters is a signal strength reading calibrated in dBm, as you can see in the top photo taken while I was transmitting a carrier on 145.500MHz. I wasn't able to check how accurate the actual reading is but as a relative indicator the dB measurements seem quite accurate so this could be quite a useful tool for making antenna comparisons. It turns the frequency counter into a digital field strength meter.
Although it isn't a lab grade high accuracy frequency counter I think the Yaege FC-1 is a useful addition to my electronic test equipment and is extremely good value for money.
Sunday, December 19, 2010
Useful RFI
I apologize for being even more grumpy than normal but I haven't had much sleep. Olga and I were woken up at around 1 in the morning by a lot of noise outside. It was a group of young people who had apparently been having a party in the house opposite. Despite the fact that the temperature was heading for -7C and the girls, according to Olga who was looking out of the window, were none too warmly clad, they were not simply saying goodbye but continuing an animated conversation. Someone decided the party must be carrying on outside so they switched on a car's headlamps and turned on the stereo very loud. Because of the way the houses are crammed together here with virtually no front gardens this was taking place right below our bedroom window. After ten minutes we were both getting very angry. It isn't often that Olga uses the f word about people.
I felt like calling the police, but the chances of them actually making an appearance before the miscreants had slept off their hangovers was pretty remote so we discarded that idea. Olga went downstairs and turned on the lights to try and make it obvious that we had been disturbed. I went into the shack, switched on the K2 and sent a 10W dit on 30m, which switched on the security lights of the nearby neighbours that have them. This did appear to have the effect of making the tiny minds think "gosh, other people live around here and oh my, it's after 1 in the morning, perhaps they are trying to sleep and our noise has disturbed them!" because shortly afterwards the group dispersed and peace and quiet resumed. But neither of us are good sleepers and it took a while before we calmed down enough to sleep again. Hence the foul mood this morning.
It has sometimes been a bit annoying that I can't go on any band except 80m after dark because of the problem with security lights. But on this occasion it turned out to be useful. If only I knew that the thoughtless young people had touch sensitive lamps by their bedside I might even have been tempted to try a bit of all-night WSPR!
I felt like calling the police, but the chances of them actually making an appearance before the miscreants had slept off their hangovers was pretty remote so we discarded that idea. Olga went downstairs and turned on the lights to try and make it obvious that we had been disturbed. I went into the shack, switched on the K2 and sent a 10W dit on 30m, which switched on the security lights of the nearby neighbours that have them. This did appear to have the effect of making the tiny minds think "gosh, other people live around here and oh my, it's after 1 in the morning, perhaps they are trying to sleep and our noise has disturbed them!" because shortly afterwards the group dispersed and peace and quiet resumed. But neither of us are good sleepers and it took a while before we calmed down enough to sleep again. Hence the foul mood this morning.
It has sometimes been a bit annoying that I can't go on any band except 80m after dark because of the problem with security lights. But on this occasion it turned out to be useful. If only I knew that the thoughtless young people had touch sensitive lamps by their bedside I might even have been tempted to try a bit of all-night WSPR!
Friday, December 17, 2010
An APRS Gateway
Yesterday I spent a couple of hours trying out aprsg - an APRS iGate that runs on both Linux and Windows which has been developed by Tapio, OH2GVE and Antti, OH3HMI and released under the GNU GPL.
The program has no user interface. Under Windows it displays a G icon in the system tray. All configuration is done by editing an INI file, in examples of which all the documentation is contained! Despite its relative simplicity there are a few unanswered questions about how things work, so some trial and error is necessary.
The unique feature of aprsg - as far as I know - is that it lets you specify filters to control what is gated from the internet to RF. You can gate packets addressed to specific callsigns or callsign blocks (using a mask) and this can be ANDed or ORed with area based filters (either a box or a circle centered on a point.) It was wonderful in this relative APRS desert to see local stations and objects appearing on RF and being displayed on my TH-D72 and VX-8GR. It was like being back in Prague again! This is not something you would want to do in an area where there is other APRS activity but for someone who lives out of range of any digipeater or gateway aprsg could make APRS usable and fun.
The program supports multiple RF ports and can do cross-band gating using the same rules. I didn't try this, and did not understand how to set different call-ssids to the different RF ports. It appeared to me that the gateway and everything connected to it uses the same call-ssid, though this may be my misunderstanding.
A significant limitation is that aprsg only supports KISS TNCs (and AX.25 on Linux) but does not provide any way to send a script to TNCs that need a couple of commands to get them into KISS mode. It doesn't support AGW Packet Engine, but those who don't have TNCs might be able to connect it to a TrueTTY virtual TNC for sound card operation.
Aprsg provides no support for digipeating - a pity, the possibility of filter-based digipeating would be most interesting. It also doesn't provide a local APRS-IS server for users to connect graphical APRS clients like APRSISCE/32. So you would need to connect your GUI client separately to APRS-IS using a different call-ssid to your gateway.
These limitations apart, aprsg is a potentially useful program for anyone wanting to set up an APRS internet gateway. It's quite easy to get going and has a very low resource usage.
The program has no user interface. Under Windows it displays a G icon in the system tray. All configuration is done by editing an INI file, in examples of which all the documentation is contained! Despite its relative simplicity there are a few unanswered questions about how things work, so some trial and error is necessary.
The unique feature of aprsg - as far as I know - is that it lets you specify filters to control what is gated from the internet to RF. You can gate packets addressed to specific callsigns or callsign blocks (using a mask) and this can be ANDed or ORed with area based filters (either a box or a circle centered on a point.) It was wonderful in this relative APRS desert to see local stations and objects appearing on RF and being displayed on my TH-D72 and VX-8GR. It was like being back in Prague again! This is not something you would want to do in an area where there is other APRS activity but for someone who lives out of range of any digipeater or gateway aprsg could make APRS usable and fun.
The program supports multiple RF ports and can do cross-band gating using the same rules. I didn't try this, and did not understand how to set different call-ssids to the different RF ports. It appeared to me that the gateway and everything connected to it uses the same call-ssid, though this may be my misunderstanding.
A significant limitation is that aprsg only supports KISS TNCs (and AX.25 on Linux) but does not provide any way to send a script to TNCs that need a couple of commands to get them into KISS mode. It doesn't support AGW Packet Engine, but those who don't have TNCs might be able to connect it to a TrueTTY virtual TNC for sound card operation.
Aprsg provides no support for digipeating - a pity, the possibility of filter-based digipeating would be most interesting. It also doesn't provide a local APRS-IS server for users to connect graphical APRS clients like APRSISCE/32. So you would need to connect your GUI client separately to APRS-IS using a different call-ssid to your gateway.
These limitations apart, aprsg is a potentially useful program for anyone wanting to set up an APRS internet gateway. It's quite easy to get going and has a very low resource usage.
Tuesday, December 14, 2010
Work FM Satellites
I came across this website while reading a thread about the new Kenwood TH-D72. It claims to be the best website for current information about working FM satellites. It looks pretty good, but I really need to find the time to look through all the information. There's a blog, too.
The trouble with this hobby is that there is so little time and so many interesting, challenging things you can do!
The trouble with this hobby is that there is so little time and so many interesting, challenging things you can do!
Monday, December 13, 2010
APRS Handies head to head
My long awaited package from Martin Lynch was finally delivered by UPS on Saturday afternoon and as one reader correctly guessed, it was a new Kenwood TH-D72! I was lucky. The UPS tracking page had been changed to say delivery was rescheduled for Monday, so we went out on Saturday morning. You can imagine how happy I would have been to get home and find a card through the door to say UPS had tried to deliver it! I was pleased to receive the radio and although I did consider wrapping it and putting it under the tree until Christmas Day, the chance of being the first blogger to write about it was too great to resist.
This is not meant to be a review of the Kenwood, more an account of my first impressions of the radio and how it compares with the Yaesu VX-8GR which I have been using for the past few months. The first thing you notice is that the Kenwood is quite a bit bigger than the Yaesu. It's taller, thicker and heavier. Although I think the Kenwood is nicer looking, the Yaesu feels a bit more rugged and I think its plain black finish would take knocks and scuffs better than the Kenwood's metallic grey finish. I'll probably need to get a protective case for it.
The additional thickness and weight can partly be attributed to the Kenwood's battery pack which has 1800mAh capacity, compared to the Yaesu's 1100mAh. This should translate into longer endurance in the field. Yaesu does offer an 1800mAh battery pack for the VX-8 series but it is an optional extra for quite a lot more money. Still, there is no question the slimmer, smaller VX-8GR slips more easily into a pocket for about-town use.
The TH-D72 is a dual band 2m/70cm radio so it it is more directly comparable with the Yaesu VX-8GR than with the tri-band (quad band in the USA) VX-8DR. Both radios have an integral GPS rather than the expensive optional GPS of the VX-8DR which must be fitted to an even more absurdly expensive clunky looking bracket or to a specially made Yaesu speaker mic. (Having said that, the Yaesu GPS options are good value compared to the add-ons for Icom's D-Star radios - talk about rip-offs.)
The TH-D72 comes with the usual pathetic SMA socket for the antenna and an equally pathetic dual band dummy load, er, I mean whip antenna. The first thing I did, and I mean literally the first thing, was to fit one of my SMA to BNC adapters so I can use any of my collection of BNC whip antennas with the rig. The SMA socket sits deep in a large recess on the top face of the Kenwood, so I was able to use one of the chunky gold plated adapters rather than the slimmer black one that I use on the VX-8GR.
I checked with a piece of paper to see if the adapter tightened all the way down to the body of the radio, which is essential to avoid the risk of snapping the SMA at the first accidental knock. It didn't, so I added a steel washer to fill the gap. I covered the knurled base of the adapter with a layer of self amalgamating tape to hide the gold finish and once an antenna is fitted you wouldn't know that the BNC socket was not standard equipment. Why couldn't the manufacturers fit one in the first place? By the way, neither of these radios come with a wrist strap - the ones shown in the picture were salvaged from old mobile phones in the junk box.
One of the main reasons I decided to get the Kenwood TH-D72 even though I had the VX-8GR was that I was very unhappy with the performance of the Yaesu's GPS which is slow to acquire a fix and usually can't manage it at all from inside the house. I found this a real nuisance as often I just could not be bothered to hang around waiting for it, while the chance of acquiring a fix once you are on the move is even worse. As you can see from the picture above, the Kenwood has got my position while sitting on the bench being photographed while the Yaesu's GPS screen was (and remained) blank.
The Kenwood has a display to show how many GPS satellites it is receiving and as you can see from the picture above, even on the bench it does quite well. This is a nice screen to have, but with this exception I prefer the Yaesu VX-8 display which shows more information at a glance. The Kenwood display often consists of a couple of short lines of text and you have to page through several screens to get all the information. However I do like that the Kenwood position screen shows the grid locator square - the Yaesu doesn't.
The TH-D72 has the ability to plot your track and store it in memory - not something I can see myself using though. What I do consider very useful is the ability to enter and store the co-ordinates of several locations or waypoints. You can then select one and one of the Position pages will display your distance and bearing from it. This will be very useful during WOTA operating as I will be able to enter the exact co-ordinates of the summits I intend to visit, eliminating the difficulty sometimes experienced of identifying the summit on the ground!
The TH-D72 is virtually a hand held TM-D710. It has almost the same functionality of its bigger mobile brother, in fact more: it supports the Kenwood Sky Command remote control system which my European D710 doesn't. A pity - it would have been fun to see if I could have used it to remote control my Elecraft K3, which uses a command set similar to the TS2000.
In common with the D710 the D72 has hierarchical menus. Personally I prefer the menu system of the VX-8 series, which has just two linear menus, one for radio settings and one for APRS. I know where the ones I most often use are and can quickly zip to them using the rotary control. The Kenwood menus require a lot of clicking with the four way directional button thingy.
If you want to connect your VX-8 to a PC for memory management you need to purchase third party memory management software and an interface cable. Kenwood provides the memory management software free and the TH-D72 has a USB port which can be connected to your computer using a provided, but in any case standard, USB cable - a significant saving. Through this cable you can not only manage the memories you can also edit all the radio's settings and access the built-in packet TNC. This appears to be completely compatible with the one in the TM-D710. I just changed the COM port number and APRSIS32 as set up for the D710 was immediately able to use the D72 instead. A menu option allows the internal GPS data to be output over the same serial connection. I haven't experimented with this, so I don't know if this can be done at the same time as accessing the TNC or whether APRSIS32 would be able to take advantage of it.
Hopefully the TH-D72 will, like the D710 (and unlike the Yaesu radios) be software upgradeable. I discovered, to my disappointment, that my APRS repeater objects being transmitted by my G4ILO gateway were displayed by the VX-8GR but not by the Kenwood. The packets were received but were apparently considered to be invalid. A bit of research by Kai Gunter, LA3QMA led to the conclusion that this is a bug, not just in the TH-D72 firmware but in the TM-D710 as well, as the same objects were displayed by older model Kenwoods. The problem is apparently caused by the time-stamp in the objects created by APRSIS32 which is in local time (ending in 'h') instead of zulu time (ending in 'z'.) The objects are correct according to the APRS spec, so the Kenwood should display them.
The TH-D72 is full duplex. That is, it can receive on 70cm while transmitting on 2m or vice versa. There are very few current model radios that can do this, one of which (the Alinco DJ-G7) doesn't do it very well as 70cm is severely desensed by the 2m transmission. This would make it a good choice for FM satellite operation allowing you to hear your own signal. One of these days I will try this, I just need to get round to making a suitable dual band antenna.
Another neat feature of the TH-D72 is the nine EchoLink memories. This allows the radio to store the DTMF sequence needed to connect to up to nine different conferences or nodes so you can recall them by name and transmit them to your local EchoLink repeater. If you use EchoLink it is a real boon as I can never remember node numbers - heck, I still can't remember my mobile phone number!
The Kenwood TH-D72 is quite an amazing radio packing an incredible number of features into its small form factor. However I would not go so far as to say it is a better radio than the VX-8GR. There are things I like and things I dislike about each of them.
I'm still making my mind up which of the two of them is going to be the keeper but I suspect it's going to be the Kenwood.
This is not meant to be a review of the Kenwood, more an account of my first impressions of the radio and how it compares with the Yaesu VX-8GR which I have been using for the past few months. The first thing you notice is that the Kenwood is quite a bit bigger than the Yaesu. It's taller, thicker and heavier. Although I think the Kenwood is nicer looking, the Yaesu feels a bit more rugged and I think its plain black finish would take knocks and scuffs better than the Kenwood's metallic grey finish. I'll probably need to get a protective case for it.
The additional thickness and weight can partly be attributed to the Kenwood's battery pack which has 1800mAh capacity, compared to the Yaesu's 1100mAh. This should translate into longer endurance in the field. Yaesu does offer an 1800mAh battery pack for the VX-8 series but it is an optional extra for quite a lot more money. Still, there is no question the slimmer, smaller VX-8GR slips more easily into a pocket for about-town use.
The TH-D72 is a dual band 2m/70cm radio so it it is more directly comparable with the Yaesu VX-8GR than with the tri-band (quad band in the USA) VX-8DR. Both radios have an integral GPS rather than the expensive optional GPS of the VX-8DR which must be fitted to an even more absurdly expensive clunky looking bracket or to a specially made Yaesu speaker mic. (Having said that, the Yaesu GPS options are good value compared to the add-ons for Icom's D-Star radios - talk about rip-offs.)
The TH-D72 comes with the usual pathetic SMA socket for the antenna and an equally pathetic dual band dummy load, er, I mean whip antenna. The first thing I did, and I mean literally the first thing, was to fit one of my SMA to BNC adapters so I can use any of my collection of BNC whip antennas with the rig. The SMA socket sits deep in a large recess on the top face of the Kenwood, so I was able to use one of the chunky gold plated adapters rather than the slimmer black one that I use on the VX-8GR.
I checked with a piece of paper to see if the adapter tightened all the way down to the body of the radio, which is essential to avoid the risk of snapping the SMA at the first accidental knock. It didn't, so I added a steel washer to fill the gap. I covered the knurled base of the adapter with a layer of self amalgamating tape to hide the gold finish and once an antenna is fitted you wouldn't know that the BNC socket was not standard equipment. Why couldn't the manufacturers fit one in the first place? By the way, neither of these radios come with a wrist strap - the ones shown in the picture were salvaged from old mobile phones in the junk box.
One of the main reasons I decided to get the Kenwood TH-D72 even though I had the VX-8GR was that I was very unhappy with the performance of the Yaesu's GPS which is slow to acquire a fix and usually can't manage it at all from inside the house. I found this a real nuisance as often I just could not be bothered to hang around waiting for it, while the chance of acquiring a fix once you are on the move is even worse. As you can see from the picture above, the Kenwood has got my position while sitting on the bench being photographed while the Yaesu's GPS screen was (and remained) blank.
The Kenwood has a display to show how many GPS satellites it is receiving and as you can see from the picture above, even on the bench it does quite well. This is a nice screen to have, but with this exception I prefer the Yaesu VX-8 display which shows more information at a glance. The Kenwood display often consists of a couple of short lines of text and you have to page through several screens to get all the information. However I do like that the Kenwood position screen shows the grid locator square - the Yaesu doesn't.
The TH-D72 has the ability to plot your track and store it in memory - not something I can see myself using though. What I do consider very useful is the ability to enter and store the co-ordinates of several locations or waypoints. You can then select one and one of the Position pages will display your distance and bearing from it. This will be very useful during WOTA operating as I will be able to enter the exact co-ordinates of the summits I intend to visit, eliminating the difficulty sometimes experienced of identifying the summit on the ground!
The TH-D72 is virtually a hand held TM-D710. It has almost the same functionality of its bigger mobile brother, in fact more: it supports the Kenwood Sky Command remote control system which my European D710 doesn't. A pity - it would have been fun to see if I could have used it to remote control my Elecraft K3, which uses a command set similar to the TS2000.
In common with the D710 the D72 has hierarchical menus. Personally I prefer the menu system of the VX-8 series, which has just two linear menus, one for radio settings and one for APRS. I know where the ones I most often use are and can quickly zip to them using the rotary control. The Kenwood menus require a lot of clicking with the four way directional button thingy.
If you want to connect your VX-8 to a PC for memory management you need to purchase third party memory management software and an interface cable. Kenwood provides the memory management software free and the TH-D72 has a USB port which can be connected to your computer using a provided, but in any case standard, USB cable - a significant saving. Through this cable you can not only manage the memories you can also edit all the radio's settings and access the built-in packet TNC. This appears to be completely compatible with the one in the TM-D710. I just changed the COM port number and APRSIS32 as set up for the D710 was immediately able to use the D72 instead. A menu option allows the internal GPS data to be output over the same serial connection. I haven't experimented with this, so I don't know if this can be done at the same time as accessing the TNC or whether APRSIS32 would be able to take advantage of it.
Hopefully the TH-D72 will, like the D710 (and unlike the Yaesu radios) be software upgradeable. I discovered, to my disappointment, that my APRS repeater objects being transmitted by my G4ILO gateway were displayed by the VX-8GR but not by the Kenwood. The packets were received but were apparently considered to be invalid. A bit of research by Kai Gunter, LA3QMA led to the conclusion that this is a bug, not just in the TH-D72 firmware but in the TM-D710 as well, as the same objects were displayed by older model Kenwoods. The problem is apparently caused by the time-stamp in the objects created by APRSIS32 which is in local time (ending in 'h') instead of zulu time (ending in 'z'.) The objects are correct according to the APRS spec, so the Kenwood should display them.
The TH-D72 is full duplex. That is, it can receive on 70cm while transmitting on 2m or vice versa. There are very few current model radios that can do this, one of which (the Alinco DJ-G7) doesn't do it very well as 70cm is severely desensed by the 2m transmission. This would make it a good choice for FM satellite operation allowing you to hear your own signal. One of these days I will try this, I just need to get round to making a suitable dual band antenna.
Another neat feature of the TH-D72 is the nine EchoLink memories. This allows the radio to store the DTMF sequence needed to connect to up to nine different conferences or nodes so you can recall them by name and transmit them to your local EchoLink repeater. If you use EchoLink it is a real boon as I can never remember node numbers - heck, I still can't remember my mobile phone number!
The Kenwood TH-D72 is quite an amazing radio packing an incredible number of features into its small form factor. However I would not go so far as to say it is a better radio than the VX-8GR. There are things I like and things I dislike about each of them.
- Yaesu VX-8GR - Like: smaller size, lighter weight, feels more durable, more informative displays. Dislike: deaf GPS.
- Kenwood TH-D72 - Like: sensitive GPS, editable waypoints, accessible TNC, EchoLink support, full duplex. Dislike: hierarchical menus, plain displays requiring scrolling through pages to view all information, more bulky.
I'm still making my mind up which of the two of them is going to be the keeper but I suspect it's going to be the Kenwood.
Saturday, December 11, 2010
APRS could have helped protect Charles and Camilla
The Metropolitan Police are denying that the incident in which a car carrying Prince Charles and his wife came under attack by student demonstrators occurred through a failure in radio communications. Reports that royal protection officers were using a different frequency to those policing the protest are "untrue", the police insist. The two teams were in communication using email or mobile phones. They what?? Perhaps they had carrier pigeons as a backup.
It seems to me that someone needs to knock on the door of Scotland Yard and suggest that they need a tactical digital communications system on the lines of APRS. If the officers escorting the royal couple could have seen on a map display where the demonstrators were and exchanged brief tactical messages with other officers in the area, this embarrassing incident would never have happened. It makes you wonder just how competent our security forces really are.
It seems to me that someone needs to knock on the door of Scotland Yard and suggest that they need a tactical digital communications system on the lines of APRS. If the officers escorting the royal couple could have seen on a map display where the demonstrators were and exchanged brief tactical messages with other officers in the area, this embarrassing incident would never have happened. It makes you wonder just how competent our security forces really are.
Friday, December 10, 2010
Lost memory
I am a strong believer that "if it ain't broke, don't fix it." I also find that, particularly if it is anything to do with computers, the law "if something can go wrong, it will" operates with near 100% certainty. As a consequence, I an extremely reluctant to upgrade or update anything unless it fixes a problem I've experienced or am likely to experience, or provides new functionality that I actually need. I get anxious whenever the "Windows has new updates" balloon pops up, worrying about whether my computer is going to get screwed fixing some obscure vulnerability I don't understand in some bit of Windows I may not even use.
One of the problems of getting old is that you tend to forget things and sometimes I do something having forgotten that the day before I had decided there was no point in doing it. And so, this morning, I decided to update the firmware in my Kenwood TH-D710 in order that it could identify from APRS packets newer radios like the VX-8G and TH-D72, regardless of the fact that I hardly ever use the radio's own APRS display and the update would not affect the ability of APRSIS32 to identify these radios on my PC.
I downloaded the update software, browsed the help file that came with it and then ran the program and followed the instructions it displayed. The update went without a hitch. I was a bit concerned when the concluding instruction was to perform a full reset, which I thought would erase all my settings, but I had not seen any dire warnings about this so I went ahead. Sure enough, on completion the Kenwood was now in factory default mode, with all my settings and laboriously entered memory channels lost forever! Arrghh! If only there was a System Restore for real life!
Kenwood does provide a free memory management program for the TM-D710, MCP-2A, which can be used to edit, back up and restore memories and settings. However it needs a second serial cable attached to a different port to the one used for the built-in TNC. I had never got around to making up another cable as I don't need computer control of the radio and storing channels in memory manually isn't that hard so I don't usually bother with programming software. Besides, all four serial ports on the shack PC were already used. So I had never tried it.
In the hope that it would save me time re-entering the settings and memories, which I could then back up, I installed MCP-2A and moved my serial cable from the radio's control head (the TNC port) to the PC port at the back. But no matter what I tried, the program could not communicate with the radio.
Now I'm completely stumped. I'm using the same PC serial port and cable as I used to perform the upgrade and access the TNC, so the port and serial cable work. I tried the "Auto" baud rate setting and several manual selections and it made no difference. As this is the first time I have used it, I'm wondering if the rear PC port is actually broken. Have I overlooked something stupid? Is there anything else I could try to test if it works?
One of the problems of getting old is that you tend to forget things and sometimes I do something having forgotten that the day before I had decided there was no point in doing it. And so, this morning, I decided to update the firmware in my Kenwood TH-D710 in order that it could identify from APRS packets newer radios like the VX-8G and TH-D72, regardless of the fact that I hardly ever use the radio's own APRS display and the update would not affect the ability of APRSIS32 to identify these radios on my PC.
I downloaded the update software, browsed the help file that came with it and then ran the program and followed the instructions it displayed. The update went without a hitch. I was a bit concerned when the concluding instruction was to perform a full reset, which I thought would erase all my settings, but I had not seen any dire warnings about this so I went ahead. Sure enough, on completion the Kenwood was now in factory default mode, with all my settings and laboriously entered memory channels lost forever! Arrghh! If only there was a System Restore for real life!
Kenwood does provide a free memory management program for the TM-D710, MCP-2A, which can be used to edit, back up and restore memories and settings. However it needs a second serial cable attached to a different port to the one used for the built-in TNC. I had never got around to making up another cable as I don't need computer control of the radio and storing channels in memory manually isn't that hard so I don't usually bother with programming software. Besides, all four serial ports on the shack PC were already used. So I had never tried it.
In the hope that it would save me time re-entering the settings and memories, which I could then back up, I installed MCP-2A and moved my serial cable from the radio's control head (the TNC port) to the PC port at the back. But no matter what I tried, the program could not communicate with the radio.
Now I'm completely stumped. I'm using the same PC serial port and cable as I used to perform the upgrade and access the TNC, so the port and serial cable work. I tried the "Auto" baud rate setting and several manual selections and it made no difference. As this is the first time I have used it, I'm wondering if the rear PC port is actually broken. Have I overlooked something stupid? Is there anything else I could try to test if it works?
Thursday, December 09, 2010
UPS: Useless Pathetic Shower
What a useless courier company UPS is. I ordered something from Martin Lynch on Tuesday afternoon and was informed that it had been shipped an hour later by UPS. At 7.45 on Wednesday morning the UPS tracking site showed the package had arrived in the depot at Carlisle and was marked as in transit for delivery that day. I waited in all day and nothing arrived. Later that evening I checked the site again and found the message at 6.45pm: THE PACKAGE WAS MISSED AT THE UPS FACILITY, UPS WILL DELIVER ON THE NEXT BUSINESS DAY / DELIVERY RESCHEDULE. The delivery date was changed to today (Thursday.)
So I waited in all day today and still no UPS man. Again I checked the UPS tracking site this evening and the same message had been added, this time at 7.48pm. The delivery date is now rescheduled for tomorrow (Friday.)
We have had poor weather conditions and the roads have been icy but FedEx called as usual around lunch time to the neighbour across the road who has a regular delivery. And Interlink Direct called to pick up two packages of items I'd sold on eBay the shipment of which I'd arranged online yesterday. (Tip: use the code XMAS10 to get £5 off a delivery before Christmas.) So I don't think that's a valid excuse, really.
I wonder what the chances are that I will actually receive my new toy tomorrow? I just hope that when it does arrive I don't find they have lived up to the other meaning of their acronym: United Package Smashers.
So I waited in all day today and still no UPS man. Again I checked the UPS tracking site this evening and the same message had been added, this time at 7.48pm. The delivery date is now rescheduled for tomorrow (Friday.)
We have had poor weather conditions and the roads have been icy but FedEx called as usual around lunch time to the neighbour across the road who has a regular delivery. And Interlink Direct called to pick up two packages of items I'd sold on eBay the shipment of which I'd arranged online yesterday. (Tip: use the code XMAS10 to get £5 off a delivery before Christmas.) So I don't think that's a valid excuse, really.
I wonder what the chances are that I will actually receive my new toy tomorrow? I just hope that when it does arrive I don't find they have lived up to the other meaning of their acronym: United Package Smashers.
Death of 20m incorrectly reported
It's a good job I looked at the beacon reports this morning or I wouldn't have noticed that there were no reception reports for the 20m band. The problem was that I had visited 20m yesterday and put the K3 into data mode. An annoying feature of the K3 is that when you change bands it restores the mode you last used on that band. It does that even if the band change is being made under software control, even if the mode it is restoring is inappropriate for the frequency you are changing to under the band plan. This is totally bonkers logic because no computer program worth its salt should make assumptions about the state of the radio so when changing the frequency it should also set the mode. Unfortunately if it sets the mode too quickly, or before the frequency change is sent, the K3 "feature" overrides the mode set by the software. Consequently the option in Faros to "force CW mode" doesn't work on the K3 and you are left in the mode you last used on that band.
Faros is not alone in experiencing this problem. Complaints have been frequent on the Elecraft reflector that when clicking on DX cluster spots in various programs the radio changes to the right frequency but is in the wrong mode. One of the reasons I wrote KComm specifically for the Elecraft radios was that I could make it work the way the radios work instead of being stuck with some generic logic. But there is nothing I can do about programs I didn't write. I wish that more ham radio applications were open source so you could fix problems like this yourself instead of having to ask a developer to make the necessary changes (and very often getting nowhere.)
Faros is not alone in experiencing this problem. Complaints have been frequent on the Elecraft reflector that when clicking on DX cluster spots in various programs the radio changes to the right frequency but is in the wrong mode. One of the reasons I wrote KComm specifically for the Elecraft radios was that I could make it work the way the radios work instead of being stuck with some generic logic. But there is nothing I can do about programs I didn't write. I wish that more ham radio applications were open source so you could fix problems like this yourself instead of having to ask a developer to make the necessary changes (and very often getting nowhere.)
Wednesday, December 08, 2010
My first QSO with V4 mode
This was on 80m, running 25W to the bent 80plus2 dipole in the attic. I also copied snatches from WD4KPD and KC2DMC. I have never worked across the Atlantic on 80m on any mode, so this new mode seems quite promising.
Yet Another Digital Mode
Windows PC users now have the option to try yet another weak signal digital mode. Called V4, it is described as "a robust, easy to use, keyboard sound card mode that would fit into the narrow digital segments of our HF bands." The mode is 200Hz wide and capable of sending text at 40 - 60 words per minute.
Do we need yet another keyboard digital mode? Although PSK31 is very popular and very narrow, performance deteriorates under conditions of multipath reception (such as in NVIS propagation) or when the ionosphere is disturbed (polar paths during periods of auroral activity) while RTTY, though also popular, is archaic, inefficient and successful only by brute force methods (a big amplifier and a beam.) More robust FSK modes such as MFSK, Olivia, Thor and DominoEX perform better but are much wider which can be a barrier to use. V4 uses the same robust modulation scheme as WINMOR but has been optimized for use as a keyboard chat mode. A detailed protocol description can be found here and the software can be obtained after joining the V4 Protocol Yahoo Group.
I have only just been admitted to the group so I have some reading to catch up on and it will be a few days before I can find the time to try V4 for myself. However I am quite interested in this mode which seems to have been developed by licensed hams keeping in mind the need for responsible band use (so no 2.2kHz wide signals!) and with all the details being published and open. The software modem has been implemented as a standalone TNC that can be interfaced with other applications such as my own program KComm which is also interesting to me. So I think you can expect to hear more about the V4 Protocol in this blog in the weeks to come.
Do we need yet another keyboard digital mode? Although PSK31 is very popular and very narrow, performance deteriorates under conditions of multipath reception (such as in NVIS propagation) or when the ionosphere is disturbed (polar paths during periods of auroral activity) while RTTY, though also popular, is archaic, inefficient and successful only by brute force methods (a big amplifier and a beam.) More robust FSK modes such as MFSK, Olivia, Thor and DominoEX perform better but are much wider which can be a barrier to use. V4 uses the same robust modulation scheme as WINMOR but has been optimized for use as a keyboard chat mode. A detailed protocol description can be found here and the software can be obtained after joining the V4 Protocol Yahoo Group.
I have only just been admitted to the group so I have some reading to catch up on and it will be a few days before I can find the time to try V4 for myself. However I am quite interested in this mode which seems to have been developed by licensed hams keeping in mind the need for responsible band use (so no 2.2kHz wide signals!) and with all the details being published and open. The software modem has been implemented as a standalone TNC that can be interfaced with other applications such as my own program KComm which is also interesting to me. So I think you can expect to hear more about the V4 Protocol in this blog in the weeks to come.
Beacon monitoring with Faros
Alex, G7KSE wrote recently about monitoring the International Beacon Project beacons on 20, 17, 15, 12 and 10 metres, which gave me the idea to try it again for myself. I did try the Faros beacon monitoring software by VE3NEA a few years ago but being a tightwad I never registered it so the trial came to an end after 30 days. I was also less than enthusiastic about leaving the computer and radio running every day 24/7. Work out the power consumption and it can add a significant amount to the quarterly bill which is unlikely to go unnoticed by the chancellor of the exchequer (the XYL.)
These days the computer is usually running from when I get up (or after breakfast) until when I go to bed in order to run my HF and VHF APRS gateways so it is no extra trouble to do some beacon monitoring as well. I don't have a spare radio or antenna so I will have to use my main radio (my K3) and antenna for the beacon monitor. This means that if I want to go on the air the beacon monitoring will stop. Currently my enthusiasm for actually making contacts is at a very low ebb so this is not much of a problem. I shall still shut down at night and restart in the morning, at least during the winter months when there is no night time propagation on 20m and up. Apart from the pointless waste of joules, the loud click from the K3 each time Faros changes bands will be a disturbance as the shack is only just across the landing from our bedroom.
The antenna I am using is the short multiband 80plus2 dipole bent to fit into the roof space, with additional 10m and 6m elements. It works fine on 20, 15, 12 and 10m. On 17m I can get a good SWR with the aid of the K3's built-in tuner (which is the source of the loud clicks) but performance is noticeably down on the magnetic loop. However, the magnetic loop is used by my K2 for the HF APRS gateway so it is not available.
VE3SUN has written a very good article explaining how to set up a system to display the beacon reception charts created by Faros on a web page. It looked easy so I went ahead and set up an IBP Beacon Reception page on G4ILO's Shack. I found that the WinSCP software that VE3SUN recommends to automate the uploading of the reception charts to the website popped up annoying windows whenever it updates so I used SyncBack SE instead. Unlike WinSCP it isn't free, but I had purchased a license a few years ago and the code still worked with the latest version.
I converted the JavaScript in VE3SUN's example page to PHP. This means that I can test for the existence of the beacon monitor graphics and display a friendly message rather than have the browser display a "missing picture" graphic if the monitor has not been running and that day's GIF image doesn't exist.
I have added to the page a short list of currently active beacon monitors to make it easy to compare my reception reports with other people's. It would be nice if, instead of each beacon monitor having his own results on his own web site, there was a central site that collated all the IBP reception reports and displayed them on a map, like WSPR does. Perhaps that would rejuvenate interest in the IBP which seems to have been overshadowed in recent years by WSPR and reverse beacons.
These days the computer is usually running from when I get up (or after breakfast) until when I go to bed in order to run my HF and VHF APRS gateways so it is no extra trouble to do some beacon monitoring as well. I don't have a spare radio or antenna so I will have to use my main radio (my K3) and antenna for the beacon monitor. This means that if I want to go on the air the beacon monitoring will stop. Currently my enthusiasm for actually making contacts is at a very low ebb so this is not much of a problem. I shall still shut down at night and restart in the morning, at least during the winter months when there is no night time propagation on 20m and up. Apart from the pointless waste of joules, the loud click from the K3 each time Faros changes bands will be a disturbance as the shack is only just across the landing from our bedroom.
The antenna I am using is the short multiband 80plus2 dipole bent to fit into the roof space, with additional 10m and 6m elements. It works fine on 20, 15, 12 and 10m. On 17m I can get a good SWR with the aid of the K3's built-in tuner (which is the source of the loud clicks) but performance is noticeably down on the magnetic loop. However, the magnetic loop is used by my K2 for the HF APRS gateway so it is not available.
VE3SUN has written a very good article explaining how to set up a system to display the beacon reception charts created by Faros on a web page. It looked easy so I went ahead and set up an IBP Beacon Reception page on G4ILO's Shack. I found that the WinSCP software that VE3SUN recommends to automate the uploading of the reception charts to the website popped up annoying windows whenever it updates so I used SyncBack SE instead. Unlike WinSCP it isn't free, but I had purchased a license a few years ago and the code still worked with the latest version.
I converted the JavaScript in VE3SUN's example page to PHP. This means that I can test for the existence of the beacon monitor graphics and display a friendly message rather than have the browser display a "missing picture" graphic if the monitor has not been running and that day's GIF image doesn't exist.
I have added to the page a short list of currently active beacon monitors to make it easy to compare my reception reports with other people's. It would be nice if, instead of each beacon monitor having his own results on his own web site, there was a central site that collated all the IBP reception reports and displayed them on a map, like WSPR does. Perhaps that would rejuvenate interest in the IBP which seems to have been overshadowed in recent years by WSPR and reverse beacons.
Thursday, December 02, 2010
Defeated by Microsoft
I have never understood why Microsoft has become the most successful software company in the world. When compared to similar products the underlying design of their software, to me, seems unnecessarily complex. And the company couldn't care less about backward compatibility and breaking something when bringing out a new version. Microsoft software development tools, compared to third party products like Delphi or Lazarus, are far more difficult to use in my opinion. Visual Basic long ago ceased to be a "basic" programming language for amateurs like myself.
I had an idea for a program to run on my HTC Touch Pro smartphone that needed to access the phone's internal GPS. A couple of months ago I actually got a good way towards implementing it for the Android platform (even though I'd never programmed in Java before) just by downloading the source code of someone else's GPS application and modifying it using the free development tools. But because my phone was running an unofficial port of Android on which not all features worked I could only run it in an emulator, not transfer the app to the phone. In any case, the XD Android port was unstable and ate battery power even worse than Windows Mobile did, so I had to go back using WM 6.1 despite the fact that under Android it was a much nicer phone.
So I thought I'd have a go at writing my program for Windows Mobile. I had a copy of Visual Studio 2005 sitting on the shelf. So as before, I started Googling for example programs for accessing a GPS.
If I am writing a program for Windows desktop using Lazarus / Free Pascal I can Google for what I am trying to do and nearly always find code I can use. Even if it was written for Borland Delphi in 1996 it usually still works. The problem with the Windows smartphone / PDA platform is that it has been through many incompatible incarnations in less time than that. There is Windows CE, Pocket PC, Windows Mobile versions 4, 5, 6 and 6.1, Windows Smartphone, Windows Phone 7, Compact Net Framework 1.0, Compact Net Framework 2.0 and Compact Net Framework 3.5. If you do manage to find a relevant example there is no guarantee that it is actually compatible with the development tools and SDKs you have installed on your PC, or with your mobile device.
The first program I tried that actually did anything came with two DLLs, one for serial port access and one to decode the GPS data. That would print out a few NMEA strings and then fail with an exception. None of the other examples I tried would do anything at all. The problem with the first program appeared to be in the serial port DLL, so I tried to upgrade it to version 2.0 of the .Net Compact Framework which had built-in serial port support. I copied examples of serial port access code but although the program didn't crash it never received anything from the GPS at all, even though I knew it was working (e.g. by running APRSISCE.) Unfortunately when run from Visual Studio the Net CF 2.0 programs would display an error on the phone that "this device has a newer version of the Compact Framework installed that must be uninstalled first." I wasn't about to do that since who knows what it would break. So much for backward compatibility.
One of the reasons implementing my idea was so easy on the Android platform is that Google had provided a GPS object that gave you ready to use data. On Windows Mobile you have to listen to the GPS via a serial port and then parse the NMEA data that comes out. So, having failed to find a GPS example that would run for more than a couple of seconds I decided to look for serial port examples. None of those would receive any data from the GPS either. I even found a free GPS test application. That would receive several lines of data from the GPS then disappear without trace.
At this point I started to wonder if there was a problem with the internal GPS of my HTC Touch Pro. I did some more Googling and found that users of some GPS apps on HTC smartphones with internal GPS had found these apps did not recognize the internal GPS or timed out while waiting to get data from it. Presumably these apps had been written based on the same code examples I had been trying. One user had found the only way to get the GPS data into the program was to use a program called GPSGate. But this was a commercial program, costing money, which I had no wish to spend just to see if this worked when everything else hadn't.
After a couple of days of fruitless effort my interest in continuing with this project had evaporated completely so I gave up. At least, unlike with abortive hardware projects, no components were wasted. I restored the PC back to a couple of days earlier to remove all the hundreds of megabytes of APIs, SDKs and examples I'd installed. And I have gained a new respect for people who actually manage to develop software using Microsoft tools.
I had an idea for a program to run on my HTC Touch Pro smartphone that needed to access the phone's internal GPS. A couple of months ago I actually got a good way towards implementing it for the Android platform (even though I'd never programmed in Java before) just by downloading the source code of someone else's GPS application and modifying it using the free development tools. But because my phone was running an unofficial port of Android on which not all features worked I could only run it in an emulator, not transfer the app to the phone. In any case, the XD Android port was unstable and ate battery power even worse than Windows Mobile did, so I had to go back using WM 6.1 despite the fact that under Android it was a much nicer phone.
So I thought I'd have a go at writing my program for Windows Mobile. I had a copy of Visual Studio 2005 sitting on the shelf. So as before, I started Googling for example programs for accessing a GPS.
If I am writing a program for Windows desktop using Lazarus / Free Pascal I can Google for what I am trying to do and nearly always find code I can use. Even if it was written for Borland Delphi in 1996 it usually still works. The problem with the Windows smartphone / PDA platform is that it has been through many incompatible incarnations in less time than that. There is Windows CE, Pocket PC, Windows Mobile versions 4, 5, 6 and 6.1, Windows Smartphone, Windows Phone 7, Compact Net Framework 1.0, Compact Net Framework 2.0 and Compact Net Framework 3.5. If you do manage to find a relevant example there is no guarantee that it is actually compatible with the development tools and SDKs you have installed on your PC, or with your mobile device.
The first program I tried that actually did anything came with two DLLs, one for serial port access and one to decode the GPS data. That would print out a few NMEA strings and then fail with an exception. None of the other examples I tried would do anything at all. The problem with the first program appeared to be in the serial port DLL, so I tried to upgrade it to version 2.0 of the .Net Compact Framework which had built-in serial port support. I copied examples of serial port access code but although the program didn't crash it never received anything from the GPS at all, even though I knew it was working (e.g. by running APRSISCE.) Unfortunately when run from Visual Studio the Net CF 2.0 programs would display an error on the phone that "this device has a newer version of the Compact Framework installed that must be uninstalled first." I wasn't about to do that since who knows what it would break. So much for backward compatibility.
One of the reasons implementing my idea was so easy on the Android platform is that Google had provided a GPS object that gave you ready to use data. On Windows Mobile you have to listen to the GPS via a serial port and then parse the NMEA data that comes out. So, having failed to find a GPS example that would run for more than a couple of seconds I decided to look for serial port examples. None of those would receive any data from the GPS either. I even found a free GPS test application. That would receive several lines of data from the GPS then disappear without trace.
At this point I started to wonder if there was a problem with the internal GPS of my HTC Touch Pro. I did some more Googling and found that users of some GPS apps on HTC smartphones with internal GPS had found these apps did not recognize the internal GPS or timed out while waiting to get data from it. Presumably these apps had been written based on the same code examples I had been trying. One user had found the only way to get the GPS data into the program was to use a program called GPSGate. But this was a commercial program, costing money, which I had no wish to spend just to see if this worked when everything else hadn't.
After a couple of days of fruitless effort my interest in continuing with this project had evaporated completely so I gave up. At least, unlike with abortive hardware projects, no components were wasted. I restored the PC back to a couple of days earlier to remove all the hundreds of megabytes of APIs, SDKs and examples I'd installed. And I have gained a new respect for people who actually manage to develop software using Microsoft tools.