- ... The chances of collision potential are not zero in an APRS network. If you have a single digipeater that can hear EVERY user station, the digipeater willMessage 1 of 16 , May 12, 2013View SourceOn Fri, May 10, 2013 at 5:00 PM, Robert Bruninga <bruninga@...> wrote:
> We agree completely in ever digi putting out the info, but every DIGiThe chances of collision potential are not zero in an APRS network.
> should source this info, and most digipeaters have BEACON room for 2 or 3 of
> them. And I do like to see this local info…, but the objects should be
> “sourced” by those 4 digipeaters with a direct path (no hops) so that the
> DIGI only transmits them when the channel is clear. Only the digipeaters
> can hear their “input area” and so only they can add this info to the
> channel so they do not collide with any user packets at all.
> Sourcing them at one place and having them bounce around to all 4 digis
> takes up 5 times as much channel capacity. And none of those packets are
> guaranteed not to collide with user packets. But if they are –sourced- at
> the digi, then the collision potential is zero.
If you have a single digipeater that can hear EVERY user station, the
digipeater will attempt to send the packet during a time when no other
stations are transmitting. Even in this scenario there is a remote
possibility that a user station may key up exactly at the same time
that the digipeater keys up. Regular user stations are supposed to
have a random hold off time to keep them from clobbering each other,
and the digipeaters are supposed to key up right away. But if a user
station decides to key up and waits it's random amount of time, and as
that hold off expires, the digipeater decides to send the repeater
object, a collision can result.
Now add in a bunch of digipeaters surrounding the original digipeater.
The digi sourcing the repeater object can not tell if the remote
digipeaters are hearing incoming packets or have a clear channel, so
there's the chance of the voice object colliding with a user packet
trying to get into one of the remote digipeaters.
I agree that sourcing the packets at the digipeater has a lesser
chance of creating collisions on the network, and using a zero hop
path reduces the network load much more than a user trying to send the
packets around the area with a multi-hop path, but to say that the
collision potential is zero is misleading.
> > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW4 times the load... there's always a source packet whether from a user
> Again, that is 5 times the channel QRM compared to the way these objects
> are supposed to be designed so that they have zero impact on users by having
> no path and being sourced at each digi.
station, or from a digipeater. Again, trying to imply that a packet
sourced by a digipeater has zero impact on the users is misleading. If
the user can hear the packet, it has an impact. That packet has used
up airtime, and is heard by all stations within range, including all
> > So basically the packets are travelling in a ring or box around theAgain I would disagree... there are far worse methods available. Trust
> > repeater.
> But that is the worst possible method generating 5 times the channel load.
me, let the users play and you'll find out! If Tony were to use the
path WIDE2-2, the packets would travel much further and cause more
network load than his specified 4 hop path.
> The total amount of QRM being generated is as if these beacons were every 2Again, a misleading analysis. There is no possible way to send a
> minutes if you count the total time slots involved. When sourced at the
> digis, the time slots count is actually ZERO since the digis will only
> originate the packet (no hops) when the channel is clear. So although I
> keep saying it is 5 times larger, it is really infinitely larger QRM because
> 5 times larger than nothing is infinite.
packet out that takes up zero airtime. A packet sourced from a user
station is no different than a packet sourced from a digipeater. The
user station waits until it hears a clear channel before transmitting.
A digipeater waits until it hears a clear channel before transmitting.
Each station can only ensure clear channel occupancy within the area
it can hear directly.
The concern is that a packet sourced by a home station may clobber
another home or mobile user trying to access the nearby digipeater.
When a packet is sourced by a digipeater, it too has the same
potential to clobber packets from other users on surrounding
The biggest difference is that when sourced from a home station asking
for a digipeat by the local digipeater, the packet needs to be on the
air two times to get the same coverage area as when that packet is
sourced by the digipeater. (Given that the digipeater covers a larger
area than the home station is capable of covering.)
>> Also we have a very lightly loaded network out here…This I agree with wholeheartedly. We should all strive to operate as
> True, but it sets a bad example and these things tend to get entrenched
> and hard to correct later.
efficiently as possible.
> Thanks for putting out this info. I wish more people did it. But I worryAccurate observation and explanation of the operations of the packet
> that this is setting a bad example. My web page that describes all this is
> on http://aprs.org/localinfo.html
radio network would go a long way towards getting people up to speed.
Unfortunately many people don't take the time to learn and understand
the intricacies of all of the inner workings of the APRS network.
There are also a number of concepts touted as being the panacea of
APRS network operations that just don't work in the real world.
The concept of APRS and its use is my favourite aspect of amateur
radio. I have far more time and money invested into APRS than all
other aspects of amateur radio combined. I love it, but there are a
lot of basic misconceptions floating around and being espoused as the
gospel when they are misleading at best.
- ... Per http://www.aprs-is.net/Connecting.aspx ... Nothing in there about unless you re also transmitting on RF . So client-generated packets directlyMessage 2 of 16 , May 12, 2013View SourceOn 5/12/2013 12:18 PM, James Ewen wrote:
> When APRSISCE/32 sends packets directly to the APRS-IS stream, the RFPer http://www.aprs-is.net/Connecting.aspx
> path is not included. I'm not sure if that happens with other programs
> or not. I've never spent the time to see if it is true. Regardless,
> that might be the source of Bob's observation.
> Packets originating from the client should only have TCPIP* in theNothing in there about "unless you're also transmitting on RF". So
> path, nothing more or less (AE5PL-TS>APRS,TCPIP*:my packet).
client-generated packets directly injected to the APRS-IS will only
contain a path of TCPIP*. The same packet transmitted on RF will
contain the configured RF path. Eventually, each RF port will have the
ability to specify its own path for transmitted packets and the Chat
interface will also allow a local override of the default RF path.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS. And that's yet another reason to run single-RF-port instances. If
you override the path in the Chat, which port did you intend it to use
that path on? Or just how complicated are we going to make this?
- On Sun, May 12, 2013 at 11:30 AM, Lynn W Deffenbaugh (Mr) ... So that s as per the APRS-IS interface specification. Yet another reason why one should not baseMessage 3 of 16 , May 12, 2013View SourceOn Sun, May 12, 2013 at 11:30 AM, Lynn W Deffenbaugh (Mr)
>> Packets originating from the client should only have TCPIP* in theSo that's as per the APRS-IS interface specification.
>> path, nothing more or less (AE5PL-TS>APRS,TCPIP*:my packet).
> Nothing in there about "unless you're also transmitting on RF". So
> client-generated packets directly injected to the APRS-IS will only
> contain a path of TCPIP*. The same packet transmitted on RF will
> contain the configured RF path.
Yet another reason why one should not base observations of the APRS-RF
network on data seen on the internet.
Everyday you learn a little more! Thanks Lynn.
- ... When I think about this a bit, and after reading James comment, I m going to disagree with your 5 times comment. Because I specifically directed thatMessage 4 of 16 , May 12, 2013View SourceAt 05:00 PM 2013-05-10, Robert Bruninga wrote:
Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity. And none of those packets are guaranteed not to collide with user packets. But if they are sourced- at the digi, then the collision potential is zero.
> The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW
Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.
When I think about this a bit, and after reading James comment, I'm going to disagree with your 5 times comment. Because I specifically directed that packet to go from digi to digi, rather than using a WIDE2-2 the only extra QRM is the initial packet from my home station. So it's 20% extra QRM rather than five times. After that it's one digi hearing the next digi.
My home station can hear the first two digis and likely the other two digis could hear a carrier and static when I transmitted my initial packet. So that initial packet could wipe out other packets for the first two digis. The two remoter digis would hear a local packet much sooner than my packet due to the FM capture effect.
Furthermore, when I think about it, there is no real reason why the VERMLN digi owner couldn't put in exactly the same path I specified. That way there is only one digi to update should the repeater object require changes rather than having to update four digis. Or am I mistaken?
Hmm, ok, my thinking is slightly flawed in that an adjacent digi could wipe out another packet being received by an adjacent digi which the first digi can't hear. But that could happen no matter where the repeater object is sourced.
Lynn, we're getting pretty far off the topic of APRSIS32. OTOH we're firmly on the topic of APRS so ....
I quite enjoy these technical discussions and understanding what all happens at a deeper level than running the configuration program and dumping my packets to the APRSIS network. Even if I'm wrong. <smile> So long as my understanding increases.
- ... And there is a reasonable chance, on a WIDE2-2 path, that my packet wouldn t make it to the fourth digi. Most of the time my home station only hears theMessage 5 of 16 , May 12, 2013View SourceAt 10:52 AM 2013-05-12, James Ewen wrote:
>> > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object145.29-RW
>If Tony were to use themore
>path WIDE2-2, the packets would travel much further and cause
>network load than his specified 4 hop path.And there is a reasonable chance, on a WIDE2-2 path, that my packet wouldn't make it to the fourth digi. Most of the time my home station only hears the first two digis reliably. And VERMLN and LLOYD can't reliably hear ALIANC. At least I don't think so.
So if VERMLN digis the packet and PROVST hears the VERMLN packet and digis the VERMLN packet then ALIANC will hear the packet. But if VERMLN digis the packet, then LLOYD and then PROVST the ALIANC won't hear my packet because the two hops will be used by at PROVST.
And, of course, the WIDE2-2 means that my packet is going to head off north and west where we don't need it.
>Accurate observation and explanation of the operations of thepacket
>radio network would go a long way towards getting people up tospeed.
>Unfortunately many people don't take the time to learn andunderstand
>the intricacies of all of the inner workings of the APRSnetwork.
And that is, of course, true in every endeavor of life. <smile> It's up to the fanatics, and in James case I mean that in the kindest way, to educate the others when they see a problem. After all it's it's ten thousand fanatics that built up Wikipedia and Open Street Map, etc, etc,
>The concept of APRS and its use is my favourite aspect ofamateur
>radio. I have far more time and money invested into APRS thanall
>other aspects of amateur radio combined.I can vouch for that. James VE6SRV has lot of digis scattered around the central and northern chunk of the province. As well as Curtis VE6AEW.