Order Tray | Contact Us | Home | SIG Lists

[aprssig] designflaws (rollover from ui-view group)

Andre PE1RDW aprs at pe1rdw.demon.nl
Wed Dec 7 17:54:14 UTC 2005


It got to offtopic for the ui-view group and it looks like bob does not 
visit the yahoogroups aprs group so I´ll take it here.

Robert Bruninga schreef:

>>>>uiview at pe1rdw.demon.nl 12/06/05 5:19 PM >>>
>>>>        
>>>>
>>The biggest problem that is hampering aprs is not 
>>things missing from ui-view but design flaws in the 
>>aprs protocoll that are atributed to Bob designing 
>>it for a human interface of the tapr tnc2 firmware.
>>    
>>
>
>How the software interfaces to the TNC is invisible
>to the user.  Sharing a single 1200 baud channel
>amongst hundreds of users also has nothing to
>do with how the software talks to the hardware.
>It has all to do with basic fundamentals of digipeating
>and a shared channel.  That is what the APRS 
>protocol was supposed to do.
>  
>
It may be invisable to the user untill he tries to use things like 
dynamic paths for messaging etc. or use a tnc firmware that the author 
did not consider (been there myself)

>AUthors can use KISS mode or the TNC cmd: line 
>interface independent of the protocol, as everyone 
>knows, since many softwares do one or the other or 
>both.  ANd none of the network sharing problems 
>and fundamental issues we are discussing have 
>anything to do with that interface.
>
>  
>
Wrong, in a busy channel like most of the usa you have no way of knowing 
when a frame will be send so unless you use kiss you can not change the 
path for messaging queries etc. without risking sending it with the 
wrong path. so all your messages have to be send to the same flood area 
as your beacon, not very efficient.

>>Sadly Bob didn´t know about kiss or was afraid to 
>>program for it so we are stuck with a kludge on 
>>kludge system.
>>    
>>
>
>No, I chose to use the command line interfaece
>because back in 1983, when I first begain this
>protocol, the "cmd:" line interfeace was what
>ALL packet users were familiair with.  And in order
>for APRS to "take-off" it was best if it remained 
>familiair to its  initial new users.
>
>de Wb4APR, Bob
>
>  
>
And now we are stuck with a bloated system wasting a lot of space 
because it was designed human readable, compare the 8 byte position 
format of opentrac with the 17 byte format of normal position report (8 
lat +9 long).
No wonder that the base 91 compresion and mice formats where added later on.

Long before aprs was accepted kiss was already in use by tcp/ip and bbs 
users, they didn´t seem to have the problem of getting it to "take off" 
and don´t come with the argument that aprs is now bigger then bbs and 
tcp/ip trafic, we all know that this has nothing to do with hardware or 
software but rather by the lack of hamspirit by a lot of users (all at ww)

The idea of aprs is a very good one, I do aplaud you for comming up with 
it but it is time to evolve to the next level, initialy I had the idea 
of starting on it myself but Bill Hermann pointed me to opentrac and it 
looks like it has the basics to be able to do what I have in mind so 
I´ll contribute my ideas to that project, I have a feeling they are more 
willing to listen.

73 de Andre PE1RDW





More information about the aprssig mailing list