开云体育

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.

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.
_._,_._,_

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?

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?

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.