On Mon, Nov 2, 2009 at 4:35 PM, Alexander Chemeris <[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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
