Re: 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
toggle quoted message
Show quoted text
Sent: Saturday, February 08, 2020 4:37 PM
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.
|
Re: 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.
|
Sending messages without RF
Morning,
I was wanting to send messages via the internet
and I am not connected via RF, what’s the beast path to do so in making sure it
goes from internet to RF? This is the home station and its just set up to
monitor the aprsis server.
?
Any help would be great.
?
Thanks,
?
Peter
N0WRE
|
Yes, that helped. I now have YAAC sending messages.
Thanks for your help!
KF7EEL
Eric C
|
Re: positionless Weather Report
You are probably transmitting positionless weather reports because your selected station APRS symbol isn't a weather station symbol. According to the APRS protocol specification, course and speed are only interpreted as applying to wind for weather stations (which are normally fixed position and therefore always have a self-speed of zero); for all other stations, course and speed are assumed to apply to the motion of the station itself. So, to avoid misinterpretation, if your station isn't identified as a weather station, YAAC transmits a position report with your symbol, position, and the course and speed of the radio, followed by a positionless weather report with all the weather parameters in it. Since both packets have the same callsign-SSID, a receiving station should be smart enough to match them together.
Hope that explains why you're transmitting two packets each beacon time.
Note this little quirk also allows for the possibility of mobile weather stations (i.e., storm chasers), but such stations have to do the vector math to convert vehicle-relative air velocity into wind velocity (prior to packet transmission) by vector-subtracting the vehicle ground velocity and accounting for the vehicle course rotating the bearing reference of the wind vane.
Andrew, KA2DDO author of YAAC
toggle quoted message
Show quoted text
-------- Original message -------- From: Alan Bartkowiak <N2ZVN.AE@...> Date: 2/3/20 13:40 (GMT-05:00) To: [email protected] Subject: [yaac-users] positionless Weather Report I'm sure I probably have something configured incorrectly but cant seem to find the issue. My beacon reports correctly giving my longitude?and latitude along with my free text. Where? the problem comes in is I also have it "report weather".? The weather is reported separately? from the beacon which I think is ok however it does not include the longitude?and latitude . My weather report looks like this: Positionless Weather Report, KA2DDO Yet another APRS system wind 4.0 mph, direction 277, gust 7, temperature 44, rain 0.02 in last hour, rain 0.00 in last 24 hours, rain 0.02 since midnight, humidity 73, barometer 29.82, "yDvs"
I'm using WeeWX to read the weather station and produce the wxnow.txt file and WXNOW.TXT on YAAC for the port type.? The weather report looks fine but is missing my position, longitude?and latitude.
Thank you for any assistance?. Alan N2ZVN
|
positionless Weather Report
I'm sure I probably have something configured incorrectly but cant seem to find the issue. My beacon reports correctly giving my longitude?and latitude along with my free text. Where? the problem comes in is I also have it "report weather".? The weather is reported separately? from the beacon which I think is ok however it does not include the longitude?and latitude . My weather report looks like this: Positionless Weather Report, KA2DDO Yet another APRS system wind 4.0 mph, direction 277, gust 7, temperature 44, rain 0.02 in last hour, rain 0.00 in last 24 hours, rain 0.02 since midnight, humidity 73, barometer 29.82, "yDvs"
I'm using WeeWX to read the weather station and produce the wxnow.txt file and WXNOW.TXT on YAAC for the port type.? The weather report looks fine but is missing my position, longitude?and latitude.
Thank you for any assistance?. Alan N2ZVN
|
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.
On 2/2/2020 8:07 PM, Andrew P. wrote:
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
|
|
This email has been checked for viruses by AVG antivirus software.
|
|
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
|
Re: URDC II configuration
Just got back to the house, I have Audacity on the desktop, hadn't thought about looking for a Pi version.? Data is getting to aprs.fi as my station shows up with the correct SSID.? And you're right about joining the Direwolf group, the example conf files I'm finding have issues, for example I can't use "digi" for the SSID as it returns an error, and IBEACON gives me an unrecognized command error.? Thanks for the help, I'm off to join the Direwolf group.
In the future it may be a good idea to use YAAC with a Pi and a CM108 (modified) audio dongle, I'd like to use it portable or mobile for public service events.
|
Re: URDC II configuration
If you run DireWolf from a terminal window, it should print out several lines of text describing each received packet as they come in. So, you need to confirm you're actually getting audio into the sound port you are listening to. You might want to try installing a program called audacity. It's an audio editing package useful for musicians, theatre technicians, and others who process sound, but it's also a convenient way to ensure you're actually getting audio into your computer. Have it recording the input from the UDRC card and confirm that when you hear packets on the radio's speaker, you see the corresponding envelope growth on the Audacity oscilloscope graph. That way, you can confirm you're configuring DireWolf to listen and transmit on the correct audio port. As for getting data to aprs.fi, that won't happen until you have an I-gate connection to the APRS-IS backbone with a valid passcode (so you're allowed to forward the packets to the APRS-IS). Either DireWolf or YAAC can do the I-gating function. You might want to join the DireWolf mailing list ( [email protected]) or NW Digital Radio's udrc mailing list ( [email protected]) to ask them for more information.
|
Re: URDC II configuration
It would be nice to have the map and features of YAAC available. I had trying running Direwolf alone, but it wasn't apparent that anything was being decoded.? I could hear the local WX station in the TM-V71A audio but it wasn't showing up on aprs.fi? My own station was showing up on aprs.fi though.? It was getting pretty late and I set things aside to get some sleep.? I'd be happy to get the configuration right for Direwolf and at least get something working as an Igate for now, until the local one is back in service.? YAAC would be a big bonus in the (hopefully near) future.
|
Re: URDC II configuration
YAAC does not have any TNC modem capability built into it; it expects you to provide some external implementation (in hardware or software). Given you're using a Raspberry Pi with UDRC-II, your best option would be to use DireWolf as your software TNC. As such, you wouldn't even need to use YAAC as a digipeater or I-gate, as DireWolf has that capability all by itself (and it would be more efficient at it too, because DireWolf isn't trying to update all the graphical screens YAAC has), although you could choose to not enable DireWolf's digipeating and I-gating capability and use YAAC to do so for the logging.
Even if you use DireWolf as a stand-alone digipeater and/or I-gate, you could still run YAAC and connect it to the KISS or AGWPE ports on the DireWolf process so you could watch what DireWolf was processing.
Andrew, KA2DDO
author of YAAC
|
Hi,
? I'm new here, I've spent a few hours with a Raspberry Pi and a URDC II interface trying to set up an Igate/Digipeater.? Our local Igate has failed.? Getting to the point, I wanted to use YAAC with the raspberry pi URDC II interface combination.? Things were going along well until I came to the configure ports page of the set-up wizard.? Some help with this would be appreciated, its my hope that someone has already done this, but then maybe not as the URDC II uses the GPIO pins of the pi rather than a USB port.
?? Ron, Yellowknife, NT, Canada? VE8RT VE8TEA
|
Re: next beta build#147 of YAAC
Thanks Andrew :)
toggle quoted message
Show quoted text
On 1/23/2020 1:19 PM, Andrew P. wrote: next beta build#147 of YAAC ("Yet Another APRS Client"), created 2020-Jan-23
downloadable from
or
changes and updates include:
1. fill in missing information in the Javadocs for the YAAC source code.
2. fix the built-in help index merging. This required changing all of
the plugins that had help extensions, as the old format would actually
cause help generation to fail when sort-merging the index.
3. implement and document command-line options to support limited
configuration setting, suitable for use by third-party installation
scripts.
4. eliminate excessive digits after the decimal point for QRU maximum
range.
5. add user-selectable new formats for logging GPS track data, including
the existing format of whatever YAAC is receiving, and per-source
(local and remote) logging in NMEA-0183 sentences, GPSD JSON
structures, GPX (GPs eXchange) XML, and CSV format.
6. fix error in time-limiting the playback of a GPS log file.
7. fix memory and CPU leak when closing raw packet view.
8. fix spurious NullPointerException when setting up map windows.
9. add safety check to make user confirm they really want to change
their Mic-E status to the Emergency setting before actually doing
it.
10. copy the latest version of Hessu's tocalls.dense.json file.
11. normalize the entries on the View menu to not say "View" or
"Show" redundantly.
12. add one-touch changing of Mic-E status to the small screen plugin.
--
Michael Cozzi
cozzicon@...
kd8tut@...
269-519-2389
|
next beta build#147 of YAAC
next beta build#147 of YAAC ("Yet Another APRS Client"), created 2020-Jan-23
downloadable from
or
changes and updates include:
1. fill in missing information in the Javadocs for the YAAC source code.
2. fix the built-in help index merging. This required changing all of
the plugins that had help extensions, as the old format would actually
cause help generation to fail when sort-merging the index.
3. implement and document command-line options to support limited
configuration setting, suitable for use by third-party installation
scripts.
4. eliminate excessive digits after the decimal point for QRU maximum
range.
5. add user-selectable new formats for logging GPS track data, including
the existing format of whatever YAAC is receiving, and per-source
(local and remote) logging in NMEA-0183 sentences, GPSD JSON
structures, GPX (GPs eXchange) XML, and CSV format.
6. fix error in time-limiting the playback of a GPS log file.
7. fix memory and CPU leak when closing raw packet view.
8. fix spurious NullPointerException when setting up map windows.
9. add safety check to make user confirm they really want to change
their Mic-E status to the Emergency setting before actually doing
it.
10. copy the latest version of Hessu's tocalls.dense.json file.
11. normalize the entries on the View menu to not say "View" or
"Show" redundantly.
12. add one-touch changing of Mic-E status to the small screen plugin.
|
