300bps Packet

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

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

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: [email protected] [mailto:[email protected]] On Behalf Of Ray Wells
Sent: Tuesday, November 23, 2010 3:17 PM
To: John Goerzen
Cc: [email protected]
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

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

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).

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: [email protected] [mailto:[email protected]] On Behalf Of Dave Platt
Sent: Wednesday, November 24, 2010 4:33 AM
To: [email protected]
Subject: Re: 300bps Packet

software

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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:[email protected]]
Sent: Wednesday, November 24, 2010 8:22 PM
To: Tsutsumi Family
Cc: 'Dave Platt'; [email protected]
Subject: Re: 300bps Packet

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

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.

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: [email protected] [mailto:[email protected]] On Behalf Of Dave Platt
Sent: Thursday, November 25, 2010 3:37 AM
To: [email protected]
Subject: Re: 300bps Packet

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Resent with text mode.
________________________________________
From: Tsutsumi Family [mailto:[email protected]]
Sent: Friday, November 26, 2010 10:39 AM
To: 'David Ranch'; '[email protected]'
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:[email protected]]
Sent: Friday, November 26, 2010 4:06 AM
To: Tsutsumi Family; [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of Dave Platt
Sent: Thursday, November 25, 2010 3:37 AM
To: [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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

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.

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.

See above...

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.

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.

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.

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.. :)

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.

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.

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.

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.

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.

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.

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

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).

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).

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hello Tomi,

Oh yes, and a lot of documentation out there online and in the books has lots of conflicting information.

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.

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.

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!

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?

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).

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.

Right, and I know better. Sorry.

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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

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

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

<cut>

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