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

[Andre]

Op 30-12-2011 1:58, Steve Dimse schreef:
> 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?
Not now but by the time Bob's system is actualy inplace it can be, it 
takes as much time to add the rgate funtion in igate software as it 
takes to add axudp suport in an android client.
>
>> 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.
His current plan still calls for the client selecting a path, why else 
would there be 3 settings for path rates and ranges, the only place left 
for selecting paths is in the beacon comment, even if paths are selected 
on some calculation yet to work out there still has to be an option to 
select if you want to be gated or not.
>>  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
>
> [AXIPDRV]
>
> DEST_ADDR=192.168.0.10<== 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.
connecting to aprs-is is just as hard for many clients, if I want to 
connect to aprs-is with ui-view I have to figure out what server I 
connect to, I have to fill in the aprs-is pass and I have to work out 
what filter to use and where to put that filter, especialy the filter is 
a big stumbeling block for many users, software evolves, it might not be 
plug and play right now but at least it works right now and will most 
likely be plug and play soon enough.
> And if I understand this correctly, as I travel I need to edit those files to the IGate closest to me, correct?
No you don't have to edit any files, untill clients are smart enough to 
adjust the path themselfs you only have to set the path for the right 
udp gate, clients can be changed to automate that and probably will when 
users demand it.
>
>> Actions speak louder then words.
>>
> I agree. And Bob's actions in APRS exceed yours by quite a bit.
You make it sound like I was not part of the small group that got aprs 
moving in the netherlands and elevated it from 2 wide only digipeaters 
to network we have today. Nice to know my work is appreciated
> 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.
I have a system that already works and gets easier to use as clients 
evolve just like the clients evolved to make installing tncs and aprs-is 
access simpler, and I would not call Bob's system seamless unless all 
local stations on aprs-is are to be gated to rf and I sure hope that is 
not the intention because there is not enough room to do it without 
dropping a lot of packets, many areas are swamped already right now.
>> 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.
Guess I have to see about getting a configfile generator out once the 
system is debugged to my liking, it took years to get aprs-is to where 
it is now, my system has been running for 2 days, a lot of other aprs 
ideas are still in the dream phase or simply died before any on air 
testing so it is best to keep things in perspective
> Steve
>
73 Andre PE1RDW