On 2005-05-18 21:52:13 -0400, Bob Parnass said:

The biggest challenge is writing scanner
software is not the GUI. It is deducing the scanner's
command set (when writing control software) and the radio's
memory image layout (when writing configuration/cloning
software).

The latter is especially challenging
because most manufacturers won't share the info
without signing restrictive nondisclosure agreements.
If you don't want to be bound by such
handcuffs, you must learn the memory image
layout through your own experimentation and by sharing info
with other developers.


I have to respectfully disagree with Mr. Parnass on this. The situation he
describes has not been true for some time. At least since the time of the
Icom R-8500.

Icom and Uniden both document and publish their command sets. I downloaded
them from public manufacturer web sites. They will provide this
information for the asking. Uniden has already released the command set for
their upcoming BCD-396T TrunkTracker IV scanner on their web site. Icom
makes their command sets available either in documentation provided with
the unit or from their web site. The rig manufacturers don't want to be in
the software business (and Icom should get out of it because their software
is terrible IMO) and they know that software availability sells radios.
Now, they may not give it to you before it's widely available . That's a
different kettle of fish.

The part I disagree the most about is the importance of the GUI. The user
interface is CRITICAL! If you don't get that right it doesn't matter if you
understand how the radio works or not. The user won't use the software.
Believe me, I have tried this and the GUI is the hard part. I had a program
working with an ICOM R-8500 in an afternoon. It could do the basics,
command the radio to scan, read back the frequency, set the frequency, etc.
That's very straightforward serial interface programming. ActiveX
controls make that part trivial.

The GUI was a bear! Drag and drop, multi-column tables, setting functions,
etc. takes a lot of thought when laying out the interface. The radio is
fairly complex and doesn't have the best control layout to begin with.
Making that into a useable interface is tough.

What I would like to see in radio software is the following...

1. I WANT TO BE ABLE TO DIRECTLY IMPORT CSV FILES FROM THE PUBLIC FCC
DATABASE!

I should be able to do queries from the ULS, get the result as a CSV and
import that result into the program. This is not trivial to program but not
impossible either. This feature should be standard and a central feature
of the software.

Export to CSV should also be available so I back the radio memory up.

If you really get modern, do all the memory management with XML.

2. Be able to layout the memory by dragging and dropping the frequency
memory entries. In other words, you download the radio memory to the
program and work with it there, then upload the result.

Example: Louisville Metro PD channel 2 is in location 474 and I want it in
389. I should be able to drag it (or cut and paste) to 389. I should not
have to re-type it. This is supported in every modern OS. There's no reason
not to implement this.

Also for this one, use checkboxes for on/off features and pulldowns for the
multiple mode settings. Picture a spreadsheet and you get the idea
perfectly.

3. The design of the software should be oriented to frequency memory
management, not remote control. There is no need for remote control by a PC
for most applications. The radio works fine standing alone and you want to
be able to use it without a laptop (unless it's a WinRadio, duh! I know
that..) if you want to. Full blown remote control of a rig should be a
secondary "nice to have" feature.

4. If you provide audio recording inside the application, implement it
properly using a standard media format like MP3. By properly I mean with a
clear user interface. Make sure to implement some kind of metadata tagging
so that a person can actually tell what the recorded content is.
Frequency, callsign, description and time is a good place to start. The ID3
tags support this. USE STANDARDS!

In general, write your code as generically as possible. Keep all the
rig-specific controls in a separate DLL or other library. This will let
you implement different radios with very little additional work. What you
need is a program that implements common features that all radios have,
then specialize in product specific features like trunk tracking.

Do not dumb down your software because some idiot might be "confused".
Someone who is easily confused probably can't get the software installed
and the radio connected to the computer.

Visual Basic .NET is more than enough to do this job.

It would be worth your time to study the scanner market and figure out
where the need is. If the Uniden scanners are the market leaders, write
your code for them first.

Write a good application, install tough commercial copy protection
(authorization keys at least) and go for it! If you write a good one, I
think people will come because most of the available software sucks, some
loudly.

Michael Harpe, N4PLE
Sellersburg, IN