discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD de


From: LRK
Subject: Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)
Date: Fri, 30 Dec 2011 15:03:30 -0600
User-agent: Mutt/1.4.2.3i

On Fri, Dec 30, 2011 at 03:02:35PM -0500, Marcus D. Leech wrote:
>
> >I keep thinking this may be a reason for the lower interest in GnuRadio.
> >If someone writes a program to run on a USRP2 and daughterboard and I want
> >to run it on my USRP1, the UHD part should take care of the differences
> >if the frequencies and such are compatible. The computer should be able
> >to tell what hardware is connected and use the appropriate parts or
> >default to the most likely.

> The problem is that it's very often the case that the "computer" can't 
> really intuit
>   what your *intent* was when you're dealing with new hardware.  Sample 
> rates,
>   for example, aren't always compatible between different USRP families 
> (oh, sure,
>   there are spot places where there are overlaps, but not in general).
> 
> So, you have a flow-graph that "knows" that the sample rate is 
> 3.2Msps--what should
>   UHD *do* when you plug it into a USRP2-family device that doesn't 
> support that
>   sample rate?

The obvious thing to do is either set the closest possible rate and
provide a warning or decide it is not at all close and error off. If
the user program can read the actual setting, it might well just use 
that with a little math to make the program work.

My suggestion is not that these things can be perfect but that the user
should spend her time working on software defined radio development not
repeatedly fixing new bugs. My fisrt build of 3.5(?) on Ububtu resulted
in a situation where starting the program caused the USRP to vanish. If
I just moved it to the FreeBSD machine, it would not work there either.
Powering down, it would reload and work again. I think it was loading
the USRP with the wrong firmware but that went away and I never identified
the problem.

As I said, I'm old school. We did not have all the memory and speed of
today and making programs bullet-proof was part of the job.


-- 
LRK
gr-user . ovillatx.sytes.net



reply via email to

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