... If I recall Pactor II may be monitored without the costly proprietary SCS hardware and software, so it may be a more acceptable app in Ham use -- at leastMessage 1 of 17 , Oct 1, 2005View Source
> Since it is a one to one link, there are noIf I recall Pactor II may be monitored without the
> collissions, perhaps, maybe, ocassional QRM from
> others who consider to own certain frequencies. The
> transfer protocol is more elaborate and better
> (compression, interleaving, convolutional encoding,
> Viterbi decoding, etc).
costly proprietary SCS hardware and software, so it
may be a more acceptable app in Ham use -- at least
one may determine who the QRMing offender is and
report them -- one may also determine is the op is
sending Ham-legal communications or something else.
QRMing is rarely against folks camoing out on a
freq 24/7 but most often the result of someone
engaged in a QSO where another op is too careless
or selfish to bother to check for activity and
who jumps on top of them.
There is no lack of space on the bands, except perhaps
during the all-too-frequent contests, so there is no
excuse for QRMing -- especially witha digital signal
that cannot be decoded by 99% of Hams and may be
readily abused for non-Ham legal or nefarious purposes
> I have been following Q15X25 as it may have betterThat is why we are all on this list.
> characteristics, those of modern HF data
> communications systems.
> Certainly, 300 baud FSK is far from optimal.For sure -- but that may also be a regulatory quirk
choking-off new technologies that needs to be addressed.
> Q15X25 and similar modulation methods may allow toAgreed.
> have more people to communicate with on HF. With
> recent developments, there seems to be hope for may of
> 73 de Jose, CO2JA
... It might fit in your frame if we used, as you do, a BBS only frequency. We did not, anyone could connect freely. Perhaps that´s part of my problem withMessage 1 of 17 , Oct 1, 2005View Source--- Charles Brabham <n5pvl@...> wrote:
> --- In Q15X25@yahoogroups.com, Jose AmadorIt might fit in your frame if we used, as you do, a
> <co2ja@y...> wrote:
> > Something I did not mention on my other reply. I
> > to run 600 watts to "achieve" some 100 kb of
> > compressed fwd per day.
> > With pactor, 25 to 100 watts were able to move
> > times more traffic. I had a link with Africa for
> > forwarding to Europe which worked many times with
> > little as 25 watts with better thruput than 300
> > packet with 600 watts in much shorter links.
> > Jose, CO2JA
> Personally, I have never heard of a Packet BBS SYSOP
> before who ran
> more than 50-70 watts power. If you were running 600
> watts, that may
> have been part of your problem with Packet.
> Were the stations you connected to all running 600
> watts too? - Or
> were they running 50-70 watts, as all the SYSOPs I
> know have found to
> be work out best? ( I know a lot of SYSOPs, by the
> way. )
BBS only frequency. We did not, anyone could connect
Perhaps that´s part of my problem with packet, I hate
losing time with bad links and retries. I was able to
do it, those were my finals and my power bill, at the
service of my users. And it never caused problems to
anyone. I do not operate a HF packet forwarding link
since 1998. With pactor, or whatever replaces 300 baud
FSK modems, it is not necessary to run high power to
run a reliable link.
> Your story doesn't make a lot of sense... I haveSo, what makes sense is to use the BEST BBS software.
> operated both modes
> and though PACTOR does give better throughput, it
> does not do so for
> all of the BBS software currently in use.
I understand it does not make sense to you, but not
all BBS programmers (and I do not mean to offend any
of them) are equally gifted. Only the best software
> PACTOR is also prohibitively expensive, and hasI do not want to impose that on anyone. Have I meant
> virtually no signal
> detection capability, very often making PACTOR
> operators into
> unwilling ( and unwitting ) lids. Lots of BBS SYSOPs
> won't go for
> being party to that.
> Add the greatly expanded bandwidth of the higherPactor 2 fits into my CW filter.
> performing PACTOR
> modes, and you have a nice QRM generation system
> there, second to
> none when it comes to crashing people's QSO's.
> Then there is the difficulty in trying to operatePactor is not meant to do that. If you operated it,
> multiple PACTOR
> QSO's on a single frequency. Packet handles this
> just fine, PACTOR
> does not.
and read the manual, you know that it does not make
sense to make that comparison.
> Most SYSOPs utilize Packet because nothing betterI do not do Internet forwarding. And you might know
> has come along to
> replace it. - You are welcome to consider PACTOR as
> a 'better'
> replacemnent for Packet if you wish, but understand
> that by doing so,
> you place yourself with a tiny minority among BBS
> SYSOPs, for the
> reasons outlined above.
that time in HF forwarding counts, when the bands are
not open 24/24 like a wire or VHF/UHF.
> That's just how it is, agree with it or not as youI respect your point of view, you are entitled to it.
> wish. Whatever
> PACTOR is, it is not a "replacement" for Packet. -
> Good or bad.
> Charles, N5PVL
But I also feel I have the right to disagree. As I
disagree to go into a name calling fight that solves
And period. End of the thread, at least for me, it is
not relevant to Q15X25.
... Do you recall how this is done? I have only seen monitoring software for PACTOR I and am interested in monitoring PACTOR II. 73, Mark N5RFXMessage 1 of 17 , Oct 4, 2005View SourceAt 07:43 AM 10/1/2005, you wrote:
>If I recall Pactor II may be monitored without theDo you recall how this is done? I have only seen monitoring software for
>costly proprietary SCS hardware and software, so it
>may be a more acceptable app in Ham use --
PACTOR I and am interested in monitoring PACTOR II.
APRS is not tied to AX.25. Most of the display programs as well as internet servers let you input data in a text format. The APRS spec is here:Message 1 of 17 , Oct 7, 2005View SourceAPRS is not tied to AX.25. Most of the display programs as well as
internet servers let you input data in a text format. The APRS spec is
Being most APRS position reports are from 13 to 40 bytes long (native
APRS format) you don't need the speed of Q15X25. Also, most APRS
transmissions in the wild are UI frames, or unacknowledged information
frames. Meaning, they don't use the connected mode (or ARQ) function
If your looking to optimize HF APRS from the present AX.25 UI frame
300 baud means, you'd be better off looking at a mode that offers
heavy FEC and good low signal performance. MT63, MFSK16 or perhaps
Olivia come to mind. All offer good low signal performance and heavy
300 baud on HF, as a signaling rate, is less then optimal due to group
delay caused by different paths through the ionosphere. That is the
reason Q15X25 reduced the baud rate to 83.5 (on each carrier) to
reduce this effect.
--- In Q15X25@yahoogroups.com, Tapio Sokura <oh2kku@i...> wrote:
> I was wondering if there are any established a) frequencies and/or
> Q15X25 modem parameters for HF APRS use? 300 bps packet seems to be
> lot less than optimal on HF and it would be interesting to see how
> Q15X25 would do instead. I did some googling on this subject, but
> find any concrete information on frequencies/parameters, just some
> that mention the possibility of combining the two.
... If you are not operating within the automated sub-bands, then you are most definately QRM ing other hams with your PACTOR signals. The one and only placeMessage 1 of 17 , Oct 8, 2005View Source
> > Were the stations you connected to all running 600If you are not operating within the automated sub-bands, then you are
> > watts too? - Or
> > were they running 50-70 watts, as all the SYSOPs I
> > know have found to
> > be work out best? ( I know a lot of SYSOPs, by the
> > way. )
> It might fit in your frame if we used, as you do, a
> BBS only frequency. We did not, anyone could connect
most definately QRM'ing other hams with your PACTOR signals.
The one and only place where you can operate PACTOR ( or Packet ) for
BBS operation without regularly crashing people's QSO's are the
That's why they exist.
Packet BBS operation as a 'loner' who does not play by the rules
other SYSOPs operate by is a pointless endeavor. Competent
autoforwarding's first requirement is an ability to play well with
others, in a cooperative way and friendly way.
> With pactor, or whatever replaces 300 baudYou are the one and only amateur who has ever suggested to me that
> FSK modems, it is not necessary to run high power to
> run a reliable link.
Packet is unreliable except when using high power.
From my location at the southern tip of Texas, I forward regularly
with stations in Canada, California, Indiana, Florida and ( Here's an
easy one ) Missouri. - All with 50 watts on HF Packet.
> > Your story doesn't make a lot of sense... I havehttp://www.uspacket.org/l_protowars.htm
> > operated both modes
> > and though PACTOR does give better throughput, it
> > does not do so for
> > all of the BBS software currently in use.
> So, what makes sense is to use the BEST BBS software.
What makes sense is to work with protocols/modes that are usable by
all BBS software, including the new BBS software that is coming up.
> > Then there is the difficulty in trying to operateLooks like you are picking and choosing what is or is not 'relevant'
> > multiple PACTOR
> > QSO's on a single frequency. Packet handles this
> > just fine, PACTOR
> > does not.
> Pactor is not meant to do that. If you operated it,
> and read the manual, you know that it does not make
> sense to make that comparison.
according to how well it matches up with your personal views.
As manager of an ARRL Skipnet, I can assure you that the ability to
operate half a dozen or more stations on one frequency is highly
relevant, unless and until somebody comes along and finds a way to
greatly expand the autoforwarding sub-bands.
If we can only have two stations per frequency, and those stations
must be five or six times wider, that means that the network can only
have a few participating stations, and so it would have very little
coverage or capability, worldwide.
We are trying to get more BBS stations to participate, not to shut
them out by using inappropriate modes/protocols that do not 'play
well with others' and so reduce our capability in this area.
It should never be forgotten that participation in a network is a
cooperative venture. Your value to that network in large part hinges
upon your ability to work cooperatively with many other hams around
>Right now I am manager of the NET117 ARRL SkipNet, experimenting with
> I respect your point of view, you are entitled to it.
> But I also feel I have the right to disagree. As I
> disagree to go into a name calling fight that solves
> And period. End of the thread, at least for me, it is
> not relevant to Q15X25.
utilizing Q15x25 mode for autoforwarding. In my case at any rate,
these questions and discussions are highly relevant to what I do.
I have to think about stuff like bandwidth, signal strength, the
ability to share a frequency, bitrate, compatability with all ( not
just my personal favorite ) BBS software and ease of operation, along
with a number of other factors.
Personally I would like to see Q15x25 mode go into regular use for
autoforwarding - but it is not my job to promote Q15x25. What I am
doing is evaluating the mode instead, doing my best to give it a fair
chance to show it's stuff. - Both good and bad.
I'm beginning to wonder if 17 meters is the best place to do this
evaluation, but that's the spot the ARRL folks gave me so that's what
I have to work with right now. - I sure wish 15 meters was open more