Assertion `dac_rate () == 128000000' failed

GNU Radio
1

Hi all,

Could any of GnuRadio developers remove this assert?

usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int,
double): Assertion `dac_rate () == 128000000’ failed.

It’s no longer valid when you reclock your USRP and just makes
it impossible to use libusrp in this case.

I’m now trying to make GnuRadio usable with OpenBTS without
patching of GnuRadio and this is show-stopper for me now.

PS Whom should I contact with more re-clocking related fixes?
To date no Python examples seem to work with re-clocked USRP
without patching. I’m seeking for a way to make them working
without too much changes. Probably USRP FPGA frequency can
be set from environment variable? Is there any nicer way to do this?

–
Regards,
Alexander C…

2

On Sun, Nov 1, 2009 at 6:13 PM, Alexander C.
[email protected] wrote:

Could any of GnuRadio developers remove this assert?

usrp_standard.cc:1024: virtual bool usrp_standard_tx::set_tx_freq(int,
double): Assertion `dac_rate () == 128000000’ failed.

It’s no longer valid when you reclock your USRP and just makes
it impossible to use libusrp in this case.

Sounds reasonable to me.

I’m now trying to make GnuRadio usable with OpenBTS without
patching of GnuRadio and this is show-stopper for me now.

PS Whom should I contact with more re-clocking related fixes?
To date no Python examples seem to work with re-clocked USRP
without patching. I’m seeking for a way to make them working
without too much changes. Probably USRP FPGA frequency can
be set from environment variable? Is there any nicer way to do this?

Most gnuradio development occurs with git, so the easiest way to get
changes accepted upstream is by generating patches against the master
branch at:

gnuradio.git - GNU Radio master

Patches or pull requests from a published repository clone can be
submitted to the patch-gnuradio mailing list.

I currently work with both openbts and gnuradio, so I can assist with
host side re-clocking or git issues. I’m still getting setup on the
hardware side, but as a start for testing I created an openbts branch
in my repo at:

git://github.com/ttsou/gnuradio-ttsou.git openbts

Viewable at:

http://github.com/ttsou/gnuradio-ttsou/tree/openbts

For your last question, using the mid-level interfaces in usrp_basic
may be more appropriate for your needs.

Thomas

3

Hi Thomas,

On Mon, Nov 2, 2009 at 23:28, Thomas T. [email protected] wrote:

Most gnuradio development occurs with git, so the easiest way to get
changes accepted upstream is by generating patches against the master
branch at:

gnuradio.git - GNU Radio master

Patches or pull requests from a published repository clone can be
submitted to the patch-gnuradio mailing list.

Thank you for information!
I do hate this awkward heap, named git, so I’d better go with patches.

I currently work with both openbts and gnuradio, so I can assist with
host side re-clocking or git issues. I’m still getting setup on the
hardware side, but as a start for testing I created an openbts branch
in my repo at:

git://github.com/ttsou/gnuradio-ttsou.git openbts

Viewable at:

http://github.com/ttsou/gnuradio-ttsou/tree/openbts

Hum, why branch GnuRadio if it works pretty nicely with OpenBTS?

For your last question, using the mid-level interfaces in usrp_basic
may be more appropriate for your needs.

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.

–
Regards,
Alexander C…

4

Hi Thomas,

On Thu, Nov 5, 2009 at 00:19, Thomas T. [email protected] wrote:

On Mon, Nov 2, 2009 at 4:35 PM, Alexander C.
[email protected] 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 C…

5

On Mon, Nov 2, 2009 at 4:35 PM, Alexander C.
[email protected] wrote:

Thank you for information!
I do hate this awkward heap, named git, so I’d better go with patches.

No problem. I’m quite fond of git, but that discussion is for another
time and place. To each their own.

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 mentioned future changes, so I was suggesting a branch to
collect the current and any future re-clocking related patches.

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, 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. I agree that the examples
should be left alone since they’re not dependent on what the usrp is
clocked at.

Thomas