Date   

Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

Yes the one from KB3KBR-1 Sent from my Droid Charge on Verizon 4G LTE


-----Original Message-----
From: Lynn W Deffenbaugh (Mr)
Sent: 5/9/2012 8:37:08 AM
To: aprsisce@...
Subject: Re: [aprsisce] Re: FTM-350 FREQ OBJ problem?
 

I'm seeing three objects matching "145.130*".  Can you be specific as to actual object name AND transmitting station ID?

145.130 owned by W6PKT-5 show no range on my system.
145.130- owned by KB3KBR-1 shows in my drop-down, but I can't MultiTrack (bug to track down)
145.130WA owned by VE7ZKI-10 shows no range on my system.

None of these should show any Range.  I can't even find any recent 145.130* at aprs.fi that include W3MIE (but I didn't search really hard).

However, with my loose parser of packet contents, if you have W3MIE as the first non-frequency component in the comment, I'll see the W3M and consider it a non-compliant, single digit, Westerly range of 3 Miles.  This is a side effect of attempting to generate a humanly readable face for the random bits of flotsam and jetsom that are out there in packets.

If you look at any low altitude WinLink object,  you'll find that they are injecting Rnm with single digits as well.  I'll probably update my range rummager to require a space (or end of comment) after the non-compliant term before picking the value out of it.

Lynn(D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/9/2012 12:30 AM, Greg Depew wrote:

I noticed a new problem with the range finder. when parsing 145.130 I have the repeaters callsign of W3MIE parses it as 3mi range. Sent from my Droid Charge on Verizon 4G LTE


-----Original Message-----
From: James Ewen
Sent: 5/9/2012 3:55:36 AM
To: aprsisce@...
Subject: Re: [aprsisce] Re: FTM-350 FREQ OBJ problem?
 

On Tue, May 8, 2012 at 9:24 PM, Brian <n5brj@...> wrote:

> I do not find any reference to my FTM-350 supporting a FREQUENCY
> Object (frequency in the object name).  From what I can tell in the manual,
> it only parses a QSY frequency from the comment section.

That sounds like what we are hearing...

--
James
VE6SRV



Re: To much information

Lynn Deffenbaugh
 

aprs.fi will show all information that it has for a station. You'll have to study the aprs.fi help files and/or join the aprs.fi Google group to ask Hessu directly. aprs.fi is simply a web viewer of APRS-IS-provided information.

That said, if you don't want to see telemetry, then don't transmit telemetry. You can do this by unchecking Enables / Telemetry Enabled, but you'll lose visibility to your battery state and GPS information. I think aprs.fi will quit showing you the telemetry after some time of your station not transmitting it.

But before you turn it off, have you seen what features aprs.fi provides by your telemetry transmissions? See:

http://aprs.fi/telemetry/a/G4ZXN-10

As for the etc etc element, I'm assuming you meant the additional telemetry components and have no issue with speed, heading, height, or anything else that aprs.fi shows?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/9/2012 5:02 AM, g4zxn wrote:
Greetings all,
When I tap on my ssid on Aprs.fi the window appears giving speed, heading, height and comment.
Is it possible to remove the "telemetry " element and the "Battery: 92%, Charging/AC: 95" etc etc element?.

Regards
Martin



------------------------------------

Yahoo! Groups Links




To much information

g4zxn <g4zxn@...>
 

Greetings all,
When I tap on my ssid on Aprs.fi the window appears giving speed, heading, height and comment.
Is it possible to remove the "telemetry " element and the "Battery: 92%, Charging/AC: 95" etc etc element?.

Regards
Martin


Freq Nuances (Dev: 2012/05/09 04:50)

Lynn Deffenbaugh
 

Note: I purposely have a very soft and loose parser attempting to identify ANYTHING that might be ANYONE's attempt to define freqeuncy in a comment. This will generate a LOT of false positives, which I will work towards eliminating as they are identified. Machines definitely don't infer things as well as humans do, until someone smarter than them teaches them the nuances. If you notice false frequency positives, OR missed frequency intents, please post the explicit station ID and object owner (if an object) to the list and I'll see about informing the frequency parser.

Don't count water meters (NNN.NNNgh) as frequency objects (ignoring numbers with gh following) (Brian N5BRJ)

Require whitespace after non-compliant R/N/E/S/W single digit constructs. (Greg W3MIE's 145.130)

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


Re: FTM-350 FREQ OBJ problem?

Lynn Deffenbaugh
 

I'm seeing three objects matching "145.130*". Can you be specific as to actual object name AND transmitting station ID?

145.130 owned by W6PKT-5 show no range on my system.
145.130- owned by KB3KBR-1 shows in my drop-down, but I can't MultiTrack (bug to track down)
145.130WA owned by VE7ZKI-10 shows no range on my system.

None of these should show any Range. I can't even find any recent 145.130* at aprs.fi that include W3MIE (but I didn't search really hard).

However, with my loose parser of packet contents, if you have W3MIE as the first non-frequency component in the comment, I'll see the W3M and consider it a non-compliant, single digit, Westerly range of 3 Miles. This is a side effect of attempting to generate a humanly readable face for the random bits of flotsam and jetsom that are out there in packets.

If you look at any low altitude WinLink object, you'll find that they are injecting Rnm with single digits as well. I'll probably update my range rummager to require a space (or end of comment) after the non-compliant term before picking the value out of it.

Lynn(D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/9/2012 12:30 AM, Greg Depew wrote:
I noticed a new problem with the range finder. when parsing 145.130 I have the repeaters callsign of W3MIE parses it as 3mi range. Sent from my Droid Charge on Verizon 4G LTE


-----Original Message-----
From: James Ewen
Sent: 5/9/2012 3:55:36 AM
To: aprsisce@...
Subject: Re: [aprsisce] Re: FTM-350 FREQ OBJ problem?

On Tue, May 8, 2012 at 9:24 PM, Brian <n5brj@...> wrote:

>I do not find any reference to my FTM-350 supporting a FREQUENCY
> Object (frequency in the object name). From what I can tell in the manual,
> it only parses a QSY frequency from the comment section.

That sounds like what we are hearing...

--
James
VE6SRV



Re: Frequency On Water Objects

Lynn Deffenbaugh
 

Please post the specific object IDs that you're seeing this on. Yes, it's an unintentional consequence of my looser interpretation of what might be a frequency. Hopefully they're at least flagged as "non-compliant"?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/9/2012 12:20 AM, Brian wrote:
Now I'm seeing Frequency parses on Water Objects. I wonder if this was an unintentional consequence.

Brian
N5BRJ


Re: FREQ OBJECT Uniqueness (Tones and OFFSETS)

James Ewen
 

On Tue, May 8, 2012 at 10:07 PM, Bob Bruninga <bruninga@usna.edu> wrote:

You are not reading ALL of the spec.
I sure try to, but as my wife will attest, I am very poor at reading
what is intended, I tend to read that is written. If you ask me to get
you a piece of blue paper, I will not give you a piece of red paper
even though that was what you intended to say.

 Notice the section on RECOMMENDED VOICE REPEATER OBJECTS further
down and also look at the original source http://aprs.org/localinfo.html
Yup, been there read that numerous times, and quoted it quite often. I
don't see anything different there than what is in the freqspec.txt
document.

;FFF.FFxyz*111111zDDMM.hhN/DDDMM.hhWrTnnn RXXm NETxxxxxx MTGxxxxx .........

and also all of the examples in http://aprs.org/fix14439.html all of which DEFINED
freqeuncy Objects going back to about 2005 and PRECEEDED the writing of the
SPEC in around 2008.
I can't seem to find a single example on that page at all... all I
find is a link to the page above.

In all three cases, the format of Tnnn -xxx is clearly defined for FREQ objects.
 This is clearly defined in the spec also as noted above.
I'm blind as I am missing this in the three documents, of which only 2
are referenced. I'd love to be able to agree that you have defined
what you say, but I can not for the life of me find any examples.

It has become clear that it was accidentally left out of the examples
in the middle of the spec, but that is because there is an entire section
of the spec further down that DEFINES it.
Again, I can not find that... how about copying and pasting these
blatant examples and definitions into your reply?

I Agree that this is confusing, and will correct this, but you are
DEAD WRONG when you keep putting out disinformation about
the Kenwood being non spec compliant.
I disagree... there's not enough information in the spec to define
what Kenwood is doing as being correct. Let's get the definitions
hashed out, and then create test packets, and observed result tables,
and then see who does what properly.

 And DEAD WRONG that FREQ OBJECTS do not contain TONE
and OFFSET as enumerated in GREAT DETAIL in all three of the
above references.
Paraphrasing Jerry Maguire... show me the definition.

I do believe that I have misinterpreted how the specification was
INTENDED to be implemented, but I can not find any proof or examples
that back up my new found concept. Please help me find the proof for
my new found faith!

Believe me Bob, I am one of your staunchest supporters for MOST of the
APRS specification. I beat people about the head and shoulders,
thumping people with my beat up copy of The New Testament of APRS
(Bob's Sermon on the Mount Edition). But I'm a skeptic, and really
need to be shown the light, and don't go on faith alone.


--
James
VE6SRV


Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

I noticed a new problem with the range finder. when parsing 145.130 I have the repeaters callsign of W3MIE parses it as 3mi range. Sent from my Droid Charge on Verizon 4G LTE


-----Original Message-----
From: James Ewen
Sent: 5/9/2012 3:55:36 AM
To: aprsisce@...
Subject: Re: [aprsisce] Re: FTM-350 FREQ OBJ problem?
 

On Tue, May 8, 2012 at 9:24 PM, Brian <n5brj@...> wrote:

> I do not find any reference to my FTM-350 supporting a FREQUENCY
> Object (frequency in the object name).  From what I can tell in the manual,
> it only parses a QSY frequency from the comment section.

That sounds like what we are hearing...

--
James
VE6SRV


Frequency On Water Objects

Brian
 

Now I'm seeing Frequency parses on Water Objects. I wonder if this was an unintentional consequence.

Brian
N5BRJ


Re: FREQ OBJECT Uniqueness (Tones and OFFSETS)

Robert Bruninga
 

James,

You are not reading ALL of the spec. Notice the section on RECOMMENDED VOICE REPEATER OBJECTS further down and also look at the original source http://aprs.org/localinfo.html and also all of the examples in http://aprs.org/fix14439.html all of which DEFINED freqeuncy Objects going back to about 2005 and PRECEEDED the writing of the SPEC in around 2008.

In all three cases, the format of Tnnn -xxx is clearly defined for FREQ objects. This is clearly defined in the spec also as noted above.

It has become clear that it was accidentally left out of the examples in the middle of the spec, but that is because there is an entire section of the spec further down that DEFINES it.

I Agree that this is confusing, and will correct this, but you are DEAD WRONG when you keep putting out disinformation about the Kenwood being non spec compliant. And DEAD WRONG that FREQ OBJECTS do not contain TONE and OFFSET as enumerated in GREAT DETAIL in all three of the above references.

Bob, WB4APR

---- Original message ----
From: James Ewen <ve6srv@gmail.com>)
 See my object 147.105md on the air.  Not only does my
D72 and D710 QSY, but they also properly do the weird
-500 KHz shift I included.
;147.105md*111111z3859.33N/07629.33WrT107 -050 R22m

You're good on the object name, position, tone, and
range, but there's a non-compliant offset direction
and magnitude included. There is no provision for an
offset and magnitude defined in the FREQUENCY OBJECT
specification.
and the offset is not a defined part of the
FREQUENCY OBJECT.
It most certainly is.  "Tnnn -xxx (or +xxx)"
works as it should for a FREQ object in my D710's
and D72's.


Re: FTM-350 FREQ OBJ problem?

James Ewen
 

On Tue, May 8, 2012 at 9:24 PM, Brian <n5brj@arrl.net> wrote:

 I do not find any reference to my FTM-350 supporting a FREQUENCY
Object (frequency in the object name).  From what I can tell in the manual,
it only parses a QSY frequency from the comment section.
That sounds like what we are hearing...

--
James
VE6SRV


Re: FTM-350 FREQ OBJ problem?

Brian
 

I've tried my best to keep up with these threads, but I don't know if this has been said yet. I do not find any reference to my FTM-350 supporting a FREQUENCY Object (frequency in the object name). From what I can tell in the manual, it only parses a QSY frequency from the comment section.

Has anyone seen a QSY work on the FTM-350 with a properly formatted FREQUENCY Object (using the object name)?

Brian
N5BRJ


Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

Hats held whirlwind approaching! Sent from my Droid Charge on Verizon 4G LTE


-----Original Message-----
From: James Ewen
Sent: 5/9/2012 2:11:31 AM
To: aprsisce@...
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?
 

On Tue, May 8, 2012 at 4:41 PM, Greg Depew <goatherder_4891@...> wrote:

> 435.075MHz t186 146.555rx sets the radio @ 435.075 correct tone
>  but still no 2m. 435.075MHz T186 146.555MHzrx did the same and
> i did not see any visible difference between T186 and  t186

Here's a little tidbit... if you are just trying to figure out how all
this works, and have little to no clue what is supposed to happen,
take a step back and wait for a bit. I know you're trying to learn,
and are doing a good job of it, but hang on for a bit.

You are trying to figure out what works with your radio. We are trying
to correct a discrepancy between the specification and the
implementation.

To be able to play in the hypothetical world, you need to really be on
top of what's going on. It is going to be very confusing if you don't
have a solid grasp on what we are discussing. I have to spend a lot of
time making sure what I am trying to say is accurate, and to try and
covey the information in a manner that can be understood by others. I
don't always succeed.

Then there's the fact that we all need to beat our heads together
until we all come to a consensus of what is currently happening, and
what it is we want to happen.

Having you attempting to manipulate packets and make other errors just
throws some extra noise in there. I'm not trying to be condescending
or "mightier than thou", just trying to make sure that we can hash
this out without being thrown a red herring now and then. You have the
right idea, and are headed towards the target, it's just that we are
trying to nail down the target currently.

This is fairly far beyond "normal user issues", and into the guts of APRS.

Hang onto your hat for a bit while this whirlwind spins around!

--
James
VE6SRV


Re: FTM-350 FREQ OBJ problem?

James Ewen
 

On Tue, May 8, 2012 at 4:41 PM, Greg Depew <goatherder_4891@hotmail.com> wrote:

435.075MHz t186 146.555rx sets the radio @ 435.075 correct tone
  but still no 2m. 435.075MHz T186 146.555MHzrx did the same and
i did not see any visible difference between T186 and  t186
Here's a little tidbit... if you are just trying to figure out how all
this works, and have little to no clue what is supposed to happen,
take a step back and wait for a bit. I know you're trying to learn,
and are doing a good job of it, but hang on for a bit.

You are trying to figure out what works with your radio. We are trying
to correct a discrepancy between the specification and the
implementation.

To be able to play in the hypothetical world, you need to really be on
top of what's going on. It is going to be very confusing if you don't
have a solid grasp on what we are discussing. I have to spend a lot of
time making sure what I am trying to say is accurate, and to try and
covey the information in a manner that can be understood by others. I
don't always succeed.

Then there's the fact that we all need to beat our heads together
until we all come to a consensus of what is currently happening, and
what it is we want to happen.

Having you attempting to manipulate packets and make other errors just
throws some extra noise in there. I'm not trying to be condescending
or "mightier than thou", just trying to make sure that we can hash
this out without being thrown a red herring now and then. You have the
right idea, and are headed towards the target, it's just that we are
trying to nail down the target currently.

This is fairly far beyond "normal user issues", and into the guts of APRS.

Hang onto your hat for a bit while this whirlwind spins around!

--
James
VE6SRV


Re: FREQ OBJECT Uniqueness

James Ewen
 

On Tue, May 8, 2012 at 3:15 PM, Bob Bruninga <bruninga@usna.edu> wrote:

Here's an object my peers in Calgary are sending in order to get
"proper" QSY functionality on their Kenwood radios.
;146.85-NH*111111z5106.50N/11405.92Wr146.850MHz T110 -060 R50k RYC

They insist that the radio will NOT QSY without the second
frequency in the comment, and the offset included.
Sorry, They need to re-check.  The OBJECT with only a FREQ in the name works
fine here.
I agree that they have it wrong... the format they use is not
compliant with the spec.

 See my object 147.105md on the air.  Not only does my D72 and
D710 QSY, but they also properly do the weird -500 KHz shift I included.
Here it is in all it's non-compliant glory!

;147.105md*111111z3859.33N/07629.33WrT107 -050 R22m

Check it against the specification for a FREQUENCY OBJECT

;FFF.FFFxy*111111zDDMM.hhN/DDDMM.hhWrT079 R25m NETxxxxxx MTGxxxx...

You're good on the object name, position, tone, and range, but there's
a non-compliant offset direction and magnitude included. There is no
provision for an offset and magnitude defined in the FREQUENCY OBJECT
specification.

The second frequency according to the current spec
should be interpreted as the RX frequency,
Only if it is a crossband repeater.  Otherwise only the OBJECT NAME or the
COMENT text has the frequency, not both.  Transmitting a packet with both is
not spec compliant unless it is a crossband repeater or split that cannot be
formatted into +xxx or -xxx.
There is nothing that says the RX frequency HAS to be in another band.
Normally one would not specify both the RX frequency AND offset, but
should that happen, the RX frequency should take priority. Kind of
like trying to figure out which icon to use when there's an SSID and
an icon described in the packet... the icon in the packet wins. Only
allowing an offset can create a problem when the offset require more
precision than x.xx MHz can provide. If you have some wonky repeater
on 144.100, and 147.995, the current offset can't describe that
abomination. (Yes I know 144.100 is a CW calling frequency, just an
illustration)


and the offset is not a defined part of the FREQUENCY OBJECT.
It most certainly is.  "Tnnn -xxx (or +xxx)" works as it should for a FREQ
object in my D710's and D72's.
The whole basis of this discussion is that the KENWOOD line is NOT the
authority on the specification. Kenwood has implemented their
interpretation of what they think you have written on your
freqspec.txt page. There is nothing indicating that an offset can be
included in a FREQUENCY OBJECT packet. The offset description only
applies in the POSITION COMMENT as per YOUR specification.

I know the Kenwood will QSY without the second frequency
as I use it on all of the FREQUENCY OBJECTs that I send from my
digipeaters.

Then it is disingenuous for you to be blogging that the Kenwood is non spec
compliant when it actually is.
It is NOT spec compliant... we have shown you example after example,
and you yourself have proven that it is not spec compliant with your
147.105md object above. By having the Kenwood change the offset to
-500 kHz, it proves that the Kenwood looks for an offset where there
should NOT be one.

I'm thinking that they have come up with this hybrid
to make BOTH the Yaesu and Kenwood "work".
We do have to figure out a solution.  But I don't see how you can claim the
Kenwood is not spec compliant.  We have to be careful of spreading
disinformation.
I believe we have a solution at hand, but trying to get you to see the
light is taking quite a while. Hopefully you will take the time to see
that what you have written down as a specification is not what you
THINK you have written down.

Specification has the word "specific" in it because when you define a
specification, you have to be very specific in your wording and
definition. Any ambiguity will be seized upon by the masses and
screwed up beyond belief, case in point right here.

Now, if we modify the specification slightly to remove the
inconsistencies between the two different formats, and make it work
like you "THINK" it is supposed to work, as well as how Kenwood and
Yaesu have implemented it, we can make everyone happy.

The problem is that the specification and the current implementations
are not the same. You can't expect people to implement things going
against the specification without dealing with the conflict. We should
be able to bring the specification to a place where it no longer
contains any ambiguity, and describes what has been implemented in
existing hardware.

--
James
VE6SRV


Re: {Some tags disabled} Re: FREQ OBJECT Uniqueness

Lynn Deffenbaugh
 

On 5/8/2012 9:08 PM, James Ewen wrote:
And that's what we are saying... tell people the frequency of the repeater.

Yes, it is possible to use the callsign appended with -R in an object
name, but the numeric frequency stands out from the rest of the
callsigns much more than looking for a -R in amongst the other SSIDs,
as well as immediately conveying the information to the end user.
But another thing to consider is the recommendation that only the BEST repeater, most likely to have someone listening is being advertised under the local information initiative. So, you chose one or two repeaters to beacon the frequency objects and put all fo the more local repeaters under their callsigns to allow quick QSY/Tune, but not necessarily catch the visitor's attention.

There's plenty of room for us all to operate within our preferences and proclivities, and not bludgeon each other into one particular mold.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS. Yes, I had to look up proclivity to make sure I was using it properly and not putting my foot into my mouth...


Re: {Some tags disabled} Re: FREQ OBJECT Uniqueness

James Ewen
 

On Tue, May 8, 2012 at 2:58 PM, Keith VE7GDH <ve7gdh@rac.ca> wrote:

So when I come to visit you, and you tell me to go to VE7RSI, what frequency
should I have on my VFO?
If you were talking to me on voice, you would probably already be on the
right frequency.
Standing in the same room talking to each other? Talking on the phone?
Talking on another repeater?

Okay let's go the other way... you come to Edmonton and as you are
driving into town from the west on the Yellowhead highway, you happen
to find the 146.640 repeater (maybe because it showed up on the
display of your rig as an APRS object???)... You call and I hear you,
we chat away, but you start to get weak into the repeater because you
are getting out of range. I suggest a new repeater that will be closer
to you, saying "Keith, you're running out of range of this repeater...
let's go to VE6VPR.", and I immediately change channels expecting you
to follow me over to the new repeater. What are the chances that
you're going to follow me to the new repeater?

If I told you to move over to 145.290, I'd probably have better luck
having you follow me.

If you we were somewhere else and you wanted to know
the frequency of a particular repeater, I would just tell you.
And that's what we are saying... tell people the frequency of the repeater.

Yes, it is possible to use the callsign appended with -R in an object
name, but the numeric frequency stands out from the rest of the
callsigns much more than looking for a -R in amongst the other SSIDs,
as well as immediately conveying the information to the end user.

If you want to obscure the information from the travelers in your area
and go against the "suggested standard", that's up to you. The
suggested implementation is just that, and it is what travelers will
be looking for.

Then there's the convention used by Echolink where a callsign-R
designates an echolink node on a repeater. People may tune to the
repeater expecting to find an echolink node.

You could decide that traffic lights need to be arranged in a circle,
and the colours should be blue, orange, and white, and have that
implemented in your local area... how much of an issue would that
create for visitors? Obviously the locals understand the configuration
and colour choices, but the guys wandering in for a visit are going to
be perplexed.

--
James
VE6SRV


Re: tap on ME view

Lynn Deffenbaugh
 

Fred, can you verify in the latest Dev version that I've got this fixed?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/3/2012 9:58 AM, Fred Hillhouse wrote:
I have several comments to pick from. Mostly they are of frequencies of repeaters I frequent. I also have a couple others, "[Scanning]", "unavailable" and of course "147.052MHz". If you look at the APRS.FI raw history for N7FMH-12 you can see a few.
 
In APRSISCE, if you click on ME, the second line in the window that comes up has a comment. For you [-12], you have Time (0:00:00) Biking for lunch. Yep, you need to refresh. :)
 
If I change my comment, the actual transmitted data is correct. It is the newly selected comment, however, the comment listed under ME doesn't get updated.
 
I just checked APRSIS32 and it responds the same way. The window from clicking on ME doesn't get undated.
 
I believe it does not persist across power-up. I think I tested that.
 
Best regards,
Fred, N7FMH
 
 
 


From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Lynn W Deffenbaugh (Mr)
Sent: Wednesday, May 02, 2012 22:18
To: aprsisce@...
Subject: Re: [aprsisce] tap on ME view

 

I'm afraid I don't totally understand where it said "unavailable"; in the popup menu, the station information popup, or Configure / Beacon / Comment?

Did the situation persist across a restart?  If so, please e-mail your APRSISCE.XML file to KJ4ERJ@... and mention this issue.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/2/2012 7:23 PM, fmhillhouse@... wrote:

Hi Lynn,

APRSISCE Dev.

As I was driving home tonight I click on my ME icon. I notice the comment was "unavailable". I use it when I am in the office. I had set it to 140.105MHz when I hit the road. When I got home, I checked APRS.FI and the correct comment had been sent for the bulk of the trip. Near the end I changed it around a bit and the APRS.FI record reflected each change but the station view did not.

I had noticed this before but thought I had not set it correctly so it is not a very recent change. But I cant say when I first noticed it.

Best regards,
Fred, N7FMH





Re: FREQ OBJECT Uniqueness (CLARIFIED)

Robert Bruninga
 

Its just that the comment for a FREQ OBJECT does not expect
to contain the frequency since it is already included in the
object NAME. In this case, only the TONE and offse...are needed.
And our point is that no way we can read the current spec
implies that that is legal.
You might try reading down to the section called:

RECOMMENDED VOICE REPEATER FREQUENCY OBJECTS:
---------------------------------------------

Please see: http://aprs.org/localinfo.html

OBJECT NAMES: Every New-N Paradigm APRS digipeater is supposed to
periodically transmit an OBJECT showing the locally recommended
voice repeater frequency for travelers visiting the digi's own coverage
area. APRS software should be able to locate these frequencies as
well. The format for these frequency object names is as follows:

OBJECTNAME
----------
FFF.FFF-z 5KHz repeaters with up to 62 unique (z) ID's
FFF.FFFyz 5KHz repeaters with up to 2700 unique (yz) ID's
FFF.FF-yz 10kHz repeaters with over 3600 unique (yz) ID's
FFF.FFxyz 10kHz using three xyz unique characters...

Choose letters to make your repeater frequency unique in all the world
so that it can be easily found by wildcarding the callsign FFF.FF*.

The rest of the OBJECT format contains the TONE and RANGE and any
specific information on regular net times and meeting dates. The
format for these FREQ OBJECTS is:

;FFF.FFFxy*111111zDDMM.hhN/DDDMM.hhWrT079 R25m NETxxxxxx MTGxxxx...

(15 Jun 08 change. Eliminated the leading space before the T079)

Where T079 is a tone of 79.7 Hz (always drop the tenths)
Where R25m is a Range of 25 miles (or k for km)
Where NETxxxxxx is something like "Net Tu9PM" or "Net Tu730"
Where MTGxxxx is something like "Mg3rdTu" and must be 7 bytes
Where ... 9 more bytes are possible but won't show on mobiles

---------------------------------------------------------------------
Is it any wonder so many of us are confused about what
is and is not allowed to be FreqSpec compliant?
I can see the confusion. But the format was clear in both this section and
ALL Of the examples in the http://aprs.org/localinfo.html pages which is
where all the guidance for setting up the FREQ OBJECTS was in the first
place.

But I agree that I need to clarify this up in the position/object comment
area.

Bob, Wb4APR


Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

435.075MHz t186 146.555rx sets the radio @ 435.075 correct tone  but still no 2m. 435.075MHz T186 146.555MHzrx did the same and i did not see any visible difference between T186 and  t186


To: aprsisce@...
From: goatherder_4891@...
Date: Tue, 8 May 2012 18:36:14 -0400
Subject: RE: [aprsisce] FTM-350 FREQ OBJ problem?

 

i set the obj 144.630PA(name) 145.230MHzrx T123 and the ftm 350 correctly took the input from the name but not the tone however if i make an object 144.630P(name) 145.230MHz T123 it sets the radio in simplex with the correct tone.


To: aprsisce@...
From: kj4erj@...
Date: Tue, 8 May 2012 18:28:47 -0400
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?

 
You are now at the point that spawned a bunch of the recent traffic in this group as well as in the aprssig.  The answer is, "we don't know yet".  The FTM-350 seems to now be shown to completely ignore any frequencies in the object name and only uses frequencies from the comment regardless of the name.

The testers are still trying to figure out what all to test to verify what the existing APRS radios do, and then we need to figure out just what standards will work with the most existing stuff and break the least stuff, and then document that sufficiently for the future.

So, you now probably have objects that work with both Kenwoods and FTM-350s, regardless of the fact that APRSISCE/32 says they're non-compliant.  They are, per the current spec, but they need to be or the FTM-350 won't use it.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/8/2012 6:22 PM, Greg Depew wrote:
ok so now the big question is how should the objects look like? if 145.230-w 145.230Mhz T186 -060 is ok but not because the name is the freq do we need to change the name? and i just made a cross-band obj 146.555(name) 435.075MHz t186. The ftm 350 qsy's to 435.075 with tone 186.2 but does not cross band to the 146.555 in the name.


To: aprsisce@...
From: kj4erj@...
Date: Tue, 8 May 2012 18:02:38 -0400
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?

 
Because with the current spec, the object name's frequency should never match the frequency specified in the comment.  Per the spec, this would be defining a simplex station with the same transmit (object name) ad receive (comment) frequencies.  (Parentheticals are relative to the repeater being defined).

Lynn (D) - KJ4ERJ - Author

On 5/8/2012 5:56 PM, Greg Depew wrote:
that is what my current objects have and aprs32 is saying non compliant. KB3KBR Greg


To: aprsisce@...
From: kj4erj@...
Date: Tue, 8 May 2012 17:48:08 -0400
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?

 
It's supposed to be the MHz that's necessary, not the rx.  Name your object 145.230-w (or whatever you want), but make the comment "145.230MHz T186 -060" (no quotes, of course) and it should work.  Note the absence of the rx.

Lynn (D) - K4JERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/8/2012 5:44 PM, Greg Depew wrote:
if theres no rx after the 145.230 the 350 goes to simplex, and if i have an obj 145.230-w(name) T186 -060 it will NOT  qsy. KB3KBR Greg


To: aprsisce@...
From: kj4erj@...
Date: Tue, 8 May 2012 17:34:34 -0400
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?

 
You probably don't need the rx after the MHz, actually.  And to be clear, which "it" now qsy's properly?  A D72?  or something else?

And the name is still supposed to be the repeater's OUTPUT frequency, the frequency that a user would LISTEN to.  The frequency in the packet (per spec) is supposed to be the repeater's non-standard INPUT frequency.  If your Kenwood radio going the other way, I suspect it's ignoring the frequency in the object name in favor of the one in the comment.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/8/2012 5:30 PM, Greg Depew wrote:
I have now created an obj 144.630PA(name) 145.230MHzrx T123. It now qsy's properly. Although i think its very confusing to see the input in the name rather than the output, especially when using a non qsy-able rig such as the vx8g.


To: aprsisce@...
From: kj4erj@...
Date: Tue, 8 May 2012 17:21:56 -0400
Subject: Re: [aprsisce] FTM-350 FREQ OBJ problem?

 
On 5/8/2012 5:00 PM, James Ewen wrote:
> Lynn, can you show me again where there's the FFF.FFFMHz definition
> for the rx frequency in the FREQUENCY OBJECT definition. I've got 3
> versions of the freqspec document open and I can't find it...

There isn't. The only provision for a second frequency in a FREQUENCY
OBJECT is in the following statement:

> If both the object name and the
> comment contain a frequency, then the name is considered the transmit
> frequency for the object and the frequency in its comment text is
> its crossband or non-standard split receive frequency.

According to how I read the following quote, NONE of the nice 1st/2nd 10
character stuff applies to frequency objects, you get the frequency in
the object name and that's all! Because everything else REQUIRES an
FFF.FF MHz or FFF.FFFMHz in the first 10 bytes which, by what I quoted
above, would be the transmit frequency.

> APRS FREQUENCY FORMATS:
> -----------------------
>
> There are two Frequency formats. The POSITION COMMENT format includes
> the frequency as FFF.FFFMHz in the free field text of a normal
> position or object report as noted above. The other is called the
> OBJECT format because it puts the Frequency in the OBJECT NAME using
> the format of FFF.FFxyz so that it shows up very clearly on the
> radio's positions list. Of course, an object can also have a frequency
> in its position comment as well. If both the object name and the
> comment contain a frequency, then the name is considered the transmit
> frequency for the object and the frequency in its comment text is
> its crossband or non-standard split receive frequency.
>
> As noted before, a 10x10x+ format is used for the POSITION COMMENT
> format for best display on the existing variety of APRS radios. Here
> are the standard 10-byte formats. Please note that spaces are
> required where shown. In some cases a "_" may be shown for clarity
> in this document, but in the actual format, a SPACE should be used:
>
> 1st 10-BYTES Frequency Description
> ---------- -----------------------------------------------------
> FFF.FF MHz Freq to nearest 10 KHz
> FFF.FFFMHz Freq to nearest 1 KHz
>
> Examples:
> 146.52 MHz Enroute Alabama
> 147.105MHz AARC Radio Club
> 146.82 MHz T107 AARC Repeater (Tone of 107.2)
> 146.835MHz C107 R25m AARC (CTCSS of 107.3 and range of 25 mi)
> 146.805MHz D256 R25k Repeater (DCS code and range of 25 km)
> 146.40 MHz T067 +100 Repeater (67.8 tone and +1.00 MHz offset)
> 442.440MHz T107 -500 Repeater (107.2 tone and 5 MHz offset)
> 145.50 MHz t077 Simplex (Tone of 77.X Hz and NARROW band)
>
> 2nd 10-BYTES Optional Added fields (with leading space)
> ---------- -----------------------------------------------------
> _Txxx RXXm Optional PL tone and nominal range in miles
> _Cxxx RXXm Optional CTCSS tone and range in miles
> _Dxxx RXXk Optional DCS code and nominal range in kilometers
> _1750 RXXk Optional 1750 tone, range in km, wide modulation
> _l750 RXXk Optional 1750 tone narrow modulation (lower case L)
> _Toff RXXk Optional NO-PL, No DCS, no Tone, etc.
> _Txxx +060 Optional Offset of +600 KHz (up to 9.90 MHz)
> _Exxm Wxxm East range and West range if different (N,S,E,W)
> _txxx RXXm Lower case first letter means NARROW modulation
> _FFF.FFFrx Alternate receiver Frequency if not standard offset

THIS is why we need to unify the specification to ALLOW a frequency as
the object name, but define ONE AND ONLY ONE set of parameters for the
Position Comment that provides ALL of the required information.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32











18341 - 18360 of 35629