[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: mc4020 driver for 2.6 (1 of 3)

From: Eric Blossom
Subject: [Discuss-gnuradio] Re: mc4020 driver for 2.6 (1 of 3)
Date: Tue, 18 Jan 2005 10:25:39 -0800
User-agent: Mutt/1.5.6i

On Tue, Jan 18, 2005 at 12:08:38PM -0600, Meenal wrote:
> Thanks Eric for the mc4020 patch. The fix works with mc4020 hardware.I 
> had to still tweak a little to get everything in order. I was unable to 
> find the mc4020 driver, on executing cat /proc/devices. I found out 
> that FC3 uses a new device loading system making use of /udev instead 
> of /dev.
> A quick fix for loading mc4020 , I came up with is :
> $ cd /dev/
> $ cp -a mc4020*  /etc/udev/devices
> $ chown root.root /etc/udev/devices/mc4020

Thanks for working on this. 

I know nothing about udev. Is there some action that the driver can
take to get the right thing to happen, or is it a config file thing or
a combination of both?

Is there some way that the driver is supposed to request a major
number for use?  I just grabbed 127, but it seems a bit fragile.

> There is one issue still. I was able to run fm_demod.py for a single 
> channel but when I try to execute ./fm_demod.py 97.5 94.5 , the script 
> runs for some time and then my machine freezes.


When you say the machine freezes, do you mean the whole system, or just
that GNU Radio keeps sucking cycles, but isn't producing any output?

I checked in some changes to gnuradio-core yesterday that were related
to a similar situation: high output_multiple a/d followed by a
decimating FIR.  Can you please update gnuradio-core and try the
experiment again?  In any event, we shouldn't be able to freeze the
whole system.  If it is the whole system, that sounds like a driver
problem.  Have you checked the logs?

> I am working on the CVS patch for 2.6 /2.4. Will check it back into the 
> repository soon.
> Many thanks,
> Meenal


reply via email to

[Prev in Thread] Current Thread [Next in Thread]