Date: Sat, 26 Mar 94 04:30:21 PST
From: Ham-Space Mailing List and Newsgroup <ham-space@ucsd.edu>
Errors-To: Ham-Space-Errors@UCSD.Edu
Reply-To: Ham-Space@UCSD.Edu
Precedence: Bulk
Subject: Ham-Space Digest V94 #71
To: Ham-Space
Ham-Space Digest Sat, 26 Mar 94 Volume 94 : Issue 71
Today's Topics:
How to Talk to Mir?
Navstar GPS Constellation Status (94-03-23): Correction
On-line satellite schedules?
Telecom and Meteors (2 msgs)
what does NO -2 N4USH mean?
Send Replies or notes for publication to: <Ham-Space@UCSD.Edu>
Send subscription requests to: <Ham-Space-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Ham-Space Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-space".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 25 Mar 1994 21:56:35 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!boulder!cnsnews!spot.Colorado.EDU!millerpe@network.ucsd.edu
Subject: How to Talk to Mir?
To: ham-space@ucsd.edu
I am a new ham and just beginning to read about satellite
communications with ham radio. I have seen an article that
explained that the Mir space station was fairly easy to communicate
with. What is the minimum setup that might mbe necessary for me to attempt
a contact - or even listen to the station. I have downloaded a few satellite
tracking packages and if I am using them correctly I believe I know when
it sould be overhead. The article also mentioned that 145.55 MHZ was the
frequency to use.
Any help or tips would be greatly appreciated.
Peter Miller
millerpe@spot.colorado.edu
--
===========================================================================
Peter M. Miller Home: 303-494-6990
Computing and Network Services - Small Systems Work: 303-492-4866
University of Colorado - Boulder millerpe@spot.colorado.edu
------------------------------
Date: 25 Mar 1994 10:50:54 -0800
From: dont-send-mail-to-path-lines@ames.arpa
Subject: Navstar GPS Constellation Status (94-03-23): Correction
To: ham-space@ucsd.edu
The Navstar GPS Constellation Status table dated 94-03-23 contains an
error in the notes section. Some of the details in note 8 actually
refer to PRN13 not PRN03. Both of these Block I satellites are
currently set unhealthy. I have revised the table and notes 8 and 12
now correctly reflect the situation. Thanks to Francine Vannicola of
the U.S. Naval Observatory for pointing out the error.
Navstar GPS Constellation Status
(94-03-25)
Blk NASA Orbit Launch
II PRN Internat. Catalog Plane Date
Seq SVN Code ID Number Pos'n (UT) Clock Available/Decommissioned
--------------------------------------------------------------------------------
Block I
01 04 1978-020A 10684 78-02-22 78-03-29 85-07-17
02 07 1978-047A 10893 78-05-13 78-07-14 81-07-16
03 06 1978-093A 11054 78-10-06 78-11-13 92-05-18
04 08 1978-112A 11141 78-12-10 79-01-08 89-10-14
05 05 1980-011A 11690 80-02-09 80-02-27 83-11-28
06 09 1980-032A 11783 80-04-26 80-05-16 91-03-06
07 81-12-18 Launch failure
08 11 1983-072A 14189 83-07-14 83-08-10 93-05-04
09 13 1984-059A 15039 C-1 84-06-13 Rb 84-07-19
10 12 1984-097A 15271 A-1 84-09-08 Rb 84-10-03
11 03 1985-093A 16129 C-4 85-10-09 Rb 85-10-30
Block II
II-1 14 14 1989-013A 19802 E-1 89-02-14 Cs 89-04-15 05:02 UT
II-2 13 02 1989-044A 20061 B-3 89-06-10 Cs 89-08-10 20:46 UT
II-3 16 16 1989-064A 20185 E-3 89-08-18 Cs 89-10-14 20:21 UT
II-4 19 19 1989-085A 20302 A-4 89-10-21 Cs 89-11-23 03:13 UT
II-5 17 17 1989-097A 20361 D-3 89-12-11 Cs 90-01-06 03:30 UT
II-6 18 18 1990-008A 20452 F-3 90-01-24 Cs 90-02-14 22:26 UT
II-7 20 20 1990-025A 20533 B-2 90-03-26 Cs 90-04-18 23:13 UT
II-8 21 21 1990-068A 20724 E-2 90-08-02 Cs 90-08-22 15:00 UT
II-9 15 15 1990-088A 20830 D-2 90-10-01 Cs 90-10-15 00:39 UT
Block IIA
II-10 23 23 1990-103A 20959 E-4 90-11-26 Cs 90-12-10 23:45 UT
II-11 24 24 1991-047A 21552 D-1 91-07-04 Rb 91-08-30 04:44 UT
II-12 25 25 1992-009A 21890 A-2 92-02-23 Cs 92-03-24 11:00 UT
II-13 28 28 1992-019A 21930 C-2 92-04-10 Cs 92-04-25 20:32 UT
II-14 26 26 1992-039A 22014 F-2 92-07-07 Cs 92-07-23 19:43 UT
II-15 27 27 1992-058A 22108 A-3 92-09-09 Cs 92-09-30 20:08 UT
II-16 32 01 1992-079A 22231 F-1 92-11-22 Cs 92-12-11 14:49 UT
II-17 29 29 1992-089A 22275 F-4 92-12-18 Cs 93-01-05 16:39 UT
II-18 22 22 1993-007A 22446 B-1 93-02-03 Cs 93-04-04 05:20 UT
II-19 31 31 1993-017A 22581 C-3 93-03-30 Cs 93-04-13 20:53 UT
II-20 37 07 1993-032A 22657 C-4 93-05-13 Cs 93-06-12 16:15 UT
II-21 39 09 1993-042A 22700 A-1 93-06-26 Cs 93-07-20 12:54 UT
II-22 35 05 1993-054A 22779 B-4 93-08-30 Cs 93-09-28 19:29 UT
II-23 34 04 1993-068A 22877 D-4 93-10-26 Cs 93-11-22 18:20 UT
II-24 36 06 1994-016A 23027 C-1 94-03-10 Projected usable 94-04-18
38 To be launched on need in FY '94
33 To be launched on need in FY '94
40 To be launched on need in FY '95
30 To be launched on need in FY '95
Notes
1. NASA Catalog Number is also known as NORAD or U.S. Space Command object
number.
2. No orbital plane position = satellite no longer operational.
3. Clock: Rb = Rubidium; Cs = Cesium
4. S/A had been enabled on Block II satellites during part of 1990; S/A off
between about 10 August 1990 and 1 July 1991 due to Gulf crisis; standard
level re-implemented on 15 November 1991. Currently, PRN15 and PRN20 appear
to have little or no S/A imposed.
5. Anti-spoofing was activated on 94-01-31 at 0000 UT on all Block II
satellites. (ref. NANU 050-94042)
6. PRN number of SVN32 was changed from 32 to 01 on 93-01-28.
7. PRN03 is operating on Rb clock without temperature control.
8. PRN03 was set unhealthy on 94-02-27 at 0320 UT. It was unusable beginning
at 0233 UT on 94-02-27 and will remain unusable until further notice. (ref.
NANU 083-94059)
9. The decommissioning date for PRN06/SVN03 is the date of termination of
operations of this satellite (ref. USNO) and is about 3 weeks later than the
date GPSIC gives for "deactivation".
10. The PRN06/SVN36 launch included the SEDS-2 tether experiment on the Delta II
rocket body (object 23028, 1994-016B).
11. PRN09 was unusable beginning 93-10-15 1200 UT until 93-12-07 1940 UT due to
testing. (ref. NANU 327-93288 and NANU 402-93341)
12. PRN13 was set unhealthy on 94-02-27 at 1302 UT and will remain unusable
until further notice due to "end of life testing." (ref. NANU 083-94059 and
USNO). It is unlikely that PRN13 will return to service. (ref. USNO)
13. The degraded C/A-code performance of PRN19 was corrected effective 94-01-04
at 0000 UT. (ref. NANU 343-93294, NANU 396-93337, and NANU 006-94010)
14. PRN24 was unusable from 94-01-23 1745 UT until 94-02-01 1516 UT due to a
change in operational frequency standard from Cs to Rb. (ref. NANU
023-94023, NANU 029-94024, NANU 034-94032, and USNO)
===============================================================================
Richard B. Langley Internet: LANG@UNB.CA or SE@UNB.CA
Geodetic Research Laboratory BITnet: LANG@UNB or SE@UNB
Dept. of Geodesy and Geomatics Engineering Phone: (506) 453-5142
University of New Brunswick FAX: (506) 453-4943
Fredericton, N.B., Canada E3B 5A3 Telex: 014-46202
===============================================================================
------------------------------
Date: Fri, 25 Mar 94 07:05:37 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!agate!msuinfo!netnews.upenn.edu!news.amherst.edu!nic.umass.edu!usenet@network.ucsd.edu
Subject: On-line satellite schedules?
To: ham-space@ucsd.edu
Is there an on-line source of data about Oscar and RS satellite schedules
of operation?
Albert S. Woodhull
Hampshire College, Amherst, MA, USA
awoodhull@hamp.hampshire.edu
------------------------------
Date: Fri, 25 Mar 94 07:02:29 GMT
From: ihnp4.ucsd.edu!agate!msuinfo!netnews.upenn.edu!news.amherst.edu!nic.umass.edu!usenet@network.ucsd.edu
Subject: Telecom and Meteors
To: ham-space@ucsd.edu
In Article <Cn6yLn.Mz0@ncifcrf.gov> mack@ncifcrf.gov (Joe Mack) writes:
> [Communication via meteors has] never taken off and as far as I can tell it
>'s only being used by experimenters.
I believe I read a few years ago about meteor scatter being used by
remotely located unmanned weather stations to relay information to
central locations using packet radio techniques. The information is
bundled into packets that are small enough and transmitted rapidly enough
that an entire packet has a good chance of getting through in its
entirety. The packet protocol verifies receipt of packets and causes
retransmission of unverified packets until they are successfully received.
Since the total volume of information is relatively small the overall data
rate is satisfactory.
My recollection is vague, but this could have been an article in the
journal Science, and perhaps it was as long ago as the late '70s. I
think I recall a color picture of a remote weather station in the arctic
on the cover of the issue. I would be pleased if someone could find
the reference and send it to me.
I wonder if hams have done work on meteor scatter packet transmission? It
would have to be done on clear channels and with very specialized
parameters (short packets, unlimited retries, fast response).
On a related topic, I have sometimes noticed when propagation is marginal
but not entirely dead on 10 or 15 meters that weak signals will "pop up"
briefly and then return to their normal level. I have suspected, but do
not know for sure, that this is due to meteor trail reflections.
Albert S. Woodhull N1AW
Hampshire College, Amherst, MA, USA
awoodhull@hamp.hampshire.edu
------------------------------
Date: 25 Mar 1994 18:01:18 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!blanket.mitre.org!linus.mitre.org!wralston.mitre.org!user@network.ucsd.edu
Subject: Telecom and Meteors
To: ham-space@ucsd.edu
In article <2mv5b9$t13@nic.umass.edu>, awoodhull@hamp.hampshire.edu wrote:
>
> In Article <Cn6yLn.Mz0@ncifcrf.gov> mack@ncifcrf.gov (Joe Mack) writes:
>
> > [Communication via meteors has] never taken off and as far as I can tell it
> >'s only being used by experimenters.
>
> I believe I read a few years ago about meteor scatter being used by
> remotely located unmanned weather stations to relay information to
> central locations using packet radio techniques. The information is
> bundled into packets that are small enough and transmitted rapidly enough
> that an entire packet has a good chance of getting through in its
> entirety. The packet protocol verifies receipt of packets and causes
> retransmission of unverified packets until they are successfully received.
> Since the total volume of information is relatively small the overall data
> rate is satisfactory.
There is a system call SNOTEL operating in the western US which collects
information on snowpack levels operated by the US Dept of Agriculture. The
equipment was built my Meteor Communications Corporation, Kent, WA.
The ASAF used to operate a meteor-burst link in Alaska as a back up to a
satellite link which was frequently disrupted by aurora. I think this
system was dismantled.
A number of meteor burst telemetry systems exist internationally for
hydro-meteorological data collection. At one time there were systems
operating in Egypt and in Uganda - I don't know of their current status.
-- Bill wtr@mitre.org
* I babble too incoherently to speak for my employer *
------------------------------
Date: Fri, 25 Mar 1994 19:31:49 GMT
From: mdisea!mothost!schbbs!news@uunet.uu.net
Subject: what does NO -2 N4USH mean?
To: ham-space@ucsd.edu
In article <9403242326.AA24705@freenet3.scri.fsu.edu>, bmm1@freenet2.scri.fsu.edu (Bruce M. Marshall) says:
>
>I am trying to establish an uplink to UO22 and so far have all I have
>gotten is the message 'NO -2 N4USH'. What does this mean? Does anyone
>have any info on what all the information that OSCARS 22, 23 & 25
>routinely downlink means? Some is obvious, some is not. I have found
>some problems and corrected them and am waiting for evening passes to
>check them out. Any suggestions or comments on debugging uplinks would
>be appreciated.
>thanks, Bruce. N4USH
>--
>Bruce M. Marshall bmm1@freenet.fsu.edu voice 615 481 0990 fax 615 481 8039
It means that the file that you requested to be downloaded is no longer availabledownload by the
file server. There is a parameter in the header of the file controlled by the uploader which
specifies how long the file is to kept active in the directory. If its something you really need,
upload a message to "ALL" asking for the original uploader or anyone else who might have it to
upload it again. Hope this helps.
73's
Ned Stearns AA7A
email: ned_stearns@email.mot.com
------------------------------
End of Ham-Space Digest V94 #71
******************************
******************************