¿ªÔÆÌåÓý

  1. Direwolf
  2. Messages
Expanded Topics Messages Polls
Date
Re: APRS specification

 

Don't forget about all the corrections, enhancements, and addendums on . For example, the original specification doesn't even deal with the New-N paradigm for digipeating.

Hopefully, the effort to create a non-profit foundation to carry on Bob's vision will be able to release the consolidated APRS 1.2 specification (with all mandatory versus optional parts clearly identified).

Andrew, KA2DDO

________________________________________
From: [email protected] <[email protected]> on behalf of Michael Wright <mfwright@...>
Sent: Friday, May 13, 2022 4:41 PM
To: [email protected]
Subject: Re: [direwolf] APRS specification

thanks for reminder of this document (wow, 22 years old).

I find it amusing it was called this because it is Bob APR's system or APRS for short. Then they had to come up with something for what it stands for. Which is fine because once this system starts it automatically reports positions.
And it is now 30 years old, Bob sure knew how to develop a system of long endurance. RIP Bob

Mike K6MFW

On Fri, 13 May 2022 20:13:16 +0000 (UTC), "Patrick Connor via groups.io" <n3tsz@...> wrote:

I refer to this document often when I am building or troubleshooting an APRS system.

Patrick (N3TSZ)
Re: APRS specification

 

thanks for reminder of this document (wow, 22 years old).

I find it amusing it was called this because it is Bob APR's system or APRS for short. Then they had to come up with something for what it stands for. Which is fine because once this system starts it automatically reports positions.
And it is now 30 years old, Bob sure knew how to develop a system of long endurance. RIP Bob

Mike K6MFW

On Fri, 13 May 2022 20:13:16 +0000 (UTC), "Patrick Connor via groups.io" <n3tsz@...> wrote:
?
I refer to this document often when I am building or troubleshooting an APRS system.
?
Patrick (N3TSZ)
Re: APRS specification

 

¿ªÔÆÌåÓý

Same thing thanks.?

Best Regards.?
Armando Rodriguez

On May 13, 2022, at 3:28 PM, J K via groups.io <kuhnje@...> wrote:

?
Nice! ?Also saved it as well.



On May 13, 2022 at 4:22 PM, <Patrick Connor via groups.io> wrote:

I refer to this document often when I am building or troubleshooting an APRS system.

Patrick (N3TSZ)
Re: APRS specification

 

Nice! ?Also saved it as well.



On May 13, 2022 at 4:22 PM, <Patrick Connor via groups.io> wrote:

I refer to this document often when I am building or troubleshooting an APRS system.

Patrick (N3TSZ)
Re: APRS specification

 

Very nice!

I'm adding that to my saved documentation!
APRS specification

 

I refer to this document often when I am building or troubleshooting an APRS system.

Patrick (N3TSZ)

APRS101.PDF
APRS101.PDF

Re: Traffic Hording?

 

TRUE

Back in the day, DIGIpeating and/or node hopping used intermediate stations to get to an end destination.? They were identified by their CALLSIGNs-SSIDs.? The fact (or maybe it was a change) that the CALLSIGN-SSID was not verified in any way (particularly format), gave options for non-CALLSIGNs or ALIASes.

At least that was how it was explained to me - way back when.

Robert Giuliano
KB8RCO



On Thursday, May 12, 2022, 04:11:22 PM EDT, Chuck Gelm <nc8q-aredn@...> wrote:


On 5/12/22 09:27, Rob Giuliano via groups.io wrote:
> The point I was making was that the beginning is treated as a
> "callsign", whether used in a path or anywhere else, so it should not
> be altered.
> The "system" would ONLY decrement the SSID.

I thought it was treated as an ALIAS.
WIDE* is not a callsign format.
?

Chuck
Re: Traffic Hording?

Chuck Gelm
 

On 5/12/22 09:27, Rob Giuliano via groups.io wrote:
The point I was making was that the beginning is treated as a "callsign", whether used in a path or anywhere else, so it should not be altered.
The "system" would ONLY decrement the SSID.
I thought it was treated as an ALIAS.
WIDE* is not a callsign format.
?

Chuck
Re: Traffic Hording?

 

Oops, CORRECT!? I missed the 1.??
The point I was making was that the beginning is treated as a "callsign", whether used in a path or anywhere else, so it should not be altered.
The "system" would ONLY decrement the SSID.

>Maybe I should set WIDE1-0? But how is that going to affect traffic coming out the iGate? Do they set their own WIDE?-?
? ?If you don't want your signal to be DIGI'ed, you don't specify any path elements.? In other words, no VIA elements n Direwolf.
This version will be DIGI'ed:
#PBEACON delay=1? every=30 overlay=S symbol="digi" lat=42^37.14N long=071^20.83W power=50 height=20 gain=4 comment="Chelmsford MA" via=WIDE1-1,WIDE2-1?
This version will NOT be DIGI'ed:
#PBEACON delay=11 every=30 overlay=S symbol="digi" lat=42^37.14N long=071^20.83W power=50 height=20 gain=4 comment="Chelmsford MA"??

>Anyone want to break down WIDE more specifically?
? ?Think of a WIDE1 as a commuter flight to a major airport, and the WIDE2 as the major airport with LOTS of farther away destinations.
? ?If you can get to the major airport without a commuter flight, you are likely to do that, but the commuter flight is not going to get you to your destination.
? There is lots of information on WIDEn-N if you do a web search.? One common spot many groups talk about is?

>It sounds like WIDE1-1, one hop from any node WIDE1
> WIDE1-2, two hops from any node WIDE1

This is just BAD formatting.? The purpose of a WIDE1 DIGI is fill-in, to get the packet to a more effective DIGI.
That would be like using 2 commuter flights and, hoping the second gets you to your destination.
? ?Only thing is that with the commuter flights, you know the their destination.
? ?With a second "fill-in", you get on a another flight, but it won't necessarily get you to your destination, or even be in your intended direction.
> WIDE2-1, one hops from any node set to WIDE2
? ?This is like driving the extra mileage to get to the major airport and taking a direct flight.?
> WIDE2-2, two hops from any node set to WIDE2
? ?This is like driving the extra mileage to get to the major airport and taking a flight with an intermediate stop (probably not even changing planes (hihi).?

Rob Giuliano
Re: Traffic Hording?

 

Well I messaged Joe, KW7JOE, come to find out his gate had been rebooting.

I've been watching that traffic for a while now and now I'm wishing I had said something sooner. Hopefully nothing got damaged, he's troubleshooting it currently to figure out what's going on.
Re: Traffic Hording?

 

Jim,

Ahh, well a faster decode would explain a lot, but I agree, I'll stay with direwolf and if it ends up being he catches most of the traffic because he's decoding faster well then that is that. I'll catch what he doesn't and we'll act as redundancy for the area.

Thanks for looking into that! Yet again I learned something, IE, that Microsat WX3in1's do APRS and will likely decode faster.
Thought; The faster decode might be because there are fewer layers on the Microsat vs running Direwolf on a device with a CPU.
Software vs firmware kind of thing.

Dana Myers,

Nope, my iGate is RX/TX. I never really saw the point of RX only plus we're trying to provide a service to a area that previously had NO service at all. It was a dead zone from North Coeur d'Alene to Canada.

Regarding the ID'ing, copied, understood, I will make the adjustments.
The morse code was to meet FCC requirements but if it's not needed then it's not needed. No point in garbling up the band.

Good to know about iGate behavior regarding TX. I guess that's why filters need to be used, so you're not transmitting everything coming from the APRS-IS

Thanks to all the help in this forum and recommendations I have a filter set for about a 30 mile radius, anything outside that there are other digipeaters and iGates to pickup the traffic.

If anyone has any suggestions for any other tweaks I'm all ears.
Here's the current working config.

ARATE 48000
ADEVICE? plughw:2,0
CHANNEL 0
MYCALL KD7WPQ-10
MODEM 1200 E+
PTT CM108
TXDELAY 20
SLOTTIME 10
PERSIST 63
AGWPORT 0
KISSPORT 8001? <--------- I connect to it from my desktop
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 from KE7MTF and KD7WPQ"
PBEACON sendto=IG delay=0:30 every=10:00 symbol="igate" overlay=T lat=48^18.31N long=116^31.47W
IBEACON delay=0:10 every=30:00 VIA=WIDE1-1 symbol="igate" overlay=T lat=48^18.31N long=116^31.47W
IGFILTER m/48
FILTER d/N7ISP-10 s/->
IGTXLIMIT 6 5
Re: Traffic Hording?

 

On 5/8/2022 8:53 PM, Lynn Deffenbaugh wrote:

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.
Right you are (of course). I *knew* I didn't recall the details of TxGate behavior.
I implemented a standalone DSP TNC + RxGate in an ESP32; when I got to TxGate
behavior, it became more complicated than I wanted to deal with at the time :-)



I have no idea how well? the RxGate code really works.

Thanks es 73,
Dana? K6JQ
Re: Traffic Hording?

 

On 5/9/2022 8:50 PM, Patrick wrote:

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.
If the iGate is mostly just receiving, RF -> APRS-IS, it won't cause a problem
or clog the network (RF network). It's a receiver. I'd be surprised if there's an
issue at the APRS-IS side with the incremental traffic from this iGate.

I don't know what your TX rules are, but as long as your iGate doesn't
transmit, it's not impacting the RF network anyway.

My ping times to noam.aprs2.net is about 83ms.
It doesn't sound like your network performance is a significant factor.
For comparison, my Comcast cable ping time to noam.aprs2.net is ~75mS,
of which the majority (~60mS) is at Level3 in Toronto.

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.
Does the iGate ID every 10 minutes even when it has not transmitted in the last 10 minutes?
For a fixed-location APRS node, you needn't? beacon often, perhaps every 30 minutes.

Also, why Morse ID? That isn't required at all and does create interference to the channel.
I'd suggest turning that off unless you have a specific reason to do it.

73,
Dana
Re: Traffic Hording?

 

Out of curiosity I looked at near by Igates and what was being reported and what device was being used.

On my first installed Igate, it never reports anything from Columbus Ohio, which is about 60 miles to the east. It does report packets from Dayton, which is about 50 miles to the south and Cincinnati, which is close to 90 miles to the south. It also doesn't report much to the north or west, mostly just south. That always seemed odd, but it's located in a farming area, so I didn't worry about it. I just figured there wasn't anything to report.

The devices being used in my area? are mostly Direwolf (mostly located to the south), but there are a few others, as in actual hardware.

The 2 Igates it hears in Columbus are both running hardware, specifically:? Microsat: WX3in1 Plus 2.0. Just so happens that KW7JOE is running the same device. As is one Igate North of my Igate. There are no Microsat's south of my Igates. That would make it appear to me that the Microsat device is faster decoding than Direwolf. If that is correct, that is why KW7JOE is faster on reporting.

Regardless, I am staying with Direwolf rather than buying more hardware.


Jim Bacher, WB8VSU
wb8vsu@...
https:\\
Re: Traffic Hording?

 

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.
Re: Traffic Hording?

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

Re: Traffic Hording?

 

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.
Re: Traffic Hording?

 

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.
Re: Traffic Hording?

 

" ... 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.
Re: Add Bluetooth¡­

 

¿ªÔÆÌåÓý

Yeah, I also have a Samsung Galaxy tablet and a few old Android phones. ?The old phones especially are great for amateur radio stuff.

13 Pro Max

On May 9, 2022, at 11:33 AM, Fred Hillhouse <fmhillhouse@...> wrote:

?

For short money, an Android tablet (or smartphone) works. In addition to my¡± smartphone on a plan¡±, I have other smartphones (without SIMs) that get used as tablets.

?

From: [email protected] [mailto:[email protected]] On Behalf Of J K via groups.io
Sent: Wednesday, May 04, 2022 12:04 PM
To: [email protected]
Subject: Re: [direwolf] Add Bluetooth¡­

?

Indeed! ?Added AX.25 also. ?I¡¯d love to have a packet terminal and WinLink client for iOS. ?I have an Apple developer account and wish I had the entire skill set to put something like that together, but chipping away at it.

?

Have a good one.

?

13 Pro Max



On May 1, 2022, at 11:26 PM, Craig, KM6LYW <craig@...> wrote:

? Completely agreed, direwolf+bluetooth is a great combo, extend it to the ax.25 network stack on the pi as well,

??

cool,
-craig
KM6LYW

On 5/1/22 2:52 PM, J K via groups.io wrote:

?

Anyone add Bluetooth support? ?I have a RPi02W with Fe-Pi audio board and even though have a Moblink TNC3 was thinking about getting a second TNC3, but then thought why not just add BT support to the RPi02W running DireWolf and it¡¯d be basically the same thing.

?



This email has been checked for viruses by Avast antivirus software.


3901 - 3920 of 10461