Re: [Discuss-gnuradio] Daughter board pins

[aborg]

Hi Eric. Yes it seems that the problem is that my oscilloscope just ain't
fast enough! I've spoken to some of our engineering guys here and they
concur.

However I have another related question now. As I've said, I just want to
get the IQ outputs from the FPGA onto the pins. Now I see that the USB is
pretty darn fast. However, if I'm correct, the actual data produced by the
FPGA is not occurring at this speed - from what I understand, the data
rates of radio at a decimation rate of around 250 mean the actual
bandwidth required is something like 200K/s. Again, my inexperience may
show through here but my understanding is that the RF front end and the
logic on the FGPA are reducing the analog signal to a basebase digital
equivalent that does not need massive bandwidths (as long as I'm just
talking regular FM radio, not something like TV).

So my question is, can I "probe" somewhere in the Verilog logic to get
these values at a much slower rate. I saw a signal called
"rx_sample_strobe" and was hoping that this might help, but it seems like
nothing is connected to this output. Do you have any pointers as to how I
can get these IQ values to the pins at a slower rate but still fast enough
for FM radio?

Of course, the above question is based on the assumption that the IQ data
is really being produced at these slow rates. Otherwise, I understand I
need to rethink my strategy (and understanding of how radio works!).

Thanks again ... and again!

Andrew


> On Wed, Sep 27, 2006 at 04:28:08PM +0100, Andrew Borg wrote:
>> Hi Eric. Thanks for your help. It all works exactly how you said. I was
>> enabling the correct pins using "usrp.source_c(0, 64)"   - the code I
>> pasted "usrp.sink_c(0, 64)" was a blind copy-paste from Oussama's email.
>> Sorry about the confusion.
>>
>> All I was missing was the " u._write_oe(1, 0xffff, 0xffff) ". I put that
>> it
>> and it all worked nicely.
>>
>> I have another question. I'm outputting two pieces of information on my
>> 2
>> BasicRX daughter boards - (1) 3 clocks and (2) the USB data. The Verilog
>> code looks as follows:
>>
>>   master_control master_control
>>     ( .master_clk(clk64),.usbclk(usbclk),
>>       
>> .serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
>>       .tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
>>       .tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
>>       .enable_tx(enable_tx),.enable_rx(enable_rx),
>>       .interp_rate(interp_rate),.decim_rate(decim_rate),
>>       .tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
>>       .rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
>>       .tx_empty(tx_empty),
>>       //.debug_0(rx_a_a),.debug_1(ddc0_in_i),
>>      .debug_0(rx_debugbus),.debug_1(usbdata_out),
>>      .debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),
>>      .debug_3(usbclk,clk64,clk128),
>> //
>> .debug_3({rx_dsp_reset,tx_dsp_reset,rx_bus_reset,tx_bus_reset,enable_rx,tx_underrun,rx_overrun,decim_rate}),
>>       .reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3) );
>>
>>
>> Now I'm getting some signals on my oscilloscope that I'm not happy with.
>>
>> 1) First of all, the clk64 signal looks like a sine - wave. The
>> frequency
>> is 64MhZ according to my oscilloscope. I was expecting a square wave. Is
>> this correct?
>
> You'll need good probing techniques to see a 64MHz clock and have it
> not look like a sine wave.  You won't be able to do this with a scope
> probe with a 2 inch ground lead.  For this kind of stuff I usually use
> a small wire ground lead wrapped around the ground ring on the tip.
> The traditional scope vendors make a special little spring loaded gadget
> for this.  Ideally you want the tip of the probe and the ground probe
> to be within a 1/4" of each other.
>
>> 2) I get nothing from clk128 - it may just not be connected. Is this
>> correct?
>
> I don't think this is being used.
>
>> 3) The usbclk is also outputting a signal that looks like a sine-wave at
>> around 50MHz. Is this correct?
>
> More probing problems.  The signal is 48MHz.
>
>> 4) The USB data signals look very very unsteady. They look nothing like
>> a
>> square wave or a sine wave - almost somewhere in between with slow
>> rising
>> edges and then fast drops to 0.
>
> Beats me, I've never tried probing them.  They're running at
> 480Mb/sec.  My scope won't run that fast.
>
>> I'll explain briefly what I am trying to do. Essentially I've got
>> another
>> FPGA board that I want to get the output from the USRP board to be
>> trasferred onto. Essenitally, I want the I,Q pairs that go to the USB on
>> the USRP board to go to the daughterboard pins so that I can sample them
>> on
>> this second FPGA board.
>
> OK
>
>> I've written some python code to output 1, and 0s onto the daughter
>> board
>> pins (that's why I needed the previous help - thanks again Eric).  The
>> python code is basically a loop that outputs 0x0 and 0xffff alternately
>> to
>> the daughter board pins. My oscilloscope shows a nice clean square wave
>> which comes out at about 3KHz when I remove all delays (delays made with
>> python's sleep). I guess this speed is the fastest at which the python
>> code
>> can be interpreted, and the signal sent up the usb to the FPGA and then
>> to
>> the daughter board pins.
>
> FWIW, most of the delay is the round trip on the USB each time you set the
> pins.
>
>> This has led to me to believe that, perhaps I'm
>> having a problem of speed - perhaps the USB data coming out of the FPGA
>> is
>> changing too fast for a clear wave to show up on the daughter-board
>> pins.
>> Would this be a correct analysis?
>
> With good probing techniques you should be able to see
> the pins moving.  To figure out what's going on a logic analyzer is a
> better choice.  Also, how fast is your o'scope?
>
> If you've got any EE friends, they can probably help you with the
> probing techniques.
>
>> Any help would be greatly appreciated as I'm hitting a bit of a wall
>> now.
>>
>> Thanks a lot for the already received help.
>>
>> Andrew
>
> Eric
>