Re: [aprsisce] Object Paths
- On 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)
>> 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.
- At 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.
- At 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.