There is an option on the View->Map Layers submenu to enable or disable color-coded circles around stations to indicate their Mic-E status (if any). The View help file explains all the colors. Solid-border circle around the icon indicates standard Mic-E statuses, and dashed circles indicate the custom statuses.

________________________________________
From: [email protected] <[email protected]> on behalf of Paul Bramscher <pfbram@...>
Sent: Thursday, October 8, 2020 10:09 PM
To: [email protected]
Subject: Re: [yaac-users] Golden crosshairs

Hi Andrew--

Thanks for the explanation -- and the great program! I believe his
color was orange, but he was just sending ordinary messages so I didn't
see the significance based on his content.

The International Space Station's digipeater recently (finally) went
back on-air and I used YAAC to send a couple packets up earlier today.
So I've switched from terrestrial to space RX today, which is just a
matter of switching my YAAC profiles.

The ISS recently installed a new Kenwood D710 for APRS and I'm told will
soon be installing another for voice/FM. They were testing voice for a
few weeks, but APRS is now back on-air.

73, KD0KZE / Paul

On 10/8/2020 8:52 PM, Andrew P. wrote:

Flashing crosshairs mean the following (based on the color):
red - station reporting emergency status
orange - station reporting Mic-E priority status (way too many of those)
yellow - station reporting Mic-E special status and such display is enabled in the expert-mode Behavior settings
green - station or APRS Object/Item that was requested to be located by Locate->Station menu choice is at crosshair

I'm updating the help files for the next build to better document this.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Paul Bramscher <pfbram@...>
Sent: Thursday, October 8, 2020 8:54 PM
To: [email protected]
Subject: [yaac-users] Golden crosshairs

Greetings--

I normally use YAAC unattended for RX/gating, or for satellite APRS.
Since the ISS digipeater was turned off for several weeks and I've been
working at home due to covid, I noticed a particular station within my
local Aloha Circle who had some flashing "golden crosshairs" over his
QTH. I searched the docs, but didn't turn up the meaning. What does
this indicate?

Thanks,
73, KD0KZE / Paul

开云体育

Thanks Andrew!

73, de KM4ACK

next beta build#158 of YAAC ("Yet Another APRS Client"), created 2020-Oct-13

downloadable from
or

changes and updates include:
1. fix incorrect dependencies in pom.xml files.
2. prevent error upon receiving OpenTRAC packet with an undocumented
zero-length OpenTRAC element.
3. accelerate OpenStreetMap importing of PBF files.
4. add -version command-line option to print the version of YAAC to
standard output and then terminate. Also -version:all to print
out versions of all plugins in use. This is to support KM4ACK's
Raspberry Pi scripts.
5. eliminate bounding box parameters for OpenStreetMap import, as it
is much more efficient to use a pre-bounded input file instead of
skipping over unwanted parts of a full planet file.
6. fix help index exporter so website's copy of YAAC help files will
indicate for what build the help is for.
7. stop cluttering map with marine nodes at outer zoom levels.
8. don't require DSR signal on Serial_TNC ports when using hardware
flow control on a Kenwood radio (since Kenwood didn't put the
DSR wire in the PG-5H programming cable). Requires selecting the
Kenwood work-around as well when selecting hardware flow control.
9. document issues with gpsd switching GPS receivers to proprietary
binary mode instead of NMEA-0183 ASCII mode.
10. document Linux kernel filesystem caching issues associated with
the OpenStreetMap importer.

Hi Andrew--

Thanks for the explanation -- and the great program! I believe his
color was orange, but he was just sending ordinary messages so I didn't
see the significance based on his content.

The International Space Station's digipeater recently (finally) went
back on-air and I used YAAC to send a couple packets up earlier today.
So I've switched from terrestrial to space RX today, which is just a
matter of switching my YAAC profiles.

The ISS recently installed a new Kenwood D710 for APRS and I'm told will
soon be installing another for voice/FM. They were testing voice for a
few weeks, but APRS is now back on-air.

73, KD0KZE / Paul

Flashing crosshairs mean the following (based on the color):
red - station reporting emergency status
orange - station reporting Mic-E priority status (way too many of those)
yellow - station reporting Mic-E special status and such display is enabled in the expert-mode Behavior settings
green - station or APRS Object/Item that was requested to be located by Locate->Station menu choice is at crosshair

I'm updating the help files for the next build to better document this.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Paul Bramscher <pfbram@...>
Sent: Thursday, October 8, 2020 8:54 PM
To: [email protected]
Subject: [yaac-users] Golden crosshairs

Greetings--

I normally use YAAC unattended for RX/gating, or for satellite APRS.
Since the ISS digipeater was turned off for several weeks and I've been
working at home due to covid, I noticed a particular station within my
local Aloha Circle who had some flashing "golden crosshairs" over his
QTH. I searched the docs, but didn't turn up the meaning. What does
this indicate?

Thanks,
73, KD0KZE / Paul

Greetings--

I normally use YAAC unattended for RX/gating, or for satellite APRS.
Since the ISS digipeater was turned off for several weeks and I've been
working at home due to covid, I noticed a particular station within my
local Aloha Circle who had some flashing "golden crosshairs" over his
QTH. I searched the docs, but didn't turn up the meaning. What does
this indicate?

Thanks,
73, KD0KZE / Paul

In the past I realized to contact them was a waste of time, some don't understand. I just wanted to stop digipeating, like: a Weather station transmitting every 3 minutes using WIDE1-1,WIDE2-1.

And VE2PCQ-3 have a big coverage ;).
I try APRSISCE/32, but many user wanted a Blacklist, but there is not.

So I'm testing YAAC, I'm new with this one.

--

YAAC's assumption for blacklisting is that you don't want to propagate the blacklisted station's traffic _anywhere_ (such as a station transmitting illegal traffic that you don't want to get blamed for forwarding). So, such stations' traffic doesn't get repeated through any port in YAAC (RF or Internet).

If you don't want to digipeat such traffic to RF, I'm not sure why you would still want to clutter the APRS-IS backbone with the traffic, as some other Tx I-gate might feel obliged to retransmit it to RF. In any case, YAAC doesn't have per-port blacklisting.

You might be able to adjust your digipeat alias lists on your RF ports to exclude the alias the offending station is using (i.e., only do WIDE2-n if the offender is doing WIDE1-1,WIDE2-1 and you are the first hop).

That is annoying that your offenders are over the normal duplicate suppression threshold (30 seconds) so that alternate packets from them wouldn't be dropped anyway. Perhaps I should look into the option of configurably raising that threshold; on the other hand, the offenders could easily work around that by simply putting a variable field (i.e., serial number) into the packet body so consecutive packets aren't duplicates.

Have you tried to contact the station operators to suggest they slow their packet rates?

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Pascal Charette
Sent: Wednesday, October 7, 2020 1:43 PM
To: [email protected]
Subject: [yaac-users] BlackList

Filter Blacklist work perfectly to stop digipeating fixed stations using 2 hop every 2 minutes.

But would be nice when SSID is in Blacklist get i-Gate to APRS-IS.

Because when SSID is in BlackList, it is completely ignored.

Is there a way to do it?

ve2pcq

Filter Blacklist work perfectly to stop digipeating fixed stations using 2 hop every 2 minutes.

But would be nice when SSID is in Blacklist get i-Gate to APRS-IS.

Because when SSID is in BlackList, it is completely ignored.

Is there a way to do it?

ve2pcq

Andrew,

Thank you for the clear explanation! I knew I was missing something. :-)

I have the filter configured on the APRS-IS port and now it's working the way I want.

73, Mark

No, this is a feature designed to support the proper operation of the APRS-IS with the local RF channel. When you have both an RF port (AGWPE) and an APRS-IS port open, YAAC assumes (until you configure it otherwise) that you plan on running a normal Tx-I-gate. By default, the only packets sent to an APRS-IS client by the backbone are text message packets addressed to stations that the client has forwarded to the backbone, or position packets for stations that have just sent qualifying text messages, because that is all the client should be Tx-I-gating to RF. (Note the backbone does not understand the concept of a receive-only I-gate; it treats all clients the same).

If you want additional traffic from the APRS-IS backbone, you will have to specify an APRS-IS server filter expression on the APRS-IS port to have filter-matching extra traffic forwarded from the backbone. Note that YAAC implements the proper Tx-I-gate algorithms, so such extra traffic will not be sent on to the local RF channel unless you specify yet another filter for supplemental Tx I-gate transmissions (highly _not_ recommended).

For the convenience of new users, when YAAC is configured with _only_ an APRS-IS port (no RF ports), if and only if the user doesn't specify an explicit APRS-IS server filter expression on the port, a default filter expression (a range of 100 kilometers around the beacon fixed latitude and longitude position) is implicitly created so the user will see some traffic. This default filter is _not_ implicitly used if you have an RF port. And if you have an explicit filter expression, the default filter is not added to it.

Hope this helps explain the "drop" in Internet traffic since you hooked up your radio.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Mark via groups.io
Sent: Thursday, October 1, 2020 12:24 PM
To: [email protected]
Subject: [yaac-users] APRS-IS packets not received when RF/AGWPE port enabled

Hi,

I'm a new user to YAAC and I'm experiencing a strange problem where YAAC (version 1.0-beta157 running on Windows 10 Pro x64) will not receive APRS-IS packets when a RF (AGWPE) port is enabled. When I first setup the program (gone through several cycles of using the -clear flag to try reinstall and finally figured it out how to replicate the issue) stations appear on my map, but they all eventually expire once I enable AGWPE. By disabling the AGWPE port, the APRS-IS packets start being received again. The strange thing is YAAC is still sending data to APRS-IS while the AGWPE port is enabled as I can see my station updates on aprs.fi. Is this intended behavior or am I doing something wrong to show both RF and APRS-IS data on the map?

Thanks,

Mark

Hi,

I'm? a new user to YAAC and I'm experiencing a strange problem where YAAC (version?1.0-beta157 running on Windows 10 Pro x64) will not receive?APRS-IS packets when a RF (AGWPE) port is enabled. When I first setup the program (gone through several cycles of using the -clear flag to try reinstall and finally figured it out how to replicate the issue) stations appear on my map, but they all eventually expire once I enable AGWPE. By disabling the AGWPE port, the APRS-IS packets start being received again.?The strange thing is YAAC is still sending data to?APRS-IS while the AGWPE port is enabled?as I can see my station updates on aprs.fi. Is this intended behavior or am I doing something wrong to show both RF and APRS-IS data on the map?

Thanks,

Mark

Yeah, I had thought about doing that but was hoping to not do that since YAAC seemed to be doing what I wanted (and more).

Thanks,
Eric




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

No, I never set up the aprssisserver plugin to allow transmissions from the 2nd-order clients, because I don't have the passcode validation logic in the plugin to try to ensure such a 2nd-order client is legitimate (not that that means much these days).

If you want to do something like that, I recommend using a real APRS-IS server package that can also talk to your TNCs, such as the javAPRSsrvr program, and then have both your home-station YAAC and your laptop both connect to it.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Eric H. Christensen via groups.io <eric@...>
Sent: Monday, September 28, 2020 11:52 AM
To: [email protected]
Subject: [yaac-users] YAAC aprsisserver

I'm running the YAAC aprsisserver plugin at my home station that is connected to 2m and IS (among other things). My laptop (-1) is roaming around my house and is connected to the home station over the LAN in my house (using port 14580). The expectation I had was that my home station would "see" -1 and relay messages and such over RF and IS, as appropriate, that I send from that station. When I look at my home station, though, I don't even see -1 nor any of the packets coming from that station. -1 sees the home station, though.

Do I have something setup incorrectly?

73,
Eric WG3K

I'm running the YAAC aprsisserver plugin at my home station that is connected to 2m and IS (among other things). My laptop (-1) is roaming around my house and is connected to the home station over the LAN in my house (using port 14580). The expectation I had was that my home station would "see" -1 and relay messages and such over RF and IS, as appropriate, that I send from that station. When I look at my home station, though, I don't even see -1 nor any of the packets coming from that station. -1 sees the home station, though.

Do I have something setup incorrectly?

73,
Eric WG3K

After trying a lot of options, I believe I know where the problem is: The TNC-Pi9k6 as it communicates with YAAC.? I finally got it to be accepted by YAAC as a serial device on /dev/ttyS0.? But with YAAC, there was no communication.? That is, no packets were sent or received.? I switched the TNC-Pi for the TNC-Pi9k6, and it worked.? Frustratingly, either TNC works fine with PiGate RMS or XASTIR.? There must be something awry with the communication protocols of the TNC-Pi9k6 that prevents it from working with YAAC.

Since my motivation for getting the TNC-Pi9k6 was as a backup for the TNC-Pi as used with PiGate RMS, I will leave my arrangement of the parts so that everything works as they are configured.? Not ideal, but I can live with it.

开云体育

Hi Again.

Well, that would seem to point to something OS or settings related that's getting in the way.

Sadly not having that hardware (hat) I can't hope to replicate the same issue to help debug it.? Sorry.

I do notice from reading the TNC-Pi9k6 manual ? ?? that you do not use regular TNC type commands to control it.? (I presume you have downloaded and are using the two configuration manipulation software tools that come in the zipfile??? ? )

In fact, other than a few configuration notes, the overall command structure and usage is somewhat undocumented.? I cant even tell if it is supposed to be a KISS type of TNC!

That and YAAC 1.0-beta157 doesn't list the TNC-Pi9k6 as a serial port TNC option, or the TNC-x that it appears to have been derived from.

It also appears to be verging on being an abandoned product, as MFJ cloned the TNC-x, while the prospect of new kits etc are unlikely due (it seems, a bit of a lame excuse) to the need to use SMD parts for any future versions.)

You could try asking at:-?? /search?q=RaspberryPi-4-HamRadio

Or reaching out to it's creator:-? John Hansen, W2FS at john@...? As mentioned at the end of the document above.

Hope you find a solution, when you do, I suspect others would like to know.? Me too, just out of curiosity.

73.

Dave G8KBV

From: Bill AA6BD
Date: Thu, 24 Sep 2020 14:42:08 PDT

I installed Xastir on the same Raspberry Pi.? I prefer YAAC because it is more intuitive to me, and the maps are nicer.??
I configured an interface (xastir port) and chose Serial KISS TNC with the port of /dev/ttyS0 and it was marked as "UP."? I was able to use Xastir to transmit on the port, and I saw the red LED flash on the TNC, so I believe it worked.

What do I need to change on YAAC so it will use the serial KISS TNC /dev/ttyS0?

-- 
Created on and sent from a Unix like PC running and using free and open source software:

I loaded YAAC-157 onto my Raspberry Pi running Buster to replace YAAC-152 and without changing anything, it nicely connected with the TNC-Pi9k6 including receiving and transmitting.? Therefore, I would guess that there is something in Raspberry Pi OS Stretch that interferes with it supporting YAAC to connect with the serial port /dev/ttyS0.? Note that in Buster, the serial port shows as /dev/ttyAMA0 but the user notes I found from WVCARC who makes the TNC-Pi9k6, and from John Hansen who had made it before he retired, all working with John Wiseman who designed the card, said that this change had occurred with Stretch.

If there is anything I can to to help with this, including testing, please let me know.