All:?

I recently recorded a time lapse video showing APRS-VARA activity on the 30-meter band (see below). The condensed video is only a few minutes long, but the actual recording time was approximately 8 hours. When I played it back, I noticed that stations would periodically disappear from the map over a certain amount of time and some would then reappear.?

My guess is that this is due to the time-out feature, which assumes a station is no longer active if no packets are heard over a given time period. It's obviously a useful feature, but I was wondering if the timeout can be modified for demonstration purposes i.e., video demos???

Tony -K2MO?

Video Link:

This time lapse video shows APRS activity on the 30M band using the VARA modem. www.youtube.com

On Sun, Jan 19, 2025 at 3:33, Steve via groups.io

<kf6wax@...> wrote:

Test

Thanks for that.? ?I guess Im happy that APRS can handle occasional collisions, I just wanted to avoid permanent ones (hence the scatter idea of posting what has amounted to 23 objects just now, in reality APRS.FI will handle the internet and frankly there is hardly any RF activity local to me).? I really appreciate your input.

The other aspect of course is that formatting the data for the handful of devices that can read it (and I had no idea this was a thing) is balanced against the now ubiquity of the internet (APRS largely preceded this) so observers reading packets only need a repeater callsign and then can Google the detail!

So yep. If it talks to some radios why not.? ? Cheers.

Carl

On Fri, 17 Jan 2025 at 21:36, James Ewen via groups.io

<ve6srv@...> wrote:

Carl,

The APRS packet definitions were designed to shoehorn into an existing?system. They took advantage of what existed and made it do something new. It wasn't a new system designed from the ground up, so there are some "unique" solutions. The APRS object definitions are no exception.

Just about every APRS packet is human readable to an extent... are they plain English with extremely detailed explanations of each component? Nope, you usually need to have a rudimentary idea of the structure. The APRS client software does that interpretation to pretty pictures and decoded information. But with a little knowledge, one can decipher most of the information manually. Knowing that?+900 means?+9MHz is one of those things you need to know. Most people don't even look at the raw packets, we spend a lot of time explaining packet contents to users in these forums.

As for your object timing.You mention you use timing between 25-45 minutes. I'm assuming that this is your pseudo-random timing to space out the packets. This is the usual way that a human will attempt to randomize packets like these. In fact, you are not randomizing, and will end up with overlapping packets based on the math. A better solution is to use the same timing, but use an offset to keep them apart.

It's easy to visualize that sending one packet at a 5 minute interval, and a second at a 10 minute interval, that these will overlap where multiples of 5 and 10 occur, which is every 5 minutes. Same thing happens with 26 and 32 minutes, except the overlap is based on when multiples of 26 and 32 occur. If you do multiple objects you get multiple?overlaps, with the occasional big cluster.

If you send all the packets at a 39 minute interval, but start them 4 minutes apart, they will never overlap. They will always stay 4 minutes apart. Some systems will support this spacing, others may not, so you are stuck.

Here's another thing to think about. Who is asking for the information you are providing? The basic concept of APRS is to send information periodically to keep the remote user's display populated. This works when there isn't a lot of information to convey. However as APRS is a 1200 baud channel, and has limited capacity, when lots of people send lots of information, collisions can wipe out data, making that data being sent useless.

One thing that was designed was a QRU server. This device is configured with a bunch of information, like objects for repeaters, gas stations, hospitals, etc that an end user can query when the information is needed. This however requires that the person needing the information has the ability and knowledge to know to ask the question.

All of the above isn't an admonition, or me trying to tell you that you are doing things wrong. Rather it is just a bit of information that *may* give a nudge towards looking at what you (and anyone else reading) are doing, and maybe think about doing that task a slightly different way. I know I can get stuck looking at a solution to a problem I am facing, and can't see any other perspective. But along comes someone else who asks "Why", and through trying to defend my position, or with the right outside prompt, a new and maybe better solution presents itself.

James
VE6SRV

On Fri, Jan 17, 2025 at 2:03?PM Adam - KC2ANT via <kc2ant=[email protected]> wrote:

Kenwood and the FTM-350 and newer support auto tune to the station comment that is configured that way.

-500 is down 5MHz, -060 is down 60KHz, etc.


-------- Original Message --------
On 1/17/25 1:24 PM, Carl via <gw0tqm=[email protected]> wrote:

>? Looking into this, it appears to be a language Kenwood radios understand.? ?My guess???? is that Yaesu radios will not?? I haven't checked if understands this syntax yet, but I shall.??
>?
>? So much potential in APRS I have never heard of :(
>?
>? Thing is, +900 doesn't shout +9MHz to me and I can't imagine casual APRS browsers (most who will be using let's face it) will either?? So I'm torn, rather.
>?
>? Carl
>?
>?
>?
>?
>?
>

On Fri, 17 Jan 2025 at 21:36, James Ewen via groups.io

<ve6srv@...> wrote:

Carl,

The APRS packet definitions were designed to shoehorn into an existing?system. They took advantage of what existed and made it do something new. It wasn't a new system designed from the ground up, so there are some "unique" solutions. The APRS object definitions are no exception.

Just about every APRS packet is human readable to an extent... are they plain English with extremely detailed explanations of each component? Nope, you usually need to have a rudimentary idea of the structure. The APRS client software does that interpretation to pretty pictures and decoded information. But with a little knowledge, one can decipher most of the information manually. Knowing that?+900 means?+9MHz is one of those things you need to know. Most people don't even look at the raw packets, we spend a lot of time explaining packet contents to users in these forums.

As for your object timing.You mention you use timing between 25-45 minutes. I'm assuming that this is your pseudo-random timing to space out the packets. This is the usual way that a human will attempt to randomize packets like these. In fact, you are not randomizing, and will end up with overlapping packets based on the math. A better solution is to use the same timing, but use an offset to keep them apart.

It's easy to visualize that sending one packet at a 5 minute interval, and a second at a 10 minute interval, that these will overlap where multiples of 5 and 10 occur, which is every 5 minutes. Same thing happens with 26 and 32 minutes, except the overlap is based on when multiples of 26 and 32 occur. If you do multiple objects you get multiple?overlaps, with the occasional big cluster.

If you send all the packets at a 39 minute interval, but start them 4 minutes apart, they will never overlap. They will always stay 4 minutes apart. Some systems will support this spacing, others may not, so you are stuck.

Here's another thing to think about. Who is asking for the information you are providing? The basic concept of APRS is to send information periodically to keep the remote user's display populated. This works when there isn't a lot of information to convey. However as APRS is a 1200 baud channel, and has limited capacity, when lots of people send lots of information, collisions can wipe out data, making that data being sent useless.

One thing that was designed was a QRU server. This device is configured with a bunch of information, like objects for repeaters, gas stations, hospitals, etc that an end user can query when the information is needed. This however requires that the person needing the information has the ability and knowledge to know to ask the question.

All of the above isn't an admonition, or me trying to tell you that you are doing things wrong. Rather it is just a bit of information that *may* give a nudge towards looking at what you (and anyone else reading) are doing, and maybe think about doing that task a slightly different way. I know I can get stuck looking at a solution to a problem I am facing, and can't see any other perspective. But along comes someone else who asks "Why", and through trying to defend my position, or with the right outside prompt, a new and maybe better solution presents itself.

James
VE6SRV

On Fri, Jan 17, 2025 at 2:03?PM Adam - KC2ANT via <kc2ant=[email protected]> wrote:

Kenwood and the FTM-350 and newer support auto tune to the station comment that is configured that way.

-500 is down 5MHz, -060 is down 60KHz, etc.


-------- Original Message --------
On 1/17/25 1:24 PM, Carl via <gw0tqm=[email protected]> wrote:

>? Looking into this, it appears to be a language Kenwood radios understand.? ?My guess???? is that Yaesu radios will not?? I haven't checked if understands this syntax yet, but I shall.??
>?
>? So much potential in APRS I have never heard of :(
>?
>? Thing is, +900 doesn't shout +9MHz to me and I can't imagine casual APRS browsers (most who will be using let's face it) will either?? So I'm torn, rather.
>?
>? Carl
>?
>?
>?
>?
>?
>