discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Assertion `dac_rate () == 128000000' failed.


From: Alexander Chemeris
Subject: Re: [Discuss-gnuradio] Assertion `dac_rate () == 128000000' failed.
Date: Fri, 6 Nov 2009 00:53:05 +0300

Hi Thomas,

On Thu, Nov 5, 2009 at 00:19, Thomas Tsou <address@hidden> wrote:
> On Mon, Nov 2, 2009 at 4:35 PM, Alexander Chemeris
> <address@hidden> wrote:
>> Hum, why branch GnuRadio if it works pretty nicely with OpenBTS?
>
> Because individual branches are routinely part of git development. Of
> course, that is not necessarily the case with other revision control
> systems.

You should replace "git" with "DCVS" here. git is not the only
and exclusive DCVS in the world.

> You mentioned future changes, so I was suggesting a branch to
> collect the current and any future re-clocking related patches.

Yep, if I'll find I need more then one-two patches, I'll setup
my own branch. But my question was different - what have you
patched in your branch, as for me it works pretty good with
mainline GnuRadio with the only exception of this small change.

>> Right. But problem is that no python code (especially examples)
>> don't set FPGA clock rate on start. So you either need to modify
>> all python examples (ugh!) or provide a way to set default FPGA
>> clock rate without touching any python files. One way I see is to
>> pull default FPGA clock rate from environment.
>
> Ok, I see your point. As you know, the driver itself defaults to 64M,
> which is appropriate,

If you own re-clocked USRP, then it's not fair that driver defaults
to 64M, as you will always have to change it to, say, 52M. So I
really think that ability to change default value will be useful.

> and provides interfaces to change that value.
> IMO, that part should not change. One option is to set the clock rate
> information in the gr-usrp constructors.

Yep, that's needed too. But then you'll have to change every
other applications (examples included) to set the freq. And
you'll have to provide this freq from somewhere - from command
line, probably. Thus you'll have to pass the same command
line param to every application you run - because you own
re-clocked USRP and just want to use it.

> I agree that the examples
> should be left alone since they're not dependent on what the usrp is
> clocked at.

Right.

-- 
Regards,
Alexander Chemeris.




reply via email to

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