AmateurRadio.com

This video is a short beginning tutorial for XDX and Dx Clusters we even try a little Telnet.

Announcements:

• Happy New Year!
• The Mid-America GNU/Linux Networkers Conference (MAGNetcon) will be May 6-7, 2011 at the St. Louis Union Station Marriott. If you know anyone that might be a sponsor, exhibitor, or speaker, please let us know. Application forms are available on the web site.
• Donations are now being accepted to send LHS to the Dayton Hamvention 2011, May 20-22. Please click on the Donate button on the website.
• Donation received from Charles (no call sign given). Thank you, Charles!
• The podcast RSS feed lost it’s title after a podPress upgrade. This has been fixed.
• We’ve been informed of a RSS feed problem for some podcatchers that use the XML tag. Joe, K1RBY, emailed us about this problem when using gPodder, but a solution has yet to be found. Anyone else see this problem? Let us know! (Ed. Note: The problem has been fixed and will be detailed in episode 54.)
• Look for new episodes of Resonant Frequency in 2011!

Topic:

• An interview with David Freese, W1HKJ, the primary author of fldigi.
• Dave, now 72 years old, has been licensed continuously since 1957 and is retired from the U.S. Coast Guard. He had been maintaining gMFSK, a Gnome multimode HF terminal program, and decided to create fldigi to prove he could still write code. He started with UNIX, then MINIX, and has been with Linux since the beginning. He’s been writing ham radio programs since the 1970′s. His software will run under Linux, Windows, FreeBSD, OSX, and Puppy.
• flpuppy, aka digipup, is also available from Dave’s site. This is a version of Puppy Linux with fldigi, a logbook, and a geodesic calculator already installed.
• Other developers are Stelios, M0GLD, Leigh, WA5ZNU, and Skip, KH6TY.
• Much of the underlying code in fldigi is from the original gMFSK program, in particular the modem code. Other modes have been added since, along with the GUI.
• Dave says there are about 2500 users of fldigi and he spends 50 hours per week on coding and support.
• Other projects Dave is involved with include:
  • NBEMS (Narrow Band Emergency Messaging System), consisting of fldigi, flarq, flwrap, flmessage, and flrig, all using the Fast Light Toolkit.
  • flwkey for sending Morse code via the winKeyer chip.
  • A computer-aided transceiver (CAT) program that controls the Kachina 505DSP transceiver.
• Dave describes how he came to develop fldigi using C++ and FLTK.
• More features of fldigi:
  • Version 3.21 of fldigi, now in alpha test, will have the capability of sending and receiving weatherfax. It will also have an embedded browser that will work with all the PSK modes and RTTY. It has a built-in log book that stores records in ADIF files.
  • While not designed specifically for contesters, fldigi is adequate for casual contesters.
  • Fldigi will generate Cabrillo reports for many contests.
  • The online documentation is quite extensive, at about 140 web pages, with many illustrations. There are sample screenshots of the waterfall display for various modes and audio samples of them.
• Much of the modem code in DM780 is from fldigi.
• Rick Ellis wrote code that allows the N1MM logger to display the waterfall.
• Gary, WB8ROL, “Mr. Olivia”, modified fldigi for his own purposes, calling it fldigirol.
• More cool features of fldigi:
  • Many of the controls in fldigi have different reactions to left-, middle- and right-click. For example, rolling the mouse wheel over the macro buttons will scroll them!
  • The mouse tab in the waterfall configuration allows you to customize how the waterfall reacts to mouse wheel movement. You can also change the rig frequency by dragging in the waterfall.
  • Dave recommends turning on the control hints feature (tooltips). Click Configure, User Interface, General tab, check “Show tooltips”.
  • Dave describes the “QSY” and “Store” buttons.
  • Dave talks about how to use the Reed-Solomon Identification (RSID) features.
  • The “SPOT” control allows you to search for specific strings in a PSK signal, such as “CQ CQ” or “de”, allowing the program to automatically post “spots” on the PSK reporter site.
  • Dave then discusses the “Map It” macro feature.
• To keep up with the alpha test group, you can subscribe to mailing lists on the Berlios alpha test web page.
• Dave offers kudos to Ed, W3NR, who answers 95% of the problem reports, and Rick in Michigan who is the principal man for audio interfacing issues.

Contact Info:

• Contact Richard at [email protected], Russ at [email protected], or both at the same time at [email protected].
• Listen to the live stream every other Tuesday at 8:00pm Central time. Check the LHS web site for dates.
• Leave us a voice mail at 417-200-4811, or record an introduction to the podcast.
• Sign up for the LHS mailing list.
• Sign up for the MAGNetcon mailing list.
• LHS merchandise is available at the SHOP! link on Web site. Check out the Badgerwear or buy one of the other LHS-branded items at PrintFection.com/lhs or Cafe Press. Thanks!
• Thanks to Dave from Gamma Leonis for the theme music.

Music:

• “Which Road Takes Me Home” by Fatblueman from the album “Back to Winnipeg,” courtesy of Jamendo.

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.

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.

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.)

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.

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.