[aprssig] Beacon rate feedback

[Wes Johnston]

I think the Ham hud used the CD LED on the TNC it gauge channel occupancy 
(or maybe it was simply a remoted indictor?).

You are correct though, in many cases when mobile just because you don't 
decode your own packet doesn't mean it didn't get to the digi.  Without some 
limit on retries (ham hud would only try twice I think), such a 
retry-when-not-heard system would lead very quickly to network collapse.  I 
have this problem nearly every day as I arrive at work.  I try (manually) to 
"ding the network" one last time before shutting down.  Many times I see a 
packet come right back at me and I'm just so sure it was my packet bouncing 
off the digi, but it doesn't decode.  I manually try once or twice, give up 
and walk into the office.

Never the less it would be really nice if the new 710 could watch squelch 
open time vs bytes decoded to come up with a network reliability indicator 
similar to the ham hud's 'digimeter'.  Steve Bragg was really way, way ahead 
of his time in several ways with the ham hud.

Before we get into a Ford vs Chevy war... each method has it's own 
advantages... time based beacons, proportional pathing and smart beaconing.

Proportional pathing probably gives the best "snap shot" type info... more 
info as you get closer to the tracker, less info if you are further away. 
But two trackers who try to transmit at the same second each minute will 
tend to stay in lockstep.

Smartbeaconing on the other hand allows for two things... first it 
randomizes the transmit time, second it's great for collecting detailed 
route info.

Each has it's place and it's advantage in different circumstances.  I'm very 
pleased that kenwood offers _both_ in the 710 radio.  Maximum flexibility!

Also, let's not forget that the kpc3 "dumb" tracker can be used with 
proportional pathing reasonably well.  So any of you KPC3 users transmitting 
NMEA sentences can make up for the bandwidth sin by utilizing prop. pathing.

If I'm not mistaken, both the Opentrac and TinyTrackers both allow for 
setting two paths to alternate between. And OT and TT certainly do smart 
beaconing.  I guess it would really be nice if you could program a ratio of 
PATH1 and PATH2 in either of these devices... so you could for example, 
transmit 4 times with a direct path and 1 time with a regional path.

Anyway, we have many tools at our disposal to use either of these bandwidth 
saving measures!

Wes


----- Original Message ----- 
From: "Robert Bruninga" <bruninga at usna.edu>
To: "'TAPR APRS Mailing List'" <aprssig at tapr.org>
Sent: Monday, November 24, 2008 9:39 AM
Subject: Re: [aprssig] Beacon rate feedback


> This idea of retry-if-not-heard has come up a number of times on
> APRS, but the general conclusion is that it has the potential to
> be a disaster for the network.
>
> The problem is that a "decoder" in a mobile cannot tell the
> difference between an empty channel and a totally saturated
> grid-locked one.  They both have very few decodes per minute.
> Thus, these devices that try-harder-when-not-decoded  are a
> china-syndrome melt-down scenario waiting to happen.
>
> What needs to happen as the channel gets crowded and packets
> become less reliable and are not-heard is exactly the opposite,
> to reduce-the-rate, not increase it.
>
> The best general algorithm for sharing the channel with others
> while also being heard locally and getting out reliably is
> Proportional Pathing.  Set to a 1 minute rate, it maintains a
> nice consistent presence in its local vicinity for local, or
> event operations, it maintains a nice 2 minute presence in the
> area of its first digipeater, and maintains a nice 4 minute
> presence in the region.  And the operator does not have to
> change anything when doing something local (an event, 1 min) or
> traveling on a long trip (being seen once every 4 minutes out 2
> hops)...
>
> See www.aprs.org/newN/ProportionalPathing.txt
>
> Bob, Wb4APR
>
>
>
>> -----Original Message-----
>> From: aprssig-bounces at tapr.org
>> [mailto:aprssig-bounces at tapr.org] On Behalf Of Scott Miller
>> Sent: Monday, November 24, 2008 1:15 AM
>> To: TAPR APRS Mailing List
>> Subject: [aprssig] Beacon rate feedback
>>
>> I drove about 600 miles up to my sister's place in the San
> Francisco
>> area and back this weekend, and used the drive as an
>> opportunity to try
>> a few things.
>>
>> I was running an FC-301/D at 5 watts, which is a lot less
> power than
>> what I usually run on the DR-135T.  But this time, I set the
> beacon
>> interval to 30 seconds and the NICE parameter on the T2 (a
>> prototype of
>> the add-on board for the FC-301/D) to 3.
>>
>> The NICE parameter (named for the UNIX command for setting
> process
>> priority) causes the T2 to skip the specified number of
>> beacons whenever
>> it hears itself digipeated.  I've never run it higher than 1
> in normal
>> operation, and never with a significantly higher than normal
>> beacon rate.
>>
>> With the 30/3 setting, as long as it gets an echo, the beacon
> interval
>> is effectively 2 minutes.  If it didn't hear anything, it'll
>> retry every
>> 30 seconds.
>>
>> This is a higher rate than I'd run for everyday use, but I
> don't make
>> these trips often and I wanted to gather some useful data.
> And so far
>> it looks like it worked pretty well - there are very few
> places where
>> more than one packet in two minutes was seen at an IGate, and
> some of
>> those (like in Salinas) were heard by an IGate without
>> hitting a digipeater.
>>
>> For highway driving at least, I think I like this scheme
> better than
>> SmartBeaconing.  It retries in places where it's needed and
> doesn't
>> flood the network.  Whether this would still be a good idea
>> at 50 watts,
>> I'm not sure.  But I figure at 5 watts, the chances are very
> good that
>> if the digipeater can hear me, I can hear it at least as well.
>>
>> I know the HamHUD has a digi-meter to tell you when you're
> getting in,
>> and I think APRSDOS had some kind of feedback, but I can't
> recall if
>> either of those actually controlled the transmission rate that
> way.
>> Does anything else do this?  It's something that the T2's been
> able to
>> do for a while now, but I haven't really been pushing the
>> feature.  I'd
>> like to encourage greater use of it, but I'd like to hear
>> what the APRS
>> community thinks of it.  The callsign in use was N1VG-6 if you
> want to
>> check it out.
>>
>> 73,
>>
>> Scott
>> N1VG
>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>