OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
EB2DVY > PSK31    06.05.00 13:57l 352 Lines 14181 Bytes #-9573 (0) @ WW.SYD.NSW
BID : 1165-EB2DVY
Read: GUEST
Subj: PSK31 Digest V1 #378
Path: OE1XAB<OE3XSR<OK0PPL<OK0POK<9A0YRB<PP5BLU<PY4BHB<PY1LCZ<KA6EYH<KB7FRV<
      KA0WIN<F8PTT<F5TMZ<F5KTX<F3KT<F5KEQ<F6KSU<F5KDW<F8REF<F6KBN<F8KOP<
      F5ROC<F8KKA<F5RJI<F5KBW<F6GGY<F5KBQ<F5KEI<F5GJC<F6FBB<F6KNI<EA3D<
      EA3B<ED3ZAF<EA2K<EA1URR<EA1URM<EA2RCF<EA2G<EA2URV
Sent: 000429/2253Z @:EA2URV.EABI.ESP.EU #:54765 [URV-ABRA Bilbao] $:1165-EB2DVY
From: EB2DVY@EA2URV.EABI.ESP.EU
To  : PSK31@WW.SYD.NSW.AUS.OC

De: Psk31 Digest <owner-psk31@aintel.bi.ehu.es>
Para: <psk31-digest@bipt106.bi.ehu.es>

Asunto: Psk31 Digest V1 #378
Fecha: sßbado 29 de abril de 2000 10:22


Psk31 Digest         Saturday, April 29 2000         Volume 01 : Number 378



In this issue:

    [psk31] Pactor Interference
    [psk31] PSK31 and TenTec Pegasus Connection Help
    [psk31] Digipan on old 486
    RE: [psk31] Pactor Interference
    RE: [psk31] Digipan on old 486
    RE: [psk31] Digipan on old 486
    Re: [psk31] Pactor Interference
    Re: [psk31] Pactor Interference
    [psk31] Slow computer PSK31
    [psk31] Help - DigiPan Keying Problem

See the end of the digest for information about psk31-digest

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

Date: Fri, 28 Apr 2000 07:42:31 -0400
From: Howard Teller <hteller@home.com>
Subject: [psk31] Pactor Interference

PACTOR INTERFERENCE

After reading the latest complaints about unexplained Pactor
interference to PSK31 QSO's in progress on the frequency, you might be
wondering why so many Pactor station do not listen for a clear frequency
before transmitting, and so you might be interested in an excerpt from
the "Airmail" Help file, which is the software that almost all Pactor
Mailbox Client stations use. As an example how to configure the software
for fully automatic operation, with no operator needed to be present,
frequencies right in the middle of current PSK31 activity, which are
illegal for use by USA stations for automatic operation, are offered as
an example.

Furthermore, the Pactor MBO (Mailbox operator) client, who wishes to
send or retrieve mail from a particular MBO station MUST transmit only
on those frequencies monitored (robotically scanned) by MBO stations to
be detected and automatically linked with. Those frequencies are
published and sometimes programmed by technicians into the client's rig
and amounts to a "channelizing" of the ham bands, similar to CB
channels. MBO's like K4CJK can run up to 1500 watts and once a link is
established with a remote client station, will automatically use
whatever power is necessary, up to 1500 watts, to take over the
frequencies and maintain perfect communications, overpowering any PSK31
stations within a spread of 500 Hz, which is why a super-strong Pactor
station often wipes out three or more PSK31 QSO's.

Those superpower MBO stations automatically scan, 24 hours a day, almost
all the 20 meter RTTY/DATA band segments looking for clients to link
with and will stop and lock on to any client stations trying to contact
them. If any of those client stations choose to transmit in the portion
of the band currently used by PSK31, they will "bring in" a 1500 watt
station, unmanned, which cannot listen first, to take over the frequency
for their own use. NOBODY IS THERE to respond to a "Please QSY, this
frequency is in use". If the remote client station is also automatically
(and illegally in the PSK31 activity portion of 20 meters) operated to
retrieve or send mail while the operator is busy away from the
transceiver, THERE IS NOBODY AT ALL LISTENING!

MUCH OF THE 20 METER BAND HAS BEEN TAKEN OVER BY ROBOTS IN THE FORM OF
SOFTWARE DRIVEN STATIONS WITH NO OPERATORS PRESENT. This is why it
appears that Pactor stations APPEAR to act so rudely. There is nobody
there!

Here is the text straight from the Airmail Help file that everyone uses
to set up his rig:

"Setting up an Autocall Schedule: 
The heart of Autocalling is a Schedule File. This is a plain-text file

that defines stations and time slots for calling. The schedule can be
accessed by selecting Autocall Schedule from AirMail's Window menu, or
by editing the file directly with Notepad or any other plain-text
editor. (The file is named Autocall.txt unless changed in the
AirMail.ini setup file). 
The schedule file consists on one line per event, each line consisting
of fields separated by one or more spaces. The fields designate the
start and stop times (in UTC), the frequency, action, callsign, and any
modifiers. A typical schedule would contain the following:

 06:05 06:10 14072.9,14074.9,14077.9 autocall oe4xbu  

 06:20 06:25 14068.9,14071.9 autocall 9a0apl
 06:52 07:00 14072.9,14074.9,14077.9 autocall oe4xbu inhibit=2
 08:58 10:15 scan AirMail
 13:40 13:45 18104.9 autocall ap5ars inhibit=2
 13:45 13:50 14064.9,14065.9,14068.9,14072.9 autocall ap5ars inhibit=2"

Note, for example, that 14071.9 falls right in the middle of the current
PSK31 activity!

I recently participated in three weeks of negotiations with K4CJX, the
"Winlink" big gun, written up in the March QST on page 90, in which it
was requested that Pactor MBO's simply eliminate scanning between 14.070
and 14.074, as they also scan everywhere else except the traditional
RTTY segment of the band, and can easily avoid interfering with PSK31
activity, but negotiations finally broke down when the MBO's refused
because "they were there first", and that PSK31 was a newcomer and was
intruding in the middle of their territory (which is basically all of
the 20 meter CW/RTTY band except traditional RTTY).

Peter Martinez and I have discussed this at length, and we both agree
that some form of separation is legally necessary. As you can see from
Peter's lastest posting on the PSK31 reflector, he feels that even
semi-automatic operation must be legally confined to the current band
segments where fully automatic operation is allowed. This would make it
illegal for any scanning MBO station, without an operator present at the
control point, to transmit in response to a call from a Pactor client
station. Except for keyboard-to-keyboard communications on Pactor, this
should eliminate much of the current Pactor interference to PSK31
communications. I think this is an ideal great approach, but may be
difficult to enforce, because it requires physical inspection of a
station by the FCC at the time of the interference. 

Another approach would be to have some sort of legally imposed
separation, on the basis of transmitted bandwidth, so that all Pactor
stations (appproximately 500 Hz bandwidth) would have their own spectrum
space and CW and PSK31 stations (from approximately 200 Hz to 50 Hz
wide) would have their own, and interference between Pactor and CW or
PSK31 stations would hopefully disappear. The FCC could enforce
compliance simply by observing the bandwidth of stations within a
certain frequency segment. However, this would not eliminate surprise
appearances by automatic MBO stations using some new narrow-band mode of
linked communications that might appear in the future.

Both solutions require an change in FCC rules to be effective. It would
be much more effective and more quickly implemented if there were a way
that Pactor MBO stations could be convinced to merely stop scanning
within the very tiny spectrum space between 14.070 and 14.074 where
PSK31 is struggling to operate with much lower power.

If you have any ideas how to best resolve the "Pactor Interference"
problem, now might be a good time to post your ideas on the reflectors.

73, Skip Teller, KH6TY/4

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

Date: Fri, 28 Apr 2000 09:12:19 -0400
From: ko4qc@mindspring.com
Subject: [psk31] PSK31 and TenTec Pegasus Connection Help

I would like to corrospond with someone who is using/has used the TT
Pegasus for PSK31.
ko4qc@arrl.net
     Tnx,Joel,KO4QC


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

Date: Fri, 28 Apr 2000 08:27:00 -0500
From: John Chamberlain <chamber@cord.org>
Subject: [psk31] Digipan on old 486

I loaded and ran DigiPan on my 486/66 last night.  Other than having to 
wait patiently (about 10-15 seconds) for the opening screen to disappear 
and menu's to respond, all seemed to work just fine. (The author recommends 
using a 486/100 or better machine.)

Thanks, Skip, for some great programming.  As everyone's been saying, the 
feedback and versatility of the wide-screen waterfall is tremendous and 
very informative, showing the receiver's audio bandwidth, the effects of 
AGC, filter selection, etc.  Now I see what everyone's been raving about! 
...and also see how really BAD some of the PSK splatter is, compared to the 
many good signals.

John, AC5CV

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

Date: Fri, 28 Apr 2000 09:38:00 -0400
From: "Richard B Drake" <rbdrake@erols.com>
Subject: RE: [psk31] Pactor Interference

Below is a copy of section 97.109 of the FCC regulations that was
cut and pasted directly from www.arrl.org.

Since voluntary cooperation has been attempted and refused, it
seems to me that all we should have to do is petition the FCC to
enforce rule 97.109 (d) on the grounds that the automatically
controlled stations are, "causing harmful interference to other
stations." Thus, we do not require a rules change, which would
undoubtedly be a lengthy process, just enforcement of the existing
rules. That should at least take care of those automatically
controlled stations that fall under FCC jurisdiction.

73, Rich - W3ZJ

<QUOTE FOLLOWS>
§97.109 Station control.


(a) Each amateur station must have at least one control point.

(b) When a station is being locally controlled, the control
operator must be at the control point. Any station may be locally
controlled.

(c) When a station is being remotely controlled, the control
operator must be at the control point. Any station may be remotely
controlled.

(d) When a station is being automatically controlled, the control
operator need not be at the control point. Only stations
specifically designated elsewhere in this Part may be
automatically controlled. Automatic control must cease upon
notification by an EIC that the station is transmitting improperly
or causing harmful interference to other stations. Automatic
control must not be resumed without prior approval of the EIC.

(e) No station may be automatically controlled while transmitting
third party communications, except a station transmitting a RTTY
or data emission. All messages that are retransmitted must
originate at a station that is being locally or remotely
controlled.

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

Date: Fri, 28 Apr 2000 09:20:36 -0500
From: Tim <kd5ckp@yahoo.com>
Subject: RE: [psk31] Digipan on old 486

I personally am glad to hear that since that is what my PSK31 machine will be
one I figure out the keying circuit for ,y TS520SE.

Thanks for the note
73
Tim, KD5CKP
http://www,qsl.net/kd5ckp

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

Date: Fri, 28 Apr 2000 10:23:48 -0500
From: Tim <kd5ckp@yahoo.com>
Subject: RE: [psk31] Digipan on old 486

Obviously neither my fingers nor my spellchecker were working, Hi!

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

Date: Fri, 28 Apr 2000 12:06:06 EDT
From: Charles R Greene <cgreene7@juno.com>
Subject: Re: [psk31] Pactor Interference

On Fri, 28 Apr 2000 09:38:00 -0400 "Richard B Drake" <rbdrake@erols.com>
writes:

Maybe we should have an OO operator first
send the offending station(s) a notice.  The FCC
has recently reaffirmed the authority of the OO
and their deisre to support them.

Chas, W1CG



Charles Greene
Amateur Call W1CG
Bristol, RI

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

Date: Fri, 28 Apr 2000 12:52:06 -0500
From: "Bob Hicks" <w5tx@arrl.net>
Subject: Re: [psk31] Pactor Interference

Certainly we can call out the FCC and see what happens -- however, I used to
have substantial interaction with the agency over a period of years and when
we came to a point of whether we should ask a question about rules (perhaps
ambiguity etc) we always decided that if there was a possiblity of not
liking an answer, you were better off not asking question because the
commission was  always going to assume a CYA position.  So what's this got
to do with all of this-- well, just who is being interferred with??  Does
this mean other amateur stations?  The bands are not channelized (sp?) so
who owns freq??  Unless the interference was malicious and intended, I
suspect the FCC would take a dim view of jumping into the fray.
No, I think we should continue the conversations and negotiations within our
own ranks and perhaps a solution can be found.  As a result, I would suggest
we all write our representatives at ARRL and encourage them to perform early
mediation of this disagreement before too many more folks become PSK addicts
like us and we have a real problem.  I personally sent mine to Jim Haynie
our Prez.
Watcha think??

Bob
w5tx@arrl.net

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

Date: Fri, 28 Apr 2000 11:04:44 PDT
From: "Jim Hyatt" <k4jdh@hotmail.com>
Subject: [psk31] Slow computer PSK31

I have an old 486sx/33 as my shack computer.  I need software that will
run this machine.  I downloaded a DOS version but it requires a piece of 
hardware.  Any help will be appreciated.

Jim Hyatt
K4JDH

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

Date: Fri, 28 Apr 2000 09:56:17 -0700
From: David Smoler <smoler@pacbell.net>
Subject: [psk31] Help - DigiPan Keying Problem

Im having difficulty keying and returning to receive using DigiPan. I'm
observing the diode-ORed DTS/RTS lines with a scope to verify that the
problem doesn't lie in the interface. The problem is that it takes
several hits of the XMT (button, F9, or menu all work the same) to get
the DTS/RTS to stay high and the transmitter to remain in transmit. This
happens whether I want the modulation to idle or I'm sending text out of
the buffer. 

With a 35MHz scope, there's no RF feedback either, and I'm running into
a dummy load.

Same problem in returning to receive, although ESC seems to work a
little better. Am I not understanding something about how DigiPan works?
Is some setup item incorrectly set? Other than the above problem, I like
DigiPan's performance and ease of use.

David
AD6KI


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
to unsuscribe from the list send to majordomo@aintel.bi.ehu.es a message
with a text line as follow: unsubscribe psk31 or unsubscribe psk31-digest

More instructions on PSK31 Webpage: http://aintel.bi.ehu.es/psk31.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

End of Psk31 Digest V1 #378
***************************


Read previous mail | Read next mail


 22.07.2026 18:46:04lGo back Go up