Re: [Discuss-gnuradio] "Failed to set initial frequency" and SDCC 2.5.0

[Eric Blossom]

On Thu, Oct 27, 2005 at 07:14:38PM -0400, Lee Patton wrote:
> Hi all -
> 
> I seem to have the baseline packages, gnuradio, and usrp code installed
> okay. The example files "usrp_oscope.py" and "usrp_fft.py" run and
> display active data on the line. However, I cannot set the frequency.
> The GUI displays the message "Failed to set initial frequency."

Which daughterboard are you using?

Usually "Failed to set initial frequency" is because either the
default or the command line argument is out of the range that the
daughterboard can successfully tune.  (The daughterboard's set_freq
method returned False.)

If you've got more than one Rx daughterboard, are you specifying which
one you want to receive on using the -R {a,b} command line option?

Have you tried changing the frequency by entering a number in the text
field and pressing enter?  To set 104.5 megahertz, enter "104.5M"
(without the quotes).  104.5m will try to set to 104.5 millihertz.
104.5 wills to 104.5 hertz...

On the command line, the same SI standard suffixes work.  M is
probably the one you want:  ... -f 104.5M

> I originally installed SDCC 2.5.0, but after reading the USRP README, I
> installed SDCC 2.4.0. This did not fix the problem.  SDCC 2.4.0 won't
> compile *completely* under gcc 3.4 (which is why I used 2.5.0 in the
> first place), but it does (apparently) generate all the files required
> by gnuradio.  I say this because the example files run. I just can't set
> the frequency.
> 
> My questions are:
> 
> 1) Any idea how to fix the problem causing the "Failed to set init..."
> message?

See above.

> 2) Can SDCC 2.5.0 be used, or is 2.4.0 an absolute must?

I haven't tested with SDCC 2.5.0.  
2.4.0 had some compiler bugs that I had to diagnose and work around.
I'm not sure if 2.5.0 is better or just different.  2.4.0 is known to
compile our code correctly.

Looks like SDCC 2.4.0 fails to compile the AVR simulator under gcc
3.4, but that doesn't matter to us, since we aren't using the
AVR microcontroller, or any simulator for that matter.

Eric