Re: Configuration for fill-in digipeater / RF <> IS Igate

#259

Andrew,

thanks a lot for getting back to me on this. ?I wasn’t sure if I’d posted correctly and I apologize for not following up. ?After this I checked my setup again and I think I’ve figured out that I had the tx delay on the TNCPI set to short such that even though it was transmitting when my radios heard the “ack” from the Digipeater from a Igated device my radios wouldn’t hear it, they just heard the last part of the transmission I guess. So i got on and programmed a 250ms preamble delay and haven’t had any problems with the outbound transmissions. ?

Great software, I’m deploying this on a popular repeater site to cover the east / central side of phoenix area. ?

Re: Missing lake in front of my house

#258

Hi, Joe.

After much tearing of hair and taking the names of several famous mathematicians in vain :-) I have found a new algorithm for the map importer that fixes your issues on Lake Ontario (and several other places). I'm still resolving some corner cases for Lake Superior and Lake Michigan, but I hope to have them fixed as well in a few days. It's just painful that it takes 20 hours (!) to run the entire planet OSM dataset through the importer so I can check the results. I fixed most of the Lake Ontario issues using a map data excerpt for just the lake and its immediate surrounds, but even that took an hour per run.

Andrew, KA2DDO

Re: Changing Call Sign in YACC

#257

To avoid this issue for other users, I am making a change in the configuration wizard in build 149, such that changing your callsign will check for every port using the old callsign and ask whether you want to update the callsign on those ports. It will also account for SSID changes (even if the callsign doesn't change).

Re: APRS-IS passes weather, RF does not

#256

It turns out I had the delay code already in most of the TNC drivers, but the time units were screwed up, so I didn't calculate enough delay time. Fixing it all for build 149.

Re: APRS-IS passes weather, RF does not

#255

开云体育

That's what I'm planning for the next build. Just a little bit of delay before sending the next packet, and filling in the packet when it is transmitted, rather than when it is queued.

And no problem with using another APRS app better suited for the platform. Even if there wasn't a lack of Java support for the lower-powered processor on the Pi Zero, it's just too undersized to handle all of YAAC's graphical UI. And a remote station doesn't really need a graphical UI anyway.

Andrew, KA2DDO

author of YAAC

Show quoted text

-------- Original message --------
From: Bill WA4OPQ <wa4opq@...>
Date: 4/22/20 17:14 (GMT-05:00)
To: [email protected]
Subject: Re: [yaac-users] APRS-IS passes weather, RF does not

I'll always be a YAAC enthusiast, but for a remote wx station I'll probably use aprx on a pi zero.? By copying the weather format from YAAC I've got it sending positionless weather packets and using the digipeater symbol.??

It has a weather packet every ten minutes and a position packet every 30 minutes.

So there is no reason (that I can see) that YAAC has to immediately send the weather packet following the position packet. It appears that any reasonable delay is possible.

Re: APRS-IS passes weather, RF does not

#254

I'll always be a YAAC enthusiast, but for a remote wx station I'll probably use aprx on a pi zero.? By copying the weather format from YAAC I've got it sending positionless weather packets and using the digipeater symbol.??

It has a weather packet every ten minutes and a position packet every 30 minutes.

So there is no reason (that I can see) that YAAC has to immediately send the weather packet following the position packet. It appears that any reasonable delay is possible.

Re: No mobile APRS in YAAC

#253

Ok, thanks!
I’ve not understand it in the mail before.

Thanks!

Elia, IU2JWM

Show quoted text

Il giorno 22 apr 2020, alle ore 18:48, Andrew P. <andrewemt@...> ha scritto:

Again, the reason you're not seeing the iPhone in YAAC is that:

1. No I-gate station (including yourself) is going to transmit it to RF because the iPhone isn't sending any packets meeting rule#1 or rule#2 (position _after_ a rule#1 text message).

2. The APRS-IS backbone won't send it to your local station because of the same rules, since you are not specifying a filter to cause additional packets to be forwarded that don't meet rule#1 and rule#2.

Basically, if you want to monitor traffic on the APRS-IS (instead of just being a minimal-traffic I-gate), you have to specify a APRS-IS port filter expression to include the additional traffic. Note that YAAC does implement the I-gate rules, so it won't forward to RF unnecessary extra Internet traffic caused by filters unless you also specify a supplemental Tx I-gate filter.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Elia Origoni <elia.origoni@...>
Sent: Wednesday, April 22, 2020 12:17 PM
To: [email protected]
Subject: Re: [yaac-users] No mobile APRS in YAAC

Hi,
Is a digipiter plus I-Gate configured in wide1-1.
I have the pi-tnc interface and APRS-IS interface.
I don’t want to repeat my smartphone beacon trough RF.
I only want to understand why I don’t see the beacon icon of my smartphone on the map in YAAC…with all filter disabled, I don’t have to see the same things that I can see on aprs.fi<>?

Elia, IU2JWM

Il giorno 22 apr 2020, alle ore 14:59, Andrew P. <andrewemt@...<mailto:andrewemt@...>> ha scritto:

First off, is your digipeater a digipeater-plus-I-gate, or just a digipeater? Since your iPhone is not a transmitter on ham bands, the only way your Internet-originated APRS packets are going to get to amateur-band RF is via somebody's transmit-capable I-gate. If you don't have a transmit-capable I-gate in the neighborhood, no one is going to put your Internet packets on RF.

Secondly, I-gates (and the APRS-IS backbone servers) have some logic within them to keep from flooding the local RF channel with excess traffic. Unless explicitly configured otherwise at the I-gate, traffic will not be sent from the Internet to the I-gate for retransmission on RF unless:

1. the APRS packet is a text message addressed to an RF station reported to the backbone as being heard by that particular I-gate.
2. the APRS packet is a position report from an Internet-relayed station that has just sent a text message meeting rule#1 (so the text message recipient can see where the message sender is located).

This is what keeps transmit-capable I-gates from saturating the RF channel with spurious traffic.

And the APRS-IS does not know that a connected station is _not_ an I-gate. If it is connected to APRS-IS, then it will be treated like an I-gate, and therefore the rules for sending traffic to an I-gate apply in every backbone server. Traffic is only forwarded to the connected station if rule#1, rule#2, or an explicit filter specification would pass the traffic. And a proper I-gate should enforce the rules too, in case somebody floods the APRS-IS with spurious traffic, or a filter is specified on the connection to APRS-IS. This is why YAAC has the supplemental filter to force additional traffic to RF (above and beyond rule#1 and rule#2 traffic); this capability should be used very carefully and cautiously, as the the RF channel doesn't have much bandwidth.

So, send more than just a beacon from your iPhone. Remember, one of the fundamental regulations of amateur radio is that it is two-way communications. Telemetry is an allowed but secondary purpose of amateur radio.

Andrew, KA2DDO
author of YAAC

Re: No mobile APRS in YAAC

#252

Again, the reason you're not seeing the iPhone in YAAC is that:

1. No I-gate station (including yourself) is going to transmit it to RF because the iPhone isn't sending any packets meeting rule#1 or rule#2 (position _after_ a rule#1 text message).

2. The APRS-IS backbone won't send it to your local station because of the same rules, since you are not specifying a filter to cause additional packets to be forwarded that don't meet rule#1 and rule#2.

Basically, if you want to monitor traffic on the APRS-IS (instead of just being a minimal-traffic I-gate), you have to specify a APRS-IS port filter expression to include the additional traffic. Note that YAAC does implement the I-gate rules, so it won't forward to RF unnecessary extra Internet traffic caused by filters unless you also specify a supplemental Tx I-gate filter.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Elia Origoni <elia.origoni@...>
Sent: Wednesday, April 22, 2020 12:17 PM
To: [email protected]
Subject: Re: [yaac-users] No mobile APRS in YAAC

Hi,
Is a digipiter plus I-Gate configured in wide1-1.
I have the pi-tnc interface and APRS-IS interface.
I don’t want to repeat my smartphone beacon trough RF.
I only want to understand why I don’t see the beacon icon of my smartphone on the map in YAAC…with all filter disabled, I don’t have to see the same things that I can see on aprs.fi<>?

Elia, IU2JWM

Il giorno 22 apr 2020, alle ore 14:59, Andrew P. <andrewemt@...<mailto:andrewemt@...>> ha scritto:

First off, is your digipeater a digipeater-plus-I-gate, or just a digipeater? Since your iPhone is not a transmitter on ham bands, the only way your Internet-originated APRS packets are going to get to amateur-band RF is via somebody's transmit-capable I-gate. If you don't have a transmit-capable I-gate in the neighborhood, no one is going to put your Internet packets on RF.

Secondly, I-gates (and the APRS-IS backbone servers) have some logic within them to keep from flooding the local RF channel with excess traffic. Unless explicitly configured otherwise at the I-gate, traffic will not be sent from the Internet to the I-gate for retransmission on RF unless:

1. the APRS packet is a text message addressed to an RF station reported to the backbone as being heard by that particular I-gate.
2. the APRS packet is a position report from an Internet-relayed station that has just sent a text message meeting rule#1 (so the text message recipient can see where the message sender is located).

This is what keeps transmit-capable I-gates from saturating the RF channel with spurious traffic.

And the APRS-IS does not know that a connected station is _not_ an I-gate. If it is connected to APRS-IS, then it will be treated like an I-gate, and therefore the rules for sending traffic to an I-gate apply in every backbone server. Traffic is only forwarded to the connected station if rule#1, rule#2, or an explicit filter specification would pass the traffic. And a proper I-gate should enforce the rules too, in case somebody floods the APRS-IS with spurious traffic, or a filter is specified on the connection to APRS-IS. This is why YAAC has the supplemental filter to force additional traffic to RF (above and beyond rule#1 and rule#2 traffic); this capability should be used very carefully and cautiously, as the the RF channel doesn't have much bandwidth.

So, send more than just a beacon from your iPhone. Remember, one of the fundamental regulations of amateur radio is that it is two-way communications. Telemetry is an allowed but secondary purpose of amateur radio.

Andrew, KA2DDO
author of YAAC

Re: No mobile APRS in YAAC

#251

开云体育

Hi,

Is a digipiter plus I-Gate configured in wide1-1.

I have the pi-tnc interface and APRS-IS interface.

I don’t want to repeat my smartphone beacon trough RF.

I only want to understand why I don’t see the beacon icon of my smartphone on the map in YAAC…with all filter disabled, I don’t have to see the same things that I can see on ?

Elia, IU2JWM

Show quoted text

Il giorno 22 apr 2020, alle ore 14:59, Andrew P. <andrewemt@...> ha scritto:

First off, is your digipeater a digipeater-plus-I-gate, or just a digipeater? Since your iPhone is not a transmitter on ham bands, the only way your Internet-originated APRS packets are going to get to amateur-band RF is via somebody's transmit-capable I-gate. If you don't have a transmit-capable I-gate in the neighborhood, no one is going to put your Internet packets on RF.

Secondly, I-gates (and the APRS-IS backbone servers) have some logic within them to keep from flooding the local RF channel with excess traffic. Unless explicitly configured otherwise at the I-gate, traffic will not be sent from the Internet to the I-gate for retransmission on RF unless:

1. the APRS packet is a text message addressed to an RF station reported to the backbone as being heard by that particular I-gate.
2. the APRS packet is a position report from an Internet-relayed station that has just sent a text message meeting rule#1 (so the text message recipient can see where the message sender is located).

This is what keeps transmit-capable I-gates from saturating the RF channel with spurious traffic.

And the APRS-IS does not know that a connected station is _not_ an I-gate. If it is connected to APRS-IS, then it will be treated like an I-gate, and therefore the rules for sending traffic to an I-gate apply in every backbone server. Traffic is only forwarded to the connected station if rule#1, rule#2, or an explicit filter specification would pass the traffic. And a proper I-gate should enforce the rules too, in case somebody floods the APRS-IS with spurious traffic, or a filter is specified on the connection to APRS-IS. This is why YAAC has the supplemental filter to force additional traffic to RF (above and beyond rule#1 and rule#2 traffic); this capability should be used very carefully and cautiously, as the the RF channel doesn't have much bandwidth.

So, send more than just a beacon from your iPhone. Remember, one of the fundamental regulations of amateur radio is that it is two-way communications. Telemetry is an allowed but secondary purpose of amateur radio.

Andrew, KA2DDO
author of YAAC

Re: No mobile APRS in YAAC

#250

First off, is your digipeater a digipeater-plus-I-gate, or just a digipeater? Since your iPhone is not a transmitter on ham bands, the only way your Internet-originated APRS packets are going to get to amateur-band RF is via somebody's transmit-capable I-gate. If you don't have a transmit-capable I-gate in the neighborhood, no one is going to put your Internet packets on RF.

Secondly, I-gates (and the APRS-IS backbone servers) have some logic within them to keep from flooding the local RF channel with excess traffic. Unless explicitly configured otherwise at the I-gate, traffic will not be sent from the Internet to the I-gate for retransmission on RF unless:

1. the APRS packet is a text message addressed to an RF station reported to the backbone as being heard by that particular I-gate.
2. the APRS packet is a position report from an Internet-relayed station that has just sent a text message meeting rule#1 (so the text message recipient can see where the message sender is located).

This is what keeps transmit-capable I-gates from saturating the RF channel with spurious traffic.

And the APRS-IS does not know that a connected station is _not_ an I-gate. If it is connected to APRS-IS, then it will be treated like an I-gate, and therefore the rules for sending traffic to an I-gate apply in every backbone server. Traffic is only forwarded to the connected station if rule#1, rule#2, or an explicit filter specification would pass the traffic. And a proper I-gate should enforce the rules too, in case somebody floods the APRS-IS with spurious traffic, or a filter is specified on the connection to APRS-IS. This is why YAAC has the supplemental filter to force additional traffic to RF (above and beyond rule#1 and rule#2 traffic); this capability should be used very carefully and cautiously, as the the RF channel doesn't have much bandwidth.

So, send more than just a beacon from your iPhone. Remember, one of the fundamental regulations of amateur radio is that it is two-way communications. Telemetry is an allowed but secondary purpose of amateur radio.

Andrew, KA2DDO
author of YAAC

No mobile APRS in YAAC

#249

Goodmorning,
I have a Digipeater on raspberry pi and pi-TNC.
all works fine, except this thing:
if I send a beacon from my iPhone with APRS.fi app, I can see it on APRS.fi website, but not on YAAC.
I have no filters enabled.
why?
Elia IU2JWM

Re: Pi and mobilinkd

#248

开云体育

I'm not sure. I've only tested the Bluetooth plugin on Microsoft Windows and Debian Linux (Intel processors). So I don't know which Pi processors the ARM native library will work on.

Please, try it on any Pi version you want, and let me know if it does or doesn't work so I can update the documentation.

Andrew, KA2DDO

Show quoted text

-------- Original message --------
From: Jeremy West <ticfifty@...>
Date: 4/16/20 17:38 (GMT-05:00)
To: [email protected]
Subject: Re: [yaac-users] Pi and mobilinkd

You said you don't know if the second option would work for pi 4, do you know if it would for the pi 3? It sounds like the second option you gave me would be the more stable if I can make that work would you agree?

On Thu, Apr 16, 2020, 7:15 AM Andrew P. <andrewemt@...> wrote:

Greetings.

You have two options here.

If you bind the Mobilinkd TNC to your Pi using their Bluetooth drivers, you can use the Serial_TNC port type. However, if you have Bluetooth connectivity dropouts, this may hang or crash YAAC.

Another option is to use the Bluetooth plugin for YAAC and thereby let YAAC manage the Bluetooth connection (and deal with flakiness thereof) with the Bluetooth_TNC port type. It has a limited set of native libraries, so I'm not sure if the included armv5 library will work on a Pi4, but you can try it. No guarantees; I don't own that particular hardware, so I can't test it.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Re: Pi and mobilinkd

#247

You said you don't know if the second option would work for pi 4, do you know if it would for the pi 3? It sounds like the second option you gave me would be the more stable if I can make that work would you agree?

Show quoted text

On Thu, Apr 16, 2020, 7:15 AM Andrew P. <andrewemt@...> wrote:

Greetings.

You have two options here.

If you bind the Mobilinkd TNC to your Pi using their Bluetooth drivers, you can use the Serial_TNC port type. However, if you have Bluetooth connectivity dropouts, this may hang or crash YAAC.

Another option is to use the Bluetooth plugin for YAAC and thereby let YAAC manage the Bluetooth connection (and deal with flakiness thereof) with the Bluetooth_TNC port type. It has a limited set of native libraries, so I'm not sure if the included armv5 library will work on a Pi4, but you can try it. No guarantees; I don't own that particular hardware, so I can't test it.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Re: Pi and mobilinkd

#246

Greetings.

You have two options here.

If you bind the Mobilinkd TNC to your Pi using their Bluetooth drivers, you can use the Serial_TNC port type. However, if you have Bluetooth connectivity dropouts, this may hang or crash YAAC.

Another option is to use the Bluetooth plugin for YAAC and thereby let YAAC manage the Bluetooth connection (and deal with flakiness thereof) with the Bluetooth_TNC port type. It has a limited set of native libraries, so I'm not sure if the included armv5 library will work on a Pi4, but you can try it. No guarantees; I don't own that particular hardware, so I can't test it.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Pi and mobilinkd

#245

Hello, I am trying to make a mobinkd tnc2 work with a raspberry pi 4 running YAAC. I am fairly new to both APRS and raspberry pi (linux)? can you please help?me with this?

Thanks?

73's

Jeremy West?

W7TIC

Re: Coordinates and station location in the map

#244

Thank you Andrew.? That explains that I am entering the wrong format.? I was confused with the DDD MM.SS with DDD MM.mm.? Now entered the DDD MM.mm and it is now in the right location.

I have another question but that will be in another thread perhaps.

Best regards,

Maximo, DU2UXH

Re: Changing Call Sign in YACC

robert nazro

#243

Spot on. Thanks.?

Show quoted text

On Wed, Apr 15, 2020 at 11:22 AM Andrew P. <andrewemt@...> wrote:

The callsigns are not for the station as a whole, but for each APRS communications port (Serial_TNC, APRS-IS, etc.). The reason the old callsign keeps showing up in the wizard is because you didn't change the callsign on each existing port, so that old callsign comes back when the wizard comes up with a default callsign for creating new ports.

Click on the RF and IP buttons above the map; those will bring up the editing panels for each of those ports so you can fix the callsigns on them.

Hope this helps.

Andrew, KA2DDO
author of YAAC

--

Bob Nazro, W1RPQ

Re: Changing Call Sign in YACC

#242

The callsigns are not for the station as a whole, but for each APRS communications port (Serial_TNC, APRS-IS, etc.). The reason the old callsign keeps showing up in the wizard is because you didn't change the callsign on each existing port, so that old callsign comes back when the wizard comes up with a default callsign for creating new ports.

Click on the RF and IP buttons above the map; those will bring up the editing panels for each of those ports so you can fix the callsigns on them.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Changing Call Sign in YACC

robert nazro

#241

I have a new call sign and want to update YACC, but every time I change it with the wizzard it keeps the original call sign. Is there a way to do this without a complete reload? Thanks.

Re: Missing lake in front of my house

#240

Hi Andrew

Thanks for this.? I do not mean to sound ungrateful by any means.? I think you are doing a great job in creating and supporting YAAC.? It has a lot of great features and is very simple to use,? I gather then that mapping is not a trivial exercise and I should have realized this!? I look forward to future releases.

Joe VA3JLF