RE:New Linrad e-mail list user

[Leif Åsbrink <leif.asbrink@xxxxxxxxxxxxxxxxxxxx]

Hello Ramiro,

> Here is sounboard_init.log information:
> Checking /dev/dsp
> ------------------------------------------------------------------
> --------------
> /dev/dsp opened as RDONLY
> 16bit format supported
> Max no of channels = 2
> Max input speed 44100 Hz
> ------------------------------------------------------------------
> ------------------------------------------------------------------
> ----------------------------
> /dev/dsp opened as WRONLY
> 16bit format supported
> Max no of channels = 2
> Max input speed 44100 Hz
> ------------------------------------------------------------------
> ------------------------------------------------------------------
> ----------------------------
> /dev/dsp opened as RDWR
> 16bit format supported
> Max no of channels = 2
> Max input speed 44100 Hz
> ------------------------------------------------------------------
> --------------Checking 
> /dev/dsp0
> Checking /dev/dsp1
> Checking /dev/dsp2
.
.
This means that the open statement fails.
it is line 358 in setad.c and it looks like this:

  audio_out=open( devname, devmodes[k]|O_NONBLOCK, 0);

This statement is not changed since at least linrad00.28,
I do not think the reason that it does not work any more
is within Linrad.

In very early versions it was like this:
  audio_out=open( devname, devmodes[k], 0);
probably not better but you might try.

> At the following settings:******************************************
> 
> vga mode [11]
> font scale [1]
> mouse speed [10]
> input mode [0]
> rx channels [1]
> ad channels [1]
> ad speed [6000]
> ad device no [0]
> ad device mode [2]
> ad frag [0]
> da device no [0]
> min da speed [6000]
> max da speed [6000]
> max da channels [1]
> max da bytes [2]
> min da channels [1]
> min da bytes [2]
> da stop/start [0]
> check [2220102]

The above (userint) looks fine.

> First FFT bandwidth (Hz) [100]
> First FFT window (power of sin) [3]
There is no reason to load the computer with a high
order window because you do not have very high dynamic
range within the passband so there can not be a signal
that is more than about 30dB above the noise without
distortion (probably....)

> First forward FFT version [2]
> First FFT storage time (s) [4]
> First FFT amplitude [1000]
> Enable second FFT [0]
Fine.

> First backward FFT version [0]
> Sellim maxlevel [6000]
> First backward FFT att. N [6]
> Second FFT bandwidth factor in powers of 2 [2]
> Second FFT window (power of sin) [1]
> Second forward FFT version [0]
> Second forward FFT att. N [8]
> Second FFT storage time (s) [20]
Disabled

> Enable AFC/SPUR/DECODE [0]
ok.

> AFC lock range Hz [150]
> AFC max drift Hz/minute [100]
> Enable morse decoding [0]
> Max no of spurs to cancel [0]
> Spur timeconstant (0.1sek) [5]
Disabled

> First mixer bandwidth reduction in powers of 2 [4]
> First mixer no of channels [1]
> Baseband storage time (s) [200]
Ooops! This may cost a very large amount of memory
forcing your computer to use the hard disk for
virtual memory!!!

The baseband is stored at the sampling speed required to represent
the data that can pass through the filter you have selected.
With a wide bandwidth you will need very much memory because the 
baseband processing allocates a large number of arrays that are
intended for the automatic CW to ascii conversion.

When you start linrad, you get memory allocation on screen
in the waterfall graph. If the total size is large, look at
what the different processing blocks use. The last one: "bas"
shows the memory used for the baseband processing that
you will not use anyway since the code is currently disabled
because it is far from finished.

With 200 seconds, Linrad will allocate 13 megabytes for baseband
processing if you select a 100Hz wide filter. Probably too much
for a 486. Could be the problem.

> Output delay margin (0.1sek) [5]
> Output sampling speed (Hz) [6000]
> Default output mode [1]
> Audio expander exponent [3]
> A/D speed [6000]
OK.

> With the parameters I have sent to you the problem is the following:
> 
> I click with the mouse and I count seconds, with the following result:
> 
> Time(secs)   result
> 
> 0	I click the mouse
> 11	output starts
> 16 	output stops
> 29 	output starts
> 33	output stops
> 45	output starts
> 50	putput stops
> 
> You can see that it follows a fixed pattern, sound starts after 11 
> seconds, last 5 seconds and goes off for another 11 seconds. Perhaps 
> this data will help you.
No. It does not tell me anything - but it seems consistent with
using the swap space on the hard disk for processing.

73

Leif  /  SM5BSZ




LINRADDARNIL