Andrew, as always, you are my hero. I can't get to the Desktop file right now, but I do know your sample has more lines than mine, so that will probably fix it.

The explanation of the ports storing that data makes sense. And, yes, at the time I had not yet created the radio port as I was still researching how to configure that for the TNC-Pi. Of course after I did set the port up, when I hooked up my handheld to test things, its RF got into the RPi and scrambled the SD card so now I must start over from scratch.

I should have made notes when I set up the SD card before. Now I've got to find all those configuration steps for the different boards, etc. This CRS thing is a pain.

Thanks again,
Michael WA7SKG


Andrew P. wrote on 2/22/20 9:40 AM:

Regarding your two questions:

1. Bear in mind that the Raspberry Pi desktop manager is not the Cinnamon desktop manager typical of Linux Mint, so its desktop shortcut files are likely to be different. You'll need to check with how desktop files are created on the Pi. For example, this is the contents of the yaac.desktop file provided by NW Digital Radio on their DRAWS image of Raspbian (which pre-installs DireWolf, Xastir, and YAAC):

[Desktop Entry]
Name=YAAC
Exec=/usr/bin/java -jar /home/pi/YAAC/YAAC.jar -gui:small
Comment=Yet Another APRS Client
Icon=/home/pi/YAAC/images/yaaclogo64.ico
Path=/home/pi/YAAC
Terminal=true
Type=Application
Categories=HamRadio
Keywords=Ham Radio;APRS Client;KISS;AGWPE;AX.25

2. Your callsign and SSID are stored on your individual ports in YAAC that send and receive AX.25 packets (or the APRS-IS equivalent). This is because cross-band digipeaters are required to have a unique callsign-SSID for each RF port of the same station, to support packet routing. (Note that it is expected that your APRS-IS port callsign-SSID will be the same as your primary RF port on an I-gate station.) As such, if you don't have any such packet-exchanging ports, your callsign won't be remembered. So, does your configuration contain any ports of type Serial_TNC, AGWPE, KISSoverTCP, Bluetooth_TNC, Kenwood, Yaesu, File_TNC, APRS-IS, or SSL-APRS-IS? If it doesn't, then you are not storing your callsign-SSID anywhere. And, since YAAC is an APRS application, it considers your configuration to be incomplete if you don't have at least one of those port types configured (as in, how are you going to display APRS data if you don't have anyplace to get packets from?).

Hope this helps.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Michael WA7SKG <wa7skg@...>
Sent: Saturday, February 22, 2020 12:05 PM
To: [email protected]
Subject: [yaac-users] YAAC Launch Problem and Not Remembering Configuration

I'm setting up YAAC on a Raspberry Pi and have run into two issues
(so far).

1. I created a desktop launcher for YAAC, identical to what is on my
Mint machine. When I double click on it, I get a window saying something
like "This is an executable file, what do you want to do?" then gives
options of Execute, Execute in Terminal, Open, Cancel. I do not get this
on my Mint machine. Anyway around this?

2. When I open YAAC, it takes me into the configuration page. It does
not remember my call or SSID choice. After entering that and moving to
the next screen, it does remember my icon choice and pretty much
everything after that. Any ideas what that problem might be? Again, this
did not happen on my Mint machine for my base station, only the
Raspberry Pi.

tnx es 73,
Michael WA7SKG

I'm setting up YAAC on a Raspberry Pi and have run into two issues
(so far).

1. I created a desktop launcher for YAAC, identical to what is on my Mint machine. When I double click on it, I get a window saying something like "This is an executable file, what do you want to do?" then gives options of Execute, Execute in Terminal, Open, Cancel. I do not get this on my Mint machine. Anyway around this?

2. When I open YAAC, it takes me into the configuration page. It does not remember my call or SSID choice. After entering that and moving to the next screen, it does remember my icon choice and pretty much everything after that. Any ideas what that problem might be? Again, this did not happen on my Mint machine for my base station, only the Raspberry Pi.

tnx es 73,
Michael WA7SKG

the serial port can be used for a wx station ( PORT 1 ) and for KISS ( PORT 2 )? as it is 2 ports on one connector ..I did have the KISS port working with XASTIR....Im trying to get away from XASTIR..Linux isn't my strong point.

KISS over TCP is not bi- directional and will only RX.

and yes I agree that the information is limited.and needs to be a bit more specific regardiing certain functions of th WX3in1

According to the documentation on the Microsat website, the KISS (and APRS-IS simple server) ports are only available over TCP/IP (the Ethernet connection), not via the serial ports reserved for weather stations and GPS receivers.

So you would use the KISS-over-TCP port type to connect to the documented port number (I don't know the exact number, but I'm guessing port 8001 because that's what DireWolf and AGWPE use) at whatever IP address is assigned to the WX3in1 on your LAN. Alternatively, you could use the APRS-IS port type to connect to the "simple server" port just as if you were connecting directly to the APRS-IS backbone.?

Hopefully, the Microsat author would be able to provide more specific information.

Andrew, KA2DDO
author of YAAC

Any success in trying to get YAAC to display packets received when interfaced with a Microsat WX3in1 2.0?

The device is in KISS mode, and I have the port type in? YAAC set as a serial TNC , with the correct COM port and baudrate.

Thanks
?Chris

Digipeat paths are irrelevant when relaying through the backbone. Each transmit-capable I-gate makes its own decision as to what digipeat path will be used for forwarded-from-Internet packets; most choose no digipeat path at all so that only RF stations directly reachable by the I-gate will hear the transmitted packets. And the original digipeat path is buried in the 3rd-party header of the packet body, so will never be processed by digipeaters after the I-gate returns it to RF.

________________________________________
From: [email protected] <[email protected]> on behalf of Peter Dakota Summerhawk <peter.summerhawk@...>
Sent: Sunday, February 9, 2020 6:45 PM
To: [email protected]
Subject: Re: [yaac-users] Sending messages without RF

Andrew,
Yep connected to the noam.aprs2.net aprsis server with password as I get the reports coming in from the net. I was curious as to drop down I have is TEMP1-1, TEMP2-2, WIDE1-1, WIDE1-1, WIDE2-2, ARISS, SGATE,WIDE2-1 and OUTNET Just curious as to which one I need to help that along and yes I do know that it may not get through with the path being from the aprsis servers if the RX station is not within range of a digi or the like.

Thanks,

Peter

From: Andrew P.<mailto:andrewemt@...>
Sent: Saturday, February 08, 2020 4:37 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [yaac-users] Sending messages without RF

You will first need to have an APRS-IS server passcode for your callsign, so you can connect to the Internet backbone with permission to transmit packets to the backbone.

There is no way at all to guarantee your Internet packets will get to RF. First off, only text message packets that are addressed to RF stations within range of an I-gate will be forwarded through only the relevant in-range I-gates (plus your next position packet, so the RF recipient knows where the station that sent the text message is located). Secondly, that requires an RF-transmit-capable I-gate within range of your target RF station; there are few of those, due to legal constraints and concerns in different jurisdictions on automatically forwarding packets from the Internet.

There is no way whatsoever to blast your packets to RF over the whole planet. The APRS-IS backbone network and I-gate software are specifically designed to avoid that sort of behavior, since the local RF network is intended for _local_ tactical information (not irrelevant spurious data from out-of-area stations), and the VHF channel doesn't have the bandwidth for the entire planet's worth of APRS stations. If you want to reach the whole planet on RF, you'll need to use the 30-meter HF band on RF yourself (and that has even less total bandwidth than the local VHF channel).

Andrew, KA2DDO
author of YAAC

Hope this helps.

开云体育

You will first need to have an APRS-IS server passcode for your callsign, so you can connect to the Internet backbone with permission to transmit packets to the backbone.

There is no way at all to guarantee your Internet packets will get to RF. First off, only text message packets that are addressed to RF stations within range of an I-gate will be forwarded through only the relevant in-range I-gates (plus your next position packet, so the RF recipient knows where the station that sent the text message is located). Secondly, that requires an RF-transmit-capable I-gate within range of your target RF station; there are few of those, due to legal constraints and concerns in different jurisdictions on automatically forwarding packets from the Internet.

There is no way whatsoever to blast your packets to RF over the whole planet. The APRS-IS backbone network and I-gate software are specifically designed to avoid that sort of behavior, since the local RF network is intended for _local_ tactical information (not irrelevant spurious data from out-of-area stations), and the VHF channel doesn't have the bandwidth for the entire planet's worth of APRS stations. If you want to reach the whole planet on RF, you'll need to use the 30-meter HF band on RF yourself (and that has even less total bandwidth than the local VHF channel).

Andrew, KA2DDO
author of YAAC

Hope this helps.

开云体育

Yes, that helped. I now have YAAC sending messages.

Thanks for your help!

KF7EEL
Eric C

开云体育

开云体育

Hi Andrew,

Thanks for the response. By "let the TinyTrak go into KISS mode", I meant that I put the TinyTrak into KISS mode (AMODE KISS) and left the YAAC KISS command blank. My assumption is that when the TinyTrak powered on that after three seconds or so it would be in KISS mode.

I'll check the receive amplitude level in the TinyTrak when I get home tonight. I've used the TinyTrak as a non-KISS packet device before, and it worked fine for that. I'm using the Yaesu FT-60R as it's the only radio I have a cable that works with the TinyTrak. I also have a KPC-3+ (which I understand has a problem in KISS mode) and an old MFJ-1278 unit, I'd just need to work up some cables if they would work better.

I did open the test port window and watched for any data when the radio and TinyTrak appeared to be receiving (the carrier detect led was on), but after some time of watching, I didn't see anything appear in the window.

What exactly do you mean by "let the TinyTrak go into KISS mode"? I also own a TinyTrak4, and one of the annoying features about it is that you can't switch back and forth between KISS and command mode easily. On the other hand, you don't really need to for a continuously-up station. I've tried dynamic switching, but I've found it's easier to configure the TinyTrak4 into KISS mode manually and leave it there, and then configure its Serial_TNC port in YAAC to be a KISS-only device (no switching commands required). Otherwise, YAAC gets annoyed when it doesn't see the TinyTrak acting like a KISS device, and keeps trying to force it, which only works when the TinyTrak has just booted up (i.e., when it says "Press ESC three times to enter command mode", and if you don't do that within about 5 seconds, it's too late).

The other thing to watch out for is your receive audio level. Byonics has directions in the TinyTrak manual for setting the receive amplitude level, which makes a big difference in decodeability for incoming packets (especially if it's at the wrong setting).

Furthermore, the TinyTrak4 is a hardware TNC with an old-style PLL frequency detector for the FSK demodulation, so it depends on good-quality AFSK transmissions, which many stations don't have. Overmodulation and limiter distortion, having amplitudes of the two audio tones inconsistent due to pre-emphasis in the radio (a good reason to use a data port if your radio has one, because that usually bypasses the pre-emphasis and de-emphasis circuits), and being somewhat off-pitch for the two tones; all of these reduce the receivability of the transmissions. And there's not much the receiving hardware TNC can do to make up for a lousy transmission. And that's even before packet collisions, hidden transmitters, and related channel issues contribute to losing packets.

Check these things, and then, with the TinyTrak in KISS mode connected to YAAC, open the Test Port window on the Serial_TNC port. When a packet comes in, you should see a spurt of illegible characters followed by an APRS packet body in ASCII text. The illegible characters is the AX.25 packet header, which for reasons specified in the AX.25 V2.2 protocol specification has the ASCII characters of the callsigns shifted one bit over so they come out as weird characters when the terminal tries to display them as ASCII. If you don't see such spurts of characters, then your TinyTrak is not successfully decoding packets.

What is KISS mode? KISS mode is a way of setting up a TNC so that it just does the HDLC bit stuffing, CRC calculations, and AFSK tone encoding/decoding, and then lets the attached computer do everything else for generating outbound packets and processing inbound packets. Call the TNC a "dumb" modem, with the KISS protocol providing frame boundary control so the HDLC frame boundaries can be seen on a plain asynchronous byte-oriented serial connection (basically, where does one packet end and the next one begin).

Hope this helps.

Andrew, KA2DDO
author of YAAC

What exactly do you mean by "let the TinyTrak go into KISS mode"? I also own a TinyTrak4, and one of the annoying features about it is that you can't switch back and forth between KISS and command mode easily. On the other hand, you don't really need to for a continuously-up station. I've tried dynamic switching, but I've found it's easier to configure the TinyTrak4 into KISS mode manually and leave it there, and then configure its Serial_TNC port in YAAC to be a KISS-only device (no switching commands required). Otherwise, YAAC gets annoyed when it doesn't see the TinyTrak acting like a KISS device, and keeps trying to force it, which only works when the TinyTrak has just booted up (i.e., when it says "Press ESC three times to enter command mode", and if you don't do that within about 5 seconds, it's too late).

The other thing to watch out for is your receive audio level. Byonics has directions in the TinyTrak manual for setting the receive amplitude level, which makes a big difference in decodeability for incoming packets (especially if it's at the wrong setting).

Furthermore, the TinyTrak4 is a hardware TNC with an old-style PLL frequency detector for the FSK demodulation, so it depends on good-quality AFSK transmissions, which many stations don't have. Overmodulation and limiter distortion, having amplitudes of the two audio tones inconsistent due to pre-emphasis in the radio (a good reason to use a data port if your radio has one, because that usually bypasses the pre-emphasis and de-emphasis circuits), and being somewhat off-pitch for the two tones; all of these reduce the receivability of the transmissions. And there's not much the receiving hardware TNC can do to make up for a lousy transmission. And that's even before packet collisions, hidden transmitters, and related channel issues contribute to losing packets.

Check these things, and then, with the TinyTrak in KISS mode connected to YAAC, open the Test Port window on the Serial_TNC port. When a packet comes in, you should see a spurt of illegible characters followed by an APRS packet body in ASCII text. The illegible characters is the AX.25 packet header, which for reasons specified in the AX.25 V2.2 protocol specification has the ASCII characters of the callsigns shifted one bit over so they come out as weird characters when the terminal tries to display them as ASCII. If you don't see such spurts of characters, then your TinyTrak is not successfully decoding packets.

What is KISS mode? KISS mode is a way of setting up a TNC so that it just does the HDLC bit stuffing, CRC calculations, and AFSK tone encoding/decoding, and then lets the attached computer do everything else for generating outbound packets and processing inbound packets. Call the TNC a "dumb" modem, with the KISS protocol providing frame boundary control so the HDLC frame boundaries can be seen on a plain asynchronous byte-oriented serial connection (basically, where does one packet end and the next one begin).

Hope this helps.

Andrew, KA2DDO
author of YAAC

Hi all,

I'm setting up YAAC on a Raspberry Pi 3+ running Rasbian Buster. I've downloaded and setup YAAC and I configured a Tinytrak4 to do KISS mode. The Tinytrak4 is connected to the Raspberry Pi via a USB to serial cable with a null modem. I also have a serial GPS unit plugged into the Raspberry Pi.

YAAC sees the GPS unit. YAAC sees the Tinytrack4 in command mode, I can make config changes and so forth. When I power the Tinytrak4 up and let it go into KISS mode, I see nothing. There are no packets reported even though I can see activity on the radio (a Yaesu FT-60R handheld with the appropriate cable from Byonics). If I unplug the cable from the handheld I can hear packet traffic.

I will be the first to admit I've never really understood how KISS mode works. I've never been able to get it to work and I've always used the text mode. I'm pretty sure I've got something wrong, but I can't figure it out. Does anyone have any thoughts?

Thanks for any help.

Kelley

Bear in mind that the src and dest fields in the externally-supplied APRS packet (not just a text message) are the values to be placed in the AX.25 sender and destination address fields in the AX.25 packet. This is _not_ the format for command-mode TNC-2 or for APRS-IS packet transmission and reception. If you choose not to specify these, the callsign-SSID of your transmitting port will be the sender (possibly different if you have multiple radio ports for a cross-band digipeater), and whatever tocall you have selected for YAAC (defaulting to APJYC1) will be the AX.25 destination. Note that externally-supplied packets will get the default digipeat path defined by your YAAC configuration (defaulting to WIDE1-1,WIDE2-1); you cannot control this from the external application, but can configure it inside YAAC. Also, after the colon terminating the destination field, the remaining text has to be a valid APRS packet as described in the APRS 1.0.1 Protocol Specification document (such as starting with ! for a position report, or : [again] to indicate a text message with an addressee). So if you are trying to send an APRS text message and you don't have two colons in a row, and then another colon after the addressee callsign, it won't work.

I presume you're using the "src>dst:text" format because you want a different callsign in the sender field than your station callsign. If your regular station callsign and tocall are acceptable, you can use just the format of a plain-text APRS packet without the "src>dst:" prefix. Unless you're acting as a proxy for another station, "src>dst:" probably shouldn't be used, but I assume you need to do that so that SMS messages can come back to the designated DMT station.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Hello,

Thank you for creating and maintaining this project, it is far better than Xastir!

I am trying to use an external message port to interface with a python script the will send DMR SMS messages to APRS, and the other way around.
I have successfully created a python script that opens a socket to the external message server, which is in "src>dst:message" mode. YAAC is receiving and re-transmitting packets. However, I notice when they show up in APRS.fi, they are formatted as "SOURCE>DESTINATION,PATH:MESSAGE". When sent over RF, my TH-D72 is not receiving the message packet, but can see the packet digipeated. I have noticed that other messages from YAAC interface, APRSdroid, etc. follow "SOURCE>PATH,DESTINATION:MESSAGE" format. I have played around with the path settings in the external message port, but the destination call is always before the path. Maybe I am doing something wrong, or could it be a bug?

I really appreciate YAAC, and the fact it has the ability to interface with other scripts.

Thank you for your time.

KF7EEL
Eric C

Thank you. How stupid. The SSL port configuration panel is still checking the passcode length (copied and pasted from the non-SSL APRS-IS port configuration panel, since a valid passcode is required to enable port transmitting on a non-SSL connection), but of course a passcode is never entered for the SSL port type. This will be fixed in the next build.

Note that this shouldn't prevent you from using the port with that filter expression; it's just very annoying. If it does prevent you, please get back to me.

Now another question is, while I'm fixing this, should I have the port configuration panel confirm you have already loaded your LotW certificate and private key? :-)

Andrew, KA2DDO
author of YAAC

________________________________________
From: Phil Pacier - AD6NH <ad6nh@...>
Sent: Tuesday, January 28, 2020 1:06 PM
To: Andrew P.
Subject: Re: YAAC SSL

Thank you for your quick response. Your reply would make perfect sense if not for the fact that the beacon is indeed turned on, as shown in the screenshot. Unless there is another beacon setting somewhere else, I'm not sure what else needs to be set, as I don't have to do anything else with the non-ssl port. Thank you!

[cid:part1.9FE2B021.38829628@...]

--

73 de Phil Pacier, AD6NH
APRS Tier2 Network Coordinator

D-Star Administrator: W6HRO & REF070

On 1/28/2020 10:01 AM, Andrew P. wrote:

Hi, Phil.

Good to know that the SSL servers are coming back.

The problem you are having has nothing to do with SSL; you'd have the same problem with a passcode APRS-IS port. The issue is that the 'm' filter you are using tells the APRS-IS server to send packets for all stations within a certain radius of your beaconed position. However, your beacon is turned off, so the APRS-IS server will never _know_ your position to compute that radius circle and select those packets.

I've had several other people complain about this operator-error issue ("how come I'm not receiving any packets from the APRS-IS?"), so I recently added a check to YAAC to confirm that you are configured to send a beacon before you are allowed to use only an 'm' filter expression. If you don't want to beacon, I recommend using an 'r' filter expression (i.e., r/lat/lon/radius ) with your approximate decimal (N or E oriented) latitude and longitude.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: Phil Pacier - AD6NH <ad6nh@...><mailto:ad6nh@...>
Sent: Tuesday, January 28, 2020 12:51 PM
To: ka2ddo@...<mailto:ka2ddo@...>
Subject: YAAC SSL

Good day, Andrew! I hope you are doing well. We have revitalized the SSL connection to the Tier2 servers, and currently have two servers accepting connections on port 24580. The ssl.aprs2.net address has those two servers and it works fine now.

I have been trying to setup an SSL connection from YAAC but I am having difficulty. I requested an up-to-date key from ARRL and verified that it works with APRSDroid. Here are two screen shots, one of the settings, and one of the error message I get in YAAC:

[cid:part1.135C4A34.ECDA3791@...]

[cid:part2.22FBEF9B.EDC0FFE0@...]

Thank you for your assistance!

--
--

73 de Phil Pacier, AD6NH
APRS Tier2 Network Coordinator

D-Star Administrator: W6HRO & REF070

Hi, Phil.

Good to know that the SSL servers are coming back.

The problem you are having has nothing to do with SSL; you'd have the same problem with a passcode APRS-IS port. The issue is that the 'm' filter you are using tells the APRS-IS server to send packets for all stations within a certain radius of your beaconed position. However, your beacon is turned off, so the APRS-IS server will never _know_ your position to compute that radius circle and select those packets.

I've had several other people complain about this operator-error issue ("how come I'm not receiving any packets from the APRS-IS?"), so I recently added a check to YAAC to confirm that you are configured to send a beacon before you are allowed to use only an 'm' filter expression. If you don't want to beacon, I recommend using an 'r' filter expression (i.e., r/lat/lon/radius ) with your approximate decimal (N or E oriented) latitude and longitude.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: Phil Pacier - AD6NH <ad6nh@...>
Sent: Tuesday, January 28, 2020 12:51 PM
To: ka2ddo@...
Subject: YAAC SSL

Good day, Andrew! I hope you are doing well. We have revitalized the SSL connection to the Tier2 servers, and currently have two servers accepting connections on port 24580. The ssl.aprs2.net address has those two servers and it works fine now.

I have been trying to setup an SSL connection from YAAC but I am having difficulty. I requested an up-to-date key from ARRL and verified that it works with APRSDroid. Here are two screen shots, one of the settings, and one of the error message I get in YAAC:

[cid:part1.135C4A34.ECDA3791@...]

[cid:part2.22FBEF9B.EDC0FFE0@...]

Thank you for your assistance!

--
--

73 de Phil Pacier, AD6NH
APRS Tier2 Network Coordinator

D-Star Administrator: W6HRO & REF070