[aprssig] IS-to-RF proposal (rev b)

Steve Dimse steve at dimse.com
Thu Dec 29 19:58:03 EST 2011

On Dec 29, 2011, at 7:16 PM, Andre wrote:

> Android is a linux variation, it's just a bit broken.

Well, it can't be used on your system, right?

> And reading back it looks to me that unless clients get rewritten the users have to do more then just use their client normaly, first the tocall needed to be set, then the path was to be altered and now he will have to insert a voice frequentie in his beacon and his desired path.

No, Bob's original plan required change in the clients, his current plan does not. If one has a voice frequency then that can be inserted into the comment string (for example Ham Tracker already allows this), however it is optional and certainly not needed if there is no voice frequency, as is the case for me, I only carry my cell phone. If Bob's current proposal were implemented then my position would appear on RF wherever I travel, assuming the local bandwidth was available and the local IGate operator allowed INet to RF position. Nothing is required on the client side.
> From a user experiance it will be no harder then setting agwpe up for a tnc, he does not have to setup a hub or gate unless he wants to.

Yes, but the setup is not simple to the average user. Do you actually think people want to follow instructions like this?

\A configuration file named with the format @{Name}.INI must be created
(i.e. @LU7DID.INI) with the parameters of the port.

The file name MUST start with @ or the driver won't initialize properly.

The content of the file has to be


DEST_ADDR=   <== IP Address of Destination
DEST_PORT=93             <== Port of the Destination
DEST_HOST=               <== Hostname of Destination (overrides DEST_ADDR)
CALLSIGN=LU7DID-14       <== Unique CallSign for the Port
UDP_PORT=93              <== UDP port where this Port will listen
DEBUG=                   <== Logging and Debug [0..4]

When a user runs Ham Tracker for the first time, the program prompts for their callsign and the APRS IS validation number. Enter those and their position is sent to the APRS IS in a clean manner. That is slightly different from dwnloading and installing multiple DLLs, figuring out what server you want to connect to, and writing multiple config files.

And if I understand this correctly, as I travel I need to edit those files to the IGate closest to me, correct?

> Actions speak louder then words.
I agree. And Bob's actions in APRS exceed yours by quite a bit.

You have an awkward system that is difficult to use and only works on a tiny minority of today's mobile devices. Personally I think Bob needs to keep talking so he motivates IGate authors to write a relatively simple module that will perform this function in a seemless manner for all mobile devices.

> Anyway, I just keep perfecting my idea and when the time is right to move it beyond a small scale network interfacing axudp with aprs clients might have become as simple as interfacing with aprs-is.

If you really want to gain acceptance, I would recommend paying attention to your user experience.


More information about the aprssig mailing list