Date   

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












Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

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











Re: FTM-350 FREQ OBJ problem?

Fred Hillhouse
 

One thing that should be added for any tester is the revision of radio software. Revisions will play a part.
 
Best regards,
Fred, N7FMH
 


From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Lynn W Deffenbaugh (Mr)
Sent: Tuesday, May 08, 2012 18:29
To: aprsisce@...
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










Re: FTM-350 FREQ OBJ problem?

Lynn Deffenbaugh
 

Try an object with any name, that has a body of:

435.075MHz t186 146.555rx

and see what the FTM-350 does. Assuming you did mean it to be narrow as well? Otherwise, it'd be T186 for wide. And then try the opposite as well (different name maybe):

146.555MHz t186 435.075rx

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










Re: FTM-350 FREQ OBJ problem?

Lynn Deffenbaugh
 

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










Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

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









Re: FREQ OBJECT Uniqueness (Ah HA!)

Robert Bruninga
 

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.
It may WORK, but according to the SPEC, that's
only allowed in the SECOND 10 characters of the comment!
Ah ha! Now we are getting somewhere. I can see your point. The intent of
that section is to show how the first 10 bytes and the second ten bytes are
used in the position/object comment fields.

Although the fact that the first 10 bytes are NOT NEEDED in a FREQ object,
and therefore the 2nd 10 slide up to be the first 10 is not explicitly
stated, only assumed to be obvious..

Yes, this does need to be clarified. Especially, since when the first 10
bytes are absent, then the leading space is not required.

Bob, Wb4APR



2nd 10-BYTES Optional Added fields (with leading space)
---------- -----------------------------------------------------
<Extra examples removed>
_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)
Yep, Bob just proved that the D710 and D72 are non-spec compliant
because they're mixing the definitions of a FREQUENCY OBJECT with the
attributes of a POSITION COMMENT without requiring the (optional)
frequency to appear as the 1st 10 bytes of the packet.

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.
Nope, show me, step by step, how the spec as currently written allows
for a FREQUENCY OBJECT's comment to start with a tone and offset?

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.
Agreed. That's why we're pushing for a unified specification of ONE
repeater frequency definition with an OPTIONAL (but recommended)
frequency as the object name.

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



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

Yahoo! Groups Links


Re: FTM-350 FREQ OBJ problem?

Lynn Deffenbaugh
 

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








Re: FREQ OBJECT Uniqueness

Robert Bruninga
 

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.
Where'd you get "cannot be formatted"? All I read is
"non-standard", not "cannot be formatted" in:
Example, an offset of 625 KHz cannot be formatted using xxx.
Neither can an offset of 10.25 MHz.

Bob, WB4APR


Re: FTM-350 FREQ OBJ problem?

Greg Depew
 

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







Re: {Some tags disabled} RE: FTM-350 FREQ OBJ problem?

Robert Bruninga
 

so that means make an obj 144.630PA 145.230Mhzrx T123 ??
That works / doesn't work for me on a D72. The radio tuned OK,
but it went to 144.630 simplex, no offset, no tone.
That is because when there is a FREQ OBJECT with the FREQ in the name, then
it expects to find the Tnnn as the first bytes of the comment.

I still haven't been able to come up with any combination
where I can get the D72 to tune to a specific offset...
Just follow the spec. Works every time. For a freq object with the freq in
the name, then just put Tnnn -xxx in the start of the comment and it will
work every time

Bob, Wb4aAPR


Re: FREQ OBJECT Uniqueness

Robert Bruninga
 

Please. The message was referring to 6.25KHz steps. I did not think I had
to include a sentence saying "6.25KHz steps ONLY APPLIES if you are set to
6.25 KHz steps".

Or do I need to say "6.25 KHz steps do not apply if your radio is set to 5
KHz steps".

Please can we keep the noise level down by only making substantive comments.

Bob, Wb4aPR

-----Original Message-----
From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf
Of Keith VE7GDH
Sent: Tuesday, May 08, 2012 4:50 PM
To: aprsisce@yahoogroups.com
Subject: Re: [aprsisce] FREQ OBJECT Uniqueness

Bob WB4APR wrote...

145.006xy will tune to 145.00625
Not on the D72A that I have in front of me. I believe that it is
because the radio tunes in 5 kHz steps.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"


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

Yahoo! Groups Links

18221 - 18240 of 35498