Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard

[Eric Blossom]

On Thu, Sep 16, 2010 at 03:26:17PM +0200, Matthias Schäfer wrote:
>  Am 16.09.2010 07:49, schrieb Eric Blossom:
> > A couple of things.  32000 is likely to be too big and will probably
> > result in clipping.  Try 3200 to start with.
> >
> > It's unlikely that f/w can write samples to the buffer fast enough to
> > keep the data streaming. However in your case, you only need to
> > initialize the samples in the buffer once, then you can just keep
> > sending it over and over.  
> >
> > Do (2) once.
> >
> > // Start in known good state (IDLE)
> > bp_clear_buf(DSP_TX_BUF_0);
> >
> > // start first buffer xfer
> > bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> >
> > while (1){
> >
> >   // wait for xfer to complete
> >   while ((buffer_pool_status->status &
> >           (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
> >     ;
> >
> >   // Reset flags
> >   bp_clear_buf(DSP_TX_BUF_0);
> >
> >   // start next xfer
> >   bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> > }
> >
> >
> > Eric
> Hi Eric,
> thank for your fast reply. I tried the things you told me but it doesn't
> work nevertheless. I'm using the txrx_uhd f/w with the additional void
> SEND_DATA() (see below). After tuning the USRP2 with the mentioned
> host-app (see above), I'm sending a UDP packet to the USRP2 with a
> special port which becomes filtered by the eth_pkt_inspector which then
> invokes SEND_DATA(). The serial port then tells me the following:
> 
> Waiting for the buffer pool.
> Buffer pool idles. Filling buffer.
> Filled buffer. Start sending.
> Done.
> Done.
> 
> and than the USRP2 stucks in the inner waiting-loop until I restart it.
> If the debug-symbols (putstr) make any problems here, I tried it several
> times without serial port but it didn't have any effect. The H/W seems
> to be okay, because sending and receiving with grc works fine.
> 
> Do I maybe have to set some dboard/buffer pool flags before sending?
> Does my tuning procedure maybe leave the dboard in a "no-sending"-state?
> 
> static void SEND_DATA () {
>     putstr("Waiting for the buffer pool.\n");
> 
>     while((buffer_pool_status->status & BPS_IDLE(DSP_TX_BUF_0)) == 0)
>         ;
> 
>     putstr("Buffer pool idles. Filling buffer.\n");
> 
>     // fill buffer
>     uint32_t *p = buffer_ram(DSP_TX_BUF_0);
>     uint32_t i;
>     uint32_t sample = (3200 << 16) | 0;
> 
>     for (i = 0; i < BP_NLINES; i++) {
>         p[i] = sample;
>     }
> 
>     putstr("Filled buffer. Start sending\n");
> 
>     bp_clear_buf(DSP_TX_BUF_0);
> 
>     // first xfer
>     bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> 
>     while (1) {
> 
>         // wait for xfer to complete
>         while ((buffer_pool_status->status &
>               (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
>             ;
> 
>         putstr("Done.\n");
> 
>         bp_clear_buf(DSP_TX_BUF_0);
> 
>         // fire it off
>         bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
>     }
> }
> 
> 
> Cheers,
> Matthias


Matthias,

I'm not familiar with the changes that were made for the UDH fpga
image.  It may be that the timestamp checking is being done in the DSP
path.  If so, raw samples won't have the (possibly) required header.
I assume that there's a "NOW" flag that can be set in the header, but
I don't know the details.  Looking at the UHD host code should show
you how the packet is built.  Looking at the UDH firwmare will show
you which part of the header (UDP) is stripped off (probably by
adjusting the starting line number, passing on the VRT (or whatever)
header to the DSP pipe.

I believe the code above will work if you add the possibly required
header when you initialize the buffer.

Eric