These data were submitted on: Sunday, April 24, 2005 at 07:12:24:

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

NAME:  "Zaba"

CALL:  OH1ZAA

E-mail:  zaba (at) dlc.fi   address modified!

MOTHERBOARD::  ASUS A7V133-VM   3x PCI-slot

CPU::  AMD Duron 1000

CPU Speed::  1000 MHz

RAM in MB::  392 MB SDRAM  (64MB shared)

SOUND CARD::  integrated AC'97

SOUND CHIPSET::  VIA VT82C686B (ver.50)

SOUND DRIVER(S)::  snd-via82xx

ALSA VERSION::  1.0.8

VIDEO CARD::  integrated  S3 Savage4

VIDEO CHIPSET, BUSS TYPE::  S3 Savage4

VIDEO DRIVER::  SVGALIB automatic selection

VIDEO OUTPUT::  single

LINUX DISTRIBUTION::  Knoppix

LINUX VERSION::  3.8.1

KERNEL VERSION::  2.6.11

GCC VERSION::  3.3.5

SVGALIB VERSION::  1.9.21  (latest development)

LINRAD VERSION::  lir01-33  (latest April 2005)

TEXT:  Knoppix Live_CD 3.8.1 booted PC straight into operation. 

In console 'knoppix-installer' transferred linux to HDA (10 GB).

Knoppix size on disk is under 2.5 GB (after apt-get update & upgrade).

Installed svgalib-1.9.21 with NO_HELPER option (edit Makefile.cfg).

Linrad install:   './configure'   'make'   'make svga'   

Less than 30 minutes to install svgalib and linrad .. 

edit libvga.config       only  mouse setting needed 

Audio services started automatically with 'Linrad'

Microphone input active; picks up whistled CW from headset 

Sampling set for 48000 Hz ; CPU load about 15% ; delay < 1s

Fastest install so far .... first time automatic sound output!

              Good luck to all!   73, "Zaba" OH1ZAA/2

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


  "Zaba" added the following:

Greetings to all (potential) Linrad users!

It was good to see that Leif started the discussion again about the
real everyday use of 'Linrad', as that is the ultimate goal most of
us are aiming at. Before continuing about install procedures I was
going to commence this sort of discussion, and since it has already
started by itself, I will make a couple of additional comments.

It was shocking to notice how much I had already forgotten of last
weekend's experiences with the 'Linrad' install procedures. Given
all the different open questions it is sometimes hard to choose the
direction for the next (partial) solution. It is even a hard job to
digest all the mail of the past week on the [linrad]-reflector, all
of it being very relevant information. Leif, I don't think that you
have distributed "too much" information on your web-site; however it
would be nice to be able to construct systematic pointers within the
subjects, which is not so easy, as many items are linking to various
others and some are kind of "recursive" (requiring actually some pre-
information; which is partly dependent on the reader's experience).

The technical key is here: 'Linrad' is inherently so capable in its
core properties, that with a small hardware investment of say about
200 euros (250 dollars) it is able (for 98% of the time) to beat the
performance of commercial receivers with a price tag of 5000 euros or
more, if we are talking about the specific monitoring of small band
segments (like 40 kHz or 80 kHz) using appropriate sound cards. And
with a few cheap quartz crystals or a clean synthesizer we can have
many of those segments. Personally I think that for man-made noise
'Linrad' is most effective on the 28/50/70/144 MHz bands (with wide
margins to include other frequencies, depending on local conditions).

Especially for the VHF-minded it is always important to have a fully
dedicated receiver for each band, in order not to miss out on rare
openings. It means that one can operate on any one band, but it
should not result in losing the monitor on the "favorite" band.
This calls for a computer that is not shared with other users or
even other applications. Old vintage could be the proper solution.

So, actually I was quite happy afterward, when I accidentally wiped
out the NTFS-partition of my Win2k install on one of the slower PC's,
a Duron_1000. Actually I have recently taken my hat off for the Win-
systems regarding the ease with which software packages install on
those systems. But yesterday with the ASUS A7V133-VM motherboard the
new Win2000 install was rejected twice with a "Hardware error", which
was enough to make it my first Linux-only machine. Sometime ago I had
already lost its sound under Windows. Given with a couple of successes
with Knoppix about a week ago, I thus went for a Knoppix 3.8.1 install.

Knoppix is fun, while it will show you the whole distro in operation
before installing it to hard-disk. After executing 'knoppix-installer'
the system will be on the HD (with GRUB into MBR), and it will start
up exactly as from the Live_CD. Graphics will operate immediately.
I have never failed with any of the Knoppix 3.4 - 3.8.1 installs on
any of the machines (about six altogether). It is Debian-based so
after 'apt-get update' and 'apt-get upgrade' taking about 80 MB of
downloads the newest kernel 2.6.11 is feeling well enough for action.

It took only 30 minutes to install SVGALIB 1.9.21 and Linrad 01-33
(and editing libvga.config for the PS2-mouse) to have the built-in
AC'97 sound pick up signals from the microphone input of the MB.
Also output was there. The CPU load was about 15% and the total
delay was 0.99 s in weak signal CW-mode. I could detect whistled
CW delayed by 1 s when fed to the MIC-input with a headset mike.
I sent a more specific report to Rein's Linrad User Data Bank.


Soon it will be time for the pulse generator and front-end hardware.
Using simple circuits as an alternative to the high-performing WSE-
equipment (with extreme dynamic range), 'Linrad' is very adaptable
for mobile and DX-pedition environments, especially in a single-TX
environment. However, it requires extra effort on top of programming
to have the full home-brew working package. I do not think that one
saves very much by implementing the old 486-series, as cheap boards
and capable CPU's are available (new) in the range of 40-60 euros.
Another issue is the signal delay that will grow with slow CPU's.

If you buy a used PC, make sure that it works. Also there are often
(ugly) reasons when a (new?) motherboard is dumped cheap in a store.
It is far better to pay 20 euros more for an original package, than
to spend 20 hours to chase for the reasons why the deal doesn't work!

         Good luck to you all!           73, "Zaba"  OH1ZAA/2


P.S. I managed to install Linrad on a 25/33 MHz 486 a couple of years
     ago, using the SuSE 8.0 distro with a 2.4.18 kernel (lir00-xx).. 


                ----------O----------


Hello all!

Before taking my couple of old 486's out of the dust, wouldn't
it be good to have a couple of reference values for the CPU-load
and signal delay under 'Linrad'. Possibly not much RAM-hardware
is needed for the actual running operation. Even if the delay would
be a couple of seconds, it would make 'Linrad' a perfect monitoring
tool around the 50/70/144 MHz calling frequencies, especially in
industrial or city environments with a lot of man-made noise.

As far as I have understood there are a few issues related to
CPU-load and delay. The reason that my Duron_1000 is taking so
much (15%) CPU load is probably mainly due to my high output
rate (48000). Adequate performance would be achieved already
with 6000 Hz sampling in the D/A converter, which would reduce
FFT-calculations substantially. I will see if the VIA VT82C686B
chip allows for independent sampling rates. It would be handy to
be able to do the complete 'Linrad' processing with a basic plain
motherboard (built-in audio and built-in graphics). Zero PCI/AGP!

Another thing is that 'Linrad' development has not been linear
through the years, meaning that Leif has reported several times
that the code has been substantially improved. Therefore it may
be that some listed values are not valid anymore for the newest
lir01-xx series (Leif, if that is what you mean by "too much"
information, then I could possibly agree, but there is a risk
to lose other embedded information if these old reports would
be removed; I guess the best is to display clearly the time
frame and technology/software versions during measurement).

Finally the (not so hypothetical) question is. Given a 486/33,
what is the approximate CPU load and delay with input sampling
at 48000 and output at 6000? My experience was that the screen
update was very sluggish initially in the lir00-xx series. So
possibly the main improvement has been there. Also ISA-cards
seem to slow down the CPU during transfers (a DMA issue)? For
passive monitoring I would allow several seconds of delay, but
for regular QSO's one second is about maximum, dependent on the
mode. Recent Skype-experiments (with occasional delays) prove
that the longer delays are very problematic in live discussions.

Hopefully we are able to progress from the software problems to
a real operating environment, even if it would be part-time....

             73, "Zaba"  OH1ZAA/2   [The sky is no limit]


P.S. I failed with an install on a Cyrix/166+ (forgotten CPU?).




At 19:06 24.4.2005 +0200, EA1ABZ wrote:

> Hi Leif and Linraders.
>
> I have googled a lot and getting pieces from many places, and found 
> a solution mixing everything.
> The trick is to create a swap partition to increase memory.
>
> Sarge installer could not load the fdisk-udeb  and more installer modules, 
> ecause of lack of memory space, the trick is using first the WOODY installer 
> (3.0r4 that works for Leif for example) for creating swap partition.
>
> Boot with the woody installer and make a swap partition on your disk (50MB will do). 
> If you have a swap partition on your disk there is no need to do it. Be sure that 
> you create the swap before exiting.
>
> Abort the woody installer and boot with the sarge installer.
>
> Choose "expert26"
>
> "entering low memory mode" ---> Continue
> "choose language" + Enter  (only english will work on low memory mode)
> "choose country or region" + Enter
> "select keyboard layout" + Enter
> "American english" + Enter
> "select and mount cdrom" +Enter
> "modules to load" -----> Continue
> "prompt for parameters" ----->  NO
> "start PC card services" ----->  NO
> Continue  (it will detect the CDROM)
> Continue
>
> "Load installer components from CD" + Enter
>
> STOP HERE!!
>
> ALT-F2  (to switch alternate text console)
>
>
> WARNING-WARNING-WARNING-WARNING-WARNING!!!
>
> Ensure what device corresponds to your swap partition that you create with the 
> woody installer. In my case, it was created in the slave disk of the first IDE cable
> (in the second partition/dev/hdb2). It corresponds to /dev/hdb2 in Linux speaking, 
> but here is different. bus0 is first ide cable, bus1 is second ide cable, "target1" is 
> second disc. "part2" is "partition 2" (hdb2)
>
> Do not blame me if you loose data on your disk!!!  ;-)
>
> END WARNING- END WARNING- END WARNING- END WARNING-END WARNING!!!
>
>
> mkswap /dev/ide/host0/bus0/target1/lun0/part2  (this creates the swap)
> swapon /dev/ide/host0/bus0/target1/lun0/part2  (this turns on the swap)
>
> type "free" to see that swap is working
>
> type "exit" to stop the text console
>
> ALT + F1   to go to the install screen
>
> Select all needed installer componets (now that you have swap, there will not be space 
> problems. Select nic-********  stuff, or everything if you wish)
>
> Continue
>
> Configure the network
> Go to "detect hardware"
>
> Partition your disks, but DO NOT CREATE SWAP!. You have a swap already running
>
> Continue with the installer untill you finish
>
> That is all.
> I have tested it here until partitioning the disks. And it works
>
> Hope it helps.
>
>
> Ramiro
> EA1ABZ.

                ----------O-----------

Hi Zaba and all,

There was one thing in your posting:


>> I do not think that one saves very much by implementing 
>> the old 486-series, as cheap boards and capable CPU's 
>> are available (new) in the range of 40-60 euros.

It is quite clear that 486 machines are a bit too small
but the early Pentium machines are adequate.


>> Another issue is the signal delay that will grow with slow CPU's.

Not really. The signal delay is determined essentially by the filter.
Even on a 100MHz machine the processing time is negligible.
Of course it is possible to get some CPU-induced delay by selecting
inappropriate processing parameters, but when using Linrad to
process the output of an ordinary radio, the input bandwidth
is only about 3kHz and the mode is CW. By setting a reasonably large
first mixer conversion ratio, the sampling rate in the baseband 
becomes so low that even a 386 would be mighty fast:-)
The limited maximum bandwidth one can set the filter to should
be of no concern in this case. 


>> If you buy a used PC, make sure that it works. 

Oooh! Do not buy any. People have them and you can pick them up 
for free - but they are 486-machines now. Very soon people will be
happy when you carry away old Pentiums for them so they do not
have to transport them to the recirculation junk-yard themselves:-)


73

Leif / SM5BSZ

                  ----------O-----------


Great information, Leif-san!!!

Again a lot of interesting detail, that cannot be easily picked up with
a quick glance through your Web-site (though I'm sure it is all there).

There is a big (probably the biggest) group of operators that will never
get down to building their own RX-hardware (or 'Linrad'_front-ends), so
I guess you were studying the 486 install with respect to that audience,
equipped with a 3 kHz pre-filtered spectrum. My "fault" was to immediately
think about the full potential ( > 18 kHz bandwidth) of an average 16-bit
sound card, whether a PCI-version or integrated on the motherboard. Thus
my mind was already up in spheres with band-scopes and hard "de-noising".
I certainly support to serve the masses with otherwise obsolete hardware,
but as it turned out the 486 is not going to suffice for 48000 Hz inputs.

Thanks for explaining the different phases of signal processing. I have
been at it many times before, but it seems that human mind (at least mine)
has a time constant where the stored information falls to the 1/e level in
a period that is frightening. As I said, I have to start again the process
of questioning that I started last year before derailing onto other things.

So, several things work around FFT-methods, which is good as they seem to
work fast and qualitatively well (but turn against themselves when used
with inappropriate parameters). Actually I have to study all the different
stages and possible options after I have a real-life running setup, so the
15% CPU-load I mentioned for the Duron_1000 is based on default settings.
I don't even know whether noise cancelling is activated. Also I am running
with the I/Q-channels in phase, so we are still far off the regular mode.

In addition there are a bunch of pending question ripening and issues that
have never been discussed before on the reflector, but for now I would not
like to burn your valuable time with these as I might be able to pick up the
basics and considerable background detail form the Web-site. As a matter of
fresh curiosity I wonder, whether multi-threaded 'Linrad' will see daylight
soon, and whether it will run in the lir02-series (or higher up the ladder)?

I just checked pricing for motherboards and the cheaper processors. Most
brands offer the cheapest motherboards starting from 40 euros and pricing
for the cheap CPU's start at about 60 euros. As blower noise is something
that should not occur in the RX-environment at all, I would go for a cheap
but relatively fast processor and slow it down, while lowering its core
voltage. The interesting options are the Sempron 2400+ that can probably
be slowed down from a 333 bus to 200 MHz, and the 90nm Celeron D325J that
can be slowed from 533 to 400 MHz. Blower speed can be accordingly lower.

A motherboard with integrated sound and graphics would serve all 'Linrad'
needs for a 16-bit 40kHz bandwidth solution. It requires some luck to hit
the right chips on the board, so that they will be supported by ALSA/OSS
and the SVGALIB-collection (if not now, then pretty soon hopefully).

So we face a lot of challenges for the coming times. And we are living
in interesting times as far as the technology is concerned. Fortunately
the time for experimenting at home is not over yet. But there is a lot
of distraction in the process itself; so it's good to keep "heading"!

Good luck to all with your experiments!     73,  "Zaba"  OH1ZAA/NNoY



P.S. I have not noticed the ISA-slowing issue with 'Linrad', but it was
     the reason that SCSI-I was changed to SCSI-II as the CPU came to a
     halt during bus-action. I have seen similar effects on most boards
     with ISA-slots (however, being ignorant regarding DMA-status).



At 23:26 24.4.2005 +0200, SM5BSZ wrote:

> Hi Zaba,
>
> > Before taking my couple of old 486's out of the dust, wouldn't
> > it be good to have a couple of reference values for the CPU-load
> > and signal delay under 'Linrad'. Possibly not much RAM-hardware
> > is needed for the actual running operation. Even if the delay would
> > be a couple of seconds, it would make 'Linrad' a perfect monitoring
> > tool around the 50/70/144 MHz calling frequencies, especially in
> > industrial or city environments with a lot of man-made noise.
> ???????
> What sampling speed (bandwidth) are you talking about?
> I think a 486 would be limited to SSB bandwidth  or just a little
> more. I do not think the CPU will be fast enough to allow the
> noise blanker but collecting a long time averaged waterfall
> would be possible for monitoring purposes.
>
> > As far as I have understood there are a few issues related to
> > CPU-load and delay. The reason that my Duron_1000 is taking so
> > much (15%) CPU load is probably mainly due to my high output
> > rate (48000). Adequate performance would be achieved already
> > with 6000 Hz sampling in the D/A converter, which would reduce
> > FFT-calculations substantially.
> Hmmm, that is not the way Linrad works. The FFT calculations are
> determined by the input sampling rate and the window. To a lesser
> extent also by the fft1 bandwidth. The second fft is not used
> in these cases unless you have a SSB receiver with a good dynamic
> range within the passband such as the FT1000D. The third fft
> is at a rate explicitly set by the user and on a slow computer
> one would set the parameters for a sampling rate in the order
> of 200Hz. The filtered signal is finally resampled to the
> output sampling speed of the D/A. No FFT is involved here - I have
> written a stupid routine that uses Lagranges interpolation formula to
> fit four points on the baseband (200Hz) function to a third order
> polynomial. The non-integer (and variable) re-sampling rate needs
> typically data points that are about 10 times more closely spaced
> (big computer baseband rate=500Hz for CW, D/A rate 5kHz) and
> despite the stupid design of the routine it does not take much time.
>
> At 48 kHz output sampling speed it is very different. The routine becomes
> ridiculous. The interpolation formula is used for each data point
> in the output data stream:-( Absolutely stupid!!!
>
> The purpose of the routine is to allow non-integer resampling rates
> to permit non-synchronous audio cards for input and output. The
> routine will produce a low distortion audio signal, something
> that might be essential. Fitting a second order polynomial would
> produce audible distortion on a noise-free sinewave.
>
> Obviously an FFT should have been used to fit a sine-wave over a
> couple of points. That sinewave could then be used to take samples
> from at any desired output rate.
>
> Another thing is that the BFO uses the sine and cosine functions of
> the C library (presumably the processor) to shift the frequency
> from zero to 400Hz or whatever the operator asks for. This is also
> ridiculously slow if you go for 48kHz and there is no reason for
> it because the BFO could be generated by phase increments through
> multiplications.
>
> Under normal operating conditions the carelessnes described above
> is totally insignificant.
>
> > Another thing is that 'Linrad' development has not been linear
> > through the years, meaning that Leif has reported several times
> > that the code has been substantially improved.
> Hmm, I would say it has been very linear. Like a good 3 bit A/D
> converter;-)  I have added new functions one by one, but once
> added and coarse debugged, established functions are essentially
> unchanged.
>
> > Therefore it may be that some listed values are not valid
> > anymore for the newest lir01-xx series
> I do not think so. The total CPU load has been too high
> on some systems occasionally due to various bugs but the
> actual CPU use is not different over time.
>
> > (Leif, if that is what you mean by "too much"
> > information, then I could possibly agree, but there is a risk
> > to lose other embedded information if these old reports would
> > be removed; I guess the best is to display clearly the time
> > frame and technology/software versions during measurement).
> No. I referred to my habit of giving alternate solutions on
> each problem - seems that many people want to know "the one
> and only good solution" (just think about how X-yagis are
> used on 144 MHz.......)
>
> > Finally the (not so hypothetical) question is. Given a 486/33,
> > what is the approximate CPU load and delay with input sampling
> > at 48000 and output at 6000?
> I do not think you can sample at 48 kHz with such a machine.
> I would suggest 6000 for input and 5000 for output (if you can)
> The delay is small - it is not much related to the processor.
>
> > My experience was that the screen
> > update was very sluggish initially in the lir00-xx series. So
> > possibly the main improvement has been there.
> Yes. I made many changes motivated by various timing issues.
> I think late versions handle priorities reasonably well. It
> will skip screen updates in a way that you can hardly notice
> in case there is a shortage of CPU time.
>
> > Also ISA-cards
> > seem to slow down the CPU during transfers (a DMA issue)? For
> > passive monitoring I would allow several seconds of delay, but
> > for regular QSO's one second is about maximum, dependent on the
> > mode.
> ????????
> I have never seen anything like this.
> Is it really something you have seen with Linrad?
>
> Just remember, if you want a filter that is flat over 18 Hz
> and that drops by 6 dB for a 20 Hz bandwidth, that filter has
> a Q that makes the delay about one second.
>
> For a short delay, expand the baseband graph and put only three
> yellow points on the passband. The filter will then have a
> "normal" Q and a much shorter delay.
>
> It is not computing - it is just math;-)
>
>
> 73
>
> Leif / SM5BSZ






                  ----------O-----------

Thanks Leif!

That already answers a couple of my questions! In fact I would
NOT be satisfied to look at a plain 3 kHz output of a regular
radio, but indeed the full I/Q processing of the full bandwidth
of a regular inexpensive 16-bit sound card. I guess the famous
'Linrad' noise-canceling would show its best features there.

After all we would only need a preamplifier, an oscillator,
a pair of mixers and a couple of op-amps to achieve a fair
dynamic range for effective monitoring (for 99.9% of time)
on the relatively quiet bands (e.g. 50/70 MHz in Winter).

Using 48000/8000 sampling rates this would allow 40 kHz input
bandwidth and about 3.5 kHz output bandwidth (filter margin).
It would provide a nice band scope too. The FFT-algorithm must
be pretty optimized these days to allow quick calculations,
but it is a fact that it takes time to fill the buffers with
enough samples to get sufficient data for the FFT-transforms
to commence. So with these additional remarks it would be nice
to get some (delay/load) comments still on my previous mail.

                         73, "Zaba"  OH1ZAA/2


At 19:54 24.4.2005 +0200, SM5BSZ wrote:

> Hi Zaba and all,
>
> There was one thing in your posting:
>
> > I do not think that one saves very much by implementing
> > the old 486-series, as cheap boards and capable CPU's
> > are available (new) in the range of 40-60 euros.
> It is quite clear that 486 machines are a bit too small
> but the early Pentium machines are adequate.
>
> > Another issue is the signal delay that will grow with slow CPU's.
> Not really. The signal delay is determined essentially by the filter.
> Even on a 100MHz machine the processing time is negligible.
> Of course it is possible to get some CPU-induced delay by selecting
> inappropriate processing parameters, but when using Linrad to
> process the output of an ordinary radio, the input bandwidth
> is only about 3kHz and the mode is CW. By setting a reasonably large
> first mixer conversion ratio, the sampling rate in the baseband
> becomes so low that even a 386 would be mighty fast:-)
> The limited maximum bandwidth one can set the filter to should
> be of no concern in this case.
>
> > If you buy a used PC, make sure that it works.
> Oooh! Do not buy any. People have them and you can pick them up
> for free - but they are 486-machines now. Very soon people will be
> happy when you carry away old Pentiums for them so they do not
> have to transport them to the recirculation junk-yard themselves:-)
>
>
> 73
>
> Leif / SM5BSZ
>
>
                 ----------O-----------

  May 3 2005

 Sir Roger (as far as I'm concerned you are Knighted from now on)!

This day has given one of the most exhilarating moments of my life!

After downloading Roger/W3SZ's new Linrad Live_CD based on Knoppix,
I booted my Abit IC7 board with ICH-5 sound, and one minute later I
was speechless, staring at a fully operating 48 kHz Linrad_01-33!!

It was also the first time ever that I saw an operational USB-mouse
[normally not listed in 'libvga.config'] under SVGALIB (1.9.21).

You took me by surprise, Roger. I thought Knoppix would go through
all the usual startup routines with the graphics, but no, there was
this sudden question: "Do you want to run Linrad, without...? Well,
I responded Y, and there it was: The Linrad screen, ready to start.

This is a Big Day for 'Linrad'. I can imagine myself strapping up a
front end or audio output of a rig to the audio jacks of the built-in
sound (ICH-5) on the back of the PC, and really start using 'Linrad'
in the station environment. Actually that is what I am going to do
soon, though I don't have quick solutions here at the secondary QTH!

Without further initial comments I'll keep on gasping for a while!

Thanks for the great effort, Roger! It's either a Nobel (to share
with Leif) or the Knighting if it can be arranged through G-land!

                                        73,  "Zaba"  OH1ZAA/2

            -----------#-------------

 May 05 2005

Sir Roger,

This is really great. I have served the W3SZ-Linrad_CD to four PC's
and they all went straight into Linrad-operation. Another four PC's
are waiting impatiently in queue.

Three PC's showed immediate audio input/output with the MB-integrated
VIA/Intel circuits. The remaining EPoX 4B2M+ board required a scan of
the sound parameters (U on the 'Linrad' start-up screen): sound would
work after setting the '00' configuration for read 'Only' (O/W-select).
Alsaconf identified the integrated audio as Intel 82801BA/BAM AC'97
Audio rev(12) [i810 driver].

Suggestions:

Roger: your description http://www.nitehawk.com/w3sz/linrad_knoppix.htm
shows how to make the Live_CD. Everyone may want to have their own variant
of such a disk. However, I tried to install the Live_CD on the hard disk,
as it may be the most solid and adaptable "final" situation. However, I
was not able to find 'Linrad' back after installing. Possibly I missed
part of the documentation relating to the release of your CD.

One immediate improvement that could be done to save a lot of downloading
time among the projected number of hundreds of users, could be to do the
usual apt-get update/upgrade procedure, and make a new version of the CD.

After I installed the CD on hard disk, the upgrade required about 260 MB
of Knoppix (actually Debian) files (the usual improvements as the result
of ongoing Linux-development). 'Linrad' does not need these downloads to
operate, but if the PC is used for the future support of 'Linrad', then
it is good that the latest and safest tools are up-to-date. Certainly
new (Debian) downloads will be available almost daily, but the initial
transfer volume would be in low megabytes with a new May-2005 CD_issue.

Regarding the quest for 'Linrad' after installing W3SZ-Knoppix-Linrad,
I did 'updatedb' and 'locate linrad', and I got a load of references to
files and directories. However, even in root-mode I could not change to
the indicated directories. This is certainly still due to my ignorance
with the finest details of the Linux-system.

For HomePNA-users under this Knoppix version (and other distro-releases
after kernel 2.6.8) I recommend to issue the following commands as root:
'rmmod pcnet32'  'modprobe pcnet32 homepna=1'  and subsequent initiation
of Network Card DHCP services (Yes) via the "Fat Penguin" (lower toolbar).
This can be embedded in the configuration files, but I have not yet gone
through that exercise. Probably I will first check out the other 4 PC's.

                                73, "Zaba"  OH1ZAA/2


P.S. As far as I can recall I only remember numerous failures with ALSA
     in combination with the Delta44-card. Any http:-link to one success?

 
May 5 05


    More on this