[aprssig] Injecting Traffic Incident Objects (Yes! (and no))

[Robert Bruninga]

I'd use the standard APRS decay algorithm.  Transmit once when the new
object is posted, then 8 secs later, then 16, then 32, then 1 min, then 2
min, then 4 min and then 8 min and then 16 minutes until it expires.  If
any of the first three are digipeated, then the other two are ignored by
all digis because of the UIDUPE setting in all digipeaters.  So these are
really there to improve reliabiloity of getting the info out quickly even
if there are collisions.

But this only works when using a WIDEn-N path.  So DO NOT do the 8, and 16
retry because we do not want any WIDEn-N digipeating for these kinds of
local objects.  They should be directed to specific digis by callsign, and
that mode of digipeating does not have UIDUP filering...

Begin with a 32 second retry and then 1 min and so on.  This will still
result in 5 retries in the first 16 minutes... and then every 16 minutes
until it expires..  Though for local simplex or one digi information, the
general concept in APRS is ten minute refresh.

Bob, WB4APR

On Sun, Sep 18, 2016 at 4:18 PM, K5ROE Mike <K5ROE at roetto.org> wrote:

> Gentlemen, thanks for your responses, much to think about.  I raised the
> issue of IS injection because I assumed reverse Igates were much more
> common than they are.  Interesting concept to overcome VHF deficiencies.
> (LoS)
>
> If anyone's curious this is the input from the RSS feed:
>
> <item>
> <title>
> <![CDATA[ I-81N at MM 94.0 ]]>
> </title>
> <link>
> <![CDATA[
> http://www.511virginia.org/?lon1=-80.731528&lat1=37.021412&
> lon2=-80.731528&lat2=37.021412
> ]]>
> </link>
> <description>
> <![CDATA[
> Description:<br>On I-81 North at mile marker 94 in the County of Pulaski,
> motorists can expect major delays due to a tractor trailer accident.
> Traffic backups are approximately 1.0 mile.<br>Last updated:<br>Sun
> 09/18/2016 3:51 PM EDT
> ]]>
> </description>
> <guidisPermaLink="false">INSW4024675-09182016</guid>
> </item>
>
> As you can see, there's both relative and absolute position data and well
> as a unique identifier that I plan to use expire the object.
>
> There's been comment about channel congestion; is there any way to
> objectively measure?  The issue here is that the data has to be announced
> often enough to make it useful, without overloading the channel.
>
> Thanks again guys
>
> 73 K5ROE
>
>
>
>
> On 09/18/2016 02:19 PM, Robert Bruninga wrote:
>
>> On Injecting traffic incidents as APRS objects.
>>
>> I did this in several iterations over the years.  It can be a good idea.
>> Or
>> a TERRIBLE idea depending on how it is done, and depending on local
>> loading....
>>
>> The state of Virginia publishes... traffic incidents.. to be useful as
>>> APRS objects.
>>> I have written a rudimentary parser to inject these into APRS.
>>> 1) the propriety , would this somehow be against the 'vision' of APRS?
>>>
>> Its PERFECT and should be on RF, that is where the APRS mobiles need to
>> see
>> it.
>>
>> 2) has this been tried before and deemed to be a bad idea?
>>>
>> Ive tried it many times over the years and that is why we have a WRECK
>> symbol
>>
>> 3) Would it better to inject APRSIS or RF?  If RF should I consider a
>>> longer path than WIDE2?
>>>
>> ON RF, but ONLY with a single digi path.  No one wants spam coming in from
>> out of area and each digi is considered "an area" in APRS.
>>
>> SO the desired way to do this is to compare the location of each incident
>> and then to compare it to the local digi in THAT area.  And then ONLY use
>> the path of that single digi.
>>
>> If  you are in a metro area and get reports on accidents near digis you
>> cannot hit, then you need to find a partner in the area to also run your
>> code over on his side of town.
>>
>> No one wants out of area spam and it is never a good idea to flood ANYTING
>> to APRS beyond a single hop.  Not only due to the spam issue, and channel
>> loading issue, but simply because someone in the same digi area is usually
>> REACHABLE.  Someone sending spam via two hops is not in the local area and
>> is harder to reach... to pin his coax or whatever...
>>
>> Of course the rules here in the mid atlantic, (one of the densest APRS
>> nets
>> in the world) may be different from the middle of Kansas, so use judgment.
>>
>> Bob
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> http://www.tapr.org/mailman/listinfo/aprssig
>>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160918/0f1641d9/attachment.html>