|
I was asked to place a repeater as an object on the map.
?
I did the following, but got an extra line? - the one with 'ExtraMHz' in it.? ?I didn't type that, what does it mean?
?
|
your object comment should be
439.350MHz Toff -900?CC1 DMR dvsph.net
It only needs MHz after the frequency
take a look here, about half way down the page
APRSISCE does most of the formatting for you, but the comment is very specific
take a look here for APRSISCE specific
On Thursday, January 16th, 2025 at 19:11, Carl via groups.io <gw0tqm@...> wrote:
I was asked to place a repeater as an object on the map.
?
I did the following, but got an extra line? - the one with 'ExtraMHz' in it.? ?I didn't type that, what does it mean?
?
|
Genius,? Thanks,
Looking at the guidance I'm a bit surpised it thinks repeater beacons should be every 10mins.? I'm scattering mine 25-45 mins (and all slightly different) mind you only a handful are going to RF.
Thanks again.
Carl
|
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 APRS.FI 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 aprs.fi let's face it) will either?? So I'm torn, rather.
Carl
|
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.
toggle quoted message
Show quoted text
-------- Original Message -------- On 1/17/25 1:24 PM, Carl via groups.io <gw0tqm@...> 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 APRS.FI 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 aprs.fi let's face it) will either?? So I'm torn, rather.
Carl
|
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.
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=yahoo.co.uk@groups.io> 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
>?
>?
>?
>?
>?
>
|
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.
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.
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=yahoo.co.uk@groups.io> 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
>?
>?
>?
>?
>?
>
|
Remember that sometimes people gate IS traffic to RF without your knowledge. I have one such IGate that (based on a filter) takes IS only and puts in on RF, such as APRSISMO, APRSDroid, a repeater object from my home station, because depending on the weather I'm deaf and dumb in that compass direction, etc, etc.
Also, as an RVer, I very much enjoy seeing a repeater object pop up on my screen, pressing one button and (hopefully) being able to make a local contact.
It's safer than trying to look up info on repeater book or google, but I am but one voice on the airwaves.
Just my 2 cents
73,
Adam
KC2ANT
-------- Original Message -------- On 1/17/25 5:21 PM, Carl via groups.io wrote: 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.
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=yahoo.co.uk@groups.io> 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
>?
>?
>?
>?
>?
>
|
Carl