<div>I've resisted weighing in on this, but viscous digipeating seems to be something I called "yield digipeating" back in 1998 when the aprsdigi software was written.  I like your name better, but I think the concept is the same.  My philosophy was that is a low lying digi saw a particular digi (designated by the config) that there would be no need for the low lying digi to sent the packet.  So the idea was to queue a packet for a few seconds and wait to see if the big digi sent it.  If the bigger digi sent it, then we would assume that everyone in the footprint had heard it - making the copy from the little digi redundant.  If I understand viscious digipeating correctly, that is what it is.</div>

<div> </div>
<div>The concept of fracticide is certainly valid in my home qth.  We have one digi locally and the next nearest digi's are 100km to the east and 80km to the west.  There is a very very small area that I can hear two digi's and don't get a decode.  Most of the time I do get a decode of my position and when the digi I decoded finishes playing my packet, I see that the other one is just finishing up as well when the S meter goes from full scale to 7 s units.  Due to different TXd's and other factors two copies of my packet don't take up exactly ONE time slot... it's more like 1.25 or 1.5 time slots, but still it's better than having each of three digipeaters make my packet take 3 time slots.</div>

<div> <br clear="all">Wes<br>---<br>God help those who do not help themselves.<br><br><br></div>
<div class="gmail_quote">On Sat, Oct 24, 2009 at 11:57, Matti Aarnio <span dir="ltr"><<a href="mailto:oh2mqk@sral.fi">oh2mqk@sral.fi</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">I keep hearing rumors that in some big cities in US the 144.390 MHz<br>is under constant radio traffic.<br>
<br>Do you have any audio recordings of what those main digipeaters hear<br>on their radios?<br><br>I would like to hear the radio traffic in big US cities, at quiet night<br>time, "quiet" daytime, and at peak traffic time.<br>
<br>I would like to do some analysis on _uncompressed_  8 kHz 8 bit mono<br>recording, if any such exist.  That would be a bit under 29 MB per hour.<br>I can not use audio that has undergone any sort of lossy compression,<br>
as those tend to skew signal phases.  Lossless compression is acceptable,<br>like ZIP, possibly also FLAC.<br><br>An 8-bit resolution sample is enough, IF you can make it so that maximum<br>signal amplitude is 80-95% of full scale, and never clips.<br>
A 16-bit resolution lets you off with lower full range signal, but not<br>with clipping overamplitude.<br><br>I can receive them with ftp transfer, and of course retrieve from web<br>page, or whatever you can make yourselves.  Details to be negotiated<br>
when there are files for me to receive.<br><br>By the way, do you KNOW when there are peak traffic times, and how busy<br>they are?  In Erlangs ?<br><br>One of very first things that my Aprx did was to present on telemetry data<br>
an estimate of channel occupancy in erlangs based on number of bytes<br>received  in each packet plus some guesses overhead.   This method works<br>well enough at lowish traffic levels - at least under 0.3 Erlangs.<br><br>
More precise measurement would take radio RSSI signal, and account<br>fraction of time when it is over some defined treshold.  That would<br>know not only of successfully decoded packets, but also of failures<br>due to two transmitters colliding at too even signal power levels.<br>
<br>73 de Matti, OH2MQK<br><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br><a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</blockquote></div><br>