[Discuss-gnuradio] Re: Questions about GNURadio 2.6 communication examples

['Eric Blossom']

On Fri, Jan 13, 2006 at 11:45:18AM -0500, Naveen Manicka wrote:
> Hi Eric and Matt,
> 
> How r u doing?

Fine, thank you.

FYI, I've cc'd the list on the reply.  In the future, please ask these
questions there.  You'll probably get a quicker answer, and everyone
will benefit from the Q & A.

> I am running the communication examples in the gmsk folder and have a few
> questions regarding them. 
> 
> (You can certainly just give me pointers, if explaining the whole question
> is going to take a lot of your time. Do excuse me if the questions seem too
> obvious, I am still only getting a feel of the new code)
> 
> 
> 1. benchmark_gmsk_rx.py:
> 
>       The function rx_callback has 2 parameters ok and payload. Where is the
> parameter "ok" getting its value from. Coz, whenever I ran the benchmark_rx
> on one machine and the benchmark_tx on another machine, the rx showed the
> packets being received and the pkt_no being unpacked correctly, but never
> was the ok = True.

ok is True iff there are no errors detected in the payload.
The fact that you're seeing ok = False, means that it is properly
finding the beginning of the packet and is properly decoding the
payload length.

Are you using the Flex400 daughterboards?
Make sure that the boards are at least 3 or 4 meters apart.
Try adjusting the rx gain with the -g option.

> I tried to trace back to find where the value is getting passed, but wasn't
> very successful. Am I missing something?

Yes ;) 

The callback is made in the last line of
gnuradio-core/src/python/gnuradio/blksimpl/gmsk2_pkt.py

> 2. benchmark_gmsk_tx.py
> 
>       When the send_pkt function is used to send out the payload, the pkt
> contents are (struct.pack('!H', pktno) + (pkt_size - 2) * chr(pktno & 0xff))
> 
> What are the later 2 terms for (+ (pkt_size - 2) * chr(pktno & 0xff))?

I'm just building a test packet with a total payload of pkt_size bytes.
The payload in the example consists of two bytes of packet number,
followed by the pkt_size-2 bytes of the low 8-bits of the packet
number. 

> 3. tunnel_ip_null_mac.py
> 
>       I am having a little trouble following the example. How is the USRP
> shifting from being a transmitter to a receiver? Does it always listen on
> both the selected transmitter and receiver?

This uses the USRP Automatic Transmit/Receive Switching feature.  The
receive pipeline is always running.  The transmit pipe only runs when
there is data available to send.  The daughterboard specific code (db_*.py)
tells the FPGA how to set up the i/o pins for transmit versus receive.
If there is data in the FPGA TX fifo, the i/o pins are set one way,
else the other.  The one way enables the transmitter, the other
disables it.  Note that at this point, the only daughterboard that
implements this is the Flex 400.

> Since only one USB port is being used for all communication with the USRP,
> is it possible for a 2 way simultaneous interaction with the USRP (i.e
> sending and receiving at the same time)

Yes.

> and will we be able to use all the 4
> daughter boards on the USRP at the same time? (My first instinct was it may
> not be possible. I might be wrong) 

Maybe.  Depends on what you're trying to do.  Right now when using
both the A and B sides at the same time, the samples for the A and B
sides are interleaved.  This may cause a problem, or may be OK.  It
depends.  This could be fixed by reworking the verilog code, but it's
not likely to get reworked by either Matt or I in the short term.  At
some point in the future, when adding time stamps to the incoming and
outgoing data streams, we'll probably implement separate queues for
each DDC and DUC.

> Also, how is GNUradio interacting with the kernel to route the incoming
> packets to itself (since the USRP is connected through USB, and is not
> primarily identified as a network device)

Through the kernel tun interface.  

The README in gnuradio-examples/python/gmsk2 has pointers to the
relevant documentation.

> Could you suggest an antenna to use with the basic tx and rx boards (Will
> something like the ones on a wireless router be sufficient?)?

First off, you really want to be using the Flex 400 (or future Flex *)
daughterboards for this, not the basic tx/rx.

The README talks about suitable antennas for the Flex 400.

> Thanks,
> Naveen

Eric