¿ªÔÆÌåÓý

Traffic Hording?


 

There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater

My issue with it is a couple things...
- I setup a iGate in the area because there was no coverage in the area at the time.
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer

My question is, how can I tune my iGate to respond properly and fast enough to negate the point of traffic in the area being redirected to another area so far away and optimize the local APRS experience for all users?
Currently I'm running 2M, I plan to change this to include 440 in coming months or days.

A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.
Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?

My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas

My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.

My config is as follows (I'm cutting out the stock information)

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 15
SLOTTIME 1
PERSIST 33
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IGTXVIA 0 WIDE1-1,WIDE2-1
IGTXLIMIT 6 10


 

There is no "redirection" of traffic. If your I-gate heard it, you sent it to the APRS-IS backbone too, as a redundant copy, and the backbone filters out duplicates. Is the traffic supposedly being "hoarded" by this I-gate a direct path to that I-gate, whereas it is a one-hop digipeat to yours? In that case, it makes perfect sense: the _local_ I-gate is forwarding the traffic from its first transmission rather than having to wait for it to be (unreliably) digipeated to a remote I-gate somewhere else. Furthermore, if the sender is using proportional pathing, not all of their packets might be digipeated anyway (because they won't request being digipeated in their paths). The point of multiple I-gates is failure redundancy, not load-balancing. The RF load is where it is, and adding more receiving I-gates somewhere else won't change the local RF load.

Frankly, if any one I-gate can't handle the full traffic from a saturated 1200-baud RF channel, it's a pretty sad excuse for an I-gate, because that's just not that much traffic (an old-style 9600-baud dialup modem could handle the Internet connection for that much traffic with bandwidth to spare).

Andrew, KA2DDO

________________________________________
From: [email protected] <[email protected]> on behalf of Patrick <kd7wpq@...>
Sent: Sunday, May 8, 2022 3:23 AM
To: [email protected]
Subject: [direwolf] Traffic Hording?

There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater

My issue with it is a couple things...
- I setup a iGate in the area because there was no coverage in the area at the time.
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer

My question is, how can I tune my iGate to respond properly and fast enough to negate the point of traffic in the area being redirected to another area so far away and optimize the local APRS experience for all users?
Currently I'm running 2M, I plan to change this to include 440 in coming months or days.

A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.
Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?

My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas

My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.

My config is as follows (I'm cutting out the stock information)

ARATE 48000
ADEVICE plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 15
SLOTTIME 1
PERSIST 33
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IGTXVIA 0 WIDE1-1,WIDE2-1
IGTXLIMIT 6 10


 

I notice that you do not have any filters set. You must include a line beginning with IGFILTER to tell the APRSIS server what information you want sent to your Igate. Consult section 9.10 of the user guide and an accompanying document titled Successful Igate operation.?
?
Good luck and 73 de
Patrick (N3TSZ)


On Sunday, May 8, 2022, 03:23:56 AM EDT, Patrick <kd7wpq@...> wrote:


There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater

My issue with it is a couple things...
- I setup a iGate in the area because there was no coverage in the area at the time.
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer

My question is, how can I tune my iGate to respond properly and fast enough to negate the point of traffic in the area being redirected to another area so far away and optimize the local APRS experience for all users?
Currently I'm running 2M, I plan to change this to include 440 in coming months or days.

A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.
Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?

My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas

My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.

My config is as follows (I'm cutting out the stock information)

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 15
SLOTTIME 1
PERSIST 33
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IGTXVIA 0 WIDE1-1,WIDE2-1
IGTXLIMIT 6 10


 

I am not sure what you mean by "Traffic Hording" .
Are you referring to his station "always winning the race to an APRS-IS server"?
This should NOT be a competition to 'most packets posted on APRS-IS'.
The imnportant point is good consistent coverage.

There are only a few factors that influence this:
1. First to receive
??? Closer to the transmitting station is typically 'first to receive' as the RF reaches it first.
??? Most often intermediate DIGIs would be the largest factor here.? So literally, closest (no DIGI required) would win.
? ? ?? In most cases, this is related to highest, or most coverage area.
??? >>> Another factor here is overlapping DIGI coverage.? If the TX hits several DIGIpeaters and
?????????? is retransmitted over the same area, thos in the overlap area may get interference from the others and
?????????? miss part of the packet
2. Quickness to decode
??? If a station is slow to decode (error correction may be a factor), this may give another station time to win the race.
??? However, the error corrcection may make the more packets availble quicker to the APRS-IS server.
??? So you would win when the closer stations doesn't get a clean packet.
3. Internet access to the APRS-IS server(s)
?? a) ISP speed at the IGATE site is probably the biggest factor.
?? b) DNS servers used by your provider and DNS settings may influence how fast they resolve the APRS-IS server.
?????? EXAMPLE: you send noam.aprs2.net and the DNS server sends back an IP address for one of the 'pool' servers.
?? a) Since most clients use a 'pool' address for APRS-IS, it is hard to ensure you have the shortest route to an APRS-IS server.
?????? There are some network settings that may help this, but I have never tried to optrimize this.

As far as "too busy" is concerned, any IGATE is almost defintely RF limited.? If the data is on RF and heard, it can be IGATEd.

Robert Giuliano
KB8RCO



On Sunday, May 8, 2022, 03:23:56 AM EDT, Patrick <kd7wpq@...> wrote:


There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater

My issue with it is a couple things...
- I setup a iGate in the area because there was no coverage in the area at the time.
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer

My question is, how can I tune my iGate to respond properly and fast enough to negate the point of traffic in the area being redirected to another area so far away and optimize the local APRS experience for all users?
Currently I'm running 2M, I plan to change this to include 440 in coming months or days.

A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.
Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?

My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas

My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.

My config is as follows (I'm cutting out the stock information)

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 15
SLOTTIME 1
PERSIST 33
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IGTXVIA 0 WIDE1-1,WIDE2-1
IGTXLIMIT 6 10


 

On Sun, May 8, 2022 at 10:22 AM Rob Giuliano via <kb8rco=[email protected]> wrote:
2. Quickness to decode
??? If a station is slow to decode (error correction may be a factor), this may give another station time to win the race.
??? However, the error corrcection may make the more packets availble quicker to the APRS-IS server.
??? So you would win when the closer stations doesn't get a clean packet.

Error correction?? AX.25 UI Frames underpinning APRS over the air are about as "spray and pray" and one can get.?


 

This brings up a question:
Are you concerned with traffic from APRS-IS to RF, or (as most users are concerned) with RF to APRS-IS servers?

APRS-IS to RF depends are the RF to APRS-IS.? The server tends to use the return path.

Robert Giuliano
KB8RCO



On Sunday, May 8, 2022, 10:21:54 AM EDT, Patrick Connor via groups.io <n3tsz@...> wrote:


I notice that you do not have any filters set. You must include a line beginning with IGFILTER to tell the APRSIS server what information you want sent to your Igate. Consult section 9.10 of the user guide and an accompanying document titled Successful Igate operation.?
?
Good luck and 73 de
Patrick (N3TSZ)


On Sunday, May 8, 2022, 03:23:56 AM EDT, Patrick <kd7wpq@...> wrote:


There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater

My issue with it is a couple things...
- I setup a iGate in the area because there was no coverage in the area at the time.
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer

My question is, how can I tune my iGate to respond properly and fast enough to negate the point of traffic in the area being redirected to another area so far away and optimize the local APRS experience for all users?
Currently I'm running 2M, I plan to change this to include 440 in coming months or days.

A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.
Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?

My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas

My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.

My config is as follows (I'm cutting out the stock information)

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 15
SLOTTIME 1
PERSIST 33
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IGTXVIA 0 WIDE1-1,WIDE2-1
IGTXLIMIT 6 10


 

¿ªÔÆÌåÓý


Hello Patrick,

There's a station about 65 miles from my position, about 50 miles from our digipeater position that seems to somehow be hording all the iGate traffic.
I'm about 15 miles from our digipeater


The answers from Andrew, Patrick C, Rob, and John all have excellent points but I had a few final thoughts too:

?? - You don't mention which station is doing the "hording" so it's difficult to give you more ideas

?? - How well does your station hear these other client APRS stations?? I see your KD7WPQ-10 station is on the northern shore of a lake but you're surrounded by mountains to the east and west.? Those mountains are going to create some level of RF reflections which might be creating some decoding challenges for your station

?? - 50 miles is a LONG way for many packets to reach your station.? Unless those remote APRS client stations are transmitting with good antennas and some real power, your station probably won't be able to decode many of the packets.? This would be the #1 reason of why the other APRS client stations reporting into the "hording" station


My issue with it is a couple things...
- He's pulling enough traffic that it's quite possible if things got busy enough that his iGate wouldn't be able to handle the load and if that ends up being the case then users suffer


That's a bit of the nature of APRS in general.? It's a lossy network so and packet loss will be expected even in the best conditions but with future beacons, position packets, etc. coming later, people should be able to get a clear picture of what's going on in a given area.


Currently I'm running 2M, I plan to change this to include 440 in coming months or days.


APRS on 70cm isn't very common but it's worth a try.? Is there a coordinated frequency in your area for APRS on 70cm?? Btw... if you're thinking about 9600bps FSK APRS, I would recommend you read:

??

Yes.. it's faster but it's also a much more sensitive data mode requiring some real tuning to work (at all).


A fellow ham and I have been working on getting coverage in the area and splitting the areas in such a manner that we hope to never see more traffic than any one iGate can ever handle there by potentially providing the best user experience possible.


This is a great plan when done right.? Try to avoid overlapping coverage areas (PHG circles if you will) by simulating the RF propagation for a given area.? That takes time and it's not easy but a well thought out design will go a long ways.


Granted we're new to APRS but that doesn't mean we're not trying or am I just being vein?


Well.. As you've seen in the other comments, it's not entirely up to you.? Even if you ultimately come up and an excellent design for say "classic digipeater network", other people can plop down their own digipeaters and somewhat screw things up.? What I would also recommend is to monitor the APRS traffic and see if you have some stations that are "over beaconing" and saturating the network due to drifty GPS receivers, etc.? I have some scripts here to help if you're interested.


My fellow ham put up a digipeater about a year or more ago and we've been putting up iGates to fill in the uncovered areas


If these are all Raspberry PI + Direwolf based, I hope you're building these for the long haul including SD card write hardening, some sort of battery backup, remote power cycle support, etc.? If many of these stations are Internet enabled Igates, make sure you're patching and rebooting the OS on a regular cadence.? If the OS is EOL, it's time to upgrade to continue getting updates.? If you don't do ALL these things, you will be doing a LOT of on-site support on these nodes.


My iGate consists of a Rasberry Pi 3B, a CMedia sound fob, PTT is triggered via the CMedia's GPIO pin to a commercial Kenwood which has been repurposed for APRS use.


Sounds good.? What antennas?? Any duplexers to keep the signal clean in/out of the antenna?


Regarding your Direwolf AX.25 settings, changing your settings to be more aggressive will only DAMAGE the overall performance of the network.? Please don't do that unless the entire RF APRS is aligned to the more aggressive timers.

TXDELAY 15 <----------- That's pretty fast for old radios.? Are you 100% sure that's correct?
SLOTTIME 1? <--------- That's a slot time of 10ms when the Direwolf default should be 100ms
PERSIST 33? <--------- The Direwolf default here is 63
AGWPORT 8000 <------ Unless you are using these, disable it with a setting of 0
KISSPORT 8001 <------ Unless you are using these, disable it with a setting of 0
FIX_BITS 1 AX25 <----- At minimum, remove the "AX25" as you're disabling the APRS heuristics for better decodes but consider removing this line completely as it can do more harm than good
CBEACON dest="MORSE-10" info="de KD7WPQ"
IGMSP 0? <------------- Why are you setting this (Number of times to send position of message sender)?? I recommend to remove this line
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.N long=116^31.W power=5 height=20 gain=3 comment="Ponderay, ID iGate"

This isn't a valid PHG level for power.? Please see for valid values.
Are you really only using a 3db gain antenna?? If so, consider using a better gain but still inexpensive antenna like a 6.5dbi Diamond CP22E antenna

PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.N long=116^31.W
IBEACON delay=0:01 every=10:00 VIA=WIDE1-1,WIDE2-1 symbol="igate" overlay=T lat=48^18.N long=116^31.W

Don't use WIDE2-1 unless you really need it.? You're only contributing to the congestion of the network


IGTXVIA 0 WIDE1-1,WIDE2-1

Sending to WIDE2-1 might be ok when you're first starting out and there isn't much of a network operating.? As things are to get rolling using WIDE2 will hurt the scaling of the network.? Per the above URL, it consisely says:

?? 2& = TX igate with path set to 2 hops (not generally good idea)


IGTXLIMIT 6 10


Do you know if this rate limiter is impacting your station (check your direwolf logs)?? If you're in a busy area, 10 packets in 5 minutes is not a lot and might need to be tuned but please don't outright disable it.

--David
KI6ZHD


 

OK, I'm going to try and answer everyone...

Andrew P.,
??? I agree with your statement about iGates.
The station in question is KW7JOE. He broadcasts every 5 minutes

May 08 13:11:57 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE:@082011z4722.91N/11642.10W# KW7JOE 12.1V, 48.7DEG. OFFGRID SOLAR, WX3in1
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :PARM.Vin,Rx1h,Dg1h,Eff1h,Temp,O1,O2,O3,O4,I1,I2,I3,I4
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :UNIT.Volt,Pkt,Pkt,Pcnt,Deg,On,On,On,On,Hi,Hi,Hi,Hi
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :EQNS.0,0.075,0,0,10,0,0,10,0,0,1,0,0,0,0
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :BITS.11111111,WX3in1Plus20 Telemetry
May 08 13:12:47 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE:T#163,162,009,005,053,146,00000000

Granted, it may be very well nothing he's done but traffic from my area, in a valley is hitting the digipeater that a buddy of mine put up to fill the area due to lack of coverage (at the time), then going to another digipeater then out his iGate 60 miles away.

I'm not sure when he put up his iGate but at the time we put ours in there wasn't anything in the area. N7ISP was set in such a manner to only cover the north as it can't see south but this was purposefully as the Coeur d'Alene area has it's own iGates and doesn't need a digipeater.

The two digipeaters in question are N7ISP-10 and INDMT.
Now I don't know about INDMT but N7ISP-10 is a stand alone digipeater with no internet which is why my buddy and I got together to put up a iGate at my location 15 miles north.

Patrick Conner,
??? Understood and set. I'll post the modified config at the bottom. I welcome constructive criticism :)

Rob Giuliano,

??? Yes, basically regarding winning the APRS-IS server race and you bring up some good points regarding networking, DNS, ect.
??? I won't go into all the networking tid-bit but I don't use my ISP servers, I use DNS over TLS and my router is pointed to multiple DNS servers and has a DNS cache though I do have a filter that reloads from time to time so I may have some network tuning to do.
??? I agree, it shouldn't be a competition, my problem with it is he's 60 miles away and is somehow pulling traffic from this area which negates the point of why we put the iGate up in the first place. At that time there was nothing and yes, good consistent coverage is more important for sure, redundancy is also very good but packets should be going to the closest iGate (15 miles) not the furthest (60 miles) unless that local iGate is non-responsive, then it should go to whichever is available.

My concern is mostly RF to APRS-IS.
There is not much traffic in my area but at the same time I don't want to miss anyone or anything but I also don't want to be pulling coverage from an area that doesn't need it.
Regarding APRS-IS to RF, I was pretty much letting the server decide what goes out and so far as I can see nothing goes out that hasn't already been sent in and that is GOOD! I don't want misc unrelated traffic blowing up the area and jamming the local network.

John Huggins,
??? Yea, just disabled that. I'm still learning

David Ranch,
??? You're always very clear and precise in your message and I thank you VERY much for that! Well and your replies, MUCH appreciated!!!
??? The station in question was mentioned above. Hopefully that clears things up.
??? If I recall the antenna isn't 3db, I want to say it's 6 but I will go get the model number and double check and adjust accordingly as soon as I get outside.
??? The problem is that the station that is 60 miles away is getting the traffic via our digipeater vs my iGate which is 15 miles away.
??? Regarding APRS on 440, I'll have to start a new topic on that. I didn't realize it wasn't that common on 440, so it may not be worth looking into. Really I hadn't given it much thought other than, "Maybe people might like some 440 coverage?", and good to know on the tuning. I'll be sure to get with another operator I know that has some bench equipment for proper tuning, if and when I do it.
??? I am VERY interested in the scripts, shoot away!
??? I am constantly doing updates and tuning on the iGate but the digipeater is off the grid. I do think we're going to have to go pull it, do some more tuning and updates this summer but it's best that I know what I need to do now before I actually go grab it.
??? I am curious if you have a list of recommended hardening? I know a couple thing I do is noatime, nodtime, enabling more memory pressure and there's another app I use that pre-loads common applications into memory to reduce SD card writes. On my desktop it's almost reduced writes to nothing. Every time I do a trim, it trims 0 unless I've been deleting files.
??? No duplexers, no filters, any suggestions? If I can keep the signals clean, I'm game!
??? TXDELAY 15 believe it or not was working, at least locally, but I went ahead and set it back to 20 to be safe.
??? As for the IGTXLIMIT, no there is not a lot of traffic in my area but I don't want to hinder traffic either.
??? As for the reports, how are you getting a daily report? I'm very interested!
??? I can shoot the other station a email to let him know but I doubt a beacon every 5 minutes isn't deliberate, he's likely transmitting it for his own logs though it's getting 60+ miles out.

I adjusted my config, constructive criticism always welcome!

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3
PTT CM108
TXDELAY 20
SLOTTIME 10
PERSIST 63
AGWPORT 0
KISSPORT 8001
#FIX_BITS 1 AX25
CBEACON dest="MORSE-10" info="de KD7WPQ"
#IGMSP 0
IGSERVER noam.aprs2.net
IGLOGIN (Redacted)
PBEACON delay=21 every=10 overlay=S symbol="igate" lat=48^18.31N long=116^31.47W PHG3160/WIDE comment="Ponderay, ID iGate"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18N long=116^31W
IBEACON delay=0:10 every=10:00 VIA=WIDE1-1 symbol="igate" overlay=T lat=48^18N long=116^31W
IGFILTER m/48
FILTER d/N7ISP-10 s/->
#IGTXVIA 0 WIDE1-1
#IGTXVIA 1 KD7WPQ
#IGTXVIA 0
IGTXLIMIT 6 5


 

On 5/8/2022 2:34 PM, Patrick wrote:

My concern is mostly RF to APRS-IS.
There is not much traffic in my area but at the same time I don't want to miss anyone or anything but I also don't want to be pulling coverage from an area that doesn't need it.
I do not understand what you're concerned about. In the RF-to-APRSIS direction, the
so-called RxGate direction, the more, the merrier. APRS-IS handles duplicate traffic by
design.

Just because a station is forwarding frames from RF to APRSIS doesn't stop any other
station from doing so.

Regarding APRS-IS to RF, I was pretty much letting the server decide what goes out and so far as I can see nothing goes out that hasn't already been sent in and that is GOOD! I don't want misc unrelated traffic blowing up the area and jamming the local network.
I'm not as familiar with the scheme APRS-IS uses to select a TxGate, but I'm pretty sure it
favors a TxGate with the shortest path (fewest digis) based on observed traffic.

73,
Dana? K6JQ


 

¿ªÔÆÌåÓý


Hello Patrick,

The station in question is KW7JOE. He broadcasts every 5 minutes

May 08 13:11:57 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE:@082011z4722.91N/11642.10W# KW7JOE 12.1V, 48.7DEG. OFFGRID SOLAR, WX3in1
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :PARM.Vin,Rx1h,Dg1h,Eff1h,Temp,O1,O2,O3,O4,I1,I2,I3,I4
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :UNIT.Volt,Pkt,Pkt,Pcnt,Deg,On,On,On,On,Hi,Hi,Hi,Hi
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :EQNS.0,0.075,0,0,10,0,0,10,0,0,1,0,0,0,0
May 08 13:12:37 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE::INDMT :BITS.11111111,WX3in1Plus20 Telemetry
May 08 13:12:47 APRS-iGate direwolf[2626]: [ig>tx] INDMT>APMI06,TCPIP*,qAS,KW7JOE:T#163,162,009,005,053,146,00000000

Packet #1 is a standard info beacon with a position.? That really should happen no quicker than every 10 minutes and realistically, can come far less often.. say every 30min.? Packet #2 is the the beginning of a set of telemetry packets.? Consider these the column titles for the rest of the telemetry data.? Packet #3 are the units for those columns.? The rest is the various data.? The more often you send it, the more resolution you have in the data but one needs to question do they need that much resolution.? I would argue NO.? You can see a graphical depiction of that data here:??


Btw.. if this location is correct.. it seems that the INDMT node has some decent elevation which helps in all respects for distance, more packet decodes, etc.




??? The problem is that the station that is 60 miles away is getting the traffic via our digipeater vs my iGate which is 15 miles away.

As other have described, it shouldn't really be a "competition" but I understand your perspective.? Two things I should have mentioned before:

?? - I've found that Direwolf isn't the faster decoder.? I bet with disabling the FIX_BITS option, that might speed things up a little

?? - A Raspberry Pi isn't the fastest computer either.? You could throw more CPU power at it and it might help but you have to question why it would matter

?? - What is your Internet connection like?? Very generally speaking, the faster it is.. the lower the serialization delays thus "lower the ping times".? If you're looking to get to the APRS-IS network the fastest, every little bit helps



??? Regarding APRS on 440, I'll have to start a new topic on that. I didn't realize it wasn't that common on 440, so it may not be worth looking into. Really I hadn't given it much thought other than, "Maybe people might like some 440 coverage?", and good to know on the tuning. I'll be sure to get with another operator I know that has some bench equipment for proper tuning, if and when I do it.

I don't know if there are any "packet clubs" in your area of Idaho but if there is, you might see if there is much interest or if it's been tried before.? I'm not saying there isn't a benefit here but the propogation of 2m is far better than 70cm.? Instead, maybe consider setting up a packet BBS with some cool features like CONVERS chat, WW messaging, etc.


??? I am constantly doing updates and tuning on the iGate but the digipeater is off the grid. I do think we're going to have to go pull it, do some more tuning and updates this summer but it's best that I know what I need to do now before I actually go grab it.

If the digipeater is off grid (no internet), there is very little risk.? If it works.. don't touch it.


??? I am curious if you have a list of recommended hardening? I know a couple thing I do is noatime, nodtime, enabling more memory pressure and there's another app I use that pre-loads common applications into memory to reduce SD card writes. On my desktop it's almost reduced writes to nothing. Every time I do a trim, it trims 0 unless I've been deleting files.

Section 6 - 11 for sure:?


??? No duplexers, no filters, any suggestions? If I can keep the signals clean, I'm game!

Not always required for "quiet sites but it can help your radio with avoiding being swamped by nearby signals, etc.? Look on Ebay and other sites for say a 4 cavity 2m duplexer set.? They aren't cheap though.


??? TXDELAY 15 believe it or not was working, at least locally, but I went ahead and set it back to 20 to be safe.

This is only important for TRANSMITTING so it won't help your receive "performance"


??? I can shoot the other station a email to let him know but I doubt a beacon every 5 minutes isn't deliberate, he's likely transmitting it for his own logs though it's getting 60+ miles out.

I adjusted my config, constructive criticism always welcome!

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+ /3?? <------------ To possibly speed up decodes a little, you can remove the "/3" but you will have a higher current draw from the Pi

--David
KI6ZHD


Lynn Deffenbaugh
 

On 5/8/2022 8:38 PM, Dana Myers wrote:
I'm not as familiar with the scheme APRS-IS uses to select a TxGate, but I'm pretty sure it
favors a TxGate with the shortest path (fewest digis) based on observed traffic.
The APRS-IS doesn't "select" a TxGate.? The APRS-IS servers keep track of what stations were received via every connected IGate.? Any message addressed to any of those stations that were "recently" heard, will be sent to ALL connected IGates that heard that station.? A subsequent "courtesy" posit from the message-originating station will follow as well.? Each individual IGate decides to put the message and posit through to RF based on its own configuration.? There is no "intelligence" or "routing" in the APRS-IS network, and IGates aren't "selected" by anything.? Each IGate decides what to transmit based on its own implementation and without any knowledge of any other IGate.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


 

--
Packet #1 is a standard info beacon with a position.? That really should happen no quicker than every 10 minutes and realistically, can come far less often.. say every 30min.? Packet #2 is the the beginning of a set of telemetry packets.? Consider these the column titles for the rest of the telemetry data.? Packet #3 are the units for those columns.? The rest is the various data.? The more often you send it, the more resolution you have in the data but one needs to question do they need that much resolution.? I would argue NO. You can see a graphical depiction of that data here:
Btw.. if this location is correct.. it seems that the INDMT node has some decent elevation which helps in all respects for distance, more packet decodes, etc.
--

OK and understood on both counts


It's not a competition. I just have to wonder why my iGate is not catching traffic that is closer than the other iGate. Those you have all already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!

As for my internet, I have high speed cable internet, 2 modems, 200x20 each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure up time, currently load balanced, later will be failover. The two modem are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely change to a higher performance machine in later days as it'll just barely handle the up coming 1Gb. Not that I'll be using all that bandwidth but I'd rather the internet be the bottle neck, not my router.

Ping times vary between about 9 and 30ms but one modem does have some periodic but minute packet loss we haven't been able to figure out.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.

Regarding filters, the only issue I've noticed is my antennas are too close together. Something I'll need to remedy in the future as the iGate de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to be expected but I don't use my desk radio too often, just every now and then.

Regarding the TXDELAY, yea, I understand what it's for. Basically to allow the transmitter to trigger and stabilize prior to actual activity.

I went ahead and pulled out the "/3". The only thing running on that machine is a GUI, Direwolf and a KISS interface, that's it's whole purpose in life at the moment. I'm perfectly content with some extra CPU usage and I'm not worried about heat as all Pis I put to use have a big solid aluminum heatsink. Under normal conditions they can't overheat, I've tried purposefully just to see if they could.

OK, well thank you everyone for your input. I'm glad to have a better configuration running on the iGate which should serve this area better than it was.

Now to get the iGate up north working that should already be working but that's another story.


 

On Sun, May 8, 2022 at 10:50 PM David Ranch <direwolf-groupsio@...> wrote:
? ? No duplexers, no filters, any suggestions? If I can keep the signals clean, I'm game!
Not always required for "quiet sites but it can help your radio with avoiding being swamped by nearby signals, etc.? Look on Ebay and other sites for say a 4 cavity 2m duplexer set.? They aren't cheap though.

What's the goal here?? Bandpass the 144.390 MHz frequency?? If so, a duplexer assembly (usually comprising multiple BpBr cavity sets for two freqs) isn't the logical choice.? A cavity or two (in series) designed just for bandpassing (and no duplexing capability) is relatively economical and readily?available on the used market.

73
John, kx4o


 

Patrick,

It's not a competition. I just have to wonder why my iGate is not
catching traffic that is closer than the other iGate. Those you have all
already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!
How do you know you _aren't_ catching traffic and sending it to the APRS-IS?
Have you examined your I-gate logs to see what exact traffic you have sent
to the APRS-IS backbone? It's been said thousands of times before, but I'll
say it again:

YOU CANNOT USE THE APRS-IS FOR_ PROPAGATION ANALYSIS.

Period. End of statement. No exceptions.

The APRS-IS drops any duplicate receives of the same packet from later I-gates.
So, if you are not the first I-gate in, you will not be displayed on APRS-IS.

And crow's-flight distance doesn't matter for APRS; it's actual signal path that matters.
For example, if there is a station only 5 miles from you, but there is a mountain between you
and it, you will never hear that station directly; it will have be digipeated over or around
that mountain, which will make the packets later arriving at your station. Therefore
you probably won't be first to the APRS-IS.

As for my internet, I have high speed cable internet, 2 modems, 200x20
each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure
up time, currently load balanced, later will be failover. The two modem
are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely
change to a higher performance machine in later days as it'll just
barely handle the up coming 1Gb. Not that I'll be using all that
bandwidth but I'd rather the internet be the bottle neck, not my router.
Ping times vary between about 9 and 30ms but one modem does have some
periodic but minute packet loss we haven't been able to figure out.
Ping times to what? Unless it's ping times to the APRS-IS server you are using,
it's irrelevant. I just checked my 300MB/s link, and I have average 4.7 milliseconds
to the first ISP router upstream from mine, but 69 milliseconds average to an
arbitrary selection on the noam.aprs2.net rotator.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.
Regarding filters, the only issue I've noticed is my antennas are too
close together. Something I'll need to remedy in the future as the iGate
de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to
be expected but I don't use my desk radio too often, just every now and
then.
If you're not using it often, it shouldn't be an issue. And I-gates rarely
transmit to RF, as there is very little traffic addressed from the APRS-IS
backbone to a local RF station (and you say there are very few RF APRS stations
in your area to be candidates to have traffic sent explicitly to them), so the
I-gate shouldn't be causing desense all that often (and that's assuming you
have it configured as a RF-transmit-capable I-gate). Unless
you are cluttering the local RF channel with extra forced IS->RF traffic, of course.

Hope this helps.

Andrew, KA2DDO
author of YAAC (a slow I-gate)


 

I have two Igates that are 33 miles apart. They both report packets the other should have. Both are Raspberry Pi 2s identically configured using the same model of radios. One is on Spectrum Business Class, one is on Verizon for Internet access. They do have different antennas and have different coverage ranges. Both report lots of packets to the south, but not the other directions.

With APRS multiple stations can be transmitting at the same time. That can cause one Igate to miss what another hears. The Igates may be? forwarding to different pool servers. Those servers load levels might be different, which could get in the way as well.

As the FCC requires a station to identity every 10 minutes, so my Igates ID every 10 minutes, but with a Wide 1,1 so it's not digipeated.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 8, 2022, at 11:54 PM, Patrick <kd7wpq@...> wrote:

--
Packet #1 is a standard info beacon with a position.? That really should
happen no quicker than every 10 minutes and realistically, can come far
less often.. say every 30min.? Packet #2 is the the beginning of a set
of telemetry packets.? Consider these the column titles for the rest of
the telemetry data.? Packet #3 are the units for those columns.? The
rest is the various data.? The more often you send it, the more
resolution you have in the data but one needs to question do they need
that much resolution.? I would argue NO. You can see a graphical
depiction of that data here:
Btw.. if this location is correct.. it seems that the INDMT node has
some decent elevation which helps in all respects for distance, more
packet decodes, etc.
--

OK and understood on both counts


It's not a competition. I just have to wonder why my iGate is not
catching traffic that is closer than the other iGate. Those you have all
already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!

As for my internet, I have high speed cable internet, 2 modems, 200x20
each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure
up time, currently load balanced, later will be failover. The two modem
are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely
change to a higher performance machine in later days as it'll just
barely handle the up coming 1Gb. Not that I'll be using all that
bandwidth but I'd rather the internet be the bottle neck, not my router.

Ping times vary between about 9 and 30ms but one modem does have some
periodic but minute packet loss we haven't been able to figure out.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.

Regarding filters, the only issue I've noticed is my antennas are too
close together. Something I'll need to remedy in the future as the iGate
de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to
be expected but I don't use my desk radio too often, just every now and
then.

Regarding the TXDELAY, yea, I understand what it's for. Basically to
allow the transmitter to trigger and stabilize prior to actual activity.

I went ahead and pulled out the "/3". The only thing running on that
machine is a GUI, Direwolf and a KISS interface, that's it's whole
purpose in life at the moment. I'm perfectly content with some extra CPU
usage and I'm not worried about heat as all Pis I put to use have a big
solid aluminum heatsink. Under normal conditions they can't overheat,
I've tried purposefully just to see if they could.

OK, well thank you everyone for your input. I'm glad to have a better
configuration running on the iGate which should serve this area better
than it was.

Now to get the iGate up north working that should already be working but
that's another story.







 

" ... with a Wide 1,1 so it's not digipeated."
Not sure what you mean by Wide 1,2 and how why you feel this is no digipeated?
?? I assume you mean WIDE1-1, which WILL be digipeated.
If you provide "no path elements", then you packet should not be DIGIpeated, but will still be gated.
?? If your station is already an IGATE, then others gating you packet will always be treated as DUPEs.

Robert Giuliano
KB8RCO



On Monday, May 9, 2022, 08:55:58 AM EDT, Jim Bacher - WB8VSU <wb8vsu@...> wrote:


I have two Igates that are 33 miles apart. They both report packets the other should have. Both are Raspberry Pi 2s identically configured using the same model of radios. One is on Spectrum Business Class, one is on Verizon for Internet access. They do have different antennas and have different coverage ranges. Both report lots of packets to the south, but not the other directions.

With APRS multiple stations can be transmitting at the same time. That can cause one Igate to miss what another hears. The Igates may be? forwarding to different pool servers. Those servers load levels might be different, which could get in the way as well.

As the FCC requires a station to identity every 10 minutes, so my Igates ID every 10 minutes, but with a Wide 1,1 so it's not digipeated.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 8, 2022, at 11:54 PM, Patrick <kd7wpq@...> wrote:

--
Packet #1 is a standard info beacon with a position.? That really should
happen no quicker than every 10 minutes and realistically, can come far
less often.. say every 30min.? Packet #2 is the the beginning of a set
of telemetry packets.? Consider these the column titles for the rest of
the telemetry data.? Packet #3 are the units for those columns.? The
rest is the various data.? The more often you send it, the more
resolution you have in the data but one needs to question do they need
that much resolution.? I would argue NO. You can see a graphical
depiction of that data here:
Btw.. if this location is correct.. it seems that the INDMT node has
some decent elevation which helps in all respects for distance, more
packet decodes, etc.
--

OK and understood on both counts


It's not a competition. I just have to wonder why my iGate is not
catching traffic that is closer than the other iGate. Those you have all
already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!

As for my internet, I have high speed cable internet, 2 modems, 200x20
each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure
up time, currently load balanced, later will be failover. The two modem
are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely
change to a higher performance machine in later days as it'll just
barely handle the up coming 1Gb. Not that I'll be using all that
bandwidth but I'd rather the internet be the bottle neck, not my router.

Ping times vary between about 9 and 30ms but one modem does have some
periodic but minute packet loss we haven't been able to figure out.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.

Regarding filters, the only issue I've noticed is my antennas are too
close together. Something I'll need to remedy in the future as the iGate
de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to
be expected but I don't use my desk radio too often, just every now and
then.

Regarding the TXDELAY, yea, I understand what it's for. Basically to
allow the transmitter to trigger and stabilize prior to actual activity.

I went ahead and pulled out the "/3". The only thing running on that
machine is a GUI, Direwolf and a KISS interface, that's it's whole
purpose in life at the moment. I'm perfectly content with some extra CPU
usage and I'm not worried about heat as all Pis I put to use have a big
solid aluminum heatsink. Under normal conditions they can't overheat,
I've tried purposefully just to see if they could.

OK, well thank you everyone for your input. I'm glad to have a better
configuration running on the iGate which should serve this area better
than it was.

Now to get the iGate up north working that should already be working but
that's another story.







 

Can I blame it on a senior moment??

My intent was a required ID would not be repeated as many times as a normal beacon sent with WIDE 2,1.?

I thought I read somewhere that Wide 1,1 would not be repeated, but as you pointed out thats wrong. No idea how that failed to escape me. If I recall correctly the first number is decremented each repeated transmission until it hits zero. So with a one in the first position it would be repeated once. I should have used WIDE 0,1 to prevent it from being retransmited.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 9, 2022, at 5:51 PM, "Rob Giuliano via " <yahoo.com@groups.io target=_blank>[email protected]> wrote:

" ... with a Wide 1,1 so it's not digipeated."
Not sure what you mean by Wide 1,2 and how why you feel this is no digipeated?
?? I assume you mean WIDE1-1, which WILL be digipeated.
If you provide "no path elements", then you packet should not be DIGIpeated, but will still be gated.
?? If your station is already an IGATE, then others gating you packet will always be treated as DUPEs.

Robert Giuliano
KB8RCO



On Monday, May 9, 2022, 08:55:58 AM EDT, Jim Bacher - WB8VSU <wb8vsu@...> wrote:


I have two Igates that are 33 miles apart. They both report packets the other should have. Both are Raspberry Pi 2s identically configured using the same model of radios. One is on Spectrum Business Class, one is on Verizon for Internet access. They do have different antennas and have different coverage ranges. Both report lots of packets to the south, but not the other directions.

With APRS multiple stations can be transmitting at the same time. That can cause one Igate to miss what another hears. The Igates may be? forwarding to different pool servers. Those servers load levels might be different, which could get in the way as well.

As the FCC requires a station to identity every 10 minutes, so my Igates ID every 10 minutes, but with a Wide 1,1 so it's not digipeated.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 8, 2022, at 11:54 PM, Patrick < kd7wpq@...> wrote:
--
Packet #1 is a standard info beacon with a position.? That really should
happen no quicker than every 10 minutes and realistically, can come far
less often.. say every 30min.? Packet #2 is the the beginning of a set
of telemetry packets.? Consider these the column titles for the rest of
the telemetry data.? Packet #3 are the units for those columns.? The
rest is the various data.? The more often you send it, the more
resolution you have in the data but one needs to question do they need
that much resolution.? I would argue NO. You can see a graphical
depiction of that data here:
Btw.. if this location is correct.. it seems that the INDMT node has
some decent elevation which helps in all respects for distance, more
packet decodes, etc.
--

OK and understood on both counts


It's not a competition. I just have to wonder why my iGate is not
catching traffic that is closer than the other iGate. Those you have all
already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!

As for my internet, I have high speed cable internet, 2 modems, 200x20
each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure
up time, currently load balanced, later will be failover. The two modem
are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely
change to a higher performance machine in later days as it'll just
barely handle the up coming 1Gb. Not that I'll be using all that
bandwidth but I'd rather the internet be the bottle neck, not my router.

Ping times vary between about 9 and 30ms but one modem does have some
periodic but minute packet loss we haven't been able to figure out.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.

Regarding filters, the only issue I've noticed is my antennas are too
close together. Something I'll need to remedy in the future as the iGate
de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to
be expected but I don't use my desk radio too often, just every now and
then.

Regarding the TXDELAY, yea, I understand what it's for. Basically to
allow the transmitter to trigger and stabilize prior to actual activity.

I went ahead and pulled out the "/3". The only thing running on that
machine is a GUI, Direwolf and a KISS interface, that's it's whole
purpose in life at the moment. I'm perfectly content with some extra CPU
usage and I'm not worried about heat as all Pis I put to use have a big
solid aluminum heatsink. Under normal conditions they can't overheat,
I've tried purposefully just to see if they could.

OK, well thank you everyone for your input. I'm glad to have a better
configuration running on the iGate which should serve this area better
than it was.

Now to get the iGate up north working that should already be working but
that's another story.







 

Actually, WIDE2-2 would reduce to WIDE2-1, then WIDE2*.
? So it's actually the second number that decrements to zero.
? WIDE1-1 would reduce to WIDE*.

NOTE: the first number is part of the relay (DIGI) name.
? ? ? ? ? ? ?it really isn't much different than any other character, other than as a pseudo limit.
? ? ? ? ? ? ?So WIDE1-3 would mean a station with an ALIAS of WIDE1 would DIGI the packet.
? ? ? ? ? ? ? ? ?Depending on the configuration, it may either go to WIDE* (proper for a WIDE1)
? ? ? ? ? ? ? ? ? or WIDE1-2, if just following the the decrement scheme.


Rob Giuliano
KB8RCO


On Mon, May 9, 2022 at 18:27, Jim Bacher - WB8VSU
<wb8vsu@...> wrote:
Can I blame it on a senior moment??

My intent was a required ID would not be repeated as many times as a normal beacon sent with WIDE 2,1.?

I thought I read somewhere that Wide 1,1 would not be repeated, but as you pointed out thats wrong. No idea how that failed to escape me. If I recall correctly the first number is decremented each repeated transmission until it hits zero. So with a one in the first position it would be repeated once. I should have used WIDE 0,1 to prevent it from being retransmited.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 9, 2022, at 5:51 PM, "Rob Giuliano via " <yahoo.com@groups.io target=_blank>[email protected]> wrote:
" ... with a Wide 1,1 so it's not digipeated."
Not sure what you mean by Wide 1,2 and how why you feel this is no digipeated?
?? I assume you mean WIDE1-1, which WILL be digipeated.
If you provide "no path elements", then you packet should not be DIGIpeated, but will still be gated.
?? If your station is already an IGATE, then others gating you packet will always be treated as DUPEs.

Robert Giuliano
KB8RCO



On Monday, May 9, 2022, 08:55:58 AM EDT, Jim Bacher - WB8VSU <wb8vsu@...> wrote:


I have two Igates that are 33 miles apart. They both report packets the other should have. Both are Raspberry Pi 2s identically configured using the same model of radios. One is on Spectrum Business Class, one is on Verizon for Internet access. They do have different antennas and have different coverage ranges. Both report lots of packets to the south, but not the other directions.

With APRS multiple stations can be transmitting at the same time. That can cause one Igate to miss what another hears. The Igates may be? forwarding to different pool servers. Those servers load levels might be different, which could get in the way as well.

As the FCC requires a station to identity every 10 minutes, so my Igates ID every 10 minutes, but with a Wide 1,1 so it's not digipeated.

Jim Bacher, WB8VSU
wb8vsu@...
https:\\
On May 8, 2022, at 11:54 PM, Patrick < kd7wpq@...> wrote:
--
Packet #1 is a standard info beacon with a position.? That really should
happen no quicker than every 10 minutes and realistically, can come far
less often.. say every 30min.? Packet #2 is the the beginning of a set
of telemetry packets.? Consider these the column titles for the rest of
the telemetry data.? Packet #3 are the units for those columns.? The
rest is the various data.? The more often you send it, the more
resolution you have in the data but one needs to question do they need
that much resolution.? I would argue NO. You can see a graphical
depiction of that data here:
Btw.. if this location is correct.. it seems that the INDMT node has
some decent elevation which helps in all respects for distance, more
packet decodes, etc.
--

OK and understood on both counts


It's not a competition. I just have to wonder why my iGate is not
catching traffic that is closer than the other iGate. Those you have all
already gone over. It was more or less basically, "What am I doing wrong?".
Redundancy is great, for sure!

As for my internet, I have high speed cable internet, 2 modems, 200x20
each and soon I'll have 1,000/1,000 fiber along with 2 modems to ensure
up time, currently load balanced, later will be failover. The two modem
are basically for troubleshooting purposes between the cable company and I.
For my router I'm running PfSense on a A1SRi-2758. This may likely
change to a higher performance machine in later days as it'll just
barely handle the up coming 1Gb. Not that I'll be using all that
bandwidth but I'd rather the internet be the bottle neck, not my router.

Ping times vary between about 9 and 30ms but one modem does have some
periodic but minute packet loss we haven't been able to figure out.

Regarding the 440 or BBS stuff, I'll look into that. That would be handy.

Regarding filters, the only issue I've noticed is my antennas are too
close together. Something I'll need to remedy in the future as the iGate
de-senses my 706 on 2M and the 706 will de-sense the iGate. Something to
be expected but I don't use my desk radio too often, just every now and
then.

Regarding the TXDELAY, yea, I understand what it's for. Basically to
allow the transmitter to trigger and stabilize prior to actual activity.

I went ahead and pulled out the "/3". The only thing running on that
machine is a GUI, Direwolf and a KISS interface, that's it's whole
purpose in life at the moment. I'm perfectly content with some extra CPU
usage and I'm not worried about heat as all Pis I put to use have a big
solid aluminum heatsink. Under normal conditions they can't overheat,
I've tried purposefully just to see if they could.

OK, well thank you everyone for your input. I'm glad to have a better
configuration running on the iGate which should serve this area better
than it was.

Now to get the iGate up north working that should already be working but
that's another story.







Lynn Deffenbaugh
 

¿ªÔÆÌåÓý


On 5/9/2022 8:51 PM, Rob Giuliano via groups.io wrote:
Actually, WIDE2-2 would reduce to WIDE2-1, then WIDE2*.
? So it's actually the second number that decrements to zero.
? WIDE1-1 would reduce to WIDE*.

Actually, WIDE1-1 would decrement to WIDE1*.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


 

Andrew P,

It transmits when it needs to or every 10 minutes to ID and broadcast to say it's here but that's about it. So every now and then when I am on my 706 on 2M it will interrupt a conversation here or there but not enough to make it impossible to recover the conversation.

I've thought about giving the antennas separation but it doesn't bother me that much so I just let it be.

And no, it's not cluttering the band, it only transmits when there is someone to send to or a request has been made.

I would call it a low activity iGate, and that's fine, I don't want a bunch of unnecessary junk cluttering the band.
The iGate is there for anyone in the area to use, not misc. internet traffic.

I am not nor would NOT use APRS for propagation analysis, there are other better tools for that and going for a drive will clarify what those tools can not, but I have used and have found it to be pretty accurate with what I've seen in real life.

I understand propagation and rf reflection and that just because my station hears it doesn't mean there weren't errors or got to the server first vs the other station may have heard it better. My primary focus was tuning my iGate to be the best it can be because it seemed as if my iGate was doing nothing and another igate 60 miles away was doing the lifting.
What's the point of having a iGate that doesn't do it's job?
I don't want to be that guy that just PLOPS in a gateway and say, "oh look at me, I have a gateway, come one, come all, look at me (waving hands)" that does nothing more than cause problems and clogs the network. I want to be the guy of which people are grateful to have on their network that doesn't cause problems and quietly sits in the background.
But I do understand that I won't be able to get everything I want nor be able to service all traffic in the area but I can optimize what I have to provide the best service within my means.

My ping times to noam.aprs2.net is about 83ms.

Jim Bacher,

Good points on the server response times. I guess there's a lot of factors involved and maybe something I should investigate.
Maybe I can find a closer faster server but it doesn't mean that it'll always be the fastest as the server could end up with some busy moments.

My iGate is set for IDing every 10 minutes as well via morse and APRS WIDE1-1. No point in broadcasting throughout the whole network, that would be unnecessary traffic.
Which makes me wonder if KW7JOE's node isn't set to wide1-1 because I'm hearing him through our local digipeater.
I think I'm going to shoot him a email. I don't want to know about his battery statistics but maybe there's a reason he's sending it so far (shrug).

Maybe I should set WIDE1-0? But how is that going to affect traffic coming out the iGate? Do they set their own WIDE?-?

Anyone want to break down WIDE more specifically?

It sounds like WIDE1-1, one hop from any node WIDE1
WIDE1-2, two hops from any node WIDE1
WIDE2-1, one hops from any node set to WIDE2
WIDE2-2, two hops from any node set to WIDE2

I'm not sure, that's why I ask, clarification much appreciated.