[aprssig] Traffic Objects (new subject)

Robert Bruninga bruninga at usna.edu
Wed Sep 3 16:22:05 CDT 2008

>>  As the system was designed, only 
>> MESSAGES can go to RF automatically 
>> (without sysop intervention).
> I ran into this problem about 18 months ago 
> when I tried to build a system that would 
> look for traffic problems (via the publicly
> available loop sensor data) and post it to RF.

Fantastic!  We need this kind of initiative in local APRS!

> I could never figure out a way to reliably 
> get the data into the ether - and also couldn't 
> be sure that I could force those objects to be
> deleted once the traffic cleared.

Huh?  On RF, it's a slam dunk.  Getting the data out is trivial.
Just TX on RF using the fundamental decay algorithm so they show
up quickly.  To kill them after use, just transmit them again
with the KILL indicator (and decay algorithm so that they
reliably disappear too).  All receiving APRS radios and clients
will add them and delete them automatically.

> This is a real problem. Not only do we need a
> design, we need to figure out how to get it 
> widely implemented...

Maybe I am missing something, but if you are designing this for
RF, then there should be no problems at all.  And it is such a
great APRS service, I'd be happy to help if there are any
issues.  Particularly choosing the right local digipeater path
so that the traffic problem object only goes to the local RF
area where it applies...


More information about the aprssig mailing list