[aprssig] APRS DOS a time for change?

Rich Mazzeo forummail at richmazz.com
Fri Jan 11 17:12:16 EST 2008

    Hi Mark, all I have so far is:

___The decaying transmission algorithm for position, messages, objects. 
(i.e. don't let the user pick the rate, let winaprs pick the decay rate like 
DOS does

___A warning to users who enter WIDE4-4 or worse in the default path box.

___Objects: some way to draw them with the mouse similar to DOS. Maybe a 
separate line in the drop down menu under "Add/Edit Station" and "weather" 
objects, that lets me pick "open triangle, filled triangle, line, color, 
etc". When I hit ok it will let me draw it and approve before 
transmitting.(something close to that). Currently it's very easy to send an 
object with a bad format or none at all.

___TCP/IP Filter: Someone just brought that up. As of now I have to block 
all incoming TCP/IP traffic and serve as an incoming gate only. Otherwise 
the station list will fill up and boot the RF stations off. A distance 
filter would really work well, whether internal, or in the TCP/IP settings 
to send the distance request directly to the server. A separate list and 
memory allocations for TCP/IP stations altogether is another thought. like 
"max TCP/IP stations = x" type of thing that keeps RF stations separate. 
Bonus points for a check box somewhere that lets me "Display RF stations" 
and "Display TCP/IP" stations, so I can show either TCP or RF or both on my 

Some bugs I've noticed :

___Settings > Alternate VHF Path > Other... won't change the path no matter 
what I type in there.
___Settings > Alternate VHF Path > the paths I have in altpath.txt aren't 
being sent, it's as if altpath.txt is corrupted, but it looks fine.

___Messaging: when entering an alternate path in the "send message" box, it 
is not implemented and just sends the message with the current path.

___Warning/Danger radius: WinAPRS doesn't seem to take any action when a 
moving station passes within my set limits, could be user error.

Feature requests:

___Messaging: Bring back the backslash! If I recall correctly I used to be 
able to hit backslash on a queued message to disable (kill) it. Right now my 
only option is to "fake ack" it with the "=" or "backspace" key. The end 
result is the same, but when I come back later, I can't always remember if I 
"fake acked" it or if the other station really got it.

___Messaging:  I wish there was a way to "transmit all un-acked messages 
now". (Like the N key in the message window, but will send any message 
marked as "Q". this would really come in handy when I am taking APRS 
checkins for Skywarn

___Messaging: Rather than the current path options on the send message 
dialog, how about 5 radio buttons for path choice: -None-, Default (the 
default), and the other 3 would be the first 3 paths from our altpath.txt 
file. Altpath1, Altpath2, Altpath3.

___Messaging: A warning, or "remaining character count" when our message 
will be sent with 2 or more packets. When RF conditions are tough, I'd like 
to try and fit it all in one line rather than risk 1 or 2 words spilling 
over to a second packet that might not make it.

___Weather: Any plan on supporting La Crosse weather stations?

I came up with most of this on the fly right now just based on my own user 
experience.  I'm sure someone will chime in if anything I put down is 
already done or is the results of user error.


----- Original Message ----- 
From: "Mark Sproul" <kb2ici at amsat.org>
To: "Rich Mazzeo" <forummail at richmazz.com>; "TAPR APRS Mailing List" 
<aprssig at lists.tapr.org>
Sent: Friday, January 11, 2008 3:13 PM
Subject: Re: [aprssig] APRS DOS a time for change?

> Rich
> Please send me a list of what you see needs to be implemented in WinAPRS
> Mark
>>    I will second this.  I currently use WinAPRS, but as Brian stated, 
>> many of the features Bob intended were never implemented as planned. And 
>> now, WinAPRS hasn't been updated in over a year and a half.  If there was 
>> a way to get APRSDOS as a windows app and function the way it was 
>> intended (tiger map support would be awesome too!), I would gladly chip 
>> in a secondary "windows port" fee.  It just seems there is nothing else 
>> out there at the moment for windows thats easy to install and use.
> -- 
> ------------------------------------------------------------------
> Mark Sproul                              |
> http://ecs.rutgers.edu                   |
> msproul at jove.rutgers.edu                 |
> Manager - Engineering Computing Services | 732-445-3121
> Rutgers University School of Engineering |
> Office: Eng D111                         |
> ------------------------------------------------------------------ 

More information about the aprssig mailing list