This is good news. Thanks!

I'll set up a test station this week to check out 13 and 14.

I'm excited about 25, and especially for parsing remote data. If the next version could send tweets it would be perfect, as weather reporters in our state use Twitter.

next beta build#149 of YAAC ("Yet Another APRS Client"), created 2020-May-09

downloadable from
or

changes and updates include:
1. yet more improvements and bugfixes in OpenStreetMap importer, including
support for coastline shapefiles and actually fixing tiling of large
bodies of water, and adjusting default assumptions for incomplete OSM
records to account for cases where the assumptions didn't apply (such
as assuming a riverbank is a closed area of a section of the river
[both banks] rather than potentially only one shoreline).
2. fix errors in the Maven pom.xml files provided for an alternate means
of building YAAC. Note that the Ant build.xml files are still the
supported means of building YAAC and its plugins.
3. clean up Javadocs and fill in more missing Javadocs.
4. eliminate incorrect identification of TCPXX as a digipeater alias.
5. more minor performance enhancements.
6. add ability to parse time intervals (Ages) as well as display them.
7. fix up display of the YAAC Help->About dialog, ensuring that it
can't grow excessively large from installing many plugins and increasing
the font size.
8. allow quad-sized icons so if all icons are displayed in double-size
then more significant stations/objects can still be displayed in
a larger size on the map.
9. fix displaying weather stations as old-style weather map symbols
so that the temperature and dew point are in the configured
temperature units instead of fixed at Fahrenheit.
10. fix beacon configuration to ensure any modified beacon record has
the chance to be saved when switching to another beacon record,
and ensure the controls for setting beacon-specific rates are
properly set to the last values for that beacon instance instead
of always to the APRS defaults. Also add sanity check to beacon
free-text comment in case user puts the word EMERGENCY in the
text, just to validate that they really want to announce a real
emergency to listening stations.
11. fix configuration wizard to propagate callsign-SSID changes to
existing ports rather than only to any new ones (which might not
be created when the callsign is changed).
12. add to list of standard APRS-IS backbone rotator domain names, the
CWOP rotator (which contains traffic from non-amateur-radio
Citizen's Weather Observation Program stations)
13. for the WxNow.TXT port driver, supplement support for the 2-line
Cumulus file format with chooseable support for the 1-line
Weathercat (TNC2 command-mode frame) format, and allow freely
typing the model code of the weather sensor as an alternative
to the canned list of model codes.
14. add transmit slowdown to radio ports to try to ensure TNC has time
to get the last packet out before pushing a new packet into the
TNC, as some TNCs don't have the buffer space for more packets
from the computer when the last one hasn't finished going to the
radio yet. Was already there for Serial_TNC port type, added for
other TNC port types.
15. update the list of referred websites for obtaining OpenStreetMap
dataset downloads.
16. restructure the email composition method in the Telemetry Alarm
plugin so it can be accessible from other plugins.
17. properly handle weather data in APRS packets when the field is
provided but filled with "..." to indicate the sending station
does not actually have that data parameter.
18. reduce JVM heap thrashing by replacing calls to
StringBuilder.append(s.substring(start,end)) with
StringBuilder.append(s, start, end).
19. add more support in core YAAC for inter-plugin data sharing.
20. eliminate spurious re-render of the OpenStreetMap layer just
because a new station was heard.
21. refactor MADIS weather data quality check so it can be used
elsewhere than just in the Health Monitor view, including in
the new Weather Alert plugin (more about this later).
22. fix issue reported on APRSSIG mailing list 8 May 2020 about
I-gating packets with embedded carriage return and line feed
characters.
23. (provided by James Palmer AG5VQ) fix bugs in the CallsignDB
plugin to support multiple licenses/callsigns per individual
licensee.
24. fix duplicate speaking of the degree portion of a longitude
in the sounds plugin.
25. add new Weather Alert plugin, which reports when certain conditions
are detected in local or remote weather data, by verbal speech,
email, SMS, highlighting the station on the map, and sending
APRS text messages.

I sent my initial message twice because the first time I did not see any
indication that it had been sent.
The second time, I noticed the header about moderator approval.

Greetings, all.

I'm not sure if it's the new subscribers sending in duplicate, or a bug ("feature"?) of Groups.io, but I find most new message submitters have two new messages waiting for moderation approval from me.

No need to send it twice; I'll get to it as soon as I can get to my computer. It's too hard to use the Groups.io admin screens on a cellphone.

The group is currently configured to require moderator approval for anyone's first message to the group, since anyone can join without requiring moderator approval. I haven't yet have to reinstate moderation on anyone yet (what a polite group!).

Andrew, KA2DDO
author of YAAC
mailing list moderator

Thank you for taking a look at that. If you can send me updated source or Unix/Linux patch files, I will merge that into the build I was planning on releasing tomorrow (if I don't get it done tonight).

That build already has some significant improvements and some new features available coming up.

Andrew, KA2DDO
author of YAAC

Andrew,

I am a retired software developer and Extra class Ham, AG5VQ. I recently started experimenting with APRS and found YAAC to be both interesting and in active development.

While experimenting with the callsigndb plugin, I discovered the following defects:

• Looking up call signs loaded from the FCC DB shows at most the call sign, country, status, and expiration date.
• Many amateur callsigns from the ACMA database are not found, because clients (e.g. Client id 118314, the Central Highlands Amateur Radio Club) may have multiple call signs.
• The sequence (No callsigndb.dat; Load RAC; Exit; Load RAC) results in
  java.io.IOException: unable to move obsolete DB .dat file out of the way
• The sequence (No callsigndb.dat; Load FCC; Load FCC) results in multiple EOFExceptions.
• Reloading call sign source can cause an unnecessary rebuild of the DB, e.g., due to mismatches between null valued Strings loaded from callsigndb.dat and empty Strings loaded from FCC, etc.

I have created fixes for these defects and hope you will be interested in incorporating them in the next version of the plugin.

Thank you for creating YAAC and for making it so useful, easy to understand and modify.

Jim Palmer

High altitude balloon filers do use 144.390 but there is no need there to use a >high transmit rate and it's suggested to use a Wide2-1 path. That's more than >enough to get the position painted on the internet and help with payload >recovery if the balloon gets out of range.

Actually, it's suggested to use no digipeat path for high altitude balloons, as at their typical cruising altitude, they can hit several counties directly without digipeating, so waking up several dozen digipeaters for a first hop is also discourteous. The best balloon setups change their path based on their altimeter, so they only digipeat when close to the ground or landed where they need the digipeat support.

That sounds dangerously like a way to clog the national channel with your burst. Sure, you'd save a tiny bit of time not having to key up and send multiple flag bytes on the channel before starting subsequent packets, but several models of TNCs can't handle that packet rate (they expect dead time before the next packet to get the last packet forwarded to the computer, probably because they don't have multi-threaded firmware), and it wouldn't reduce the total amount of time you would be holding the channel by very much.

Just how many packets were you planning on bursting in each batch, and how often? Or, in other words, what percentage of the shared national channel's local bandwidth were you planning to consume with these bursts? With the average size of an APRS packet, the 1200-baud local channel can't handle more than about 900 packets in a a half hour from all nearby stations combined, and that's with stations who listen for clear-channel before transmitting and otherwise "play well" with other channel users, so as to minimize wasted channel time due to collisions.

Note that normal APRS stations send their data at a much slower rate than when the data comes in. For example, a GPS receiver typically provides an updated position every second. But the fastest "polite" rate for sending APRS position reports for one originating station is no more often than once a minute (i.e., 1/60 of the data points), and is more typically every 10 minutes, depending on the rate of motion of the reporting station. Similarly, some weather stations can report data as often as once a second, but typically only send to APRS once every 10 to 15 minutes (how fast does weather really change?). Also, note that most digipeaters (including YAAC) will retransmit out the receiving port; this is so stations on the "other side" of the digipeater can hearing the originating station's packets (i.e., the whole point of a digipeater), so unless your private channel port is receive-only, you will be interfering with your own trackers (especially if they are transmit-only trackers that don't listen for a clear channel before transmitting).

So, unless you plan on downsampling the dog-tracker position reports from your private channel before retransmitting them, and staggering the resampling, you will probably annoy all the other local users of the national RF channel.

There is presently no down-sampling feature for digipeated packets in YAAC. On the other hand, YAAC (like most well-behaving digipeaters) automatically drops duplicate packets from any specific received station so it will only forward a duplicated packet no more often than every 30 seconds. This is a digipeater feature to protect the channel from originating stations making excessive transmissions, such that the excessive transmissions won't be multiplied by the digipeaters.

I presume each of your dog-trackers has a unique station ID (and would therefore appear as a unique originating station on APRS)? That might bypass the digipeater throttling. If they all use your callsign and have the dog instance in the packet body, they might get throttled unpredictably, depending on the throttling algorithm implementation in each digipeater.

I would strongly recommend slowing down your dog-trackers' transmit rate. After all, the dogs can't run _that_ fast, and standard APRS position data only has a quantized resolution of about +/- 60 feet (well within the position error of GPS receivers without perfect skyview). And slowing down the tracker transmission rate would definitely extend the trackers' battery life. Either that, or use your own frequency instead of the nationally shared frequency. I know of several bicycle events that do that in order to get more frequent updates from multiple trackers without interference.

Just my $.02.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of scotty ratcliffe <scottyratcliffe@...>
Sent: Sunday, May 3, 2020 5:27 PM
Subject: Re: [yaac-users] more digi settings

Right now i have two radios running in to YAAC, 1 on 144.390 national frequency, the other on a different frequency for my dog trackers. I have the dog trackers transmitting a a high rate. Is it possible to "store and forward" say 30 seconds of packets from 2 radio and send in burst?

Right now i have two radios running in to YAAC, 1 on 144.390 national frequency, the other on a different frequency for my dog trackers. I have the dog trackers transmitting a a high rate. Is it possible to "store and forward" say 30 seconds of packets from 2 radio and send in burst?

You were correct Andrew, very easy fix, I must have look at that page 5 times and not seen it. Thank you for your help!?

Greetings.

What exactly do you want to do here?

YAAC already supports timeslotting, configurable on a port-by-port basis, although that is limited by how much extra timing baggage the external TNC adds. I am adding a feature to _prevent_ consecutive packet sends, because I have had reported to me that a lot of TNCs can't handle getting a second packet from the computer while the first packet isn't finished transmitting yet, such that back-to-back packets cause the second packet to be dropped or destroyed, and not all USB-to-RS232 interfaces and TNCs supports hardware flow control (so the computer can be held back by the TNC until the TNC can accept another packet).

Awaiting your clarification of your feature needs....

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of scotty ratcliffe <scottyratcliffe@...>
Sent: Friday, May 1, 2020 7:18 PM
Subject: [yaac-users] more digi settings

Hello is it possiable to add more digi setting like conesctive packet send. and to set the time to hold packets for the burst send.
_._,_._,_

Persisting locally-defined objects across restarts is easy. This is a configurable capability in YAAC. Go to the menu choice File->Configure->Expert Mode, select the Behavior tab, and check the checkbox labelled "Restore locally-originated objects when YAAC restarts".

________________________________________
From: [email protected] <[email protected]> on behalf of ab8xg via groups.io <ab8xg@...>
Sent: Saturday, May 2, 2020 7:36 PM
To: [email protected]
Subject: [yaac-users] Not saving objects

Hello all and thanks for letting me join the group.
The problem I am having is when I create an object it works fine as long as I have the program running, or don't loose power etc. Then the object is gone and I have to do it over. Can't find a place to save it. It is marked as permanent on the setup menu. Any way not a huge deal I would just like to find out if I am missing something. And I'm sure I am.

Thanks
Kenny Coen /AB8XG

<>

Hello all and thanks for letting me join the group.?

开云体育

Thank you.

The recommended place to begin is with a radio listening to your local traffic through a TNC (hardware or software). If you don't already have a hardware TNC, the software ones actually perform much better and only require a soundcard interface to your radio.

You don't need a passcode unless you're planning on sending traffic to the APRS-IS Internet backbone. You can do radio operations or receive-only Internet without one.

If you decide you want to send to APRS-IS, then, if you don't have a Logbook of the World certificate (so you can use the secure means to log into the backbone), you need to privately email the author of your chosen software and tell them your identity and callsign so they can verify you are a licensed amateur radio operator and then issue you a passcode.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Hi.

im new to YAAC. ?How do I get a passcode? ?Where do I begin?

delivers1234
kr3lim

Hello is it possiable to add more digi setting like conesctive packet send. and to set the time to hold packets for the burst send.

Random Internet packets don't get transmitted to RF by transmit-capable I-gates. There are very specific rules implemented by both APRS-IS backbone servers and I-gates to ensure the local RF channel isn't jammed by excessive IS->RF relaying, and only packets of interest to the local RF neighborhood are forwarded.

For an Internet packet to be transmitted to RF, it has to pass one of the following rules:

1. The packet must be an APRS text message addressed to an RF station whose own packets were forwarded to the Internet by the specific I-gate.

2. The packet is a position report packet of an Internet-relayed station that has just sent a rule#1 text message.

3. Any other packets that the I-gate is specifically (and not defaultly) configured to relay.

So, if your APRSdroid system isn't sending text messages addressed to RF stations local to your I-gate, nothing from it will be transmitted by the I-gate unless you set up filters to cause the backbone server to send those packets to the I-gate, and more supplemental filters to force the I-gate to transmit those packets that don't meet rule#1 or rule#2.

Better off attaching an HT to your Android phone so you can send RF packets directly from the location where your phone is at. :-) Forcing packets just from the phone's callsign is inappropriate. What if the phone is nowhere near the I-gate? Sending non-local packets to the local RF network just clutters the limited-bandwidth RF channel.

Hope this helps explain how I-gates are supposed to work.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Thomas Utesch <tom@...>
Sent: Wednesday, April 29, 2020 9:30 AM
To: [email protected]
Subject: [yaac-users] 2 Way IGate

I have YAAC configured as a two way iGate. I'd like the packets I send from my phone using APRSDroid to be transmitted locally by my iGate. The phone packets are reaching APRS-IS as I seem them on aprs.fi. But they do not transmit from the IGate. I must be missing something. Thanks

Tom - KG2U