[aprssig] APRS DOS a time for change?

[The Bland Ranch]

As much as this is a basically good idea, how much of these responses would be
wasted becuase the originater is dumb tracker and can't receive anything?

Chuck Bland
NA6BR

Quoting Derek Koonce <derek at dkoonce.com>:

> 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
> >
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>