<div dir="ltr"><div><div>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.<br><br></div>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...<br><br>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.<br><br></div>Bob, WB4APR<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 18, 2016 at 4:18 PM, K5ROE Mike <span dir="ltr"><<a href="mailto:K5ROE@roetto.org" target="_blank">K5ROE@roetto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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)<br>
<br>
If anyone's curious this is the input from the RSS feed:<br>
<br>
<item><br>
<title><br>
<![CDATA[ I-81N at MM 94.0 ]]><br>
</title><br>
<link><br>
<![CDATA[<br>
<a href="http://www.511virginia.org/?lon1=-80.731528&lat1=37.021412&lon2=-80.731528&lat2=37.021412" rel="noreferrer" target="_blank">http://www.511virginia.org/?lo<wbr>n1=-80.731528&lat1=37.021412&<wbr>lon2=-80.731528&lat2=37.021412</a><br>
]]><br>
</link><br>
<description><br>
<![CDATA[<br>
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<br>
]]><br>
</description><br>
<guidisPermaLink="false">INSW4<wbr>024675-09182016</guid><br>
</item><br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks again guys<br>
<br>
73 K5ROE<br>
<br>
<br>
<br>
<br>
On 09/18/2016 02:19 PM, Robert Bruninga wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Injecting traffic incidents as APRS objects.<br>
<br>
I did this in several iterations over the years. It can be a good idea. Or<br>
a TERRIBLE idea depending on how it is done, and depending on local<br>
loading....<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The state of Virginia publishes... traffic incidents.. to be useful as<br>
APRS objects.<br>
I have written a rudimentary parser to inject these into APRS.<br>
1) the propriety , would this somehow be against the 'vision' of APRS?<br>
</blockquote>
Its PERFECT and should be on RF, that is where the APRS mobiles need to see<br>
it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) has this been tried before and deemed to be a bad idea?<br>
</blockquote>
Ive tried it many times over the years and that is why we have a WRECK<br>
symbol<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Would it better to inject APRSIS or RF? If RF should I consider a<br>
longer path than WIDE2?<br>
</blockquote>
ON RF, but ONLY with a single digi path. No one wants spam coming in from<br>
out of area and each digi is considered "an area" in APRS.<br>
<br>
SO the desired way to do this is to compare the location of each incident<br>
and then to compare it to the local digi in THAT area. And then ONLY use<br>
the path of that single digi.<br>
<br>
If you are in a metro area and get reports on accidents near digis you<br>
cannot hit, then you need to find a partner in the area to also run your<br>
code over on his side of town.<br>
<br>
No one wants out of area spam and it is never a good idea to flood ANYTING<br>
to APRS beyond a single hop. Not only due to the spam issue, and channel<br>
loading issue, but simply because someone in the same digi area is usually<br>
REACHABLE. Someone sending spam via two hops is not in the local area and<br>
is harder to reach... to pin his coax or whatever...<br>
<br>
Of course the rules here in the mid atlantic, (one of the densest APRS nets<br>
in the world) may be different from the middle of Kansas, so use judgment.<br>
<br>
Bob<br>
______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/li<wbr>stinfo/aprssig</a><br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/li<wbr>stinfo/aprssig</a><br>
</blockquote></div><br></div></div></div></div></div></div>