Re: [Discuss-gnuradio] pipe trick

[Bob Vincent]

I examined the internal buffering and thread scheduling code
in the GnuRadio core.
The scheduler is "sink-driven", as I understand it, relying on
USRP polling to pull data from the internal buffers.
It has been arranged to have sufficient data ready to go, since the USRP
must transmit isochronously.

Modifying the scheduler is non-trivial because of the issues in getting
the right amount of data for each processing block.

The way it's written now works ok for continuous flows, but is not too
good for "event driven" packet radios.
Even for continuous flows, there is a little bit of a problem with
matching the transmit and receive clocks. The MSK modulation tolerates
this ok, but wouldn't work so well at high bitrates.

We are interested in pursuing an event-driven scheduler and transmit
keying so that we could adapt this code to a packet radio. 
What's holding us off is that we don't want to deviate from GR mainline
development.
It would be nice to have an idea what the schedule is.

At 09:40 AM 4/10/2005, Chuck Swiger wrote:
> At 03:02 AM 4/10/2005 -0400, you
> wrote:
> > How are you _reading_ the data
> > from the pipe?  Even if you're flushing
> > the data into the pipe after every write, the reader could be
> > buffering it.
>
> Tks Dave - yes, yesterday I put a vector_sink_b after the
> file_descriptor_source
> of the pipe and verified that it is reading ALL the date sent across
> it.
> That is, after sending 20 \0xaa characters, the vector contains
> (170, 170, 170, 170  ...  170, 170)   all 20 of
> them.
>
> The little trickle of data going out to the usrp every byte written is
> interesting
> and just now measured this:
>
> bytes written to pipe   size of output to usrp 
> meaning
> -----------------------------   -------------------------------
> ------------
> 2                      
> 49144                  
> 6143 complex samples  49144 / 8
>                                                
> 6143+1 = 3 * 2048
>                                                
> 2048 is size of bytes_to_syms interpolation
>
> 3                      
> 65528                  
> 8191 complex samples
>                                                
> 8192+1 = 4 * 2048
>
> 4                      
> 81912                  
> 10239 complex samples
>                                                
> 10239+1 = 5 * 2048
>
> etc
>
>
> Every byte written to the pipe is /supposed/ to produce 8 * 2048 * 25 =
> 409600 samples
> the output rate to the usrp is 1.6msps (usrp interpolates by 80 to get
> 128e6) so it only
> has to write about 4 characters / second to the pipe to keep it stuffed (
> or approximately
> 3.906 as Spock would say ).    Then, as soon as I close
> the pipe after getting these
> little 'ticks'  of data, boom, it takes off and processes the data
> at full speed and produces
> the correct output and prints text on a nearby receiver and psk31
> software.
>
> This didn't happen with a pipe head and a sound card sink - only with the
> usrp at the tail.
> Even changed the bytes_to_syms interpolation back to 256 as in the sound
> card version,
> but still get the same issue with the usrp.
>
> Interestingly, the X25 interp fir filter doesn't show up mathematically
> in the output, even
> tho it's in the stream. It's like the entire gnuradio stream is being
> clocked by the pipe and the
> X2048 bytes_to_syms interpolator at the beginning.
>
> --Chuck
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio