Linux Scanner Software

[SCPD]

I have the crude beginnings of a scanner control program for Linux (and eventually BSD and Mac OS/X). The intent is to create something to control the radio, not program it. Click the link for more info.

 

[ka3jjz]

Interesting - most of the scanner-related software I've seen for Linux-like systems revolves around tcl/tk

73s and GL Mike

 

[windigofer]

Good job on this so far (and good to see more folks developing for Linux, LOL) :3

Any plans to eventually integrate the control libs into hamlib or possibly include GRE500 capability? (Yes, I know, you despise VISA II-ish control ) Been planning out a GRE500 programming tool for Linux (and hopefully portable to MacOS X as well), and I'd planned on having a remote control head in the program, but if you're going to be doing this as well, no need to reinvent the wheel, so to speak

 

[SCPD]

good to see more folks developing for Linux

I omitted Mac OS/X and BSD in the subject line (and the Mac build is broke - need to fix that).

Any plans to eventually integrate the control libs into hamlib or possibly include GRE500 capability?

Hamlib? Nah. PSR-500 support - yes. I'd like to add CI-V for the dozen or so radios that speak it.

Been planning out a GRE500 programming tool for Linux (and hopefully portable to MacOS X as well),

I am so far pleased with the cross-platform compatibility with GCC and GTK+ across these three OSes. When folks ask for software that can run on Linux, I'm not a fan of telling them to run Windows program "X" on top of WINE or some VM environment.

I'd planned on having a remote control head in the program, but if you're going to be doing this as well, no need to reinvent the wheel, so to speak

A remote head would be easy once you got past the roundish nav buttons near the top of the keypad. I'm not interested in writing a radio memory manager. To be done well, you have to specialize in one or a few specific models. My goals are bit different - less depth and more breadth. I'd like to re-create the "Tuner" program bundled with Unitrunker for Linux, Mac OS/X and BSD.

 

[windigofer]

I omitted Mac OS/X and BSD in the subject line (and the Mac build is broke - need to fix that).

Understood on that :3 (And if the Mac build is breaking on getting data from the radio/to the radio, there may be a reason for this--apparently the MacOS X FTDI driver uses a not-quite-standard name for the TTY USB port. Linux uses /dev/ttyUSB0 in general; with MacOS X it's something like /dev/tty.usbserial-GRE-xxxx (where xxxx=the device model number) based on reports I've gotten from MacOS X users who have the GRE USB interface.)

Hamlib? Nah. PSR-500 support - yes. I'd like to add CI-V for the dozen or so radios that speak it.

All good :3 (I know the Hamlib libraries tend to have as many HF rigs as actual ham radio libraries, and they've been asking for scanner stuff--but I personally think this may be better suited to a different library.)

I am so far pleased with the cross-platform compatibility with GCC and GTK+ across these three OSes. When folks ask for software that can run on Linux, I'm not a fan of telling them to run Windows program "X" on top of WINE or some VM environment.
A remote head would be easy once you got past the roundish nav buttons near the top of the keypad. I'm not interested in writing a radio memory manager. To be done well, you have to specialize in one or a few specific models. My goals are bit different - less depth and more breadth. I'd like to re-create the "Tuner" program bundled with Unitrunker for Linux, Mac OS/X and BSD.

In regards to porting stuff to MacOS X, Apple actually has some pretty good documentation on their website for Linux developers/cross-*nix developers who wish to develop for both Linux and MacOS X (which isn't TOO bad as long as you remember some of the basic differences between SysV-family *nixes like Linux and BSD-family *nixes like MacOS X; MacOS X also has some mild wierdness re the use of MachTen kernels versus FreeBSD or OpenBSD, but nothing insurmountable). MacOS X's closest "relative", OS-wise, is NeXT's OS which actually was a fairly typical MachTen-kernel BSD (it can be argued, and HAS been argued, that MacOS X is essentially a "NeXT Daughter")--a lot of apps appearing on Linux and *BSD have also been successfully ported to MacOS X.

In regards to use of the GTK+ toolkit--roughly how well behaved is that under MacOS X? (I do not have a Mac at home--merely my Ubuntu box I'm developing on which only *looks* like a Mac thanks to the eyecandy that is Compiz Fusion--and have been waffling between doing GTK+ and WxWidgets for the windowing system for the programming tool; I'd *really* like to use GTK+, as it's far less of a PITA to get things actually *going* with it, but was concerned about how mature the MacOS X port was of it. (No problems at all under Linux, obviously. ) If you're having good results with it, then I can feel safe in doing the windowing system development under GTK+, at least. One less major headache )

 

[SCPD]

And if the Mac build is breaking on getting data

I had a Mac owner test it out - got a "bus error". I was able to reproduce the problem on Linux (the Mac build was from a slightly newer - and less tested - version of the code).

In regards to use of the GTK+ toolkit--roughly how well behaved is that under MacOS X?

I'll be in a better position to answer that when I can revisit doing a Mac build - with the assistance of someone that actually owns a Mac with the relevant dev tools installed.

have been waffling between doing GTK+ and WxWidgets for the windowing system for the programming tool; I'd *really* like to use GTK+, as it's far less of a PITA to get things actually *going* with it, but was concerned about how mature the MacOS X port was of it.

I've heard good things about wxWidgets (back when it was still called wxWindows) from someone who used it.

My main criteria was the ability to do non-blocking IO (concurrent UI + serial port IO + network IO). I figured out how to do that with GTK+ and ran with it. From a compile-and-run perspective - the only change from Linux to OS/X was removing a reference to an RS-232 related IOCTL flag that Linux had and OS/X didn't (same issue I think for BSD). My own coding mistakes aside, the GTK end of things - so far - looks good.

I'm actually doing GTK the hard way by programmatically constructing the dialog. I'll move over to using XML once I get some other IDE issues cleaned up. I couldn't get Anjuta to work so I'm using Netbeans with the C++ dev pack. It works reasonably well with GDB. The main hassle with GTK is most of the tutorials are out-of-date. Some of the examples use gtk_xxxx calls that have been marked as "deprecated" in the documentation.

What I'm really wondering is how well does a binary release work across multiple Linux distro like kernel 2.4 vs. 2.6 or RedHat vs. Slackware.

 

[ka3jjz]

Since there seems to be some interest in this, I've coded a Wiki article that lists various non-Windows OS scanner/receiver software packages. It's called 'Scanner/Receiver Software for Non Windows OS' and can be found under 'Forum Specific Topics/Software Applications'. There are a couple I can't access right now due to firewall issues at work, so I'll add them later tonight.

Please feel free to update and correct this article as needed. BC246 and 396 owners might want to take a look here...73s Mike