OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   05.05.07 08:03l 250 Lines 9836 Bytes #999 (0) @ WW
BID : 10104-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 34 #24, 5/5
Path: DB0FHN<DB0FOR<DB0SIF<HB9EAS<DB0FSG<OE7XLR<OE2XUM<DB0WGS<OE6XPE<IW2OHX<
      I0TVL<DK0WUE<F4BWT<F6KMO<7M3TJZ<ZL2BAU
Sent: 070505/0543Z @:ZL2BAU.#79.NZL.OC #:46305 [Waimate] $:10104-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To  : APRDIG@WW

Message: 31
Date: Tue, 24 Apr 2007 09:43:44 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: [aprssig] RE: "Local Info" confusion...

>I see the "local info" initiative has yet made another
>change in the format... I'm not sure why to change when
>the previous method is working just fine.  Please explain

Thanks, I'll share the response with the APRSSIG.  When Alabama implemented
this in all their digis, it was soon observed that all Uiview clients would
mark the DIGIPEATERS as IGATES that were the source of these 3rd party
voice repeater objects.  This is the wrong method for detecting Igates, but
we are stuck with it, and Uiview cannot be changed.

So rather than having every digi being marked with the IGATE square around
it, we decided to abandon that approach and go back to the original OBJECT
format.  And rather than have the PHG data that takes up 7 bytes and also
is not displayed on Uiview, and not easy to interpret on the front panel of
the radio, we came up with this very concise display:

147.105-D  - The "D" is for Davidsonville (location)
T107 R30m  - Tone and reliable Range in miles
Net 8PM Tu - Net time
MTG 8Th    - Meeting time

The idea was to have everything a visitor would want to see right there on
the front panel of his radio every 10 minuets. And at no-cost to the
network since these objects are ONLY DIRECT and are originated by the DIGI
which will not TX until the channel is clear.

If it is DCS instead of tone and metric, then it is "D234 R15k" It's a
fantastic resource for all of HAM radio travelers.

Oh if the range is different in one direction than another, then this is
also possible "N15 S35mi "  which means a the repeater favors the south by
35 miles and only 15 miles to the North.

Hope that helps.

For details see: http://www.ew.usna.edu/~bruninga/localinfo.html

Bob, WB4APR

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

Message: 32
Date: Tue, 24 Apr 2007 09:47:08 -0400
From: "Wes Johnston, AI4PX" <wes_at_kd4rdb.com>
Subject: Re: [aprssig] FW: Garmin Rino protocol

I think the trick would be to simply record the polling message and clean up
the wav file (in this case).  I gave up trying to decode on air (not that
the 600baud signal is that difficult, it was more of a time issue), and use
use a "dummy" rino110 in our comms trailer hooked to an external antenna.
It hears all the local rinos and a script downloads the waypoints every 10
seconds and looks for the changes.  Any changes in waypoint position cause
that waypoint to be forwarded to an xastir server port.

I have some rinos and can play however.

Wes

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

Message: 33
Date: Tue, 24 Apr 2007 07:53:10 -0700 (PDT)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: Re: [aprssig] Tactical call signs

On Mon, 23 Apr 2007, John Habbinga wrote:

>This might be legal as long as you don't setup your path for digipeating and
>you don't use APRS messaging through an I-Gate to RF.
>
>>Yep.  Legal.  Not only that, you can even identify in Morse code
>>every 10 minutes and keep everything tactical.  That satisfies the
>>FCC identification rules.  Of course that last would probably be
>>considered bad practice, but it's certainly allowed.

It's legal in _any_ case.  In the last case I wouldn't be transmitting on
RF at all, the igate would.  For the first, I only have to identify my own
transmission, not my digipeated transmission.

Yes, there's obviously a problem here regarding how the igate or the
digipeater might authenticate the packet as coming from a ham, but it's not
a rules violation for the original person sending the packet to send it
with tactical calls and/or CW ID every 9.x minutes.

You obviously think otherwise.  Please quote the sections in the FCC rules.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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

Message: 34
Date: Tue, 24 Apr 2007 07:58:29 -0700 (PDT)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: Re: [aprssig] Tactical call signs

On Mon, 23 Apr 2007, John Habbinga wrote:

>I was responding to the use of CW for use as an ID when using a digipeater.
>Since CW will not translate through a digipeater, then you can't use it as
>an ID when using a digipeater.  Your callsign needs to be contained in the
>UI frame.  Where in the UI frame probably doesn't matter, as long as it is
>somewhere that the digipeater will not strip it out.

Sorry to be so pedantic here, but it doesn't say the above in the FCC
rules.

I know the CW ID thing is a bit off-center, but it illustrated the rules
nicely which is why I mentioned it.  Another case closer to APRS usage
might be:   Using tactical callsigns for a station or digi with a longer
path (wide2-2 or wide3-3) but ID'ing with your callsign to a shorter path,
even no path at all.  This is also legal and perhaps more in keeping with
the original thread topic.

Again, I wouldn't actually _do_ CW ID thing when using APRS, as I consider
it very bad practice.  It's legal though.  The one case where I _would_ do
it is when using an older TNC as a fill-in digi and it didn't do callsign
substitution.  Then I _must_ enable CW ID every 9.x minutes in order to
keep things legal, at least if anyone every actually digipeated through it.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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

Message: 35
Date: Tue, 24 Apr 2007 07:59:29 -0700 (PDT)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: Re: [aprssig] Tactical call signs

On Mon, 23 Apr 2007, John Habbinga wrote:

>The radio operator of the originating message cannot use CW to ID the
>transmission if he has set the path so that it will go through a digipeater.

Quote an FCC regulation for that please.  Thanks.  :-)

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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

Message: 36
Date: Tue, 24 Apr 2007 08:02:56 -0700 (PDT)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: Re: [aprssig] Tactical call signs

On Mon, 23 Apr 2007, Matt Werner wrote:

>For digis I have seen and/or operate, the callsign IS in the packet.
>My point is that it doesn't need to be in the 'from' field of the
>packet, just somewhere IN the packet.

Doesn't even need to be in _that_ packet, just _some_ packet, or even CW
ID, and the packet can be set to go out to NO PATH AT ALL.

As long as you are identifying every 10 minutes (if it has transmitted at
all in the previous 10 minutes) in some manner, whether AX.25 or CW, then
you're meeting the FCC identification regulations.

How do most voice repeaters operate?  ;-)

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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

Message: 37
Date: Tue, 24 Apr 2007 08:14:52 -0700 (PDT)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: Re: [aprssig] Tactical call signs

For what it's worth, a quick read of section 97.119 of the rules should
clarify what's required for transmitter identification:


97.119(a), 97.119(b)(1), and 97.119(b)(3) are the relevant portions.

Looks like I could also identify my APRS or packet transmissions using
voice as well.  Again, not good practice, but legal.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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

Message: 38
Date: Tue, 24 Apr 2007 09:47:58 -0700
From: "Keith VE7GDH" <ve7gdh_at_rac.ca>
Subject: Re: [aprssig] RE: "Local Info" confusion...

Bob WB4APR wrote...

>When Alabama implemented this in all their digis, it was soon
>observed that all UI-View clients would mark the DIGIPEATERS
>as IGATES that were the source of these 3rd party voice repeater
>objects.

That isn't my observation here. There's a stand-alone TNC-based digi at my
elbow that is beaconing an object for the local repeater. I'm viewing it in
UI-View and it just shows as an "antenna" symbol and isn't marked as being
an IGate. I don't see a problem here, so nothing needs to be fixed, but I'm
curious why that would happen in Alabama.

Also, at www.ew.usna.edu/~bruninga/localinfo.html you say "Because of
errors in UI-View which prevents the display of PHG range data and also
prevents the use of the 3rd party format, we cannot use the very valuable
PHG data for showing the ranges of these voice repeaters." UI-View "out of
the box" doesn't display PHG but with the UI-PHG add-on that is freely
available, it does. I just checked and it displays the PHG just fine for
the local repeater that the digi is sending out as an object. What do you
mean by "errors in UI-View"? Someone reading that without prior knowledge
of UI-View might take it at face value.

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

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

aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

End of aprssig Digest, Vol 34, Issue 24



Read previous mail | Read next mail


 18.05.2024 18:36:11lGo back Go up