USRP2 current svn code not working. Is the svn code still in flux?


#1

Hi,
The current svn code does not seem to produce correct results for me
when using usrp2_fft.py

I know there has been going on a lot of usrp2 work this weekend.
Is the svn code still in a state of flux or should it work by now and
should I check my setup.

If I don’t set the frequency I get a noise signal -85 dB.
Setting the gain from the commandline does not seem to have any effect.
usrp2_fft.py
or
usrp2_fftp.y -g 80
or
usrp2_fft.py -g 0

I I do set the frequency using the commandline I get a nonsense signal
at -120 to -180 dB.
usrp2_fft.py -f 107.9e6
or
usrp2_fft.py -f 107.9e6 -g 40

Until recently (before the needed firmware updates) everything worked
fine.
usrp2_fft.py -f 107.9e6 -g 40
used to show the spectrum of a local FM station.

I use a USRP2 with a TVRX daughterboard.
I do get the 2 green leds.

I don’t know if the problem is from (my build of) the new software
firmware txrx.bin.
I build on ubuntu 7.10 64 bit.

Or maybe there are some changes in setting gain/frequency API which
require changes in the usrp2_fft.py python script.

Greetings,
Martin


#2

On Sun, 2008-10-26 at 15:37 +0100, Martin DvH wrote:

The current svn code does not seem to produce correct results for me
when using usrp2_fft.py

Could you please try usrp2_rx_cfile.py and see if the results are the
same?


#3

On Sun, 2008-10-26 at 07:44 -0700, Johnathan C. wrote:

On Sun, 2008-10-26 at 15:37 +0100, Martin DvH wrote:

The current svn code does not seem to produce correct results for me
when using usrp2_fft.py

Could you please try usrp2_rx_cfile.py and see if the results are the
same?
Results are the same.

If I look at the capture with a hex editor I see a few non-zero numbers
at the start and then only zero’s
I attached a bzip2-ed version of the result of
usrp2_rx_cfile.py -f 107.9e6 -g 40 -N 10000000 -v tmp_cfloat.raw

As the compressed file is only 30 kB (uncompressed 10 MB) you can see
there is definitely something wrong.

Note that this is from trunk from today.

I checked out your development branch too.
branches/developers/jcorgan/u2-wip
Should I build that and see what it does?

Martin


#4

On Sun, 2008-10-26 at 16:27 +0100, Martin DvH wrote:

I checked out your development branch too.
branches/developers/jcorgan/u2-wip
Should I build that and see what it does?

I’m about to merge this into the trunk, so don’t bother building it.
But I don’t expect what I’ve done so far to address this.

Can you check if varying the decimation rate (try 4, 5, 100, and 200)
impacts what you are seeing?

Also, I suspect that there might be a compatibility issue between the
version of the FPGA code that was shipped on the SD card and the current
trunk firmware/host code. In a separate email I will send to you
another FPGA bin file to try to see if it makes a difference.


#5

On Sun, 2008-10-26 at 08:33 -0700, Johnathan C. wrote:

On Sun, 2008-10-26 at 16:27 +0100, Martin DvH wrote:

I checked out your development branch too.
branches/developers/jcorgan/u2-wip
Should I build that and see what it does?

I’m about to merge this into the trunk, so don’t bother building it.
But I don’t expect what I’ve done so far to address this.

Ok

Can you check if varying the decimation rate (try 4, 5, 100, and 200)
impacts what you are seeing?

4 noise -90 dB
5 noise -93 dB
6 noise -90 dB
7 noise -98 dB
8 noise -100 dB
9 noise -92 dB
10 noise -98 dB with small peak at -93 dB center freq (possibly my radio
station)
11 noise -93 dB
12 flat -380 dB (essentially all zero’s)
13 noise -95 dB
14 -105 dB erratic changing noise with sometimes a sinc curve (noise
intermittand with zero’s)
15 noise -100 dB zomewhat erratic
16 very irratic between -100 and -180 dB (noise intermittand with
zero’s)
17 same as 16
18 noise -100 dB
19 noise -98 dB
20 flatline -380 dB
21 same as 16
22 noise at -100 with small peak at center freq -93 dB same as 10
23 flatline -380 dB
24 flatline -380 dB
25 same as 16
26 same as 10
27 flatline -380 dB
28 flatline -380 dB
29 irractic flatline (flatline at different dB levels
30 same as 16
31 same as 16
32 flatline -380 dB

100 flatline -380 dB
200 flatline -380 dB

This is with the old fpga firmware
I am nowgoing to try the new one.

Martin


#6

On Sun, Oct 26, 2008 at 8:33 AM, Johnathan C.
removed_email_address@domain.invalid wrote:

Also, I suspect that there might be a compatibility issue between the
version of the FPGA code that was shipped on the SD card and the current
trunk firmware/host code.

This has been confirmed (thanks Martin).

What this means is that people who are using already shipped USRP2s
will need to update their SD card with the latest FPGA bitstream
binary image in order to use the latest GNU Radio trunk code. Since
creating the image requires using the commercial Xilinx ISE toolchain,
we will supply the latest binary on the GNU Radio website, along with
upgrade instructions.

Eric and I have discussed how to address this in general terms, and
once I have a chance to talk to Matt to confirm, we’ll make a list
posting and update the USRP2 wiki page.

-Johnathan


#7

On Sun, 2008-10-26 at 10:09 -0700, Johnathan C. wrote:

On Sun, Oct 26, 2008 at 8:33 AM, Johnathan C.
removed_email_address@domain.invalid wrote:

Also, I suspect that there might be a compatibility issue between the
version of the FPGA code that was shipped on the SD card and the current
trunk firmware/host code.

This has been confirmed (thanks Martin).
The new fpga image in combination with the latest svn code also makes it
possible to set the gain from the gui of usrp2_fft.py without crashing
the app.
(And the gain actually changes as can be seen by the change in signal
level)

Trying to set the frequency this way is not fixed. This still hangs the
whole app.

Greetings,
Martin


#8

On Sun, Oct 26, 2008 at 09:49:07PM +0100, Martin DvH wrote:

The new fpga image in combination with the latest svn code also makes it possible to set the gain from the gui of usrp2_fft.py without crashing the app.
(And the gain actually changes as can be seen by the change in signal
level)

Trying to set the frequency this way is not fixed. This still hangs the
whole app.

Greetings,
Martin

Thanks for the data point, Martin.

I’ll take a look at this a bit later on today.

Eric


#9

On Sun, 2008-10-26 at 21:49 +0100, Martin DvH wrote:

The new fpga image in combination with the latest svn code also makes it possible to set the gain from the gui of usrp2_fft.py without crashing the app.
(And the gain actually changes as can be seen by the change in signal
level)

Trying to set the frequency this way is not fixed. This still hangs the
whole app.

I’ve updated usrp2_fft.py on the trunk to use the latest gr-usrp2. It
is working normally now with setting the USRP2 parameters via the
command line, however, as you note, changing frequency doesn’t work.
This has been isolated to some problem in either libusrp2 or in the
USRP2 firmware. Eric and I are working on this.

Other commands that operate in “batch” mode, where you set the USRP2
parameters from the command line, are working normally now as well.

Thanks again for your testing.

-Johnathan


#10

On Sun, 2008-10-26 at 14:03 -0700, Johnathan C. wrote:

is working normally now with setting the USRP2 parameters via the
command line, however, as you note, changing frequency doesn’t work.
This has been isolated to some problem in either libusrp2 or in the
USRP2 firmware. Eric and I are working on this.

Other commands that operate in “batch” mode, where you set the USRP2
parameters from the command line, are working normally now as well.

When you set the decimation above 19 then you CAN set gain in the GUI.
With decimation below 19, setting gain in the GUI hangs the app.

Setting the freq only works from commandline.

The gainrange for “TVRX rev 3” comes out as 0 , 0
This triggers a python error min <max ==False and the gain slider cannot
be used.

I saw you have a workaround for the gainrange for TVRX, probably this
should also apply for TVRX rev 2 and TVRX rev 3.
(Or there is something else wrong in the backend code)

Following patch adds the workaround for alls TVRXs.
— usrp2_fft.py 2008-10-26 22:36:36.000000000 +0100
+++ mdvh_usrp2_fft.py 2008-10-26 22:35:56.000000000 +0100
@@ -133,9 +133,10 @@

     hbox.Add((5,0), 0, 0)
     g = self.u.gain_range()
  • if self.u.daughterboard_id() == 0x0003: # FIXME: get range right in
    firmware for TVRX
  •    dbid=self.u.daughterboard_id()
    
  • if dbid == 0x0003 or dbid==0x0040 or dbid == 0x0040: # FIXME: get
    range right in firmware for “TV Rx”, “TV Rx Rev 2” and “TV Rx Rev 3”
    g[1] = 104
  •    myform['gain'] = form.slider_field(parent=self.panel,
    

sizer=hbox, label=“Gain”,
weight=3,
min=int(g[0]),
max=int(g[1]),

Thanks again for your testing.

-Johnathan


#11

On Sun, Oct 26, 2008 at 10:47:34PM +0100, Martin DvH wrote:

With decimation below 19, setting gain in the GUI hangs the app.

Setting the freq only works from commandline.

There are two problems I’ve identified: One has to do with printfs
being done by the firmware. Taking care of that fixes allows the gain
setting to work. The other problem I’m still working on, but I think
it’s that setting the freq is taking too long without servicing the
ethernet. This results in an overrun, which stops the streaming data.

The gainrange for “TVRX rev 3” comes out as 0 , 0
This triggers a python error min <max ==False and the gain slider cannot
be used.

I saw you have a workaround for the gainrange for TVRX, probably this
should also apply for TVRX rev 2 and TVRX rev 3.
(Or there is something else wrong in the backend code)

Following patch adds the workaround for alls TVRXs.

Thanks.

This needs to be fixed in the firmware table that describes the
tvrx d’boards, and the python code needs fixing so that it doesn’t die
on
the 0, 0 case, since that is the right answer for the Basic Tx and
Rx. (There’s no PGA on the USRP2.)

Eric