OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   05.06.03 09:28l 416 Lines 12789 Bytes #999 (0) @ WW
BID : 1423-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 30, 2/5
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<DB0EEO<DB0RES<ON0AR<VK6HGR<
      ZL2BAU<ZL3VML
Sent: 030604/1335Z @:ZL3VML.#80.NZL.OC #:1678 [Chch-NZ] FBB7.00i $:1423-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Local Gov. vs. FCC Regulations???
From: "Gilson, Ron" <RGilson@ecmc.edu>
Date: Fri, 30 May 2003 07:44:50 -0400
X-Message-Number: 9

Sorry I must have missed something on local gov regulating CB & other radio
coms.  What ever happened to the rules & enforcement of the FCC (1934 &
amendments).  Could some one e-mail the article which some on list are
talking about.  Thank you.
Ron
WA2WWK

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

Subject: RE: Broadband on Power --City(not FCC) enforces   radio law and busts
CBer
From: Alex <kr1st@amsat.org>
Date: Fri, 30 May 2003 07:59:05 -0400
X-Message-Number: 10

A city does have the right to enforce FCC rules when it comes to
unauthorized CB equipment or unauthorized operation of CB equipment
between 24 and 30 MHz.

The amendment:

http://www.arrl.org/news/stories/2000/11/29/3/cbbill.html

The story:

http://www.arrl.org/news/stories/2000/11/29/3/?nc=1

73,
--Alex KR1ST (- --. .. ..-.)

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

Subject: Re: Local Gov. vs. FCC Regulations???
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Fri, 30 May 2003 08:02:52 -0400
X-Message-Number: 11

>Sorry I must have missed something on local gov regulating CB & other radio
>coms.  What ever happened to the rules & enforcement of the FCC (1934 &
>amendments).  Could some one e-mail the article which some on list are
>talking about.  Thank you.
>Ron
>WA2WWK

Well, this is getting 'generic' enough that I'll answer here.

First, real the links from Alex.

You will see that localities CANNOT enact new rules.  Well, they
can, but they would have little teeth.

What localities CAN do is enact laws that MIRROR rules and regs
from the FCC so that they can easily be enforced at the local level.

All that as changed is the ability of localities to enact the SAME or
LESS restrictive rules so that they can be enforced LOCALLY.

Mike

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

Subject: Re: 10M FM OPEN! 1.a.m EST
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Fri, 30 May 2003 08:42:44 -0400
X-Message-Number: 12

Matthew Stennett wrote:
> 
>GO GET IT!
>10M FM band WIDE open  on East Coast, Friday,  1a.m.

It was an Auroral-E event.  Sporadic-E that comes after a particularly
intense aurora.  It was observed on 6m, too.

Ev, W2EV

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

Subject: CB enforcement
From: Mark Kempisty <kempistyNO1MORE2JUNK@pav.research.panasonic.com>
Date: Fri, 30 May 2003 10:23:16 -0400
X-Message-Number: 13

If I remember correctly, the enforcement powers the FCC is now allowing
municipalities to take is only for CB interference.  If its another
service, the job goes back to the FCC.

As to FCC responsiveness, my club -- Warminster Amateur Radio CLub -- in
Suburban Philadelphia had a interference on our two meter repeater.  One of
the members called the FCC interference hotline, reported it and then
figured it would go into that great big bureaucratic black hole.  He was
shocked when a field engineer from the Philadelphia office called him the
next day asking for more details.  They spent almost a full work week
tracking it down but not being able to localize it.  The engineer searched
on and off for the problem over the course of a year with the best result
that it was somewhere in northern New Jersey.  He had a meeting to go to in
North Jersey and decided to take one of the tracking vans.  After the
meeting, he parked on a high hill and started sweeping the area and got a
strong signal.  Moving to another hill gave him a second baseline and the
plotting software gave a short list of the possibilities.  Within 36 hours
the spur from the Warren County emergency services data transmitter was
fixed.  It took a year, but he wasn't going to let this one beat him.

-- Mark N3GNW

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

Subject: Re: CB enforcement
From: Earl Needham <needhame@yucca.net>
Date: Fri, 30 May 2003 10:25:18 -0600
X-Message-Number: 14

At 10:23 AM 5/30/2003 -0400, Mark Kempisty wrote:
>If I remember correctly, the enforcement powers the FCC is now allowing 
>municipalities to
>take is only for CB interference.  If its another service, the job goes 
>back to the FCC.

         Correct.

         But what I'm trying to say is that the general public (most local 
cops included) have no idea of the difference and will most likely try to 
enforce CB rules on US.

         Earl

Earl Needham, KD5XB, Clovis, New Mexico  DM84jk
KD5XB-2>APW251,PCSAT-1%:=3425.83N/10313.55W-PHG7150/WinAPRS 2.5.1 
-EARL_CLOVIS -251-<630>
SETI@Home: 10657WU/6.94yrs!

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

Subject: Re: fourth.aprs.net information....
From: "Phil Pacier, AD6NH" <ad6nh@arrl.net>
Date: Fri, 30 May 2003 12:39:21
X-Message-Number: 15

On 05/30/03, ""Dave Anderson" <dandersn@citicom.com>" wrote:
>Hi,
> 
>Just an update --- APRSFL has agreed to move into a core aprs-is server
>position, taking fourth.aprs.net.   We've also been added to
>rotate.aprs.net.
> 
>We are going to keep our identity as APRSFL, and continue to offer both full
>feeds -and- custom feeds as we have in the past.  Basically, nothing has or
>will change in how we run the server, just a new classification which should
>allow us to meet the needs of even more users worldwide.

Just a thought here - if your configuration is not changing, and you are 
still meeting the needs of -all- users, then how does a new classification 
do anything to help or harm your purpose?  A rose by any other name....

Phillip Pacier - AD6NH
http://www.aprsca.net

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

Subject: The GPS Sentences
From: T C <boytroy54@yahoo.com>
Date: Fri, 30 May 2003 10:47:22 -0700 (PDT)
X-Message-Number: 16

What do the GPS Sentences that are sent out stand for?

They look like a basic language string variables...

Are they the reason that certain data are displayed properly on the APRS+SA
program?

Thanks,

73 de w8tcc, troy

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

Subject: RE: The GPS Sentences
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Fri, 30 May 2003 18:01:59 -0000
X-Message-Number: 17

See http://www.commlinx.com.au/NMEA_sentences.htm or
http://www.mae.okstate.edu/classes/conner/mae3113/handouts/Common%20GPS%20NM
EA%20sentences.htm.

Some common sentence types:

$GPGGA
 Global positioning system fix data
 
$GPGLL
 Geographic position - latitude / longitude
 
$GPGSA
 GNSS DOP and active satellites
 
$GPGSV
 GNSS satellites in view
 
$GPRMC
 Recommended minimum specific GNSS data
 
$GPVTG
 Course over ground and ground speed

Scott
N1VG
 
----------------------------------------------------------------------

Subject: Re: The GPS Sentences
From: WA8LMF2@aol.com
Date: Fri, 30 May 2003 14:06:53 EDT
X-Message-Number: 18

In a message dated 5/30/2003 10:50:30 AM Pacific Daylight Time, 
boytroy54@yahoo.com writes:

>What do the GPS Sentences that are sent out stand for?
>  
> They look like a basic language string variables...

> Are they the reason that certain data are displayed
> properly on the APRS+SA program?

Huh?   What is this supposed to mean?  

Standard NMEA-format GPS devices automatically output a variety of GPS 
"sentences" , typically once every second.  These are standard 7-bit ASCII
text with no binary or control characters; i.e. virtually any programing
language or terminal should be able to deal with them.   Each sentence
contains several fields of data and look something like this:

$GPVTG,092.2,T,078.3,M,000.2,N,0000.3,K,A*17

$GPDTM,W84,,00.0000,N,00.0000,W,,W84*53

$GPRMC,091635,A,3409.8692,N,11807.0045,W,000.2,092.2,140503,013.9,E,A*07

$GPZDA,091637,14,05,2003,+08,00*60

$GPDTM,W84,,00.0000,N,00.0000,W,,W84*53

$GPGLL,3409.8688,N,11807.0045,W,091636,A,A*50

$GPGSA,A,2,27,28,,,,,,,,,,,00.00,07.83,00.00*30

$GPGSV,3,1,12,07,41,198,29,08,68,060,39,10,05,254,27,11,18,088,39*7A

$GPGSV,3,2,12,13,09,163,29,19,11,117,31,22,07,067,31,26,21,316,29*7E

[ These strings were captured, using HyperTerminal,  from a GPS sitting on
a table in my living room in Pasadena, California. ]

These strings will be identical for any NMEA Ver 2.x GPS device.  The data 
fields are separated by commas making it easy to write programs to pick off
the desired pieces of data.

The most commonly used GPS Data Sentences are [ Full details on the
structure of these strings is at the bottom of this post ] :

=== GPRMC   (Time, Lat, Long, Speed, MagVar)  

=== GPGLL   ( Lat, Long, Time)

=== GPGGA   (Time, Lat, Long, GPS Valid, Number of Sats Used, HDOP, Altitude) 
 

=== GPGSV   (Satellite Status)

=== GPZDA   (Time, Date)

==== GPVTG   (Compass, Ground Course Velocity)


======================================================


Details on the GPS Data Sentences:

Note 1: Lat and long are always expressed as Degrees, Minutes and decimal 
fractions of minutes, --NOT-- as Degrees, Minutes and Seconds.  There is no 
delimiter between the degrees and minutes but there IS a decimal between
the whole and fractional part of minutes.  Resulting data  is formatted as
DDMM.mmm   -- not DDMMSS

Note 2: Lat and long are not signed; a separate field indicates N/S or E/W.  

Note 3:  NMEA 3.0 format has added additional decimal places to the
lat/long values for higher resolution.  Software that parses by counting
character positions from the beginning of the string (i.e. BASIC MID$
functions instead of correctly using the comma delimiters) may not work
correctly with NMEA 3.0 format.

 GPGLL   ( Lat - Long - Time)

$GPGLL,  LLLL.lll, N, LLLLL.lll, W, HHMMSS.ss, *CS

Fields:
1 - Latitude
2 - North/South
3 - Longitude
4 - East/West
5 - UTC (HoursMinsSecs.secs)
6 - Checksum

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

GPRMC   (Time Lat Long, Speed, MagVar)  Always one per second

$GPRMC, HHMMSS.ss, A, LLLL.lll, N,LLLLL.lll, W, KK.k, HHH.h, DDMMYY 
------------------------------------------------------------------------------
-

GPGGA   (Time - Lat -Long - GPS Valid - Number of Sats Used, HDOP, Altitude)  
Always one per second

$GPGGA, HHMMSS, ss, llll.lll, N, LLLLL.LLL, W, 1, NN, 1.7, AA.a, M, -A.a, ,
, *CS

Fields
1 - UTC (HoursMinsSecs.secs)
2 - Latitude in DD MM.mm format
3 - North/South
4 - Longitude in DDD MM.mm format
5 - East/West
6 - GPS Fix  Valid=1, Invalid=0
7 - Number of Sats in Use
8 - HDOP (One is Best, 10 is Worst)
9 - Altitude 
10 - Units M=Meters, F=Feet
11 - Geoidal Sep 
12 - Geoidal Units M=Meters, F=Feet
13 - Time Since Last DGPS Update Data (Not Used)
14 - Diff Corr Station ID#  (Not Used)
15 - Checksum

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

GPGSV   (Satellite Status)

$GPGSV, N, N, NN, 01, Ele1, Azi1, SN1, 02, Ele2, Azi2, SN2, 03, Ele3, Azi3, 
SN3, 04, Ele4, Azi4, SN4, *CS

Fields:
1 - Number of GPGSV Messages
2 - GPGSV Message Number
3 - Number of Sats in View (i.e. determines number of GPGSV messages)

4 - 1st Sat Num
5 - 1st Sat Elevation In Degs (Rounded to integer)
6 - 1st Sat Azimuth in Degs (Rounded to integer)
7 - 1st Sat SNR 00-99 dB, blank when not tracking sat

8 - 2nd Sat Number
9 - 2nd Sat Elevation In Degs (Rounded to integer)
10 - 2nd Sat Azimuth in Degs (Rounded to integer)
11 - 2nd Sat SNR 00-99 dB, blank when not tracking sat 

12 - 3rd Sat Number
13 - 3rd Sat Elevation In Degs (Rounded to integer)
14 - 3rd Sat Azimuth in Degs (Rounded to integer)
15 - 3rd Sat SNR 00-99 dB, blank when not tracking sat

16 - 4th Sat Number
17 - 4th Sat Elevation In Degs (Rounded to integer)
18 - 4th Sat Azimuth in Degs (Rounded to integer)
19 - 4th Sat SNR 00-99 dB, blank when not tracking sat
20 - Checksum

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

GPZDA   (Time Date)

$GPZDA, HHMMSS, DD, MM, YY, *CS
1 - UTC Hours, Mins, Secs
2 - Day
3 - Month
4 - Year
5 - Checksum

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

GPVTG   (Compass, Ground Course Velocity)

$GPVTG,  DDD.dd, T, DDD.dd, M, NNN.n, M, NNN.n, K, *CS
1 - Heading (True)
2 - TRUE "T"
3 - Heading (Magnetic)
4 - Magnetic "M"
5 - Speed Knots or Mph
6 - Units  ("N" or "M")
7 - Speed KM/h
8 - Units ("K")
9 - Checksum

Stephen H. Smith                   wa8lmf @ aol.com 
Home Page:                                         http://wa8lmf.com
Ham Radio/Mobile SSTV page:     http://members.aol.com/wa8lmf/ham
APRS Stuff                                              
http://members.aol.com/wa8lmf/aprs

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



Read previous mail | Read next mail


 14.11.2026 00:12:45lGo back Go up