Can anybody tell me which is the best frequency for beacon, i intend
to use 14109.5 and the beacon : zs6aag becon report to
zs6aag_rsa@.... I will be very happy to try q15x25 with anybody
interested.
ZS6AAG

--- In Q15X25@yahoogroups.com, "Charles Brabham" <n5pvl@...> wrote:
>
> --- In Q15X25@yahoogroups.com, kd4e <kd4e@v...> wrote:
> >
> > There is a new band use proposal before the FCC from the
> > ARRL.
> >
> > I'd like to see a mandatory requirement for all digital
> > modes, including proprietary modes like Pactor III, to
> > embed non-proprietary ID beacons in their protocols.
> >
> > That way anyone with commonly available gear and
> > software may know who is transmitting.
> >
> > Can this be done?
> >
>
> I certainly can be done, but convincing the SCS corporation to do
so
> would be a tall order.
>
> Charles,  N5PVL
>


  Hi Folks, Hi Charles. Sorry to drag this old post up, and I hope
I read all the replies correctly, and did not jump in halfway
through the thread, but here goes. (I am using the WEB-Interface).
I also JUST joined the group.


  All SCS Controllers (Please don't call them modems, that is the term
the IDI-Yachts use because they actually perceive it as such) Have,
as default, a CWID set. It uses MYCALL and has a default of 20
WPM. AIRMAIL, the Client program, which is sort of half-FBB bbs
and half-outlook express, goes out of it's way to put the controller
into pactor 1 UNPROTO mode when it sends the callsign at the end
of the transmission. It also does not ID every odd number of
minutes, it only id's at the end. If left alone, the controller
will emit a 20 WPM CW id every 7 minutes, allowing the remote
station to retry until it is done sending it's CWID. It will then
wait for the next sync ACK to continue on.

  This modified behavior, along with the fact that FBB compression
is used despite the fact that pseudo-markov compression is ALREADY
built into the controller, along with the fact that the outdated
pactor2 protocol has not been released for general consumption
even for the purposes of SWL'ing (SCS themselves said that
hams should not be monitoring other hams e-mail) leaves a lot
of questions to be answered.

  And before it comes up and and affects my credibility on this
topic, YES, I am a winlinker. on eighty meters. early in
the morning. at 500hz pactor2, and on 14.105.2 USB pactor3,
which is THE flagship station of winlink.

  This is the Q15X25 group, and I have gone off on a tangient
about winlink, and I apologize, but there were a few posts which I
felt would be better read with some additional info.

On topic, has anyone else had the problem of extremely low
AVERAGE output power with Q15? I can not seem to nudge
more than 5 watts out of my poor jupiter, even with the ALC
lit. I would like to experiment with Q15 in UNPROTO mode
using RADIOMIRROR.

Best 73 folks,
Steven N1OHX

P.S. My controller always sends a clear CWID at the end of every
winlink session. (Classic) I also noticed a few posts that had a
subject
of "Q15x25 digest blah blah blah" And saw that this thread
had continued there. I also noticed a few MBO operators there,
saying some outrageous things. Again I apologize, and now that I
see there are MBO operators here on the list keeping tabs on the
AX.25 crowd I wonder how my winlink experience from this point on
will be?


steven2@...
n1ohx@...

--- In Q15X25@yahoogroups.com, "Scott Thile \(K4SET\)" <k4set@...>
wrote:
>
> The SCS Pactor units have employed a Pactor FEC ID at the end of
each
> connection or connection attempt since summer of 2003. It was
immediately
> implemented with Airmail and Winlink 2000. At least two of the
soundcard
> mode programs can monitor ID that (MixW and Digipan).
>
> As Jeremy stated, before that, we used a CW ID with Winlink 2000.
Of course
> having these ID options does not fix the problem of some lid or
another
> disabling them and than causing interference, which has been the
case on
> some of the NON-Winlink related QRM that we (Winlink 2000
operators) have
> been very unfortunately blamed for.


  O.K. Scott. Get ready to feel the pain of your LIES. (Or ignorance).


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

cmd: Thiis is to let you know local echo is on.
(N1OHX)
*** ERROR: PSE TYPE HELP

cmd: help reset
RESE(t):
causes a software reset. Box contents and
system
parameters will not be changed by
RESEt.

cmd: help restart
REST(art):
causes a software restart. CAUTION: RESTart
may
erase the complete mailbox contents. It sets
the
system parameters to default
values.

cmd: reset
PTC-II System  68360/DSP-56303
     Version V.3.6   Level 3
   (C) 2005  SCS GmbH & Co. KG

2097152 bytes SRAM detected
256k words DSP-RAM detected

BIOS: Version 1.90 detected

FLASHCALL: *SCSPTC*

*** STBY >>

cmd: restart
PTC-II System  68360/DSP-56303
     Version V.3.6   Level 3
   (C) 2005  SCS GmbH & Co. KG

2097152 bytes SRAM detected
256k words DSP-RAM detected

BIOS: Version 1.90 detected

FLASHCALL: *SCSPTC*

*** STBY >>

cmd: my n1ohx
Mycall: >N1OHX<

cmd: maxE 30
*** TIMEOUT-PARAMETER: 30

cmd: heklp
*** ERROR: PSE TYPE HELP

cmd: help cwid
CW(id):
First parameter:
enables (1-5) or disables (0) CW-
identification:
0: CWID off
1: Pactor (ARQ) CWID on
2: Pactor (ARQ + Unproto) CWID on
3: Amtor (ARQ) / Pactor (ARQ + Unproto) CWID
on
4, 5: like 2 and 3, CWID also after RX-
QRT
(Default: 1)

Second parameter:
0: normal CWID
1: CWID at startup on ARQ Master
calls
2: audio-CWID only / without PTT-
Keying
3: functions 1 and 2 enabled.
4-7: like 0-3 but on PACTOR slave connects CWID right
after first own TX packet.
(Default: 0)

cmd: cwid
*** CWID-PARAMETERS: 0  2

cmd: c k4set
*** NOW CALLING K4SET

*** NO RESPONSE FROM K4SET / 19:16:38 / FRI, 02-JUN-06

*** STBY >>

cmd: parameters CWID were set to 0 2, yet no CWID was sent. Let's
*** ERROR: PSE TYPE HELP

cmd: look at what AIORMAIL sets as defaults.
*** ERROR: PSE TYPE HELP

cmd: sorry for the typo's, just wanna prove this hasn't been edited
*** ERROR: PSE TYPE HELP

cmd:


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

  Let's take a journey into a FRESH copy of AIRMAIL.
CALLSIGN, BAUDRATE, QTH and LOCATOR have been set.
CWID has been SPECIFICALLY CHECKED, IT WAS NOT
A DEFAULT AND IT WAS HIDDEN UNDER AN "ADVANCED"
OPTIONS TAB!

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


2006/06/02 19:20:01 PTC-IIex modem initialized OK

cmd:

PTC-IIex - High Performance HF/VHF/UHF Communications Controller
PACTOR - Level-III - High Speed Data Transfer Protocol
  >>> Professional / Marine Firmware V.3.6  <<<
  (C) 1994-2005  SCS GmbH & Co. KG - Germany

BIOS: Version 1.90 detected

Packet Radio Port: SCS - DSP MULTI MODEM detected

cmd:
< modem reset >

PTC-II System  68360/DSP-56303
     Version V.3.6   Level 3
   (C) 2005  SCS GmbH & Co. KG

2097152 bytes SRAM detected
256k words DSP-RAM detected

BIOS: Version 1.90 detected

FLASHCALL: *SCSPTC*
[17]
*** STBY >>

cmd: TERM 4
cmd: SERB
Baudrate setting:  57600 BD (auto)
cmd: TRX RTS 0
*** ERROR: PSE TYPE HELP
cmd: AM
AMTOR/PTC-II V.3.6  (C) 1994-2005 SCS GmbH & Co. KG
===================================================
**-A-** (SCSP):>TR 0
*** T/R-REVERSE PARAMETER: 0
**-A-** (SCSP):>PT
*** PACTOR ACTIVE >>>
[17]
*** STBY >>
cmd: QRTC 4
QRT-CHARACTER = ASCII: 4
cmd: ESC 27
ESCAPE-CHARACTER = ASCII: 27
cmd: PTCH 31
*** PACTOR HOSTMODE CHANNEL: 31
cmd: MAXE 35
*** TIMEOUT-PARAMETER: 35
cmd: LF 0
*** LF IGNORE PARAMETER: 0
cmd: CM 0
*** CONNECT-MSG: 0
cmd: REM 0
*** REMOTE: 0
cmd: BOX 0
*** DIRECT BOX ACCESS: 0
cmd: MAIL 0
*** MAIL-ANNOUNCER-PARAMETER: 0
cmd: CHOB 0
*** CHANGEOVER-BELL-PARAMETER: 0
cmd: UML 0
GERMAN HUFFMAN UMLAUTS: 0
cmd: TRX S 0         (These errors are due to the fact thatI do not)
*** ERROR: PSE TYPE HELP (have auto-qsy circuitry, it is illegal on)
cmd: TRX DU 0                (band to have the PTC auto-qsy and
*** ERROR: PSE TYPE HELP     (Auto-Call. These features are,
cmd: U *1                   (however, available in AirMail)
*** UNPROTO-REPETITION-TIME: 1 (Pactor ID repetition has been SET,
cmd: CHO 25                    (Even though CWID was set in airmail)
CHANGE-OVER-CHARACTER = ASCII: 25
cmd: BK 24
BREAK-IN-CHARACTER = ASCII: 24
cmd: FSKA 171
AFSK TX AUDIO OUTPUT LEVEL (PEAK-TO-PEAK, mV): 171
cmd: PSKA 228
PSK TX AUDIO PEAK LEVEL (PEAK-TO-PEAK, mV): 228
cmd: TIME 19:20:00
Time:  19:20:00
cmd: DATE 02.06.06
Date:   FRI, 02-JUN-06
cmd: ST 2
*** STATUS-LEVEL: 2
cmd: PAC PRB 0
cmd: PAC CM 0
cmd: PAC CB 0
cmd: PAC M 0
cmd: PAC US 10
cmd: FAX MB
Baudrate setting:  57600 BD
cmd: FAX D 500
*** FM-FAX DEVIATION: 500
cmd: FAX FR 3
*** FM-FAX RX-RESOLUTION: 3
cmd: FR MO 0
*** FREE SIGNAL MODE: 0 (NONE)
cmd: SYS SERN
Serial number: (I have deleted this for security)
cmd: < Modem serial#: (This too)
MY *SCSPTC*
Mycall: >*SCSPTC*<
cmd: LICENSE
LICENSE: (Deleted for security)
cmd: < Professional (Pactor-3) firmware ver: 3.6, P-3 license OK >
<Airmail: PTC-II initialized OK first try>
TONES 2
*** AUDIO TONES: 2
cmd: MARK 1600                    (Pay CAREFUL ATTENTION TO THESE!)
*** MARK FREQUENCY (HZ): 1600 (WinLink IS UPPER SIDEBAND!)
cmd: SPACE 1400
*** SPACE FREQUENCY (HZ): 1400
cmd: MYLEV 2
*** HIGHEST POSSIBLE PACTOR LINK LEVEL: 2
*** LINK LEVEL OF ACTUAL/LAST LINK: 0  (This PROVES the CONTROLLER)
cmd: TXD 4                             (has been reset)
TX-DELAY: 4  (20 msec)
cmd: CSD 5
CS-DELAY: 5  (25 msec)
cmd: MYcall N1OHX
Mycall: >N1OHX<
cmd: ARX 0
*** AMTOR RECEPTION: 0
cmd: L 1
*** LISTEN-MODE: 1
cmd: CWID 0
*** CWID-PARAMETERS: 0  2  (AIRMAIL Just tried to disable CWID,)
cmd: CONType 3
*** PACTOR RX CONNECT TYPE: 3
cmd: <callsign set: N1OHX>
<connections enabled>
MYcall N1OHX
Mycall: >N1OHX<
cmd: JHOST4
<AirMail: host mode started>


CWID is the same as the defaults I captured in hyperterminal. I
HAVE, HOWVER,
been able to do a 7 minute on the fly CWID and an end-of-transmission
CWID with the following parameters set by FBB for that dreadful
"WINLINK CLASSIC" operation.

here it is:

!CHOB 0
!CW 1 (This ENABLES CWID)
!CWSPEED 100 (This is NOT WPM)
!FSKA 170
!PSKA 200
!CSDELAY 5
!TXDELAY 4
!MAXERR 40
!MAXSUM 60
!MAXDOWN 5
!MAIL 0
!mode 2
!MAXTRY 4
!MAXUP 3
!MYCALL N1OHX
!MYL 2
!MYSELC NOHX
!PD 0
!PDT 12
!LISTEN 0
#!STATUS 1
!MARK 1600
!SPACE 1400
!TR 0
!TONES 2
!UML 0


  These are the default parameters issued to new winlink "Classic"
ops.
Compare them to the parms issued by airmail. More on this later. I
am in
notepad.

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



>
> All you can do is provide the tools. The rest is up to the
operators!
>
> 73 and 75, Scott, K4SET, RadioMinistries
>
> ________________________________
>

  K4SET runs an MBO on 10.143.4. UPPER sideband. Remember
those MARK/SPACE frequencies? ALso notice it is an
pactor3 MBO. 2.4 KHZ wide. that puts white noise
from 10.144 up to 10.146. conservatively. Skipnet,
a packet radio operation, has been on 10.147 LOWER
sideband for...oh god...Sorry I was a tadpole...

  This is a frequency reserved for AUTOMATIC controlled
stations. It is in perpetual use. K4SET is unwelcome,
is un-coordinated, and installed an MBO on this frequency
without first inspecting the "Lay of the land". 10.147
has been utter chaos since. Charles has screenshots.

  MBO operators also install these MBO on well known PSK watering
holes. an example is ve2afq on 14.067.4. Since 14.070
is in perpetual use by up to 10 individual streams
(Conservatively) by up to 20 operators, when, and just WHEN
is the frequency clear for this MBO?

I need answers.




>  From: Q15X25@yahoogroups.com [mailto:Q15X25@yahoogroups.com]
On
> Behalf Of Jeremy Allen
>  Sent: Monday, November 28, 2005 8:17 PM
>  To: Q15X25@yahoogroups.com
>  Subject: Re: [Q15X25] Digest Number 153
>
>
>
>  Do you mean besides 10 minute CW IDs?  Both of my
>  Boxes that use such protocols (Clover II and Pactor
>  II/III) offer these options already.  They are not
>  often used, because the regs don't require the station
>  ID's to be transmitted in an "open protocol."  Station
>  ID's are transmitted with each packet in all three of
>  these modes, and while not always able to be read by
>  listeners, the current requirement is fulfilled.
>
>  73
>
>  Jeremy N1ZZZ
>
  The ID must be in the mode used. If it is an experimental
or in-compatible mode it is to be in CW. This was an
issue for packet op's at first. Some still use it. Operating
in pactor 3, then switching to pactor 1 unproto is not the same mode.
and pactor3 is clearly CLOSED AND EXPERIMENTAL. Add to that
fbb scrambling, plus pseudo/markov encoding, and you have a
pretty secure system.

  If someone could e-mail me and direct me to the appropriate
forum I will GLADLY post capture files on fellows
getting boat insurance quotes, and doctors reading and replying
to medical reports sent from the office. And if it ever comes up,
i will also post captures of ME sending my sister the word "BADASS"
and sending a picture of a semi-nude (Parts covered) 300
pound woman on an airplane procaliming that we are sending in "The
big bomb".

  I again apologize for these off-topic ramblings, and hope I do
not get moderated into the bit-bucket, but these MBO
OP'S should not go around posting lies in ax.25 forums.
especially when they are jamming FSK300 and Q15X25 literally
off-the-air.

  What is the maximum frame size for Q15X25? also does
Q15 get MORE efficient when you send larger blocks?

best 73
N1OHX@...

Steve,

If you have actual recordings of on-the-air conversations of insurance quotes
being passed and doctors conducting business I would like to have copies --
especially if the offending amateurs can be identified.

I would very much like to pass these on to Riley Hollingsworth as examples of
illegal use of the amateur bands by Winlink 2000.

tim ab0wr

On Friday 02 June 2006 15:23, stevenstimpson wrote:
> --- In Q15X25@yahoogroups.com, "Scott Thile \(K4SET\)" <k4set@...>
>
> wrote:
> > The SCS Pactor units have employed a Pactor FEC ID at the end of
>
> each
>
> > connection or connection attempt since summer of 2003. It was
>
> immediately
>
> > implemented with Airmail and Winlink 2000. At least two of the
>
> soundcard
>
> > mode programs can monitor ID that (MixW and Digipan).
> >
> > As Jeremy stated, before that, we used a CW ID with Winlink 2000.
>
> Of course
>
> > having these ID options does not fix the problem of some lid or
>
> another
>
> > disabling them and than causing interference, which has been the
>
> case on
>
> > some of the NON-Winlink related QRM that we (Winlink 2000
>
> operators) have
>
> > been very unfortunately blamed for.
>
>  O.K. Scott. Get ready to feel the pain of your LIES. (Or ignorance).
>
>
> ------------------------------
>
> cmd: Thiis is to let you know local echo is on.
> (N1OHX)
> *** ERROR: PSE TYPE HELP
>
> cmd: help reset
> RESE(t):
> causes a software reset. Box contents and
> system
> parameters will not be changed by
> RESEt.
>
> cmd: help restart
> REST(art):
> causes a software restart. CAUTION: RESTart
> may
> erase the complete mailbox contents. It sets
> the
> system parameters to default
> values.
>
> cmd: reset
> PTC-II System  68360/DSP-56303
>     Version V.3.6   Level 3
>   (C) 2005  SCS GmbH & Co. KG
>
> 2097152 bytes SRAM detected
> 256k words DSP-RAM detected
>
> BIOS: Version 1.90 detected
>
> FLASHCALL: *SCSPTC*
> 
> *** STBY >>
>
> cmd: restart
> PTC-II System  68360/DSP-56303
>     Version V.3.6   Level 3
>   (C) 2005  SCS GmbH & Co. KG
>
> 2097152 bytes SRAM detected
> 256k words DSP-RAM detected
>
> BIOS: Version 1.90 detected
>
> FLASHCALL: *SCSPTC*
> 
> *** STBY >>
>
> cmd: my n1ohx
> Mycall: >N1OHX<
>
> cmd: maxE 30
> *** TIMEOUT-PARAMETER: 30
>
> cmd: heklp
> *** ERROR: PSE TYPE HELP
>
> cmd: help cwid
> CW(id):
> First parameter:
> enables (1-5) or disables (0) CW-
> identification:
> 0: CWID off
> 1: Pactor (ARQ) CWID on
> 2: Pactor (ARQ + Unproto) CWID on
> 3: Amtor (ARQ) / Pactor (ARQ + Unproto) CWID
> on
> 4, 5: like 2 and 3, CWID also after RX-
> QRT
> (Default: 1)
>
> Second parameter:
> 0: normal CWID
> 1: CWID at startup on ARQ Master
> calls
> 2: audio-CWID only / without PTT-
> Keying
> 3: functions 1 and 2 enabled.
> 4-7: like 0-3 but on PACTOR slave connects CWID right
> after first own TX packet.
> (Default: 0)
>
> cmd: cwid
> *** CWID-PARAMETERS: 0  2
>
> cmd: c k4set
> *** NOW CALLING K4SET
>
> *** NO RESPONSE FROM K4SET / 19:16:38 / FRI, 02-JUN-06
> 
> *** STBY >>
>
> cmd: parameters CWID were set to 0 2, yet no CWID was sent. Let's
> *** ERROR: PSE TYPE HELP
>
> cmd: look at what AIORMAIL sets as defaults.
> *** ERROR: PSE TYPE HELP
>
> cmd: sorry for the typo's, just wanna prove this hasn't been edited
> *** ERROR: PSE TYPE HELP
>
> cmd:
>
>
> -------------------------
>
>  Let's take a journey into a FRESH copy of AIRMAIL.
> CALLSIGN, BAUDRATE, QTH and LOCATOR have been set.
> CWID has been SPECIFICALLY CHECKED, IT WAS NOT
> A DEFAULT AND IT WAS HIDDEN UNDER AN "ADVANCED"
> OPTIONS TAB!
>
> -------------------------
>
>
> 2006/06/02 19:20:01 PTC-IIex modem initialized OK
>
> cmd:
>
> PTC-IIex - High Performance HF/VHF/UHF Communications Controller
> PACTOR - Level-III - High Speed Data Transfer Protocol
>
>  >>> Professional / Marine Firmware V.3.6  <<<
>
>  (C) 1994-2005  SCS GmbH & Co. KG - Germany
>
> BIOS: Version 1.90 detected
>
> Packet Radio Port: SCS - DSP MULTI MODEM detected
>
> cmd:
> < modem reset >
>
> PTC-II System  68360/DSP-56303
>     Version V.3.6   Level 3
>   (C) 2005  SCS GmbH & Co. KG
>
> 2097152 bytes SRAM detected
> 256k words DSP-RAM detected
>
> BIOS: Version 1.90 detected
>
> FLASHCALL: *SCSPTC*
> [17]
> *** STBY >>
>
> cmd: TERM 4
> cmd: SERB
> Baudrate setting:  57600 BD (auto)
> cmd: TRX RTS 0
> *** ERROR: PSE TYPE HELP
> cmd: AM
> AMTOR/PTC-II V.3.6  (C) 1994-2005 SCS GmbH & Co. KG
> ===================================================
> **-A-** (SCSP):>TR 0
> *** T/R-REVERSE PARAMETER: 0
> **-A-** (SCSP):>PT
> *** PACTOR ACTIVE >>>
> [17]
> *** STBY >>
> cmd: QRTC 4
> QRT-CHARACTER = ASCII: 4
> cmd: ESC 27
> ESCAPE-CHARACTER = ASCII: 27
> cmd: PTCH 31
> *** PACTOR HOSTMODE CHANNEL: 31
> cmd: MAXE 35
> *** TIMEOUT-PARAMETER: 35
> cmd: LF 0
> *** LF IGNORE PARAMETER: 0
> cmd: CM 0
> *** CONNECT-MSG: 0
> cmd: REM 0
> *** REMOTE: 0
> cmd: BOX 0
> *** DIRECT BOX ACCESS: 0
> cmd: MAIL 0
> *** MAIL-ANNOUNCER-PARAMETER: 0
> cmd: CHOB 0
> *** CHANGEOVER-BELL-PARAMETER: 0
> cmd: UML 0
> GERMAN HUFFMAN UMLAUTS: 0
> cmd: TRX S 0         (These errors are due to the fact thatI do not)
> *** ERROR: PSE TYPE HELP (have auto-qsy circuitry, it is illegal on)
> cmd: TRX DU 0                (band to have the PTC auto-qsy and
> *** ERROR: PSE TYPE HELP     (Auto-Call. These features are,
> cmd: U *1                   (however, available in AirMail)
> *** UNPROTO-REPETITION-TIME: 1 (Pactor ID repetition has been SET,
> cmd: CHO 25                    (Even though CWID was set in airmail)
> CHANGE-OVER-CHARACTER = ASCII: 25
> cmd: BK 24
> BREAK-IN-CHARACTER = ASCII: 24
> cmd: FSKA 171
> AFSK TX AUDIO OUTPUT LEVEL (PEAK-TO-PEAK, mV): 171
> cmd: PSKA 228
> PSK TX AUDIO PEAK LEVEL (PEAK-TO-PEAK, mV): 228
> cmd: TIME 19:20:00
> Time:  19:20:00
> cmd: DATE 02.06.06
> Date:   FRI, 02-JUN-06
> cmd: ST 2
> *** STATUS-LEVEL: 2
> cmd: PAC PRB 0
> cmd: PAC CM 0
> cmd: PAC CB 0
> cmd: PAC M 0
> cmd: PAC US 10
> cmd: FAX MB
> Baudrate setting:  57600 BD
> cmd: FAX D 500
> *** FM-FAX DEVIATION: 500
> cmd: FAX FR 3
> *** FM-FAX RX-RESOLUTION: 3
> cmd: FR MO 0
> *** FREE SIGNAL MODE: 0 (NONE)
> cmd: SYS SERN
> Serial number: (I have deleted this for security)
> cmd: < Modem serial#: (This too)
> MY *SCSPTC*
> Mycall: >*SCSPTC*<
> cmd: LICENSE
> LICENSE: (Deleted for security)
> cmd: < Professional (Pactor-3) firmware ver: 3.6, P-3 license OK >
> <Airmail: PTC-II initialized OK first try>
> TONES 2
> *** AUDIO TONES: 2
> cmd: MARK 1600                    (Pay CAREFUL ATTENTION TO THESE!)
> *** MARK FREQUENCY (HZ): 1600 (WinLink IS UPPER SIDEBAND!)
> cmd: SPACE 1400
> *** SPACE FREQUENCY (HZ): 1400
> cmd: MYLEV 2
> *** HIGHEST POSSIBLE PACTOR LINK LEVEL: 2
> *** LINK LEVEL OF ACTUAL/LAST LINK: 0  (This PROVES the CONTROLLER)
> cmd: TXD 4                             (has been reset)
> TX-DELAY: 4  (20 msec)
> cmd: CSD 5
> CS-DELAY: 5  (25 msec)
> cmd: MYcall N1OHX
> Mycall: >N1OHX<
> cmd: ARX 0
> *** AMTOR RECEPTION: 0
> cmd: L 1
> *** LISTEN-MODE: 1
> cmd: CWID 0
> *** CWID-PARAMETERS: 0  2  (AIRMAIL Just tried to disable CWID,)
> cmd: CONType 3
> *** PACTOR RX CONNECT TYPE: 3
> cmd: <callsign set: N1OHX>
> <connections enabled>
> MYcall N1OHX
> Mycall: >N1OHX<
> cmd: JHOST4
> <AirMail: host mode started>
>
>
> CWID is the same as the defaults I captured in hyperterminal. I
> HAVE, HOWVER,
> been able to do a 7 minute on the fly CWID and an end-of-transmission
> CWID with the following parameters set by FBB for that dreadful
> "WINLINK CLASSIC" operation.
>
> here it is:
>
> !CHOB 0
> !CW 1 (This ENABLES CWID)
> !CWSPEED 100 (This is NOT WPM)
> !FSKA 170
> !PSKA 200
> !CSDELAY 5
> !TXDELAY 4
> !MAXERR 40
> !MAXSUM 60
> !MAXDOWN 5
> !MAIL 0
> !mode 2
> !MAXTRY 4
> !MAXUP 3
> !MYCALL N1OHX
> !MYL 2
> !MYSELC NOHX
> !PD 0
> !PDT 12
> !LISTEN 0
> #!STATUS 1
> !MARK 1600
> !SPACE 1400
> !TR 0
> !TONES 2
> !UML 0
>
>
>  These are the default parameters issued to new winlink "Classic"
> ops.
> Compare them to the parms issued by airmail. More on this later. I
> am in
> notepad.
>
> --------------
>
> > All you can do is provide the tools. The rest is up to the
>
> operators!
>
> > 73 and 75, Scott, K4SET, RadioMinistries
> >
> > ________________________________
>
>  K4SET runs an MBO on 10.143.4. UPPER sideband. Remember
> those MARK/SPACE frequencies? ALso notice it is an
> pactor3 MBO. 2.4 KHZ wide. that puts white noise
> from 10.144 up to 10.146. conservatively. Skipnet,
> a packet radio operation, has been on 10.147 LOWER
> sideband for...oh god...Sorry I was a tadpole...
>
>  This is a frequency reserved for AUTOMATIC controlled
> stations. It is in perpetual use. K4SET is unwelcome,
> is un-coordinated, and installed an MBO on this frequency
> without first inspecting the "Lay of the land". 10.147
> has been utter chaos since. Charles has screenshots.
>
>  MBO operators also install these MBO on well known PSK watering
> holes. an example is ve2afq on 14.067.4. Since 14.070
> is in perpetual use by up to 10 individual streams
> (Conservatively) by up to 20 operators, when, and just WHEN
> is the frequency clear for this MBO?
>
> I need answers.
>
> >  From: Q15X25@yahoogroups.com [mailto:Q15X25@yahoogroups.com]
>
> On
>
> > Behalf Of Jeremy Allen
> >  Sent: Monday, November 28, 2005 8:17 PM
> >  To: Q15X25@yahoogroups.com
> >  Subject: Re: [Q15X25] Digest Number 153
> >
> >
> >
> >  Do you mean besides 10 minute CW IDs?  Both of my
> >  Boxes that use such protocols (Clover II and Pactor
> >  II/III) offer these options already.  They are not
> >  often used, because the regs don't require the station
> >  ID's to be transmitted in an "open protocol."  Station
> >  ID's are transmitted with each packet in all three of
> >  these modes, and while not always able to be read by
> >  listeners, the current requirement is fulfilled.
> >
> >  73
> >
> >  Jeremy N1ZZZ
>
>  The ID must be in the mode used. If it is an experimental
> or in-compatible mode it is to be in CW. This was an
> issue for packet op's at first. Some still use it. Operating
> in pactor 3, then switching to pactor 1 unproto is not the same mode.
> and pactor3 is clearly CLOSED AND EXPERIMENTAL. Add to that
> fbb scrambling, plus pseudo/markov encoding, and you have a
> pretty secure system.
>
>  If someone could e-mail me and direct me to the appropriate
> forum I will GLADLY post capture files on fellows
> getting boat insurance quotes, and doctors reading and replying
> to medical reports sent from the office. And if it ever comes up,
> i will also post captures of ME sending my sister the word "BADASS"
> and sending a picture of a semi-nude (Parts covered) 300
> pound woman on an airplane procaliming that we are sending in "The
> big bomb".
>
>  I again apologize for these off-topic ramblings, and hope I do
> not get moderated into the bit-bucket, but these MBO
> OP'S should not go around posting lies in ax.25 forums.
> especially when they are jamming FSK300 and Q15X25 literally
> off-the-air.
>
>  What is the maximum frame size for Q15X25? also does
> Q15 get MORE efficient when you send larger blocks?
>
> best 73
> N1OHX@...

Hi guys, sorry it's been a while since I checked this group.

Here's a bit of an update.

From what I have heard the mode works fine. The only reason it doesn't
have better support (YET) is that there are no simple hardware
platforms available for it. This is why I was hoping to see Kantronics
    include the mode in their Kam XL. After all the XL bosts DSP
technology and is the only TNC I know of currently on the market
suitable.

It is disapointing to say the least that years later nothing has been
done to offer more modern DSP modes in this TNC, after all it is it's
main claim to fame. Flash upgradable with the latest modes etc etc.

Currently I receive no replies from Kantronics when emailing them
about this. It has been over a year now since they first started
development on the mode for their TNC.

My current info from the grape vine is that they don't have a lot of
interest in supporting the Amateur market for their product as money
is more forthcomming from the commercial sector.

This in it's self is very sad and bad news for us.

So what does the future hold?

I myself am currently looking at using USB sound card dongles chained
off a dedicated PC. Power usage is of course going to be horrific and
exactly the path I didn't want to go down as it will exclude such
setups on hilltops etc where power is usually provided by solar
panels. But what can you do. A TNC solution at present is going no where.

Long term, there is no reason why a developers group couldn't look at
a alternative open source image for the Kam XL. While Kantronics do
not seem interested in making their code open source. I can't see any
reason why if a group started from scratch on their own version an
alternative could be developed that supports not only Q15X25 packet
but all the other packet modes and speeds currently so sadly missing
from the XL. This sort of thing has been done for everything from the
TinyTrack to DVD recorders. Where the original designers have let the
consumer down, people have picked up the torch and turned a great yet
lacking device into a killer product by getting together with other
like minded users and writing their own firmware.

So if anyone is interested in this and has programming ability. Please
contact me vk4akp@... and perhaps we can start a developers
group to do just this.

In the mean time all my Kam XL's will go back into moth balls and I
guess I will start to go down the USB sound card trail.

Keep in mind that until a newer mode is invented, other then 1200 baud
PSK, Q15X25 is currently the only other option available to anyone
wanting to run packet on HF at a higher baudrate then the traditional
300 Baud. I have also heard of people running G3RUH at 4800 baud on
21Mhz. But once again, I don't know of any current TNC technology
available to do this.

As I've pointed out to Kantronics, what they really need is for the
packet mode to be an independant setting to the baud rate. That way
the device is far more flexable for things like HF and Satelite work.
Once again, I won't hold my breath.

Anyhow, I'd be interested to hear who's QRV in this mode and on what
frequencies etc currently.

Regards,
Ken - VK4AKP
.-.-.

--- In Q15X25@yahoogroups.com, "Scott Thile \(K4SET\)" <k4set@...> wrote:
>
> Hello all,
>
> This mode never really worked all that well, and from what I can
tell has
> more of less died. We only see occasional posts here. Maybe one of two a
> month asking what's up....
>
> Forgive me if I am mistaken, but I doubt it will be worth developing
on the
> XL as it is simply not viable in its current state of development on any
> platform.
>
> Great idea, just didn't pan out and as far as I know, the developers
in it
> have lost interest. I think there is potential, but that is all
there is at
> this point.
>
> 73 and 75, Scott, K4SET
>
> >-----Original Message-----
> >From: Q15X25@yahoogroups.com [mailto:Q15X25@yahoogroups.com]
> >On Behalf Of Ken
> >Sent: Tuesday, May 03, 2005 11:56 AM
> >To: Q15X25@yahoogroups.com
> >Subject: [Q15X25] Re: Kantronics, Kam XL
> >
> >The Kam XL is a DSP TNC. The Tech at Kantronics tells me that
> >it would be possible! The next step is to try and get the
> >author to contact Kantronics and give permission for it's use.
> >
> >They also query wether the mode is too wide to be allowd in the US?
> >
> >Please everyone, help to make this happen!
> >
> >THis would mean many HF Gateways using the Kam XL's (Very
> >popular) would become available. Q15X25 would become most
> >popular and common place on HF!
> >
> >Regards,
> >Ken.
> >.-.-.
> >
>

--- In Q15X25@yahoogroups.com, "Ken" <vk4akp@...> wrote:
>
> Hi guys, sorry it's been a while since I checked this group.
>
> Here's a bit of an update.
>
> From what I have heard the mode works fine. The only reason it doesn't
> have better support (YET) is that there are no simple hardware
> platforms available for it. This is why I was hoping to see Kantronics
>    include the mode in their Kam XL. After all the XL bosts DSP
> technology and is the only TNC I know of currently on the market
> suitable.
>
> It is disapointing to say the least that years later nothing has been
> done to offer more modern DSP modes in this TNC, after all it is it's
> main claim to fame. Flash upgradable with the latest modes etc etc.
>
> Currently I receive no replies from Kantronics when emailing them
> about this. It has been over a year now since they first started
> development on the mode for their TNC.
>
> My current info from the grape vine is that they don't have a lot of
> interest in supporting the Amateur market for their product as money
> is more forthcomming from the commercial sector.
>
> This in it's self is very sad and bad news for us.
>
> So what does the future hold?
>
> I myself am currently looking at using USB sound card dongles chained
> off a dedicated PC. Power usage is of course going to be horrific and
> exactly the path I didn't want to go down as it will exclude such
> setups on hilltops etc where power is usually provided by solar
> panels. But what can you do. A TNC solution at present is going no
where.
>
> Long term, there is no reason why a developers group couldn't look at
> a alternative open source image for the Kam XL. While Kantronics do
> not seem interested in making their code open source. I can't see any
> reason why if a group started from scratch on their own version an
> alternative could be developed that supports not only Q15X25 packet
> but all the other packet modes and speeds currently so sadly missing
> from the XL. This sort of thing has been done for everything from the
> TinyTrack to DVD recorders. Where the original designers have let the
> consumer down, people have picked up the torch and turned a great yet
> lacking device into a killer product by getting together with other
> like minded users and writing their own firmware.
>
> So if anyone is interested in this and has programming ability. Please
> contact me vk4akp@... and perhaps we can start a developers
> group to do just this.
>
> In the mean time all my Kam XL's will go back into moth balls and I
> guess I will start to go down the USB sound card trail.
>
> Keep in mind that until a newer mode is invented, other then 1200 baud
> PSK, Q15X25 is currently the only other option available to anyone
> wanting to run packet on HF at a higher baudrate then the traditional
> 300 Baud. I have also heard of people running G3RUH at 4800 baud on
> 21Mhz. But once again, I don't know of any current TNC technology
> available to do this.
>
> As I've pointed out to Kantronics, what they really need is for the
> packet mode to be an independant setting to the baud rate. That way
> the device is far more flexable for things like HF and Satelite work.
> Once again, I won't hold my breath.
>
> Anyhow, I'd be interested to hear who's QRV in this mode and on what
> frequencies etc currently.
>
> Regards,
> Ken - VK4AKP
> .-.-.
>
> --- In Q15X25@yahoogroups.com, "Scott Thile \(K4SET\)" <k4set@> wrote:
> >
> > Hello all,
> >
> > This mode never really worked all that well, and from what I can
> tell has
> > more of less died. We only see occasional posts here. Maybe one of
two a
> > month asking what's up....
> >
> > Forgive me if I am mistaken, but I doubt it will be worth developing
> on the
> > XL as it is simply not viable in its current state of development
on any
> > platform.
> >
> > Great idea, just didn't pan out and as far as I know, the developers
> in it
> > have lost interest. I think there is potential, but that is all
> there is at
> > this point.
> >
> > 73 and 75, Scott, K4SET
> >
> > >-----Original Message-----
> > >From: Q15X25@yahoogroups.com [mailto:Q15X25@yahoogroups.com]
> > >On Behalf Of Ken
> > >Sent: Tuesday, May 03, 2005 11:56 AM
> > >To: Q15X25@yahoogroups.com
> > >Subject: [Q15X25] Re: Kantronics, Kam XL
> > >
> > >The Kam XL is a DSP TNC. The Tech at Kantronics tells me that
> > >it would be possible! The next step is to try and get the
> > >author to contact Kantronics and give permission for it's use.
> > >
> > >They also query wether the mode is too wide to be allowd in the US?
> > >
> > >Please everyone, help to make this happen!
> > >
> > >THis would mean many HF Gateways using the Kam XL's (Very
> > >popular) would become available. Q15X25 would become most
> > >popular and common place on HF!
> > >
> > >Regards,
> > >Ken.
> > >.-.-.
> > >
> >
>


Ken,

  You should post this to the kantronics group. We have kantronics tech
support in there now. Maybe you can get them to help.

http://tech.groups.yahoo.com/group/kantronics/message/282

paul

Could I suggest that PAX/PAX2 be considered as candidate modems formats?

Those are very robust modem formats, far better than the traditional
Bell 103 modems
for HF, and might prove to be better than Q15X25 in poor conditions,
specially on the
lower bands. Q15X25 is faster, but requires a clean, stable channel, or
it won't work.

While PAX is rather slow, in comparison, it really fights to get the
data thru when others
fail and desist. It is better to have a slow working link than none at
all. PAX requires
about the same bandwidth as a Bell 103 modem. PAX2 is wider.

Jose, CO2JA


Paul David Gregg, KD4IDR wrote:

>--- In Q15X25@yahoogroups.com, "Ken" <vk4akp@...> wrote:
>
>
>>Hi guys, sorry it's been a while since I checked this group.
>>
>>Here's a bit of an update.
>>
>>From what I have heard the mode works fine. The only reason it doesn't
>>have better support (YET) is that there are no simple hardware
>>platforms available for it. This is why I was hoping to see Kantronics
>>   include the mode in their Kam XL. After all the XL bosts DSP
>>technology and is the only TNC I know of currently on the market
>>suitable.
>>
>>It is disapointing to say the least that years later nothing has been
>>done to offer more modern DSP modes in this TNC, after all it is it's
>>main claim to fame. Flash upgradable with the latest modes etc etc.
>>
>>Currently I receive no replies from Kantronics when emailing them
>>about this. It has been over a year now since they first started
>>development on the mode for their TNC.
>>
>>My current info from the grape vine is that they don't have a lot of
>>interest in supporting the Amateur market for their product as money
>>is more forthcomming from the commercial sector.
>>
>>This in it's self is very sad and bad news for us.
>>
>>So what does the future hold?
>>
>>I myself am currently looking at using USB sound card dongles chained
>>off a dedicated PC. Power usage is of course going to be horrific and
>>exactly the path I didn't want to go down as it will exclude such
>>setups on hilltops etc where power is usually provided by solar
>>panels. But what can you do. A TNC solution at present is going no
>>
>>
>where.
>
>
>>Long term, there is no reason why a developers group couldn't look at
>>a alternative open source image for the Kam XL. While Kantronics do
>>not seem interested in making their code open source. I can't see any
>>reason why if a group started from scratch on their own version an
>>alternative could be developed that supports not only Q15X25 packet
>>but all the other packet modes and speeds currently so sadly missing
>>from the XL. This sort of thing has been done for everything from the
>>TinyTrack to DVD recorders. Where the original designers have let the
>>consumer down, people have picked up the torch and turned a great yet
>>lacking device into a killer product by getting together with other
>>like minded users and writing their own firmware.
>>
>>So if anyone is interested in this and has programming ability. Please
>>contact me vk4akp@... and perhaps we can start a developers
>>group to do just this.
>>
>>In the mean time all my Kam XL's will go back into moth balls and I
>>guess I will start to go down the USB sound card trail.
>>
>>Keep in mind that until a newer mode is invented, other then 1200 baud
>>PSK, Q15X25 is currently the only other option available to anyone
>>wanting to run packet on HF at a higher baudrate then the traditional
>>300 Baud. I have also heard of people running G3RUH at 4800 baud on
>>21Mhz. But once again, I don't know of any current TNC technology
>>available to do this.
>>
>>As I've pointed out to Kantronics, what they really need is for the
>>packet mode to be an independant setting to the baud rate. That way
>>the device is far more flexable for things like HF and Satelite work.
>>Once again, I won't hold my breath.
>>
>>Anyhow, I'd be interested to hear who's QRV in this mode and on what
>>frequencies etc currently.
>>
>>Regards,
>>Ken - VK4AKP
>>.-.-.
>>
>>--- In Q15X25@yahoogroups.com, "Scott Thile \(K4SET\)" <k4set@> wrote:
>>
>>
>>>Hello all,
>>>
>>>This mode never really worked all that well, and from what I can
>>>
>>>
>>tell has
>>
>>
>>>more of less died. We only see occasional posts here. Maybe one of
>>>
>>>
>two a
>
>
>>>month asking what's up....
>>>
>>>Forgive me if I am mistaken, but I doubt it will be worth developing
>>>
>>>
>>on the
>>
>>
>>>XL as it is simply not viable in its current state of development
>>>
>>>
>on any
>
>
>>>platform.
>>>
>>>Great idea, just didn't pan out and as far as I know, the developers
>>>
>>>
>>in it
>>
>>
>>>have lost interest. I think there is potential, but that is all
>>>
>>>
>>there is at
>>
>>
>>>this point.
>>>
>>>73 and 75, Scott, K4SET
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Q15X25@yahoogroups.com [mailto:Q15X25@yahoogroups.com]
>>>>On Behalf Of Ken
>>>>Sent: Tuesday, May 03, 2005 11:56 AM
>>>>To: Q15X25@yahoogroups.com
>>>>Subject: [Q15X25] Re: Kantronics, Kam XL
>>>>
>>>>The Kam XL is a DSP TNC. The Tech at Kantronics tells me that
>>>>it would be possible! The next step is to try and get the
>>>>author to contact Kantronics and give permission for it's use.
>>>>
>>>>They also query wether the mode is too wide to be allowd in the US?
>>>>
>>>>Please everyone, help to make this happen!
>>>>
>>>>THis would mean many HF Gateways using the Kam XL's (Very
>>>>popular) would become available. Q15X25 would become most
>>>>popular and common place on HF!
>>>>
>>>>Regards,
>>>>Ken.
>>>>.-.-.
>>>>
>>>>
>>>>
>
>
>Ken,
>
> You should post this to the kantronics group. We have kantronics tech
>support in there now. Maybe you can get them to help.
>
>http://tech.groups.yahoo.com/group/kantronics/message/282
>
>paul
>
>
>


__________________________________________

XIII Convención Científica de Ingeniería y Arquitectura
28/noviembre al 1/diciembre de 2006
Cujae, Ciudad de la Habana, Cuba
http://www.cujae.edu.cu/eventos/convencion

Hi Paul,

I have spoken to the tech guy direct on a number of occasions. Didn't
help I'm afraid.

Regards,
Ken
.-.-.



> Ken,
>
>  You should post this to the kantronics group. We have kantronics tech
> support in there now. Maybe you can get them to help.
>
> http://tech.groups.yahoo.com/group/kantronics/message/282
>
> paul
>

> Jose A. Amador wrote:
> Could I suggest that PAX/PAX2 be considered as candidate
> modems formats?

There is no point to either -- they are costly proprietary
formats -- contrary to good sense and Ham tradition.

Many manufacturers have tried the proprietary mode
idea and all have failed.  Kantronics among them,
more recently joined by Alinco, Kenwood, and Icom's
competing VHF/UHF digital and linking schemes.

Ham radio needs a non-proprietary foundation same
as in the Internet realm, e.g. IEEE 802.11 and others.

We need a robust format that is 100% non-proprietary:

1. All of the code is published and anyone is
allowed to base apps on it.

2. No exclusive source hardware requirement.

3. Cross-OS platform compatible -- Apple, Linux, and MS.

Only then will we have something likely to earn the
support of the majority of digital mode Ham ops and
only then can we move into the digital mode future
working together vs divided and making inefficient
use of fragmented development resources.


--

Thanks! & 73,
doc, KD4E
... somewhere in FL
URL:  bibleseven (dot) com

Hi Charles!

Could you comment on how we can work towards getting Q15X25 or other
newer / faster HF packet / ax25 compatable modes into smaller hardware
TNC like platforms?

One of the big problems we see is that most of the development is done
in sound card software to support these modes.

For aplications like mobile or hilltop links etc which are often solar
or low power dependant the use of big bulky power hungry PC's is not
viable.

Should we be looking towards TNC technology still? Or through lack of
support / interest should we give up on TNC's and perhaps look towards
embedded mini PC PCB's running linux and USB sound card dongles etc?

Any idea's?

Regards,
Ken - VK4AKP
.-.-.


--- In Q15X25@yahoogroups.com, "Charles Brabham" <n5pvl@...> wrote:
>
>
> ----- Original Message -----
> From: "Rick Williams" <mrfarm@...>
>
>
> > Tomi,
> >
> > As an expert on Q15X25, could you explain why it is does not seem
to be
> > replacing conventional HF packet?
> >
> > What is the drawback other than the very wide bandwidth?
>
> Charles, N5PVL here, net manager for the ARRL Q15x25 SkipNet:
>
> The biggest problem encountered so far with Q15x25 is the reduced
range at
> comparable power levels. Driving fifteen carriers instead of one is one
> explanation for this that I have heard. - But I have heard several.
>
> Q15x25 allows multiple stations to share a single frequency/channel,
which
> puts it way ahead of the TOR modes for this use, but between the wide
> bandwidth and reduced range, it has not taken off as a replacement
for HF
> Packet, at least not at this point. As we learn more about using
Q15x25,
> this situation may improve. At any rate, it is currently being
tested and
> evaluated - as a replacement for HF Packet..
>
> You are right about the wide bandwidth being a problem. SkipNet
SYSOPs have
> a reluctance to engage in what can be seen as lid-like operating
behavior,
> so we are being very careful in our testing not to go about crashing
> people's QSO's. This means that there are very few frequency 'slots'
> available for responsible use of Q15x25 for networking purposes.
This is a
> serious limitation in itself, as one of the primary requirements for
an HF
> Packet replacement is to retain the ability to serve many locations
within a
> narrow slice of spectrum.
>
> So far, only Q15x25 mode has shown any promise at all for use in the
global
> digital net, as a replacement or enhancement of HF Packet. No other
mode
> comes as close in this respect.
>
> The HF Multicast protocol AMP shows a lot of promise as well, but is
only
> useful for messages and bulletins addressed to "ALL". - A mode that
shows
> better overall performance than HF Packet for targetted messages and
> bulletins ( point-to-point ) is what we are hoping to find in Q15x25
mode.
>
> Charles, N5PVL
>

Well some bad news today after so long a effort of trying to get this
damn mode into current technology like the Kam XL.

A response from Tomi to my request to have the mode properly
documented so developers like Kantronics could include it in their TNC
range.

---
> Do you have a more up to date Q15X25 technical description available
please? (Last release received 2005-07-20).

Sorry to say but no. I have mosty forgotten the whole modem as
I haven't used it and I don't think anyone else does either...
At least I haven't heard from anyone.

Unless I get a sudden inspiration to document stuff, I probably
won't update it any more.
---

So it seems we are at a dead end again. :( Most disapointing. I have
been chasing this since 2005! :(

OK So whats next? We still need a newer faster mode for HF that is
ax25 / packet compatable for our existing networks.

Any idea's? The big issue I see is having something that we can get
the TNC manufacturers to include. A mode that is within the capability
of some of the latest hardware like the Kam XL's etc.

My only other idea is to abandon triditional TNC technology and go
down the path of using Embedded PC boards with USB sound card dongles
and linux. While this would offer more mode flexability and access to
a better supported software base it's main limitations are these
devices are generally power hungry which is bad news for field apps
like solar sites and digi's etc.

Any idea's anyone?


~Ken - VK4AKP
.-.-.




--- In Q15X25@yahoogroups.com, kd4e <kd4e@...> wrote:
>
>  > Jose A. Amador wrote:
> > Could I suggest that PAX/PAX2 be considered as candidate
> > modems formats?
>
> There is no point to either -- they are costly proprietary
> formats -- contrary to good sense and Ham tradition.
>
> Many manufacturers have tried the proprietary mode
> idea and all have failed.  Kantronics among them,
> more recently joined by Alinco, Kenwood, and Icom's
> competing VHF/UHF digital and linking schemes.
>
> Ham radio needs a non-proprietary foundation same
> as in the Internet realm, e.g. IEEE 802.11 and others.
>
> We need a robust format that is 100% non-proprietary:
>
> 1. All of the code is published and anyone is
> allowed to base apps on it.
>
> 2. No exclusive source hardware requirement.
>
> 3. Cross-OS platform compatible -- Apple, Linux, and MS.
>
> Only then will we have something likely to earn the
> support of the majority of digital mode Ham ops and
> only then can we move into the digital mode future
> working together vs divided and making inefficient
> use of fragmented development resources.
>
>
> --
>
> Thanks! & 73,
> doc, KD4E
> ... somewhere in FL
> URL:  bibleseven (dot) com
>

Hi Karel!

As far as I can work out Q15X25 is supported within MixW and AGWPE
(AGW Packet Engine) for windows. You might want to try AGW as there is
some very good support for the TPC/IP side of things within AGW.

There are also Linux drivers available for Q15X25 as you already know.

There is also some talk of running it at a slower baudrate to fit
better within the radio's filters. 2300 baud has been suggested.

If anyone else can help Karel, please please do so. I don't know if
you guys are aware of this but Karel is working on some very important
research into helping 3rd world countries with low cost digital
communication's methods. See [http://www.IICD.org ] IICD - The
International Institute for Communication and Development (IICD).


Regards,
Ken - VK4AKP
.-.-.


--- In Q15X25@yahoogroups.com, karel fassotte <karelfassotte@...> wrote:
>
> Hello my name is karel fassotte, PE2KFA / HC1AKP. We are looking for
people that have more experience with the Q15X25 IP gateway to
intranet, internet.
>
>   As to now we have 2 programs that should do the job.
>   The Mixw part that allows packet, Q15x25. However this mode is
poorly supported under windows. Information is not easy to obtain.Ip
we cant get routing, or better no traffic.
>
>   The other is Linux NEWQPSK. In Linux by the way, the ax25
protocoll, so with the QPSK, is very well Integrated. However we have
a problem with interfacing the multimode packet modem under Linux. Has
anyone information on or experience with this specific problem??
>
>   Greetings karel fassotte
>

Don't forget 'newqpsk' mode for FlexNet's Flex32. It has no waterfall
display but on the other hand it allows you to gateway Q15x25 directly
to packet, through Flex32's internal digi function.

Don't overlook Q15x25 on VHF/UHF.

Charles, N5PVL


--- In Q15X25@yahoogroups.com, "Ken" <vk4akp@...> wrote:
>
> Hi Karel!
>
> As far as I can work out Q15X25 is supported within MixW and AGWPE
> (AGW Packet Engine) for windows. You might want to try AGW as there is
> some very good support for the TPC/IP side of things within AGW.
>
> There are also Linux drivers available for Q15X25 as you already know.
>

--- In Q15X25@yahoogroups.com, "Ken" <vk4akp@...> wrote:
>
> OK So whats next? We still need a newer faster mode for HF that is
> ax25 / packet compatable for our existing networks.

Q15x25 has demonstrated that AX25 need not be packet. - In fact there
are several digital modes that could be operated over AX25 just as
Tomi has done with multiple PSK streams.

The primary holdup is that most of the programmers who are capable of
this kind of work have been taught to look down on the concept of an
independent amateur radio network in the first place. They have
specifically been encouraged to look down on AX25, despite the
obvious irony that not a single one of them can point to anything
else that does the same thing better.

Fortunately this is true in the great majority of cases, but not all
of them.

There is a newer, slower mode that strangely enough has great
potential to speed things up on HF. Have you looked at HF multicast?
HF multicast SYSOPs are currently needed, if you find that you are
interested in providing this service and would like to participate.

There is a special section on HF Multicast at USPacket. Skim over the
articles there, if you get a chance.

http://www.uspacket.org

Charles,  N5PVL

Howdy, Ken!

I think that in both the short and long run, we will be better off with
the embedded PC's than we will be with TNC's.

This, in light of the relative ease or difficulty involved in upgrading
the software side of things.

As it stands today, the only digital modes we would have to give up in
order to go completely over to free software over the PC/soundcard
platform are the TOR modes.

Another way of looking at this is that TOR enthusiasts are the one and
only group in amateur radio today who need to cough up big bucks for a
difficult to upgrade multimode TNC in a box.

The rest of us can go "out of the box" in our thinking and operate more
useful, advanced modes for free. ( Dumpster-diver or donated old
computer. )

I don't think that this will happen on the networking side of things
overnight, but I do expect to see it happen as the price of embedded
PC's is dropping continuously, just like the full-sized ones.

In the mean-time, let us not forget that these single-board PC's can be
ordered with lots of COM ports or USB, whichever works best for you.

One situation that networkers should be aware of is that TNCs for home
use are rapidly falling out of fashion, but these units are still good
for building up ( some ) network resources and the prices on them only
have one way to go.

Right now I'm looking at an inexpensive SB embedded PC with three
usable COM ports for a PC-FlexNet node.

http://www.arcom.com/sbc-aim-386ex.htm

The development kit for these has dropped to half the price it was,
just a few years ago. I know this because I have previous experience
with this computer.

So, to cap it all off, I recommend that most hams go over to soundcard
systems and sell thier TNC's real cheap to me.

Charles,  N5PVL


--- In Q15X25@yahoogroups.com, "Ken" <vk4akp@...> wrote:
>
> Hi Charles!
>
> Could you comment on how we can work towards getting Q15X25 or other
> newer / faster HF packet / ax25 compatable modes into smaller hardware
> TNC like platforms?
>snip<
> Should we be looking towards TNC technology still? Or through lack of
> support / interest should we give up on TNC's and perhaps look towards
> embedded mini PC PCB's running linux and USB sound card dongles etc?

The efforts I am seeing might indicate that we are attempting to bite a
bit too large....

On one side, the reports that Q15X25 works better at 2300 baud, and that
the 100 baud packet mode incorporated into MultiPSK works when 300 baud
does not looks like a hint to go at lower speeds and bandwidths, and at
least match the expected thruput of 300 baud packet, reliably. It is a
pity that only some AEA TNC's could go below 300 baud, and that it did
not become popular. Greed or carelessness? Cannot tell, but the results
are there for all to see.

I have been a witness that Pactor II and III are better alternatives
than 300 (and HF 1200 baud) packet, with some 10 times the thruput.

SCS has achieved to better protect the data in transit, starting with
their old "memory ARQ", and using adaptative techniques, like switching
in more complex constellations (Pactor II with 2 carriers) or more
carriers with no more complex constellations than DQPSK, starting with
as few as 2 carriers, and going up to as many as 16, depending on the
channel quality. It is complex and has a price, but works quite well.

Should a faithful copy be made? Guess not, including the avoidance of
patent infringements, but there are salient points in display for all to
see. Adaptativity and data protection seem to be the key.

The behavior with Q15X25 seem to follow this pattern, using slower
speeds if it is more reliable, and avoiding the filters passband edges.

In a multicarrier environment, it is wise to confine them in the
flattest propagation delay portion of the passband. The edges do not
have this desirable property.

It is important to go as fast as POSSIBLE to catch band openings and
move traffic, but with an eye in EFFICIENCY, neither that fast that the
water spills out of the bucket, neither that slow that it takes an
eternity to fill it up. With 300 baud packet, most of the water was
spilled outside (endless retries....remember?)....

It is better (for moving BBS traffic) to have one drop falling INTO the
bucket for a day than a large hose with large pressure bouncing the
water on the bottom of the bucket spilling it all over the place for a
short while (wasting bandwidth). The good choice seems to be an average
of those extreme conditions. Transmitting data, and not live voice, you
are not forced to some minimum transmission speed. Just use the one that
DELIVERS the most.

The HF channel is a variable one. In good years we can move to higher
frequencies, as close to the MUF multipath diminishes or dissapears, but
regional nets with the required path geometries do not enjoy these
benefits.

And yes, the trend in the times we are living is using PC's and sound
cards, as it is versatile and somehow, affordable. Making it open
software may allow some worthwhile contributions and a shorter
development time.

I have seen one similar solution: Using smaller motherboards with less
power hungry processors (VIA, etc) allows the development to be done in
the PC and ported to a smaller and less power hungry box, powered from a
DC-DC converter. It seems to be the fashion nowadays. There are non ham
networks in South America (and possibly Africa) being built that way.

The AEA hardware solution saw the light in 1988....almost 20 years ago.
And at the pace the development goes nowadays, and the attitudes we are
seeing (life is hard and short, I am not criticizing anyone), it looks
that those boxes are history.

Once again, pactor channel access solutions seem to show the way. You
can go with a single speed for all links in a shared channel, like in
wire (X.25 was born in that environment) on VHF/UHF, but on HF all paths
in a network won't show the same quality, so you cannot use the single
speed shared channel efficiently for all, neither a mix of speeds on a
shared channel seems to be a viable solution so far. So peer to peer
links at the highest EFFICIENT speed (maximizing ALLOWABLE thruput, not
HOPING the highest theoretical one to be AVAILABLE always) seem to be
the solution. It is the way the HF, ham side of the link works in
Winlink 2000.

Could a viable mimic of that be achieved?


Jose, CO2JA


PS: Daydreaming....perhaps...even a mixture of those ideas with ALE and
an SDR....

Second...could we be able to live with variable bandwidth, adaptive
digital transmissions in our ham bamds without quarreling among us?

Sorry for the crossposting, but to me, it seems interesting for both groups.

Ken wrote:
> Well some bad news today after so long a effort of trying to get this
>  damn mode into current technology like the Kam XL.
>
> A response from Tomi to my request to have the mode properly
> documented so developers like Kantronics could include it in their
> TNC range.
>
> ---
>> Do you have a more up to date Q15X25 technical description
>> available
> please? (Last release received 2005-07-20).
>
> Sorry to say but no. I have mosty forgotten the whole modem as I
> haven't used it and I don't think anyone else does either... At least
> I haven't heard from anyone.
>
> Unless I get a sudden inspiration to document stuff, I probably won't
> update it any more. ---
>
> So it seems we are at a dead end again. :( Most disapointing. I have
> been chasing this since 2005! :(
>
> OK So whats next? We still need a newer faster mode for HF that is
> ax25 / packet compatable for our existing networks.
>
> Any idea's? The big issue I see is having something that we can get
> the TNC manufacturers to include. A mode that is within the
> capability of some of the latest hardware like the Kam XL's etc.
>
> My only other idea is to abandon triditional TNC technology and go
> down the path of using Embedded PC boards with USB sound card dongles
>  and linux. While this would offer more mode flexability and access
> to a better supported software base it's main limitations are these
> devices are generally power hungry which is bad news for field apps
> like solar sites and digi's etc.
>
> Any idea's anyone?
>
> ~Ken - VK4AKP .-.-.
>
> --- In Q15X25@yahoogroups.com <mailto:Q15X25%40yahoogroups.com>, kd4e
>  <kd4e@...> wrote:
>>
>>> Jose A. Amador wrote: Could I suggest that PAX/PAX2 be considered
>>> as candidate modems formats?
>>
>> There is no point to either -- they are costly proprietary formats
>> -- contrary to good sense and Ham tradition.
>>
>> Many manufacturers have tried the proprietary mode idea and all
>> have failed. Kantronics among them, more recently joined by Alinco,
>> Kenwood, and Icom's competing VHF/UHF digital and linking schemes.
>>
>> Ham radio needs a non-proprietary foundation same as in the
>> Internet realm, e.g. IEEE 802.11 and others.
>>
>> We need a robust format that is 100% non-proprietary:
>>
>> 1. All of the code is published and anyone is allowed to base apps
>> on it.
>>
>> 2. No exclusive source hardware requirement.
>>
>> 3. Cross-OS platform compatible -- Apple, Linux, and MS.
>>
>> Only then will we have something likely to earn the support of the
>> majority of digital mode Ham ops and only then can we move into the
>> digital mode future working together vs divided and making
>> inefficient use of fragmented development resources.
>> --
>>
>> Thanks! & 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot)
>> com

--- In Q15X25@yahoogroups.com, "Charles Brabham" <n5pvl@...> wrote:
>
> Howdy, Ken!
>
> I think that in both the short and long run, we will be better off
with
> the embedded PC's than we will be with TNC's.

  A TNC IS an embedded PC. Even my crustly old MFJ
is a self contained communications device. WHat stops it
from being flexible is FIRMware, and Analog modem.
if the firmware were soft, IE Flashable like it is on modern
tnc's, it would be indistinguishable from any "embedded" option.

>
> This, in light of the relative ease or difficulty involved in
upgrading
> the software side of things.
>
> As it stands today, the only digital modes we would have to give
up in
> order to go completely over to free software over the PC/soundcard
> platform are the TOR modes.

  Assuming soundcard is the way to go. As the death of this
mailing list has shown, undocumented, unsupported, and non-
standardized soundcard communication methods like Q15 and
olivia are killing H.F. digital. Had Q15 actually been offered
with some reasonable and TESTED default settings, IE
settings that are actually capable of sending data through
a real-life radio, things would be different. there is still
hope if kantronics are still involved with it. more on that later.

> Another way of looking at this is that TOR enthusiasts are the one
and
> only group in amateur radio today who need to cough up big bucks
for a
> difficult to upgrade multimode TNC in a box.

  'TOR enthusiasts are slaves to an outrageous monopoly.
they are also slaves to the beaurocracy involved with
what they actually do on the air. *Cough* winlink.

>
> The rest of us can go "out of the box" in our thinking and operate
more
> useful, advanced modes for free. ( Dumpster-diver or donated old
> computer. )


  It is that attitude that seperates the modern HAM
from the real world of cutting edge technology. If
adding a 5 dollar soundcard to a dumpster dived computer
and installing mixW is state of the art then our "Art" form
is in serious trouble. the only thing that has been done with mixW
and soundcard DSP's is we have an emergence of a dozen or so
different ways of accomplishing the same thing, a keyboard qso.
If dumpster equipment and donated stuff is the goal, then
soundcard is overkill, a 5 dollar RTTY tnc and a free DEC terminal
are all that is required. It will accomplish the same thing mixW has.

Many have appreciated what mixW has attempted to do for packet,
but in the real world the faulty software DCD and the strict
"gotta be within 2 hz" tuning requirements of mixW make it
impractical for serious use, IE usage other than keyboarding.

  The modern 'TOR tnc is 2 chips, a communications quality
DSP, and a low voltage communications CPU. the two do not
form a communications device, the software residing in the actual
ram in the tnc (NOT firmware or ROM!) is responsible for
programming the cpu and dsp to process analog signals
in such a way that a "Mode" is achieved. the original SCS
"greed" design has not changed since pactor2 was introduced.
pactor3, rtty,facsimile,packet, amtor and audio processing
were all added by simply updating the software. These
tnc's also have a little known 600 baud packet radio mode
that has been all but ignored by the packet community
because of various "Holy wars" with the company that produced it.

  These tnc's are not a mystery, the motorola DSP and CPU
are off the shelf parts. SCS is making a killing by protecting
thier circuit board design and the software that runs the thing.
all we need is a company with enough vision to produce thier
own DSP-CPU embedded-pc (TNC) to bring us up to date
on digital communications. achieving something on the order
of a Q15 mode that actually works is simply a matter
of writing the software for the DSP. With an open hardware
platform and development kit, amateurs could create
robust communications methods that would finally amount
to more than just typing at 31 baud to each other.
And for AX.25 things could be accomplished in a simple
12 volt tnc on the order of magnitude of what
the "flex32" folks are up to, without the hassle of carrying
around a dozen networked Linux infected IBM pc's.

Never-So-Humbly yours,
Steven-N1OHX

>  'TOR enthusiasts are slaves to an outrageous monopoly.
>  they are also slaves to the beaurocracy involved with
>  what they actually do on the air. *Cough* winlink.

Not at all locked in to any beaurocracy...  The SCS devices natively
support TCP/IP as well as a "legacy" protocol that's both open source
and (probably) more efficient then the existing system.   All that's
lacking is the desire and the need...

I had a long talk with Santa and he said that if I was really good
this year, he might bring me one of those fancy P3 TNC's next
Christmas so I can start experimenting...

73
Bill - WA7NWP

> all we need is a company with enough vision to produce their
> own DSP-CPU embedded-pc (TNC) to bring us up to date

Hum, that sounds strangely like the Kantronics Kam XL Dual Port, Flash
upgradeable, DSP, TNC that has been available now for years. ;)

> on digital communications. achieving something on the order
> of a Q15 mode that actually works is simply a matter
> of writing the software for the DSP.

Can't be too simple they've been working on Q15X25 now for over a year! :(

> With an open hardwareplatform and development kit, amateurs could
> create robust communications methods that would finally amount
> to more than just typing at 31 baud to each other.

Yes unfortunately this doesn't exist as yet. Perhaps if a group started their
own Open code replacement for the Kam XL firmware this would do the same thing?

> And for AX.25 things could be accomplished in a simple
> 12 volt tnc on the order of magnitude of what
> the "flex32" folks are up to, without the hassle of carrying
> around a dozen networked Linux infected IBM pc's.

Yes unfortunately I've had 2x Kam XL's sitting here now for well over a year
hoping to see Q15X25 available for them. Gawd I'd even settle for 1200 baud PSK
in the mean time. But I refuse to run 300baud on HF. :(

I'd say I'll end up going down the sound card trail like so many other Ham's.
Purely because it's the only option currently available. :(

It's a shame really. These TNC's are a nice bit of Kit. Low power consumption,
dual port, Nice NetRom etc software all integrated. I have my two sitting on
serial servers so they are directly on the network here. But I'd say they are
destined to be replaced by an Embedded PC box running a couple of USB Sound Card
Dongles giving me 4x Radio ports at over an Amp of power drain to feed the
hungry PC module. :(

Ken - VK4AKP
.-.-.



Never-So-Humbly yours,
Steven-N1OHX



   ----- Original Message -----
   From: stevenstimpson
   To: Q15X25@yahoogroups.com
   Sent: Thursday, January 11, 2007 6:35 AM
   Subject: [Q15X25] Re: Q15x25 / HF Packet: was HF TCP/IP


   --- In Q15X25@yahoogroups.com, "Charles Brabham" <n5pvl@...> wrote:
   >
   > Howdy, Ken!
   >
   > I think that in both the short and long run, we will be better off
   with
   > the embedded PC's than we will be with TNC's.

   A TNC IS an embedded PC. Even my crustly old MFJ
   is a self contained communications device. WHat stops it
   from being flexible is FIRMware, and Analog modem.
   if the firmware were soft, IE Flashable like it is on modern
   tnc's, it would be indistinguishable from any "embedded" option.

   >
   > This, in light of the relative ease or difficulty involved in
   upgrading
   > the software side of things.
   >
   > As it stands today, the only digital modes we would have to give
   up in
   > order to go completely over to free software over the PC/soundcard
   > platform are the TOR modes.

   Assuming soundcard is the way to go. As the death of this
   mailing list has shown, undocumented, unsupported, and non-
   standardized soundcard communication methods like Q15 and
   olivia are killing H.F. digital. Had Q15 actually been offered
   with some reasonable and TESTED default settings, IE
   settings that are actually capable of sending data through
   a real-life radio, things would be different. there is still
   hope if kantronics are still involved with it. more on that later.

   > Another way of looking at this is that TOR enthusiasts are the one
   and
   > only group in amateur radio today who need to cough up big bucks
   for a
   > difficult to upgrade multimode TNC in a box.

   'TOR enthusiasts are slaves to an outrageous monopoly.
   they are also slaves to the beaurocracy involved with
   what they actually do on the air. *Cough* winlink.

   >
   > The rest of us can go "out of the box" in our thinking and operate
   more
   > useful, advanced modes for free. ( Dumpster-diver or donated old
   > computer. )

   It is that attitude that seperates the modern HAM
   from the real world of cutting edge technology. If
   adding a 5 dollar soundcard to a dumpster dived computer
   and installing mixW is state of the art then our "Art" form
   is in serious trouble. the only thing that has been done with mixW
   and soundcard DSP's is we have an emergence of a dozen or so
   different ways of accomplishing the same thing, a keyboard qso.
   If dumpster equipment and donated stuff is the goal, then
   soundcard is overkill, a 5 dollar RTTY tnc and a free DEC terminal
   are all that is required. It will accomplish the same thing mixW has.

   Many have appreciated what mixW has attempted to do for packet,
   but in the real world the faulty software DCD and the strict
   "gotta be within 2 hz" tuning requirements of mixW make it
   impractical for serious use, IE usage other than keyboarding.

   The modern 'TOR tnc is 2 chips, a communications quality
   DSP, and a low voltage communications CPU. the two do not
   form a communications device, the software residing in the actual
   ram in the tnc (NOT firmware or ROM!) is responsible for
   programming the cpu and dsp to process analog signals
   in such a way that a "Mode" is achieved. the original SCS
   "greed" design has not changed since pactor2 was introduced.
   pactor3, rtty,facsimile,packet, amtor and audio processing
   were all added by simply updating the software. These
   tnc's also have a little known 600 baud packet radio mode
   that has been all but ignored by the packet community
   because of various "Holy wars" with the company that produced it.

   These tnc's are not a mystery, the motorola DSP and CPU
   are off the shelf parts. SCS is making a killing by protecting
   thier circuit board design and the software that runs the thing.
   all we need is a company with enough vision to produce thier
   own DSP-CPU embedded-pc (TNC) to bring us up to date
   on digital communications. achieving something on the order
   of a Q15 mode that actually works is simply a matter
   of writing the software for the DSP. With an open hardware
   platform and development kit, amateurs could create
   robust communications methods that would finally amount
   to more than just typing at 31 baud to each other.
   And for AX.25 things could be accomplished in a simple
   12 volt tnc on the order of magnitude of what
   the "flex32" folks are up to, without the hassle of carrying
   around a dozen networked Linux infected IBM pc's.

   Never-So-Humbly yours,
   Steven-N1OHX





[Non-text portions of this message have been removed]

Ken Page wrote:

>  Yes unfortunately I've had 2x Kam XL's sitting here now for well over
>  a year hoping to see Q15X25 available for them. Gawd I'd even settle
>  for 1200 baud PSK in the mean time. But I refuse to run 300baud on
>  HF. :(

Understandable....are those KAM able to run 100 baud packet?

It is preferable to have a drop falling all the time than many quick
bursts that do not make it.

Jose, CO2JA

No actually. I just tried it now. HBaud 100/1200 failed.

It's one of the big problems with these. It's amazing how advanced the Kam XL
is, yet it's still so terribly crippled.

There is no control over board rate with relation to the mode. In fact, setting
the board rate selects the mode.

For example if I set HBaud 9600 the device assumes G3RUH and there is no way to
tell it any different.

What if I'd like to try G3RUH at say 1200 or 2400 baud on HF. There is no way to
tell the device this in the settings.

They really need the packet mode setting to be separate to the baud rate
settings.

Can't see it happening though. They really seem to be very under staffed when it
comes to firmware development.

Its such a shame, it's a nice bit of Kit otherwise.

Regards,
Ken - VK4AKP
.-.-.


   ----- Original Message -----
   From: Jose A. Amador
   To: Q15X25@yahoogroups.com
   Sent: Saturday, January 13, 2007 2:09 AM
   Subject: Re: [Q15X25] Re: Q15x25 / HF Packet: was HF TCP/IP


   Ken Page wrote:

   > Yes unfortunately I've had 2x Kam XL's sitting here now for well over
   > a year hoping to see Q15X25 available for them. Gawd I'd even settle
   > for 1200 baud PSK in the mean time. But I refuse to run 300baud on
   > HF. :(

   Understandable....are those KAM able to run 100 baud packet?

   It is preferable to have a drop falling all the time than many quick
   bursts that do not make it.

   Jose, CO2JA

Hi Guys!

Well, I'm very pleased to say that I'm testing Q15X25 NewQpsk on my
Kam XL currently.

Kantronics have given me some Beta firmware to test.

(Please don't bug Kantronics for the firmware yet it's no where near
ready).

Anyhow. If someone would like to try and connect to my station and
leave a quick test message I'd apreciate it.

PBBS: vk4akp-1
Freq: 7.035 Mhz USB
Mode: Q15X25
Baud: 2500
FEC: 5
Interleave: 8

Regards,
Ken - vk4akp
.-.-.

Ken, can you adjust the parameters for a lower baud rate and have the
modem scale down automatically, as previos Q15x25 implementations do?

The reason I ask is that on the 17 meter Q15x25 ARRL SkipNet last year,
we were operating with 14 PSK streams at 2300 baud because the narrower
signal worked out a lot better with most HF rig's available passband.

73,
Charles Brabham, N5PVL

Hi Charles.

The answer to that is looking like yes.

I say looking like because of the following.

- The last Beta release allows for scaleing the modem between
1000-3000 Baud.
- For some reason it will only talk to MixW on speeds 2200-3000. (No
Lower). But I think I know why, and hopefuly Kantronics will be able
to fix this.

I am starting to learn a lot about running more complex modes on HF.

It seems HF rig's generally suffer from a lot of problems when it
comes to running these more advanced digital modes.

- RF feedback / distortion is high on the list. RF gets back into the
audio stream very easily and distorts the injected audio. Even with
isolation transformers the ALC needs to be kept relativly low.

- All isolation transformers are not created equal! LOL. The audio
band pass characteristics vary greatly. The RX transformer I currently
use for example is slicing off 50% of the lower end of the audio
spectrum at 2300, 2400, 3000 speed settings.

- Once again with RF distortion of the audio. Isolation of the
antenna's feed line to the antenna can also help. As specially with
vertical's.

My next job is to find a reasonable source of isolation transformers
that have a better audio band pass spec and build a new isolation
interface.

I'd also be interested to hear more about modes like DRM etc and how
they have handled these sort of issues? Or wether the design of DRM
gets around these issues some how?

.-.-.

--- In Q15X25@yahoogroups.com, "Charles Brabham" <n5pvl@...> wrote:
>
> Ken, can you adjust the parameters for a lower baud rate and have the
> modem scale down automatically, as previos Q15x25 implementations do?
>
> The reason I ask is that on the 17 meter Q15x25 ARRL SkipNet last year,
> we were operating with 14 PSK streams at 2300 baud because the narrower
> signal worked out a lot better with most HF rig's available passband.
>
> 73,
> Charles Brabham, N5PVL
>

I ran it like PSK31, with my rig's power turned all the way up.

I control the power out by adjusting the audio level going in to the
Mic plug, and/or use the Mic Gain control to adjust as high as I can
with zero ALC activity.

I usually ran about 50-60 watts, that way.

Note that Q15x25 is not just an HF mode. I have found it to be better
than Packet for mixed-mode digital operation over a VHF FM repeater,
of all things. - It works very well at this!

The only parameter you need to change is TXDELAY, which I had to set
for 800ms. One repeater I tried required a full second ( 1000ms ) of
delay in order to work.

This gives you digital capability when needed on your voice repeater,
at twice the speed of regular packet.

The TXDELAY being so long does slow things down, but Q15x25 tends to
large MAXFRAME and PACLEN values, so it all comes out in the wash as
a very effective mixed-mode system for VHF/UHF.

http://www.uspacket.org/mixmode.htm

73,
Charles Brabham, N5PVL

Anybody still around?

What's up? How are you doing?

73 DE Charles, N5PVL

Herro

I realise this list hasn't been touched in ages, but I thought I'd ask my
question anyway :

I recently travelled to a remote area where the only form of communication with
the outside world was satellite phone and HF radio. I figured it'd be quite cool
to be able to access network resources at home via a data link on HF.

My questions are :

How feasible is it to run TCP/IP telnet sessions over Q15X25 on HF using the
"newqpsk" implementation in Soundmodem (half duplex/one channel) ?

The newqpsk protocol seems to happily run at 2500 and 5000 bits per seconds...
can it run at other bitrates ? how many separate carriers/tones are transmitted
for 5kbit/sec ?

Why are the carriers separated by 125Hz gaps ?

Soundmodem has several options, namely Interleave, FEC, Tune length, etc... what
does Interleave mean ?

Does anyone have any idea how I could make a linux terminal available on HF
through Soundmodem+newqpsk ? Could I create a KISS interface and then attach a
Linux terminal to it ?

Thanks in advance :)

Hello Blue,

Sorry for the delay (I'm a new Q15X25 member) and I hope you're still on the
list!  Anyway, if you search in the archives in this list, you'd find
http://tech.groups.yahoo.com/group/Q15X25/message/367 where it shows that using
this "newpsk" should be pretty strait forward if you've been able to use
soundmodem for say 1200BAUD AFSK.

If you'd like to try this out on HF, we can setup a sched and see
if we can get things working!  I've not personally tried NewPSK yet but I think
it would fun to try.  I have tried 300B HF packet on the 105 Net and the lack of
any FEC really tries my patience with all the retries!


I can't answer your other questions (I've emailed Thomas Sailer in the post
without any reply) but I do know that Tomi Manninen who wrote this component for
soundmodem has been around in recent times.

Finally, for a terminal, it's hard to beat Linpac for KISS-based packet
communications.  In fact, Radek recently made me an administrator of the SF.net
project and I hope to officially add a
few patches, etc.

    http://linpac.sourceforge.net/index.php

--David
KI6ZHD

In short - you are barking up the wrong tree in a number of ways.

It's not just that you cannot reasonably expect to do what you want with
Q15x25...

The fact is that only in the imagination is it possible to do so over HF
frequencies with any digital mode.

Sorry!

Have you looked into "SailMail" ?

73 DE Charles, N5PVL


--- In Q15X25@yahoogroups.com, "aquaratza" <blue@...> wrote:
>
> Herro
>
> I realise this list hasn't been touched in ages, but I thought I'd ask my
question anyway :
>
> I recently travelled to a remote area where the only form of communication
with the outside world was satellite phone and HF radio. I figured it'd be quite
cool to be able to access network resources at home via a data link on HF.
>
> My questions are :
>
> How feasible is it to run TCP/IP telnet sessions over Q15X25 on HF using the
"newqpsk" implementation in Soundmodem (half duplex/one channel) ?
>
> The newqpsk protocol seems to happily run at 2500 and 5000 bits per seconds...
can it run at other bitrates ? how many separate carriers/tones are transmitted
for 5kbit/sec ?
>
> Why are the carriers separated by 125Hz gaps ?
>
> Soundmodem has several options, namely Interleave, FEC, Tune length, etc...
what does Interleave mean ?
>
> Does anyone have any idea how I could make a linux terminal available on HF
through Soundmodem+newqpsk ? Could I create a KISS interface and then attach a
Linux terminal to it ?
>
> Thanks in advance :)
>

Hi Charles... I just joined this group. While poking around I found references
to a Q15X25 mode and have installed it in my MixW. Now I am looking around for
someone to try to use it with. I guess I will have to do some data mining here
to locate frequencies. I am wondering if this is a qso mode or do they just use
it to transfer files and email and such?

73 de w8nsi/nnn0uzw jim

--- In Q15X25@yahoogroups.com, "Charles" <n5pvl@...> wrote:
>
> Anybody still around?
>
> What's up? How are you doing?
>
> 73 DE Charles, N5PVL
>