[aprssig] APRS DOS a time for change?

[Derek Koonce]

How about something in the system that sends back to a broadcaster a 
message that their format is incorrect? This is in the hopes to get 
those WIDE4-4 people using the correct path. This may be a difficult 
thing, but could go something like:

1. Broadcaster uses WIDE4-4 in path.
2. Digi / Igate sees this sequence in the path and broadcasts back to 
that station a message.

Granted this would generate new messages being transmitted in the area, 
but could help alert people.

Derek Koonce
KE6JTP



Rich Mazzeo wrote:
>
>    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 map.
>
> 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.
>
> Regards,
> Rich
> N3XKU
>
> ----- 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.
>>>
>>> Regards,
>>> Rich
>>> N3XKU
>>
>> -- 
>> ------------------------------------------------------------------
>> 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                         |
>> ------------------------------------------------------------------ 
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>