300bps Packet

300bps Packet

[John Goerzen]

Hi folks,

I'm trying to find a way to do 300 baud packet on Linux for HF.

The obvious answer is soundmodem, but it doesn't seem to work.  I set it 
up, but on TX all I get is a solid tone.  Weird.  Has anyone else made 
this work, and if so, could you send me your config?  I've Googled and 
have found debate over whether or not this should work, but nothing in 
the way of actual help.

On the Windows side, at least MixW does it.  I'm wondering if there may 
be other options for Linux that I don't know of?

-- John
KR0L

Re: 300bps Packet

[Ray Wells]

John,

 From what I've read, Soundmodem does not do 0k3.

 From my perspective, the obvious answer is a TNC2 compatible TNC fitted 
with a KISS only EPROM. Super reliable and works for years - about 12 
years here. You'll need kernel ax25 stuff but that's no drama.

Ray vk2tv


On 23/11/10 16:26, John Goerzen wrote:
> Hi folks,
>
> I'm trying to find a way to do 300 baud packet on Linux for HF.
>
> The obvious answer is soundmodem, but it doesn't seem to work.  I set 
> it up, but on TX all I get is a solid tone.  Weird.  Has anyone else 
> made this work, and if so, could you send me your config?  I've 
> Googled and have found debate over whether or not this should work, 
> but nothing in the way of actual help.
>
> On the Windows side, at least MixW does it.  I'm wondering if there 
> may be other options for Linux that I don't know of?
>
> -- John
> KR0L
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

RE: 300bps Packet

[Tsutsumi Family]

John,

My experience is the same and it can transmit two tones at 400 bps lowest.

I wish to analyze the source codes but have not yet done due to my software
capability limitation.

Take JA5AEA

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Ray Wells
Sent: Tuesday, November 23, 2010 3:17 PM
To: John Goerzen
Cc: linux-hams@vger.kernel.org
Subject: Re: 300bps Packet

John,

 From what I've read, Soundmodem does not do 0k3.

 From my perspective, the obvious answer is a TNC2 compatible TNC fitted 
with a KISS only EPROM. Super reliable and works for years - about 12 
years here. You'll need kernel ax25 stuff but that's no drama.

Ray vk2tv


On 23/11/10 16:26, John Goerzen wrote:
> Hi folks,
>
> I'm trying to find a way to do 300 baud packet on Linux for HF.
>
> The obvious answer is soundmodem, but it doesn't seem to work.  I set 
> it up, but on TX all I get is a solid tone.  Weird.  Has anyone else 
> made this work, and if so, could you send me your config?  I've 
> Googled and have found debate over whether or not this should work, 
> but nothing in the way of actual help.
>
> On the Windows side, at least MixW does it.  I'm wondering if there 
> may be other options for Linux that I don't know of?
>
> -- John
> KR0L
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet

[Dave Platt]

Tsutsumi Family wrote:
> John,
> 
> My experience is the same and it can transmit two tones at 400 bps lowest.
> 
> I wish to analyze the source codes but have not yet done due to my software
> capability limitation.

It looks to me as if the immediate cause of this may lie in the
following code in afsk/modem.c:

        if (params[0]) {
                s->bps = strtoul(params[0], NULL, 0);
                if (s->bps < 100)
                        s->bps = 100;
                if (s->bps > 9600)
                        s->bps= 9600;
        } else
                s->bps = 1200;
        if (params[1]) {
                s->f0 = strtoul(params[1], NULL, 0);
                if (s->f0 > s->bps * 4)
                        s->f0 = s->bps * 4;
        } else
                s->f0 = 1200;
        if (params[2]) {
                s->f1 = strtoul(params[2], NULL, 0);
                if (s->f1 > s->bps * 4)
                        s->f1 = s->bps * 4;
        } else
                s->f1 = 2200;
        s->notdiff = params[3] ? !strtoul(params[3], NULL, 0) : 0;
        *samplerate = 8 * s->bps;

The modem-configuration code appears to be insisting that the
frequencies being used, must be no less than four times the
bit-rate.  The audio sample-generation rate is then set to
8x the bit-rate.

I *think* this is being done, in order to limit the number
of times that the loop down in "modsendbits" must iterate
for each individual bit-symbol being transmitted... looks
like no more than two audio output samples are being
generated per bit.

As a result of this approach, if you try to set the bit
rate to below 575 bits/second, the upper frequency (f1)
can no longer be sustained at 2200 Hz... the software starts
to decrease it.  At 300 bits/second, it ends up being
reduced all the way down to 1200 Hz (4 * 300) and you end
up transmitting a monotone.

For the transmit side of things, you could probably fix
this by changing the logic in this section.  If one were
to disable the logic which selectively reduces s->f0 and
s->f1, one would need to change the final calculation
of *samplerate, and increase the sample rate actually
being used.

It looks to me as if a similar - and probably much hairier -
set of changes would be needed to the demodulator code
further down in this file.  The demodulator is setting
up and using a set of digital filters, through which the
incoming samples are being fed.  You'd need to make changes
to run the receiver/demodulator at a higher sampling rate,
with longer filters, and more samples being captured prior
to being fed into the demodulator filter chain.

So, making this sort of change would be a job for someone
willing to dig through the DSP logic in the modulator and
demodulator, and generalize it a bit (and quite possibly
reduce its performance in the interest of generality).

RE: 300bps Packet

[Tsutsumi Family]

Dave,

Thank you for providing the tutorial of SM source codes.

As one of ways to solve 300bps SSB operation without any code change, you
are suggesting to use the frequency setting of f0 and f1 to less than 4 x
300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
2,300Hz.

Correct?

Regards,

take

de JA5AEA

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Dave Platt
Sent: Wednesday, November 24, 2010 4:33 AM
To: linux-hams@vger.kernel.org
Subject: Re: 300bps Packet

Tsutsumi Family wrote:
> John,
> 
> My experience is the same and it can transmit two tones at 400 bps lowest.
> 
> I wish to analyze the source codes but have not yet done due to my
software
> capability limitation.

It looks to me as if the immediate cause of this may lie in the
following code in afsk/modem.c:

        if (params[0]) {
                s->bps = strtoul(params[0], NULL, 0);
                if (s->bps < 100)
                        s->bps = 100;
                if (s->bps > 9600)
                        s->bps= 9600;
        } else
                s->bps = 1200;
        if (params[1]) {
                s->f0 = strtoul(params[1], NULL, 0);
                if (s->f0 > s->bps * 4)
                        s->f0 = s->bps * 4;
        } else
                s->f0 = 1200;
        if (params[2]) {
                s->f1 = strtoul(params[2], NULL, 0);
                if (s->f1 > s->bps * 4)
                        s->f1 = s->bps * 4;
        } else
                s->f1 = 2200;
        s->notdiff = params[3] ? !strtoul(params[3], NULL, 0) : 0;
        *samplerate = 8 * s->bps;

The modem-configuration code appears to be insisting that the
frequencies being used, must be no less than four times the
bit-rate.  The audio sample-generation rate is then set to
8x the bit-rate.

I *think* this is being done, in order to limit the number
of times that the loop down in "modsendbits" must iterate
for each individual bit-symbol being transmitted... looks
like no more than two audio output samples are being
generated per bit.

As a result of this approach, if you try to set the bit
rate to below 575 bits/second, the upper frequency (f1)
can no longer be sustained at 2200 Hz... the software starts
to decrease it.  At 300 bits/second, it ends up being
reduced all the way down to 1200 Hz (4 * 300) and you end
up transmitting a monotone.

For the transmit side of things, you could probably fix
this by changing the logic in this section.  If one were
to disable the logic which selectively reduces s->f0 and
s->f1, one would need to change the final calculation
of *samplerate, and increase the sample rate actually
being used.

It looks to me as if a similar - and probably much hairier -
set of changes would be needed to the demodulator code
further down in this file.  The demodulator is setting
up and using a set of digital filters, through which the
incoming samples are being fed.  You'd need to make changes
to run the receiver/demodulator at a higher sampling rate,
with longer filters, and more samples being captured prior
to being fed into the demodulator filter chain.

So, making this sort of change would be a job for someone
willing to dig through the DSP logic in the modulator and
demodulator, and generalize it a bit (and quite possibly
reduce its performance in the interest of generality).

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet

[Andrew Errington]

On Wed, 24 Nov 2010 19:31:25 you wrote:
> Dave,
>
> Thank you for providing the tutorial of SM source codes.
>
> As one of ways to solve 300bps SSB operation without any code change, you
> are suggesting to use the frequency setting of f0 and f1 to less than 4 x
> 300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
> 2,300Hz.
>
> Correct?
>
> Regards,
>
> take

Hi,

There are no 'conventional' tones for HF modems.  Here's a site that gives a 
good explanation why:
http://wa8lmf.net/aprs/SSB_Frequencies.htm

Here are two websites listing commonly found tone frequencies:
http://vk3.aprs.net.au/aprs_on_hf.htm
http://www.aprs.net.au/hf/hf-modem-tones

HTH,

73,

Andrew
HL5/ZL3AME

RE: 300bps Packet

[Tsutsumi Family]

Andrew,

Yes, I wished to say, after reading Dave's explanation, that SSB mode
dominated on HF does not matter the frequency values of two tones as long as
the gap is maintained, i.e. 200Hz gap for 300bps operation and now I am
guessing the soundmodem users who knew this were successful for the
operation. 

My word "conventional" means for the hardware TNCs from historical
viewpoints.

Regards,

take

de JA5AEA

-----Original Message-----
From: Andrew Errington [mailto:a.errington@lancaster.ac.uk] 
Sent: Wednesday, November 24, 2010 8:22 PM
To: Tsutsumi Family
Cc: 'Dave Platt'; linux-hams@vger.kernel.org
Subject: Re: 300bps Packet

On Wed, 24 Nov 2010 19:31:25 you wrote:
> Dave,
>
> Thank you for providing the tutorial of SM source codes.
>
> As one of ways to solve 300bps SSB operation without any code change, you
> are suggesting to use the frequency setting of f0 and f1 to less than 4 x
> 300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
> 2,300Hz.
>
> Correct?
>
> Regards,
>
> take

Hi,

There are no 'conventional' tones for HF modems.  Here's a site that gives a

good explanation why:
http://wa8lmf.net/aprs/SSB_Frequencies.htm

Here are two websites listing commonly found tone frequencies:
http://vk3.aprs.net.au/aprs_on_hf.htm
http://www.aprs.net.au/hf/hf-modem-tones

HTH,

73,

Andrew
HL5/ZL3AME

Re: 300bps Packet

[Dave Platt]

Tsutsumi Family wrote:
> Dave,
> 
> Thank you for providing the tutorial of SM source codes.
> 
> As one of ways to solve 300bps SSB operation without any code change, you
> are suggesting to use the frequency setting of f0 and f1 to less than 4 x
> 300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
> 2,300Hz.
> 
> Correct?

Correct - I think this ought to work.  As long as you don't pick
frequencies so low that your audio connection (PC to rig) is
rolling off the amplitude (due to e.g. transformer isolation
in the audio path) this approach should let you generate a pair
of tones with a suitable separation.

You'll just need to tune your sideband rig a bit differently than
if you were using a traditional "hard" TNC with its receive filters
tuned for a 2200 Hz channel center.  Just tune to match up the
tone you hear during reception, with the tone that your PC generates
during transmission... it'll be an octave or so lower than the usual
pitch but it should work.

RE: 300bps Packet

[Tsutsumi Family]

Dave,

Thank you for your quick reply.

Along with Phill's configuration parameters i.e. f0=900Hz and f1=1,100Hz in
the separate correspondence, the conclusion seems to be that f0 and f1 must
be any arbitrary numbers below 1,200Hz and above the low cut frequency of
his/her TX/RX audio path with 200Hz gap.

As the above conclusion is unique nature of the soundmodem, the fact should
be widespread to the new 300bps AFSK SSB users of the soundmodem and I hope
Andrew's pointed sites will kindly cover this.

Regards,

take

de JA5AEA
-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Dave Platt
Sent: Thursday, November 25, 2010 3:37 AM
To: linux-hams@vger.kernel.org
Subject: Re: 300bps Packet

Tsutsumi Family wrote:
> Dave,
> 
> Thank you for providing the tutorial of SM source codes.
> 
> As one of ways to solve 300bps SSB operation without any code change, you
> are suggesting to use the frequency setting of f0 and f1 to less than 4 x
> 300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
> 2,300Hz.
> 
> Correct?

Correct - I think this ought to work.  As long as you don't pick
frequencies so low that your audio connection (PC to rig) is
rolling off the amplitude (due to e.g. transformer isolation
in the audio path) this approach should let you generate a pair
of tones with a suitable separation.

You'll just need to tune your sideband rig a bit differently than
if you were using a traditional "hard" TNC with its receive filters
tuned for a 2200 Hz channel center.  Just tune to match up the
tone you hear during reception, with the tone that your PC generates
during transmission... it'll be an octave or so lower than the usual
pitch but it should work.



--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 300bps Packet (and EHAS)

[Tsutsumi Family]

Resent with text mode.
________________________________________
From: Tsutsumi Family [mailto:oakie@kamakuranet.ne.jp] 
Sent: Friday, November 26, 2010 10:39 AM
To: 'David Ranch'; 'linux-hams@vger.kernel.org'
Cc: 'Dave Platt'
Subject: RE: 300bps Packet

David,

900/1100 offset seems to a typical practice for the soundmodem 300bps
operation.

I share your concern concerning it would not be the practical capability to
be used at HF.

By the way, does anybody know the implementation status in the radio amateur
world about EHAS (Hispano-American Health Link) protocol which is originally
based on radio amateur Linux AX.25 and the soundmodem of both FSK and
newQPSK modes but adds the several performance improvement techniques like
FEC, Turbocodes, ARQ e.t.c.? 

The several literatures can be googled by “EHAS”.

Regards,

take

De JA5AEA

________________________________________
From: David Ranch [mailto:linux-hams@trinnet.net] 
Sent: Friday, November 26, 2010 4:06 AM
To: Tsutsumi Family; linux-hams@vger.kernel.org
Cc: 'Dave Platt'
Subject: Re: 300bps Packet


I've used the same 900/1100 offset setting for 300baud HF packet with
Soundmodem and things worked OK I suppose.  I ultimately came to the
conclusion (as did others in my research) that without a beam and high
power, HF packet doesn't work very well.  I would get four times more
retries than actual good packet exchanges from Santa Clara, CA to say 
Denver, CO. (Google 'Network 105').  For this exact reason, I've been
tracking the Winmor efforts and it's upcoming kb-to-kb mode.  I hope one day
we'll see it on Linux where we can get a packet-like mode with real FEC for
an inexpensive price.  I now can now truly appreciate Pactor2/3 but the
beyond acceptable high costs of the single vendor TNC and the proprietary
nature of the mode are show stoppers for me.

Anyway, I have my Soundmodem HF and VHF settings here:

   http://www.trinityos.com/HAM/CentosDigitalModes/etc/ax25/


If anyone would like to put together a sched. (might be fun to try), email
me. 

--David


Tsutsumi Family wrote: 
Dave,

Thank you for your quick reply.

Along with Phill's configuration parameters i.e. f0=900Hz and f1=1,100Hz in
the separate correspondence, the conclusion seems to be that f0 and f1 must
be any arbitrary numbers below 1,200Hz and above the low cut frequency of
his/her TX/RX audio path with 200Hz gap.

As the above conclusion is unique nature of the soundmodem, the fact should
be widespread to the new 300bps AFSK SSB users of the soundmodem and I hope
Andrew's pointed sites will kindly cover this.

Regards,

take

de JA5AEA
-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Dave Platt
Sent: Thursday, November 25, 2010 3:37 AM
To: linux-hams@vger.kernel.org
Subject: Re: 300bps Packet

Tsutsumi Family wrote:
  
Dave,

Thank you for providing the tutorial of SM source codes.

As one of ways to solve 300bps SSB operation without any code change, you
are suggesting to use the frequency setting of f0 and f1 to less than 4 x
300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
2,300Hz.

Correct?
    

Correct - I think this ought to work.  As long as you don't pick
frequencies so low that your audio connection (PC to rig) is
rolling off the amplitude (due to e.g. transformer isolation
in the audio path) this approach should let you generate a pair
of tones with a suitable separation.

You'll just need to tune your sideband rig a bit differently than
if you were using a traditional "hard" TNC with its receive filters
tuned for a 2200 Hz channel center.  Just tune to match up the
tone you hear during reception, with the tone that your PC generates
during transmission... it'll be an octave or so lower than the usual
pitch but it should work.



--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[David Ranch]

Hello Take,

It's interesting you bring up the newQPSK setting. I've never found any 
comprehensive documentation on soundmodem and what some of these other 
modes are. Do you know? Anybody else on the list know or could comment?

fsk - I know what FSK is but what does it mean in respect to soundmodem? 
My Yaesu FT-950 supports an FSK input and my US Interfaces Navigator 
device does FSK too but how would soundmodem use it? Seems it's slowest 
speed is 4800Bits/sec.

pam - what is pam?

psk - I know what PSK is and I use the BPSK31 mode in Fldigi but what 
would soundmodem do with it in respect to a packet mode?

newqpsk - I know what QPSK is and I've used the QPSK31 mode in Fldigi 
(has forms of FEC enabled on it) but what would soundmodem do with it in 
respect to a packet mode? Seems it's slowest speed is 1000Bits/sec.


I would love to learn what these modes do, are they stable, and maybe 
these modes could be used as a strong alternative to trying/failing 
300BAUD HF packet.

--David

> 900/1100 offset seems to a typical practice for the soundmodem 300bps
> operation.
>
> I share your concern concerning it would not be the practical capability to
> be used at HF.
>
> By the way, does anybody know the implementation status in the radio amateur
> world about EHAS (Hispano-American Health Link) protocol which is originally
> based on radio amateur Linux AX.25 and the soundmodem of both FSK and
> newQPSK modes but adds the several performance improvement techniques like
> FEC, Turbocodes, ARQ e.t.c.? 
>
> The several literatures can be googled by “EHAS”.
>
> Regards,
>
> take
>
> De JA5AEA
>
> ________________________________________
> From: David Ranch [mailto:linux-hams@trinnet.net] 
> Sent: Friday, November 26, 2010 4:06 AM
> To: Tsutsumi Family; linux-hams@vger.kernel.org
> Cc: 'Dave Platt'
> Subject: Re: 300bps Packet
>
>
> I've used the same 900/1100 offset setting for 300baud HF packet with
> Soundmodem and things worked OK I suppose.  I ultimately came to the
> conclusion (as did others in my research) that without a beam and high
> power, HF packet doesn't work very well.  I would get four times more
> retries than actual good packet exchanges from Santa Clara, CA to say 
> Denver, CO. (Google 'Network 105').  For this exact reason, I've been
> tracking the Winmor efforts and it's upcoming kb-to-kb mode.  I hope one day
> we'll see it on Linux where we can get a packet-like mode with real FEC for
> an inexpensive price.  I now can now truly appreciate Pactor2/3 but the
> beyond acceptable high costs of the single vendor TNC and the proprietary
> nature of the mode are show stoppers for me.
>
> Anyway, I have my Soundmodem HF and VHF settings here:
>
>    http://www.trinityos.com/HAM/CentosDigitalModes/etc/ax25/
>
>
> If anyone would like to put together a sched. (might be fun to try), email
> me. 
>
> --David
>
>
> Tsutsumi Family wrote: 
> Dave,
>
> Thank you for your quick reply.
>
> Along with Phill's configuration parameters i.e. f0=900Hz and f1=1,100Hz in
> the separate correspondence, the conclusion seems to be that f0 and f1 must
> be any arbitrary numbers below 1,200Hz and above the low cut frequency of
> his/her TX/RX audio path with 200Hz gap.
>
> As the above conclusion is unique nature of the soundmodem, the fact should
> be widespread to the new 300bps AFSK SSB users of the soundmodem and I hope
> Andrew's pointed sites will kindly cover this.
>
> Regards,
>
> take
>
> de JA5AEA
> -----Original Message-----
> From: linux-hams-owner@vger.kernel.org
> [mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Dave Platt
> Sent: Thursday, November 25, 2010 3:37 AM
> To: linux-hams@vger.kernel.org
> Subject: Re: 300bps Packet
>
> Tsutsumi Family wrote:
>   
> Dave,
>
> Thank you for providing the tutorial of SM source codes.
>
> As one of ways to solve 300bps SSB operation without any code change, you
> are suggesting to use the frequency setting of f0 and f1 to less than 4 x
> 300bps =1,200 Hz such as 800Hz and 1,000Hz, not conventional 2,100Hz and
> 2,300Hz.
>
> Correct?
>     
>
> Correct - I think this ought to work.  As long as you don't pick
> frequencies so low that your audio connection (PC to rig) is
> rolling off the amplitude (due to e.g. transformer isolation
> in the audio path) this approach should let you generate a pair
> of tones with a suitable separation.
>
> You'll just need to tune your sideband rig a bit differently than
> if you were using a traditional "hard" TNC with its receive filters
> tuned for a 2200 Hz channel center.  Just tune to match up the
> tone you hear during reception, with the tone that your PC generates
> during transmission... it'll be an octave or so lower than the usual
> pitch but it should work.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[Dave Platt]

> fsk - I know what FSK is but what does it mean in respect to soundmodem?
> My Yaesu FT-950 supports an FSK input and my US Interfaces Navigator
> device does FSK too but how would soundmodem use it? Seems it's slowest
> speed is 4800Bits/sec.

FSK is the common way of doing AX.25 packet operations at 9600
baud.  In this mode, the voltage coming out of the sound card's
line output is fed fairly directly to the modulator in the radio...
a positive voltage shifts the RF frequency in one direction, a
negative voltage shifts it in the other.  This mode of hookup and
operation requires a radio-to-rig connection with very good
low-frequency response (down to DC or close to it is ideal),
and very careful adjustment of the sound-card volume control
in order to adjust the maximum signal level (and thus the
peak FM deviation) fairly precisely.

If I understand correctly, the soundmodem FSK mode (when properly
adjusted) should be compatible with the G3RUH 9600-baud
modem designs.

> pam - what is pam?

Sounds to me like Phase and Amplitude Modulation, in which
the bits being transmit control both the amplitude and the
relative phase of the carrier signal.  QAM (quadrature
amplitude modulation) is a common form of this... a signal
might transmit three or four bits for each symbol, with
two bits controlling the relative amount of phase shift
from the previous symbol, and another one or two bits
controlling the amplitude.

I don't know the details of the soundmodem's PAM.  From
what I see in the code, it appears to be doing some
filtering or convolution in the process of converting
the bits to the symbols being transmitted, and some
maximal-likelihood decoding upon reception.

I assume that one would use it as the other modes would
be used... set up two soundmodems with compatible
configurations and start transmitting, and then see how
well it works.

> psk - I know what PSK is and I use the BPSK31 mode in Fldigi but what
> would soundmodem do with it in respect to a packet mode?

See above...

> 
> newqpsk - I know what QPSK is and I've used the QPSK31 mode in Fldigi
> (has forms of FEC enabled on it) but what would soundmodem do with it in
> respect to a packet mode? Seems it's slowest speed is 1000Bits/sec.

This one looks rather interesting, in that it seems to incorporate
symbol interleaving and forward error correction.  This might
make it more robust in the face of some sorts of errors.

> I would love to learn what these modes do, are they stable, and maybe
> these modes could be used as a strong alternative to trying/failing
> 300BAUD HF packet.

There's a bit of a gotcha in the regs (in the U.S. at least) in that
most HF bands limit data transmissions to baud rates of no
more than 300 (or an FSK frequency shift of no more than 1 kHz).
Using a 1000 or 1200 baud QPSK would not be permissible on
frequencies below 10 meters, I think.

An alternative might be to use a multi-carrier HF digital
mode - one which sends a bunch of different carriers,
each modulated at a relatively low rate.  Some of the
keyboard-to-keyboard HF digital modes work this way...
but I'm not aware of anyone having used those modulations
as ways of wrapping an AX.25 or IP packet for HF digital
use.

Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[Tomi Manninen]

David Ranch wrote:

> That's a great explanation of FSK though I don't understand why radios 
> like my FT-950 have separate AFSK and FSK inputs.  I would have assumed 
> they would have a common input and you select the mode of that input 
> (AFSK or FSK).  Of course, this assumes that I make the proper 
> adjustments to my sound card for the deviation, etc.

The "AFSK" input in your radio is more or less just another microphone 
input and the output just another speaker output. You connect those
to the computer soundcard. During transmit, the radio modulates
the audio signals using whatever modulation is active. FM or USB/LSB.
And of course the other way around on receive.

The "FSK" input in your radio is a digital input. I took a look at the
FT-950 manual and it says that grounding the input results in the
radio sending a carrier on one frequency and not grounding sends
a carrier on another frequency.

> The two FSK modes I've commonly heard about (being a new HAM) is packet 
> (I've always done AFSK even at 9600) and RTTY.

You have used the "AFSK" input to do something that the Yeasu
manual describes as "AFSK based data modes". The manual seems to
happily use terms that are at the very least confusing, even
downright wrong if you ask me...

"“Packet” operation also applies to SSB-based AFSK data modes, such as 
PSK31, etc." -- yeah, right.. :)

>  I can see how FSK can 
> result in a better transmitted signal as it's really up to the radio to 
> do the transmission and the computer is only telling what it should 
> eventually send.  

Yes. But you can really only use the "FSK" mode for RTTY. The "FSK"
input doesn't enable the computer to do any kind or pulse shaping
and that is only usable on RTTY.

> With that said, it seems like AFSK with a properly 
> tuned sound system (flat frequency response, etc.) should be able to do 
> everything that FSK could do.  Is that an incorrect assumption?

Now as we are actually talking generating RF signals with an
SSB modulator, then you're right. In the ideal world
generating a modulated waveform on audio and feeding it to an
SSB modulator results in a perfect copy of the modulation
mapped on RF. In the real world things aren't quite that
rosy, there are imperfections. But when done with care,
it works good enough.

>  >The modem is actually a binary PAM modem (Pulse Amplitude Modulation),
>  >ie. it outputs the data as voltage pulses. When these are fed to an FM
>  >modulator, the resulting signal on RF is FSK modulated. Hence the name.
>  >
>  >Of course there are other features that make this modem G3RUH - like
>  >the way the data is scrambled before modulation etc.
> 
> Interesting.. *pulse amplitude*?

Yes. Between the computer and your radio, information is
in this case conveyed in the amplitudes of voltage
pulses. Binary means there are two distinct voltage levels
used, let's say -1V and +1V, and they represent a single bit
of information (0 or 1). In a general case a PAM modulation
may have more levels and one PAM symbol may transmit more
than one bit of information. This kind of modulation
is often used in baseband transmission, for example in
ethernet over twisted pair cables.

It is also important to realize that for example in the
G3UH case, the pulses are not rectangular, they are shaped.
This greatly affects the used bandwidth.

>  I think most HAMs are in agreement 
> that HF packet doesn't work well for various reasons.  Since you 
> mentioned "FM", I assume this mode is not suitable for use with SSB on 
> the HF bands?   Any thoughts on its width of spectrum it uses, etc?

Like I said, feeding PAM to an FM modulator results in (shaped)
FSK signals over the air and that is the ultimate goal in a
system like "G3RUH packet".

Feeding this kind of PAM to an SSB modulator would result in
a completely different kind of modulation over the air. Of the
top of my head, I can't say what it would actually be but
most probably nothing useful. I'm quite sure it wouldn't
work at all as like Dave Platt said, this needs a very
low frequency response and the typical ham SSB modulator
cuts at around 300Hz in the low end.

> 1) You mentioned a "DSP56002EVM"... is that a specific DSP chip and this 
> mode was then ported into Soundmodem running on X86? 

Yes, the Motorola 56002 was a member of an old DSP chip family
and the DSP56002EVM was an evaluation kit with the dsp chip,
memories, codecs etc.

Pawel wrote the original modem in assembler for the 56002
and I ported it to C to be run on Linux.

> 2) 2500 or 3000?  For an HF mode, that sounds FAST.  which leads me to 
> my next point..

Yes, it is fairly fast. With FEC the payload data rate drops though.
The best FEC (which I recommend) is 1/3 and then the actual payload
data rate is 833 or 1000 bps.

> 3) This mode is interesting to me and I think I once saw it on the air.  
> If there are 15 carriers, how wide is each carrier, and what is the 
> spacing between them?  What's the total consumed spectrum at say 2500?   
> It seems that 300BAUD AFSK packet is a bit less than 400Hz.

Carrier spacing is 125Hz at 2500 and thus occupied bandwidth
is about 15 * 125 Hz, ie. little less than 2 kHz.

> 4)You mentioned that you received complaints that this mode didn't 
> work.  Were those complains on your soundmodem implimentation or on the 
> MixW version?  Being a Linux only user, I don't care about MixW.  ;-)  

I think it was mostly from users with MixW. But MixW uses exactly
the same source code and it worked for me quite well (at that time
I had a work laptop that was restricted to M$ only).

> 5) Assuming that my assumption from point #2 above is true and the 
> Soundmodem implementation works well with  other speeds, if I was to 
> tune this down to say 900 BAUD to improve the reliability on HF, any 
> guesses to what it would do to the number of carriers, their spacing, 
> etc?  

The carrier frequencies, their spacing, the occupied bandwidth, the 
symbol rate all scale 1:1 with the "bps" setting.

But like I said, don't do that. I really regret that I made
the soundmodem implementation so flexible.

Besides, you are now confusing Baud (ie. symbols per second) with
bits per second. They are not the same. At 2500 bps the newqpsk
modem runs at 83.333 Baud (symbols per second).

>  >--> Dave Platt
>> An alternative might be to use a multi-carrier HF digital
>> mode - one which sends a bunch of different carriers,
>> each modulated at a relatively low rate.  Some of the
>> keyboard-to-keyboard HF digital modes work this way...
>> but I'm not aware of anyone having used those modulations
>> as ways of wrapping an AX.25 or IP packet for HF digital
>> use.
>>   
> Correct me if I'm wrong but it sounds like Tomi's  newqpsk mode does 
> exactly that and should be legal in the US.

I don't remember if there was an agreement over the legality in the US
and obviously that is not very interesting to me :)

However as to IP over AX.25 over newqpsk on HF. Been there, done that,
it was fun. :)

/Tomi

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[David Ranch]

Hello Tomi,

> You have used the "AFSK" input to do something that the Yeasu
> manual describes as "AFSK based data modes". The manual seems to
> happily use terms that are at the very least confusing, even
> downright wrong if you ask me...
Oh yes, and a lot of documentation out there online and in the books has 
lots of conflicting information. 

> "“Packet” operation also applies to SSB-based AFSK data modes, such as 
> PSK31, etc." -- yeah, right.. :)
Well, on the FT-950, the dedicated button for RTTY is enables the FSK 
inputs and also activates some specific narrow filters and processing.  
The PACKET button activates the AFSK inputs but also enables different 
specific filters and processing.  I do realize that Packet can be FSK 
but it's not on this radio.

> It is also important to realize that for example in the
> G3UH case, the pulses are not rectangular, they are shaped.
> This greatly affects the used bandwidth.
You've mentioned a few times of how the G3UH does unique things such as 
scrambling and now waveform shaping.  I'm going to have to look around 
to see if I can find some documentation on all this that doesn't quickly 
go into hardcore math.  I've always loved the concept of signal 
processing but I don't know if my brain can handle it.


>
>>  I think most HAMs are in agreement that HF packet doesn't work well 
>> for various reasons.  Since you mentioned "FM", I assume this mode is 
>> not suitable for use with SSB on the HF bands?   Any thoughts on its 
>> width of spectrum it uses, etc?
>
> Like I said, feeding PAM to an FM modulator results in (shaped)
> FSK signals over the air and that is the ultimate goal in a
> system like "G3RUH packet".
>
> Feeding this kind of PAM to an SSB modulator would result in
> a completely different kind of modulation over the air. Of the
> top of my head, I can't say what it would actually be but
> most probably nothing useful. I'm quite sure it wouldn't
> work at all as like Dave Platt said, this needs a very
> low frequency response and the typical ham SSB modulator
> cuts at around 300Hz in the low end.

Ahhh... understood and from this thread, I never realized that a 
souncard mode needs to be specifically designed for say SSB vs. FM.  I 
naively thought that the modulation would only impact the noise 
immunity, spectrum used (and the resulting power) use, etc.  The concept 
that an digital waveform from a soundcard sent into a SSB vs FM 
modulator and the results being very different is a foreign concept to 
me.  I'm going to have to read up on this... interesting!

>
>> 1) You mentioned a "DSP56002EVM"... is that a specific DSP chip and 
>> this mode was then ported into Soundmodem running on X86? 
>
> Yes, the Motorola 56002 was a member of an old DSP chip family
> and the DSP56002EVM was an evaluation kit with the dsp chip,
> memories, codecs etc.
>
> Pawel wrote the original modem in assembler for the 56002
> and I ported it to C to be run on Linux.

You know, I was optimizing my Linux packet system startup scripts 
yesterday ( 
http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh 
) and when playing around with the Linux AX.25 "kissparms" program, I 
noticed that the man page states:
--
       -e FEC error correction level
                   Sets the FEC error correction level in a DSP card 
based modem  (KISS  parameter  8).  Larger
                   correction  level means better noise resistance, but 
slower throughput on a good connection.
                   This is an experimental feature found in a QPSK modem 
for the Motorola DSP56001  based  DSP4
                   and EVM cards only.
--

Maybe this support is derived from some of the work you and Pawel did?



>
>> 3) This mode is interesting to me and I think I once saw it on the 
>> air.  If there are 15 carriers, how wide is each carrier, and what is 
>> the spacing between them?  What's the total consumed spectrum at say 
>> 2500?   It seems that 300BAUD AFSK packet is a bit less than 400Hz.
>
> Carrier spacing is 125Hz at 2500 and thus occupied bandwidth
> is about 15 * 125 Hz, ie. little less than 2 kHz.
Right.. and what I expected you to say.  That's a chunk of bandwidth and 
I was hoping that if I was to lower the speed, maybe I could lower the 
BW but it doesn't sound like the mode supports that approach.  Again, my 
goal would be to use a FEC-enabled mode for AX.25 that would give an 
effective 300BAUD throughput.  Even if I was to dig through your code, 
hacked out a few carriers,  I highly doubt the mode would find any real 
traction.  It seems most hams have a general disdain for packet though I 
think it's fantastic (though slow).


> The carrier frequencies, their spacing, the occupied bandwidth, the 
> symbol rate all scale 1:1 with the "bps" setting.
>
> But like I said, don't do that. I really regret that I made
> the soundmodem implementation so flexible.
QSL and when I try this out (if I can find any other HAMs to maybe test 
this with), I'll keep this in mind.


> Besides, you are now confusing Baud (ie. symbols per second) with
> bits per second. They are not the same. At 2500 bps the newqpsk
> modem runs at 83.333 Baud (symbols per second).
Right, and I know better.  Sorry.



> However as to IP over AX.25 over newqpsk on HF. Been there, done that,
> it was fun. :)
So, if that was been there, done that.  What's fun for you now?   Maybe 
data and CODEC2 over GMSK?  Maybe WinMor?


--David
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[Ray Wells]

Dave,

You might look for two articles by James Miller, G3RUH, '9600 Baud 
Packet Radio Modem Design' and 'The Shape Of Bits To Come', which 
describes various modulation methods and their bandwidth.

I have the article in an ARRL publication called 'Packet: Speed, More 
Speed & Applications'. However, both articles reference ftp.amsat.org 
where they can be found at  /amsat/articles/g3ruh/a109.zip and  
/amsat/articles/g3ruh/a108.zip respectively.

Ray vk2tv

On 28/11/10 04:30, David Ranch wrote:
>
> Hello Tomi,
>
>> You have used the "AFSK" input to do something that the Yeasu
>> manual describes as "AFSK based data modes". The manual seems to
>> happily use terms that are at the very least confusing, even
>> downright wrong if you ask me...
> Oh yes, and a lot of documentation out there online and in the books 
> has lots of conflicting information.
>> "“Packet” operation also applies to SSB-based AFSK data modes, such 
>> as PSK31, etc." -- yeah, right.. :)
> Well, on the FT-950, the dedicated button for RTTY is enables the FSK 
> inputs and also activates some specific narrow filters and 
> processing.  The PACKET button activates the AFSK inputs but also 
> enables different specific filters and processing.  I do realize that 
> Packet can be FSK but it's not on this radio.
>
>> It is also important to realize that for example in the
>> G3UH case, the pulses are not rectangular, they are shaped.
>> This greatly affects the used bandwidth.
> You've mentioned a few times of how the G3UH does unique things such 
> as scrambling and now waveform shaping.  I'm going to have to look 
> around to see if I can find some documentation on all this that 
> doesn't quickly go into hardcore math.  I've always loved the concept 
> of signal processing but I don't know if my brain can handle it.
>
>
>>
>>>  I think most HAMs are in agreement that HF packet doesn't work well 
>>> for various reasons.  Since you mentioned "FM", I assume this mode 
>>> is not suitable for use with SSB on the HF bands?   Any thoughts on 
>>> its width of spectrum it uses, etc?
>>
>> Like I said, feeding PAM to an FM modulator results in (shaped)
>> FSK signals over the air and that is the ultimate goal in a
>> system like "G3RUH packet".
>>
>> Feeding this kind of PAM to an SSB modulator would result in
>> a completely different kind of modulation over the air. Of the
>> top of my head, I can't say what it would actually be but
>> most probably nothing useful. I'm quite sure it wouldn't
>> work at all as like Dave Platt said, this needs a very
>> low frequency response and the typical ham SSB modulator
>> cuts at around 300Hz in the low end.
>
> Ahhh... understood and from this thread, I never realized that a 
> souncard mode needs to be specifically designed for say SSB vs. FM.  I 
> naively thought that the modulation would only impact the noise 
> immunity, spectrum used (and the resulting power) use, etc.  The 
> concept that an digital waveform from a soundcard sent into a SSB vs 
> FM modulator and the results being very different is a foreign concept 
> to me.  I'm going to have to read up on this... interesting!
>
>>
>>> 1) You mentioned a "DSP56002EVM"... is that a specific DSP chip and 
>>> this mode was then ported into Soundmodem running on X86? 
>>
>> Yes, the Motorola 56002 was a member of an old DSP chip family
>> and the DSP56002EVM was an evaluation kit with the dsp chip,
>> memories, codecs etc.
>>
>> Pawel wrote the original modem in assembler for the 56002
>> and I ported it to C to be run on Linux.
>
> You know, I was optimizing my Linux packet system startup scripts 
> yesterday ( 
> http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh 
> ) and when playing around with the Linux AX.25 "kissparms" program, I 
> noticed that the man page states:
> -- 
>       -e FEC error correction level
>                   Sets the FEC error correction level in a DSP card 
> based modem  (KISS  parameter  8).  Larger
>                   correction  level means better noise resistance, but 
> slower throughput on a good connection.
>                   This is an experimental feature found in a QPSK 
> modem for the Motorola DSP56001  based  DSP4
>                   and EVM cards only.
> -- 
>
> Maybe this support is derived from some of the work you and Pawel did?
>
>
>
>>
>>> 3) This mode is interesting to me and I think I once saw it on the 
>>> air.  If there are 15 carriers, how wide is each carrier, and what 
>>> is the spacing between them?  What's the total consumed spectrum at 
>>> say 2500?   It seems that 300BAUD AFSK packet is a bit less than 400Hz.
>>
>> Carrier spacing is 125Hz at 2500 and thus occupied bandwidth
>> is about 15 * 125 Hz, ie. little less than 2 kHz.
> Right.. and what I expected you to say.  That's a chunk of bandwidth 
> and I was hoping that if I was to lower the speed, maybe I could lower 
> the BW but it doesn't sound like the mode supports that approach.  
> Again, my goal would be to use a FEC-enabled mode for AX.25 that would 
> give an effective 300BAUD throughput.  Even if I was to dig through 
> your code, hacked out a few carriers,  I highly doubt the mode would 
> find any real traction.  It seems most hams have a general disdain for 
> packet though I think it's fantastic (though slow).
>
>
>> The carrier frequencies, their spacing, the occupied bandwidth, the 
>> symbol rate all scale 1:1 with the "bps" setting.
>>
>> But like I said, don't do that. I really regret that I made
>> the soundmodem implementation so flexible.
> QSL and when I try this out (if I can find any other HAMs to maybe 
> test this with), I'll keep this in mind.
>
>
>> Besides, you are now confusing Baud (ie. symbols per second) with
>> bits per second. They are not the same. At 2500 bps the newqpsk
>> modem runs at 83.333 Baud (symbols per second).
> Right, and I know better.  Sorry.
>
>
>
>> However as to IP over AX.25 over newqpsk on HF. Been there, done that,
>> it was fun. :)
> So, if that was been there, done that.  What's fun for you now?   
> Maybe data and CODEC2 over GMSK?  Maybe WinMor?
>
>
> --David
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 300bps Packet

[Phil]

On Tue, 23 Nov 2010 03:26:12 pm you wrote:
> Hi folks,
> 
> I'm trying to find a way to do 300 baud packet on Linux for HF.
> 

I played with HF packet bulletin boards ten years ago using soundmodem. At 
first it didn't appear to work but I discovered that with very careful tuning 
soundmodem does in fact transmit and receive at 300 baud.

More recently I have also played with HF APRS on 21MHz and again no problems, 
except for very careful tuning. So John, soundmodem does work correctly at 300 
baud.

-- 
Regards,
Phil

Re: 300bps Packet

[John Goerzen]

On 11/24/2010 12:51 AM, Phil wrote:
> On Tue, 23 Nov 2010 03:26:12 pm you wrote:
>> Hi folks,
>>
>> I'm trying to find a way to do 300 baud packet on Linux for HF.
>>
>
> I played with HF packet bulletin boards ten years ago using soundmodem. At
> first it didn't appear to work but I discovered that with very careful tuning
> soundmodem does in fact transmit and receive at 300 baud.
>
> More recently I have also played with HF APRS on 21MHz and again no problems,
> except for very careful tuning. So John, soundmodem does work correctly at 300
> baud.
>

Hi Phil,

That's good to know, but I must admit I don't know how to make it work. 
  Can you elaborate on what parameters you tuned, and how you found the 
appropriate values for them?  Maybe even a copy of your config file?

Thanks,

-- John

Re: 300bps Packet

[Phil]

On Wed, 24 Nov 2010 10:38:27 pm John Goerzen wrote:
> On 11/24/2010 12:51 AM, Phil wrote:
> > On Tue, 23 Nov 2010 03:26:12 pm you wrote:

<cut>

> Hi Phil,
> 
> That's good to know, but I must admit I don't know how to make it work.
>   Can you elaborate on what parameters you tuned, and how you found the
> appropriate values for them?  Maybe even a copy of your config file?
> 

Hello again John,

The following is from the HF section of my soundmodem config file. It's been 
awhile since I've played with 300 baud packet but I just tried the call 
function and it still generates the familiar 300 baud tones.

[phil@localhost ax25]$ more soundmodem.conf
<?xml version="1.0"?>
<modem>
  <configuration name="hf_packet">
    <channel name="Channel 0">
      <mod mode="afsk" bps="300" f0="900" f1="1100" diffenc="1"/>
      <demod mode="afsk" bps="300" f0="900" f1="1100" diffdec="1"/>
      <pkt mode="MKISS" ifname="sm0" hwaddr="VK4BVM-2" ip="10.0.0.1" 
netmask="255.255.255
.0" broadcast="10.0.0.255"/>

-- 
Regards,
Phil