What programs are needed to attract more ham users to Linux?

Is there a lack of radio programs for Linux (or specific distributions) that makes it difficult to attract more amateur radio users to Linux?


kb5fls's picture

How about this software from a physicist that I know who wrote this program?


hey all~ what does linux need

ubuntujason's picture

hey all~
what does linux need to attract more hams? good question....i think it needs a few things....here they are:
1. FACE TIME (caps intended)! i really think that it should be talked about....so many ask 'whats that' wheni say i run ubuntu....they give the same response when i say its a linux distro.

too few people know about linux. i think this is slowly but surely changing...and we can help. in fact i proudly educate everyone i can about the strengths of linux vs windows....on the air and in person. i've converted a few hams along the way too!

2. a little more in the way of compatibility. it took me a couple of days searchin google to figure out that the address for my serial to usb converter/adapter was /dev/ttyUSB0. when i fired up fldigi and wsjt it wasn't automatically detected...and it wasn't as easy as saying 'com1' or 'com2' etc. (like in windows)

in the end i got it and it works awesome (better then in windows) but i would have loved to see it act more in a plug and play manner!

also the radio compatibility (for detecting the frequency and/or controlling) could be better (i mean why is it that my kenwood ts-2000 [a seeming popular radio] only has 'beta' support in hamlib? where as many not as popular radios have full support?

3. now this point is unique...i do ALL my radio stuff in ubuntu. logging, digital communications, weak signal, satellite tracking, call look up, etc. etc. yet unlike in windows i don't have 1 suite of programs (like ham radio deluxe for instance) instead its ike this:
logging: klog
digital: fldigi
weak signal: wsjt (hrd does NOT do this, you must run wsjt in windows to get that program....but i included it in the list to make the point that i have to run many programs)
call look up: callgit

i think it would be awesome to have a program suite similar to hrd in windows for us free thinkers! something that could roll together logging, dx-spotting, radio control, digital communications, call sign look up, even propagation reports. (if i were a programmer i'd be working on it....but i'm not, im a web designer when my hands cooperate :P)

after saying all that....i'm very satisfied with how friendly ubuntu is to ham radio. i mean there's a amature radio repository defaulted into ubuntu...(in essence meaning ham software comes w/ubuntu....now you can't say that about windows!)

even over my 2 shorts years of being a ham...i've seen linux come a long way towards being even more ham radio friendly....but there's always room for improvement. i mean oss has lead the way for cutting edge technology....and in due time i hope more hams will wake up, break away from micro$ucks and come over to the great world of FREE Open Source Software (a la linux!)

i look forward to participating on this site...and gettin to know some of ya!
73 & vaya con Dios!
~j (ke7tdy)

All good!

David Lane's picture

These are all good points and it is up to all of us to "spread the word."

Take a look at Shackbox for a "suite" of tools. It is a pretty good start I think.

Take advantage of showing Linux at Hamfests and Field Day (and with Field Day fast approaching, it is a good opportunity to show not just good software, but interoperability with other OSs).

One thing I make a point of talking about is making sure that my ARES cadre is "software agnostic" when it comes to doing things. Can you connect to your TNC without Windows? How do you do that (and I am about to post a "new user" guide for Minicom and TNCs.) All of this is important, especially from a disaster perspective where you may NOT have the option of choosing your OS.

And since you can always carry a copy of Linux with you on a Live[CD|DVD|USB], it is much more likely you can boot up with it, than something else.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


Petr, OK2CQR's picture


if you need great logging program for Linux, try CQRLOG - http://www.cqrlog.com

73 Petr, OK2CQR

re. cqrlog

ubuntujason's picture

hey thanks for the info but i have tried that and decided to stick w/klog. i guess since it was the first logging program i tried i grew sort of biased to it lol.

no matter what program i use though (in windows or ubutnu [so i think my cable from my radio to my laptop isn't working 100%) i can never get the frequency to read properly. oh well, i tend to sit an call cq on a frequency more then i hunt and pounce....if i am scrolling across the dial and find someone i want to caht with, i listen for their rhythm then i call them....figure it increases my chances running barefoot...i learn their timing and know when to speak up :P

Do not tried it

OK1IF's picture

It is lost of time. CQR log was originally Win programm.
One freezing, problems with floating zero etc...
I strongly do not recomend it you.


Petr, OK2CQR's picture

This was not real OK1IF. New version of cqrlog for windows hasn't been released for a few years and somebody can't get over it ... .
Try Linux and CQRLOG for Linux.

I have written s/w to

HowardZ's picture

I have written s/w to control amateur radios, antenna tuners, and coax switch.

It is written in Java and thus should work on Linux.

It is in the files section of the LDG Yahoo group and the Palstar AT AUTO yahoo group.


Linux and Software Defined Radio

KD0AR's picture

I operate a Softrock 40 SDR receiver. In true amateur spirit, these units are VERY experimental. They are receivers and or transceivers that use a I-Q phase shift which is decoded in software to decode any modulation scheme thats out there. It really is cutting edge, and to be quite honest, awesome technology.

With this in mind...

The new versions of Windows (Vista and 7) will not load the drivers for the I2C chip that allows control of the DDS chip in these things. This is due to Microsoft's answer to the Digital Rights Management policy that they wont acknowledge that they've adopted. It seems there are VERY few programmers that are interested in developing this type of stuff in Linux. I understand there's Linrad, but I havent been able to set it up yet. The odd thing too, is the Windows SDR programs, at least some of them are open source, but none are available for Linux. This technology would be PERFECT for a linux system, as it is VERY processor intensive in Windows, and I believe would run far more efficient in a *nix box.

Re: Linux and Software Defined Radio

F8CFE's picture


The Hamlib project[1] is very willing to develop appropriate support for DDS chips and other experimental SDR devices. There's already support[2] for Elektor SDR kits, SoftRock Si570 AVR-USB, and more. Beta-testers are needed for AmQRP DDS-60. If your rig is not supported already, feel free to contact us on the hamlib-developer mailing list, or by opening a ticket at our sourceforge site[3]. Of course this project targets not only Linux, but *BSD, MacOSX, Windows, Solaris, etc.

Talking about SDR programs in Linux, there are fldigi, DttSP, GNU Radio, Dream DRM (Digital Radio Mondial), Linrad, .. to name a few. They are quite exciting pieces of software.

[1] http://hamlib.org
[2] http://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Supported_Radios
[3] https://sourceforge.net/projects/hamlib/

Multiple soundcards and Wine

Ed KC8SBV's picture

I got my buddy running Ubuntu. He has been using it now for a while, and is complaining that he cannot set up application to use specific sound cards. He has 3 sound cards, and in Windows had them set up with specific settings for the apps he used, like Echolink, MMSSTV, Digipan and SDR softare. Now in Ubuntu, he has tried the Linux ham radio apps, and found them wanting. So he has turned to getting the these windows apps working in Wine. Now he wants again to get his Wine apps tied to his specific sound cards with thier specific settings, etc as he had in Windows.

So you want Linux apps? He likes Digipan better than FLDigi, MMSSTV better than QSSTV. Simply wants his Wine apps to run on the intended sound card.

Now that I got him using Ubuntu, is there hope for his Windows apps in Wine this way?? The soundcards he is wanting to use are the onboard AC97, and a USB Signalink soundcard.

I see it as give the mouse a cookie.....

Multiple soundcards and Wine

ad5xj's picture

The hope is still there but not by much.

The problem with soundcards is multi-faceted.
One the card manufacturers have had little clamor for Linux drivers. The drivers we have come from third party sources mostly - not the OEM. These third party drivers tend to cover the family of chips that make up the soundcard and not specific cards.

Secondly, there is a huge gap in knowledge among application developers on integrating soundcard functions into applications. There are some very good sources for education IF YOU KNOW 'C' VERY WELL. For higher level programmers we are still looking for that ham that knows soundcard integration and DSP well enough to work with other programmers to develop a useful API or some kind of standard (I use the term loosely) by which programmers in C++, mono, or python can look to for reliable and fast service.

Thirdly, Linux hardware configurations that are complex have a lower reliability and configurability (is that a word?) than ultimately desirable. Installers for applications get confused and either default to system choices or do nothing at all for the soundcard and you wind up having to manually install the soundcard driver or interface manually.

The point is that (depending on the hardware) there can be a problem making one soundcard functon properly with Linux, much less multiple cards.

Wine does a very good job of getting some Windows applications to work on Linux (it is a single application interface vs. a virtual machine like VirtualBox or VMWare). But even it has limitations. Wine will not run applications that are very tightly integrated with Microsoft.NET libararies (like HRD or RMSExpress). It especially has a problem with applications that may use specialized drivers (like Signalink). Remember that the original Linux modem software only used external modems, not DSP based soft modems as Windows used. Linux has since come a long way in that respect but hardware configurations that involve multiple soundcards, and USB based soundcard interfaces may be a problem for some users for a while yet.

We are talking about maturity of the product. Bear in mind that XP is the result of a long history of follow-on Windows attempts (not all of which were good - remember Windows 3.11 and ME?). Ubuntu Linux and other distros are not as mature overall as Windows XP. Even so, it is WAY more stable and contains much more mature aspects than any Windows attempt at this stage of development.

Emcomm & Public Service Software

John W3JKS's picture

What we (emergency communicators, who also participate in large Public Service events) need is "WebEOC=Lite". Something along the lines of WebEOC (if you're unfamiliar with this product, checkout http://www.esi911.com/esi/index.php?option=com_content&task=view&id=14&I...), but open-source and NOT dependent upon Internet services like Google Earth for their proper function.

First and foremost (IMHO), we need a good Web-2.0-based status logging system which is flexible, supports user-defined fields and multiple concurrent instances, near real-time updating and replication (if IP connectivity is available).

There are some nice status logging systems available, but all of them seem to either cost serious $$ or utilize expensive tools like MS Access, which don't function well with multiple updating, or are hard to modify "on-the-fly".

We could REALLY use an add-on to an existing open-source application known as Xastir. Xastir (www.xastir.org) provides access to both the radio and Internet universes of the Automatic Packet Reporting System (www.aprs.org). APRS is more than just position reporting -- it provides a general-purpose short message service as well. It would be very helpful to have a dynamic web interface for Xastir to allow other users of the same LAN to view APRS in its dynamic state. Perhaps an interface to Mapserver?

I'm attempting to develop my own WebEOC-lite, starting with Tiki Wiki, but I'm just one person at the bottom of the Wiki learning curve.

We're having fun!



David KE6UPI's picture

Hello John, I have thought about this for a long time. It would be nice to have something like WebEOC. I would also like to see something like UI-View that an EOC can send a dispatch to. APRS would not be the best. You can still the GPS and maps but start new. Put on 420-440Mhz and 900Mhz and use 9600 or faster. My thought is to start out with the Database of info that you need. Then make an interface ie web page.



David Lane's picture

As someone who uses WebEOC a lot, I would have to agree that an Open Source version should be up on our list. In fact it would be nice to see ESI get out of the proprietary coding and do it themselves. For all the money they have poured into making it work (and not so well in some cases), they could have had something that would be easy to extend and support by now.

At least it finally supports Firefox....

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

Open EOC software

rhyre's picture

I saw WebEOC for the first time today, and was underwhelmed. It may be that all of the modules weren't present in the version I observed in use.

I agree that an solution that can be easily customized to work in the absence of the Internet would be helpful.

My opinion is that first job of an EOC is to support situational awareness, and make sure that everyone in the EOC is effortlessly updated as events on the ground change.

Linux & Packet Radio

Charley's picture

I have been working with Linux & Packet radio for better than 8 years. I admin some 18 - 20 packet servers. They All support FPAC and RMS Gate. At least four support a FBB BBS. The switch to Linux has been a BIG factor in deploying new and replacement network nodes in the FLA packet network. We are even deploying node in other states and countries.


Ham Radio with Linux

W0VNE's picture

I came into Linux because my Windows infested computers were becoming so slow that I was ready to toss them into the trash. In particular I had a laptop that was once very highly valued and it was nearly pushed into the trash for taking 10 minutes to start up. I googled "Fast Distro" an set up my machine with Puppy Linux. In a word WOW! It came with most of the programs I was already used to. Open office, Skype, Crypt etc. It loads in less then a minute and takes maybe 6 seconds to shut down. AMAZING. I got fldigi working with some online help (Operator errors on my part) and have been talking to people all over the world on my Ham Radio. I think its a really great program.

73 (Ham lingo for BEST REGARDS) de W0VNE

Ham Radio with Linux

ad5xj's picture

Your comments are spot on.

Several years ago I started to dual boot my machine with Windows and Linux. Eventually I settled on Ubuntu Linux and now I rarely boot into Windows except for programs that will not run in Linux even under Wine (like MultiPSK and RMSExpress). I have contacted the authors and they have no knowledge of Linux and are not willing to port their VB or VC programs to another platform. There is a disconnection by programmers where application development (especially for multiple platforms) is concerned.

I am WebMaster for our Section Web site www.laarrl.org and I do all my web site maintenance from Linux. I am also a programmer (for 20+ years now) and I have completely left Windows as a development platform. I now have a application on SourceForge called DX_Central. It was intended for use by DX'ers but I can see where amateur astronomers and SWL enthusiasts could also be interested.

Those who are interested in programming for Linux should be keenly aware of open source projects like mine. They are a treasure of examples on "how-to" in many languages, not just C++ as this application (DX_Central) uses.

There is a strong need for some organized collaboration in programming among hams that have programming experience in various areas on Linux as well.

For instance, there is a very large knowledge gap where sound card programming and DSP is concerned. Those hams with experience in such areas could make huge contributions by becoming aligned with multi-programmer projects that could involve their expertise.

The use of cross-platform frameworks like Qt by Nokia have also helped to advance the Open Source effort. It is now possible for me to create an application on Windows and bring that code into Linux and have a working app with minimal effort (assuming the programming techniques were cross-platform oriented). I hope would-be program creators will use similar products to bring ham radio applications to the Linux platform for us in the future.

Ham Radio with Linux

WA6JDI's picture

Yes Spot On.

I've had my ticket since 77 been off the air since 87 and now my brain and hands are burning to get back into my hobby(my wife willing). Now that I've decided to get back into the saddle I find Ham radio has changed a lot. Forms communication I hadn't heard of until 2 weeks ago. I LIKE IT!! I've been using Linux for some time and I knew it had the internals to work with Ham gear but not sure how to implement it yet. I'm hoping to change that as I start working to get a higher class ticket. I'm also taking Linux classes at the local college and I seriously want to get into some app development and programming and possibly customizing a kernel for my new Ham shack. When I got the January issue of LJ I knew it was time to start. (TNX LJ). I'm not a real strong programmer yet but if I can help in any way I need all the practice I can get, at least I'm in the right place.

73's de WA6JDI

Logging Programs for a Start

waparmley's picture

Great question Carlie!

One thing I frequently hear mentioned by fellow Hams who ask me about Linux is logging programs. There are a lot of very sophisticated Windows logging programs that handle multiple tasks including connecting to a DX cluster, watching for needed countries on the cluster, tracking progress toward DXCC and other awards, assembling submissions for Logbook of the World, keeping logs in specific formats required by various contests, keeping track of duplicate contacts during contests, etc., etc. Although there are some Linux logging programs, I am not aware of any that approach the sophistication that serious DXers and contesters have come to expect. (Although I'm more of a casual operator and hardware tinkerer, I have some friends who are way up on the DXCC Honor Roll, and they use some really high-powered logging programs.)

Another area that comes to mind is Slow Scan TV. I know of at least one Linux program, but I've never been very impressed with it, and it doesn't begin to compare with MMSSTV in the Windows world (at least not in my opinion).

On the plus side, FLdigi is a great digital mode program, and Dr. Joe Taylor has a Linux version of WSJT, which is used for Meteor Scatter, Moonbounce, and other weak signal modes at VHF and UHF.


ad5xj's picture

There are no less than half a dozen logging programs available in various forms on sourceforge.net. The problem I see here is that many users of Linux ham radio programs do not want to go through the process that all Windows programs went through. That process involves users providing informative bug reports and appropriate suggestions to developers. This has largely been absent in Linux development.

When a user finds Open Source applications that provide enough flexibility and other traits to warrant use, there should also be an implied need (dare I say responsibility) on the part of the user, to report both good and bad to the developer. Otherwise all that is known (and often assumed) is that the application is good and complete as offered. Each user brings a differing level of experience (both in terms of ham radio and use of software) that can be invaluable in terms of maturing an application in the direction users are expecting.

Find an application that looks attractive, has the minimal functionality desired, and install it. Have the patience and willingness to work through problems encountered by communicating with the author(s) of the app and providing vital information that could provide, not only the bug fixes, but also the new functionality you desire.

bug reporting/sugestions

RoelandJansen's picture

The linux community I know actually *tries* to get stuff working, even supply patches and all to software that contains bugs. So it's a bit weird to read here that the community doesn't help the developers.

Regarding -- what do we miss: that's easy. a HRD style piece of software.

I've seen that many windows developers didn't have portability in mind when starting code. It's *the* reason HRD is not available under linux, natively.


bminish's picture

We really need a versatile and well featured general purpose logging program. It could also be a great idea if there was some standards worked out so that the various logging programs and utilities that need access to the log could all talk to the same back end MySQL database file. If this were the case one could use / create small utilities that could do a single task well (such as LOTW or QSL card preparation, Contest logging, report generation, logging via a terminal session (yfklog) etc ) yet still use a more fully featured X based GUI logger for regular logging tasks.
Right now all the various logging options require the database to exported then reimported via the ADIF format, this is messy and error prone, in part because ADIF is not a very well defined standard.
Logging is a classic databse application at it's core, we already have a standard in hamlib for rig control, why not create the same for the actual logging data?

Brendan EI6IZ


KA1VGM's picture

CQRLog is excellent logging software. You can't beat the price either!



Roy's picture

I also am very happy with CQRlog, and was going to suggest it as a Linux logger. I have not found a contest logger, which is not a big deal for me, but I do occasionally jump into a contest, and would like the option to be available. I also use both LOTW and e-QSL, and would like to have support for both. The program works well. I have been using it in the 10 Meter Contest this weekend. I've had a lot of time to look at the software! 73,
Roy N9RG


ad5xj's picture

I am still a little fuzzy on just what "standard" would mean. There are logging guidelines such as ADIF and CABRILLO that guide programmers toward a consistent data structure. But is that what you mean?

Logging is a set of data choices made by each individual. Some choose those data points that pertain to contesting and DX. Others choose those data points that preserve casual QSO's for QSLing. Others are insistent that logging include all the data points for LOTW or CQWW. Still others are interested in keeping the data relevant to certain contests (i.e. Field Day, CQWW, 10-10, etc.).

I think you mean the user should be presented a choice or menu of data points to use, similar to the way Logger32 (on Windows) does. The back-end database will still have all the possible data points but only those chosen will be stored and presented to the user.

Even rig control gives you a choice of which rig command set to use. Granted many commands are the same from model to model, just as data points overlap between logging purposes (consider call, name, grid, etc.). Your desire for consistency is laudable, however, the implementation is yet to be defined. Having a broad array of data points at the backend database while configuring for specific user applications will go a long way toward that goal.

However, if you mean there should be a set database schema that all logging programs should follow, I am not so sure this would be a good idea. First, programmers would have to agree what data points should be included in such a schema (that would be a trick). Then, there would have to be universal acceptance by would-be application developers to use the proposed schema (another very good trick).

These are snarly issues that get resolved in the software development maturity cycle over time and with considerable user input. All this is, by the way, independent of the database engine chosen to deliver data. I am a very big proponent of light, strong, cross-platform data engines such as SQLite. But once again, this is a choice made by developers that requires general acceptance.

Please use a standardized DBI

Jonathan Guthrie - KA8KPN's picture

I agree that standardizing the data formats is a good idea, and for the reasons you describe, but your idea as written implies the need for a MySQL database. I would suggest that said logging program, and all the related utilities, should use a well-defined database interface so that people can write back ends to work with every popular database. That way, those who already have a (for example) Postgres instance wouldn't have to install a MySQL server just to run a logging program and that people who aren't going to run in any mode but standalone wouldn't need anything more than an SQLite library.

If you do it right, then the database type would only have to be configured once and the logging program, the QSL generator, contest log generator, reporting system, dupe checker, AJAX interface, etc. would all just work.

I'm sure that you didn't mean to imply that MySQL is the only possible solution, but I thought I'd make that explicit.