Greetings, all.

I'm not sure if it's the new subscribers sending in duplicate, or a bug ("feature"?) of 开云体育, 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 开云体育 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

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

The supplemental I-gate filters are saved when you press the ENTER key (on a PC-type keyboard). If you change the field again, press ENTER to confirm the change.

There are several solutions to your request. Obviously, YAAC will be promoted here (since I wrote it for exactly this kind of work), although there are other Linux/Unix APRS programs. However, a 10" monitor is probably going to be too small for a bicycle event if you are at the Net Control station and need to be able to see the entire course in detail. I typically use a laptop computer connected to a 40" flat screen for those events, but I have AC power available at those events. Other events I know of that have indoor Net Control locations use projectors as monitors. Now, if you're using APRS in a support vehicle, then the 10" screen is probably enough.

Now using a USB-connected SDR (such as the RTL SDR dongle) instead of a conventional amateur radio rig requires a bit more. A program called rtl_fm can configure such a stick to demodulate FM radio (such as 2M ham transmitters), and couple its output into Direwolf as the software modem/TNC for AX.25 packets. YAAC then connects to Direwolf to provide the graphical views of the received APRS packets.

Here's a link with directions for setting things up with the SDR and Direwolf:


Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Chuck Berry <n7chs.qsx@...>
Sent: Tuesday, April 28, 2020 7:15 PM
To: [email protected]
Subject: [yaac-users] APRS decode/map display, No Internet

Previously posted on Facebook-APRS. It was suggested that I post here.

Looking for a APRS receive/decode/display map solution for a upcoming
race event. Most solutions revolve around an IGate. I would like to do
with a SDR, Raspberry Pi and 10" monitor. Suggestions Please. Note:
Internet unavailable. There are two digipeaters in the surroundings
hills that will cover the race course. Thx, Chuck N7CHS