Soundmodem Not Decoding Real Packets

Soundmodem Not Decoding Real Packets

[Jonathan Lassoff]

I've been trying to get Tom Sailer's soundmodem to decode AX.25 packets. I've
been able to see the audio coming in from the radio and from other machines
transmitting packets through a cable. The only problem is that the DCD can be
too sensitive and turn on when there is nothing but just inducted noise in the
cable from somewhere. The noise in normal, and the level is very, very low. But,
the problem is that soundmodem tries its best to try and decode the noise. But
when a real packet comes down the line, it tries but fails to decode it
properly. I think that I have an issue with audio levels, but I'm open to being
wrong. Does anyone on list have any good ideas of things to try?

Jonathan Lassoff (KG6THI)

Re: Soundmodem Not Decoding Real Packets

[Jonathan Lassoff]

On 7/1/05, Luc Langehegermann <luc2@lx2gt.lu> wrote:
> Hello Jonathan,
> 
> > I've been trying to get Tom Sailer's soundmodem to decode AX.25 packets.
> > I've
> > been able to see the audio coming in from the radio and from other
> > machines
> > transmitting packets through a cable. The only problem is that the DCD can
> > be
> > too sensitive and turn on when there is nothing but just inducted noise in
> > the
> > cable from somewhere. The noise in normal, and the level is very, very
> > low. But,
> > the problem is that soundmodem tries its best to try and decode the noise.
> > But
> > when a real packet comes down the line, it tries but fails to decode it
> > properly. I think that I have an issue with audio levels, but I'm open to
> > being
> > wrong. Does anyone on list have any good ideas of things to try?
> >
> 
> I had a similar issue in the past, which can occur if you use the ALSA
> soundcard drivers. If you use ALSA for your hardware, are you sure to also
> use the new soundmodem, which supports it directly? The problem could be,
> that your sound driver does sample rate conversion, which can be the
> reason for not decoding packets.
> 
> Luc
> 
I tried the decoding with both ALSA and direct OSS, but it still
doesn't seem to work properly either way. I'm using soundmodem-0.9

Jonathan (KG6THI)

Re: Soundmodem Not Decoding Real Packets

[Dave Platt]

Jonathan Lassoff <jlassoff@gmail.com> wrote:
> I've been trying to get Tom Sailer's soundmodem to decode AX.25 packets. I've
> been able to see the audio coming in from the radio and from other machines
> transmitting packets through a cable. The only problem is that the DCD can be
> too sensitive and turn on when there is nothing but just inducted noise in the
> cable from somewhere. The noise in normal, and the level is very, very low. But,
> the problem is that soundmodem tries its best to try and decode the noise. But
> when a real packet comes down the line, it tries but fails to decode it
> properly. I think that I have an issue with audio levels, but I'm open to being
> wrong. Does anyone on list have any good ideas of things to try?

In my experience, the user-mode soundmodem code does a very fine job of
decoding AX.25 packets, and it does so even if the radio is operated
"open squelch".  In fact, in many areas it is a preferred practice for
packet nodes to be run with the receive squelch open - this allows
the TNC or other modem to synchronize very rapidly at the beginning
of each packet, without a long wait for the radio to detect carrier
energy and open its squelch.  This, then, allows the nodes in the
area to use a shorter beginning-of-packet synchronization burst, and
increase the useful data throughput of the packet channel.

The occasional flickering of the DCD indicator and/or LED ought
not to be a problem.  A similar phenomenon occurs on many
TNCs (which use hardware modem chips rather than audio DSP).
Any "packet" which is seen during this time (as a result of
the perceived detection of carrier as a result of noise)
will almost certainly be discarded by the soundmodem/TNC because
it fails any of several validity checks (e.g. contains enough
consecutive 1-bits to trigger an ABORT, fails the CRC16 frame
check sequence validation, is too short or too long, etc.).

In your situation, I'd look at several things:

-  Audio levels, as you suggest.  Take a look at the audio coming
   out of your radio when it's receiving a clean packet - use
   an oscilloscope.  Check for clipping (a "flat-top" appearance)
   in the waveform.  If you see it, turn the radio's audio-output
   control down until it goes away.

-  Once you're sure that the radio's audio output is clean and is
   not clipping or distorting, use the soundmodemconfig program's
   oscilloscope/waveform display to see how well the data is getting
   into your sound card.  Adjust the sound card audio input gain,
   and if necessary the radio's output level control, so that the
   waveform "seen" by the soundmodem is clean, not clipped, and is
   perhaps half of full-scale in amplitude.

-  Try running the radio with the squelch open.  It's possible that
   your radio takes so long to open its squelch that it's chopping
   off the beginning of each packet, and thus preventing the soundmodem
   from "seeing" the carrier in time to synchronize with the packet
   properly.

Also, check the quality of the signal from the sending station.  It's
not unusual for TNCs or soundmodems or audio interfaces or radios to
be misadjusted, causing any of several problems:

-  TNC or soundmodem audio output is clipping.  [I had horrible
   problems with a Dell Latitude laptop - if its PCM audio output
   control was set to above 25%, the audio waveform was clipped,
   independent of the setting of the master audio gain.  Didn't
   send packet worth a darned that way.]

-  Audio signal is overdriving the radio's mic input and is
   clipping or distorting.

-  Radio is being pushed into deviation limiting (typically at 5 kHz
   or so) and is distorting the audio, or is overdeviating and pushing
   the modulated signal outside the receiving radio's IF passband.

My own guess is that that Thomas Sailer's soundmodem code is not
the cause of your problem.  I've found it to be quite good indeed
at receiving packet.

The only gripe I have with the soundmodem, is that its handling
of back-to-back AX.25 frames in a single transmission does not
comply with the AX.25 protocol recommendation (specifically,
2.2.11 which states that the time between frames should be
filled with contiguous flags).  The soundmodem transmits one
complete flag, and then (most of the time) a partial flag,
and then a complete flag which begins the next frame.  This can
cause problems for TNCs whose HDLC parsing is not as robust
as should be the case.  Mr. Sailer has elected not to correct
this, feeling that it's a problem in the receiving TNCs.

Re: Soundmodem Not Decoding Real Packets

[Jonathan Lassoff]

Dave Platt <dplatt <at> radagast.org> writes:

> In my experience, the user-mode soundmodem code does a very fine job of
> decoding AX.25 packets, and it does so even if the radio is operated
> "open squelch".  In fact, in many areas it is a preferred practice for
> packet nodes to be run with the receive squelch open - this allows
> the TNC or other modem to synchronize very rapidly at the beginning
> of each packet, without a long wait for the radio to detect carrier
> energy and open its squelch.  This, then, allows the nodes in the
> area to use a shorter beginning-of-packet synchronization burst, and
> increase the useful data throughput of the packet channel.
> [...]
> In your situation, I'd look at several things:
> 
> -  Audio levels, as you suggest.  Take a look at the audio coming
>    out of your radio when it's receiving a clean packet - use
>    an oscilloscope.  Check for clipping (a "flat-top" appearance)
>    in the waveform.  If you see it, turn the radio's audio-output
>    control down until it goes away.
> [...]
> Also, check the quality of the signal from the sending station.  It's
> not unusual for TNCs or soundmodems or audio interfaces or radios to
> be misadjusted, causing any of several problems:
> [...]
> My own guess is that that Thomas Sailer's soundmodem code is not
> the cause of your problem.  I've found it to be quite good indeed
> at receiving packet.

I did find out that the audio output from my radio was a bit high.
I don't have an oscilloscope to play with, so I just used audacity to see the
audio while recording it. I trimmed it down so that everything is there. I'm
still having the same problem though. I have also been trying to decode packets
off of APRS here in California on 144.390 to no avail. I also tried the decoding
process with squelch open. I'm not really sure what is going on here. I also
tried twiddling with the audio levels on my input channel in a mixer program.
Any crafty diagnostic ideas?

Jonathan (KG6THI)

Re: Soundmodem Not Decoding Real Packets

[Dave Platt]

> I did find out that the audio output from my radio was a bit high.
> I don't have an oscilloscope to play with, so I just used audacity to see the
> audio while recording it. I trimmed it down so that everything is there. I'm
> still having the same problem though. I have also been trying to decode packets
> off of APRS here in California on 144.390 to no avail. I also tried the decoding
> process with squelch open. I'm not really sure what is going on here. I also
> tried twiddling with the audio levels on my input channel in a mixer program.
> Any crafty diagnostic ideas?

Hmmm.

Which audio drivers are you using - OSS, or ALSA?

I've seen some rather bizarre things with some combinations of card,
driver, and software setting.  In particular, problems can occur if:

[1] The card itself is only capable of supporting a small selection of
    sampling rates (many AC97 codes seem to want to run at 48000
    samples/second), and
    
[2] You set up the sound modem to use the "natural" sampling rate for
    the modulation in question (e.g. 9600 samples/second for 1200-baud
    packet), and
    
[3] The soundmodem is configured to use /dev/dsp, and

[4] You're using an ALSA driver with OSS emulation.

What seems to happen is that the OSS emulation layer quite politely
lies to the soundmodem, says "Sure, 9600 samples/second is supported",
and then tells the ALSA PCM layer to do sample-rate conversion in
software.  The ALSA rate converter has some problems, and it ends up
introducing noise into the received audio signal occasionally (usually
on internal buffer boundaries, I believe).  The noise is sufficient to
mess up the audio reception.

The solution to this involves disabling the sample rate conversion
process.  I _think_ (but am not sure) that the best way to do this is
to tell the soundmodem to use the ALSA API directly, rather than using
the OSS emulation via /dev/dsp - recent versions of the soundmodem can
do this, and are smart enough to use a sampling rate that the audio
chip supports directly with no conversion being required.

Re: Soundmodem Not Decoding Real Packets

[Jonathan Lassoff]

Dave Platt <dplatt <at> radagast.org> writes:
> Hmmm.
> 
> Which audio drivers are you using - OSS, or ALSA?

I've tried both. I'm using the i810_audio module with the AC97 codec for an
on-board sound device on a laptop.
 
> I've seen some rather bizarre things with some combinations of card,
> driver, and software setting.  In particular, problems can occur if:
> 
> [1] The card itself is only capable of supporting a small selection of
>     sampling rates (many AC97 codes seem to want to run at 48000
>     samples/second), and
> 
> [2] You set up the sound modem to use the "natural" sampling rate for
>     the modulation in question (e.g. 9600 samples/second for 1200-baud
>     packet), and

I cannot seem to find where this is set. Are the specifications for the config
file somewhere?

> [3] The soundmodem is configured to use /dev/dsp, and
> 
> [4] You're using an ALSA driver with OSS emulation.
> 
> What seems to happen is that the OSS emulation layer quite politely
> lies to the soundmodem, says "Sure, 9600 samples/second is supported",
> and then tells the ALSA PCM layer to do sample-rate conversion in
> software.  The ALSA rate converter has some problems, and it ends up
> introducing noise into the received audio signal occasionally (usually
> on internal buffer boundaries, I believe).  The noise is sufficient to
> mess up the audio reception.
> 
> The solution to this involves disabling the sample rate conversion
> process.  I _think_ (but am not sure) that the best way to do this is
> to tell the soundmodem to use the ALSA API directly, rather than using
> the OSS emulation via /dev/dsp - recent versions of the soundmodem can
> do this, and are smart enough to use a sampling rate that the audio
> chip supports directly with no conversion being required.

Well, from some of the things you have pointed out, I might suspect an audio
driver issue, but I'm not sure if the ALSA driver is using OSS emulation with
the older i810_audio driver.

Re: Soundmodem Not Decoding Real Packets

[ariel mastracchio]

Hello,
 
  The motherboard i have with onboard sound card
didn't work (it transmit ok, but dont decode packets,
the scope graph show a very small bandwidth with blank
noise) , i have to buy a sound blaste PCI, and work
fine!!

hugs
lu9aum

--- Jonathan Lassoff <jlassoff@gmail.com> wrote:

> Dave Platt <dplatt <at> radagast.org> writes:
> > Hmmm.
> > 
> > Which audio drivers are you using - OSS, or ALSA?
> 
> I've tried both. I'm using the i810_audio module
> with the AC97 codec for an
> on-board sound device on a laptop.
>  
> > I've seen some rather bizarre things with some
> combinations of card,
> > driver, and software setting.  In particular,
> problems can occur if:
> > 
> > [1] The card itself is only capable of supporting
> a small selection of
> >     sampling rates (many AC97 codes seem to want
> to run at 48000
> >     samples/second), and
> > 
> > [2] You set up the sound modem to use the
> "natural" sampling rate for
> >     the modulation in question (e.g. 9600
> samples/second for 1200-baud
> >     packet), and
> 
> I cannot seem to find where this is set. Are the
> specifications for the config
> file somewhere?
> 
> > [3] The soundmodem is configured to use /dev/dsp,
> and
> > 
> > [4] You're using an ALSA driver with OSS
> emulation.
> > 
> > What seems to happen is that the OSS emulation
> layer quite politely
> > lies to the soundmodem, says "Sure, 9600
> samples/second is supported",
> > and then tells the ALSA PCM layer to do
> sample-rate conversion in
> > software.  The ALSA rate converter has some
> problems, and it ends up
> > introducing noise into the received audio signal
> occasionally (usually
> > on internal buffer boundaries, I believe).  The
> noise is sufficient to
> > mess up the audio reception.
> > 
> > The solution to this involves disabling the sample
> rate conversion
> > process.  I _think_ (but am not sure) that the
> best way to do this is
> > to tell the soundmodem to use the ALSA API
> directly, rather than using
> > the OSS emulation via /dev/dsp - recent versions
> of the soundmodem can
> > do this, and are smart enough to use a sampling
> rate that the audio
> > chip supports directly with no conversion being
> required.
> 
> Well, from some of the things you have pointed out,
> I might suspect an audio
> driver issue, but I'm not sure if the ALSA driver is
> using OSS emulation with
> the older i810_audio driver.
> 
> -
> 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
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com