[aprssig] Traffic Objects (new subject)
Robert Bruninga bruninga at usna.eduWed Sep 3 21:22:05 UTC 2008
- Previous message: [aprssig] Internet to RF gating of positions
- Next message: [aprssig] Traffic Objects (new subject)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>> 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... Bob, WB4APR
- Previous message: [aprssig] Internet to RF gating of positions
- Next message: [aprssig] Traffic Objects (new subject)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
