| |
ZL3AI > APRDIG 02.04.03 10:41l 285 Lines 12478 Bytes #999 (0) @ WW
BID : 1076-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 25, 2/3
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<W7NTF<WB0TAX<SP7MGD<VK7AX<ZL2BAU<
ZL3VML
Sent: 030401/0846Z @:ZL3VML.#80.NZL.OC #:63017 [Chch-NZ] FBB7.00i $:1076-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Radiation monitoring and APRS
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 25 Mar 2003 17:37:04 -0000
X-Message-Number: 9
I think it's not going to be terribly practical to have NIST-traceable
calibrated detectors scattered everywhere, and it really might not be
necessary for getting a useful quick look. Just report raw counts/min,
averaged over 10 or 15 minutes, and optionally provide an average background
level, generated over a 1-day period, so stations won't have to resort to
polling a database to see if a station is reporting an elevated level.
Findu or aprsworld could show a graphical rate-of-change indication for
stations in a given area. Combined with good wind data, that might be
interesting to watch during the next three mile island event.
As for alpha particles, I think they have an average range of something like
4 inches in air. You can see it in a cloud chamber. But Patrick is right,
they're extremely dangerous when the exposure is internal. So the question
is, are we likely to see atmospheric contaminates that produce a lot of
alpha particles without beta or gamma that would be easier to detect? And
how do you go about making an alpha-detecting GM tube weatherproof? To
allow alphas in, they usually have very thin, fragile mica windows. I've
got some beta+gamma glass GM tubes that would probably work just fine
exposed directly to the weather, as long as the socket's properly sealed.
I've also been told that geiger counters can be used as snow depth
indicators. Snow (and water in general) absorbs cosmic radiation at a known
rate, so by placing a detector on the ground and comparing its output to the
normal background level, you can tell how much precipitation is overhead
sheilding it.
Scott
----------------------------------------------------------------------
Subject: pretty combination of APRS and GIS
From: "James Jefferson" <jj@aprsworld.net>
Date: Tue, 25 Mar 2003 15:13:50 -0600 (CST)
X-Message-Number: 10
I've created a couple of maps of north america and europe with APRS
stations over a shaded relief map.
The files are big, but I thought some people might find it interesting:
http://aprsworld.net/gisdata/pretty/
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: PTT/VOX for AGWPE - PSK31
From: "Joe Della Barba" <joe@dellabarba.com>
Date: Tue, 25 Mar 2003 17:15:26 -0500
X-Message-Number: 11
I am now convinced not to use VOX for my PTT. Is it possible to use the
parallel port instead of the serial port? I have no other use for the
parallel port, but I would like to keep the serial port free.
Thanks and 73
Joe N3HGB(-1,-5,-7,-14)
----------------------------------------------------------------------
Subject: Re: Radiation monitoring and APRS
From: Steve Jones <s.jones@rogers.com>
Date: Tue, 25 Mar 2003 18:55:40 -0500
X-Message-Number: 12
on 3/25/03 12:37 PM, Miller Scott Contr 30SCS/FTI at
Scott.Miller@vandenberg.af.mil wrote:
>I think it's not going to be terribly practical to have NIST-traceable
>calibrated detectors scattered everywhere, and it really might not be
>necessary for getting a useful quick look.
Forget about NIST traceability. I used to work in a lab that sent many
instruments out for calibration and know what to expect pricewise. Any
hobbiest considering sending a unit out must be rich or have a pretty
whacked sense of priorities.
>they're extremely dangerous when the exposure is internal. So the question
>is, are we likely to see atmospheric contaminates that produce a lot of
>alpha particles without beta or gamma that would be easier to detect? And
>how do you go about making an alpha-detecting GM tube weatherproof? To
>allow alphas in, they usually have very thin, fragile mica windows. I've
>got some beta+gamma glass GM tubes that would probably work just fine
>exposed directly to the weather, as long as the socket's properly sealed.
Detecting alpha particles is going to be tough. Most labs use detectors
with evacuated chambers to do any alpha work. You're only going to see a
few inches at best in front of the detector, possibly a lot less depending
on the window thickness. Most GM type detectors are only good for beta and
gamma. Labs doing Radon work generally use cloud chambers to directly
detect the alpha particles or they use gamma spectroscopy to measure the
gamma daughter products after they have grown in.
I think you're probably going to end up with some sort of count rate (cpm)
which is integrated over an energy range. Knowing the background rate for
the area and posting this information will probably give most people the
answer to whether the readings they are seeing are elevated.
IIRC, we were checking for Cs-137 using gamma ray spectroscopy shortly after
Chernobyl. There were a bunch of other radionuclides that we routinely
scanned for in food products coming from the USSR.
--
Steve <s.jones@rogers.com>
----------------------------------------------------------------------
Subject: Re: PTT/VOX for AGWPE - PSK31
From: WA8LMF2@aol.com
Date: Tue, 25 Mar 2003 18:58:26 EST
X-Message-Number: 13
In a message dated 3/25/2003 2:18:00 PM Pacific Standard Time,
joe@dellabarba.com writes:
>I am now convinced not to use VOX for my PTT. Is it possible to use the
>parallel port instead of the serial port? I have no other use for the
>parallel port, but I would like to keep the serial port free.
>Thanks and 73
The AGW Packet Engine does provide a VXD (virtual device driver) for TX
keying. This is contained in a separate download from the main AGW package.
(Look for the download "DRIVERS" on the AGW site.)
You can use any of the first four bits of the parallel output to key the 1st
port of the simulated dual port TNC and any of the second four bits to key
the other port,
The limitation is that the driver is a VXD, a type of driver characteristic
of Win95/98. It WILL NOT work with WIn NT/2K/XP.
A MAJOR CONSIDERATION USING PACKET ON HF
On 1200 baud VHF operation the audio packet tones are being transmitted on
FM. There is no abiguity on receive; the received tones are going to be
exactly as transmitted.
On the other hand on HF, the tones are transmitted via SSB. SSB tuning
errors at the receiver will cause the pitch of the tones to be high or low.
Tuning in the short bursts of packet to the exact correct pitch is difficult
at best, even with the flickering LED bargraphs on hardware-based devices
like the PK-232 or KAM. [ The packets aren't long enough to tune in fully
before they stop, and of course if you miss part of the burst, you lose ALL
data. ]
AGW does not provide a really usable tuning indicator for this purpose. You
pretty much have to do the audio vs RF frequency offset calculations (see
below), ensure that your radio's synthesizer standard is calibrated dead on
(or determine the degree of error by zero-beating WWV on LSB or USB and
noting if the display is all zeros after the whole MHz), and then shoot in
the dark by presetting the radio to the expected frequency.
A FAR superior softmodem for HF packet is the MIxW multimode soundcard
program. This application which runs CW, PSK31, RTTY, SSTV, MT63
hellschrieber, MFSK, as well as PACKET provides high performance software
modems for 12 different packet transmission formats (including the 9600 baud
G3RUH and "oddball" satellite packet modulation formats). The application
emulates a multi-mode KISS TNC for use by external programs.
The standard "VHF 1200 Baud" is fixed to the usual 1200/2200 tone pairing,
but the "HF 300 Baud (200 Hz Shift)" mode is FULLY TUNABLE to any arbitrary
pair of audio tones 200 Hz apart.
The program produces a waterfall display similar to most PSK31 programs
in the packet modes. If you can hear the packet data in your receiver
passband at all, you can move your audio tone pair onto the trail of an
ALREADY-ENDED packet burst with one click of the mouse and be absolutely
dead-on and ready for the next one.
The flexibility to use ANY tone pair also means you can use a 500 Hz CW
filter on USB or LSB and then tune the soft-modem to whatever audio range
passes through the filter (typically something like 600-1100 Hz). [
Traditional hardware TNCs typically listen for audio tones much higher than
will pass through the typical CW filter. The AGW packet engine uses
2100/2300 tones in it's narrowshift 300 baud mode. ]
Below I have pasted a portion of a post I have made in the past about audio
tones for 200 baud HF packet as it relates to APRS:
=========PASTE===========
Since the actual transmitted RF frequencies (on lower side band) are the
indicated suppressed carrier frequency (i.e. "dial frequency") minus the
audio tone frequencies, the actual dial frequency you want WILL DEPEND ON THE
PARTICULAR AUDIO TONE FREQS your TNC or other device produces. Unlike 1200
baud VHF packet, there is no standard for the tones used by various devices
on 300 baud/200-Hz shift HF packet:
Frequencies Devices using them
2130/2230 Hz AEA/Timewave PK-232
2100/2300 Hz AGW Packet Engine softmodem (300 baud mode)
1600/1800 Hz Kantronics KAM and standard TAPR TNC2 (MFJ 127x. etc)
1100/1300 Hz TigerTronics TigerTrak (300 baud HF mode)
[ Any pair! ] MixW 2.x in Packet Mode
This is really not a problem on SSB since (unlike FM) you can always alter
the audio frequencies at the receiving end by tuning the receiver higher or
lower.
The ==ONLY== constant is the ACTUAL RF freqs of the 200 Hz shift mark and
space tones on 30M APRS. They are:
10.149.200
10.149.400
Note that unlike classic RTTY, there is no sense of MARK vs SPACE. You can
transmit on either upper or lower sideband equally well without worrying
about "inverting" the audio tones.
To produce the correct RF frequencies with the AGW Packet Engine softmodem,
whose default audio tones on 300 baud HF are 2100/2300 you must set your
radio to 10.151.50 LSB:
10.151.500 - 2.300 = 10.149.200
10.151.500 - 2.100 = 10.149.400
Or set the radio to 10.147.00 USB:
10.147.100 + 2.100 = 10.149.200
10.147.100 + 2.300 = 10.149.400
To produce the correct RF frequencies with a KAM or TNC2 (300 Baud HF mode)
whose default audio tones are 1600/1800 Hz, you must set your radio to
10.151.00
LSB:
10.151.000 - 1.800 = 10.149.200
10.151.000 - 1.600 = 10.149.400
Or set the radio to 10.147.60 USB:
10.147.600 + 1.600 = 10.149.200
10.147.600 + 1.800 = 10.149.400
To produce the correct RF frequencies with a PK232 whose default audio tones
are 2110/2310 you must set your radio to 10.151.51 LSB:
10.151.510 - 2.310 = 10.149.200
10.151.510 - 2.110 = 10.149.400
Or set the radio to 10.147.09 USB:
10.147.090 + 2.110 = 10.149.200
10.147.090 + 2.310 = 10.149.400
To produce the correct RF frequencies with a TigerTrak whose 300 Baud/narrow
shift audio tones are 1100/1300 (weird pairing centered around the 1200 Hz
low tone for 1200 baud packet -- but actually very nice because the tone
pairs are in the dead center of the typical SSB filter bandpass and suffer
the absolutely least amount of phase and group delay distortion) you must set
your radio to 10.150.50 LSB:
10.150.500 - 1.300 = 10.149.200
10.150.500 - 1.100 = 10.149.400
Or set the radio to 10.148.10 USB:
10.148.100 + 1.100 = 10.149.200
10.148.100 + 1.300 = 10.149.400
Note that some HF radios with "DATA" or "FSK" modes offset the indicated dial
frequency to correct for the difference between the suppressed carrier freq
and the actual mark frequency, typically assuming the lower tone is 2125 Hz
(or sometimes 1800 Hz). This will force you to compute offsets different
from what I have listed for LSB/USB.
AGAIN: Quoting "dial frequency" alone is ABSOLUTELY MEANINGLESS unless you
qualify it with mode (USB/LSB/DATA, etc) and the AUDIO tone freqs in
question.
====== END PASTE ========
[commercial content deleted]
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
| |
