Re: [Discuss-gnuradio] RAW source

[Sara Chérif]

Thanks Marcus Müller , Marcus D. Leech , Activecat.

yes , we can call this "Ethernet to wireless bridge using GSM RF channel ". I have some questions, please :

1- Can I use both UDP source & TCP source  in this way :

  Can I connect output of" UDP source" & output of "TCP source" to input of "Socket PDU " and connect output of "Socket PDU "   to the input of the "PDU to tagged stream " block ?  What is wrong in this connection ?

2- But when I connect the output of TCP or UDP source to the Socket PDU , I got an error ! what does the Socket PDU block take as an input?!

3- Also when I connect output of "TCP or UDP source" to "PDU to tagged stream " I got an error , what must be the input of the PDU to tagged stream block ?! Does the "PDU to tagged stream " is used here instead of the "stream to tagged stream" block  and has same role?

4- Does the block " Socket PDU" can be used instead of a socket ? It don't understand what is the importance of this block ?

 
5-  Is there any flags so that when signaling packets are coming (SIP or ARP)  : TCP source is enabled while UDP source is disabled  ?
  And the inverse happens when there is RTP packets coming?

Note that , in network settings in Twinkle soft phone , there is a port number for RTP different from port number of SIP & we can change these ports numbers , I don't know if this may help me .

6- Do I have to write a code for socket ?or simply I can write ,in the "UDP source" block in Gnu radio(2nd lap) , the IP address & port number of the Ethernet connection (of 2nd lap) receiving from Twinkle(1st lap) ?

7-  If there is no new packets coming , I want to send zeros instead of repeating the sent packets ? How Can I do this ?

i.e: I want to insert 8 bits zeros after each ofdm symbol as a guard band : I tried to insert " pad source " block to do this , after the IFFT block  and before the cyclic prefixer block

 , but it is not allowed to connect 2 inputs to the cyclic prefixer also I don't know how to use the pad source to insert these zeros & I don't know if there is a block to concatenate between the zeros coming from the pad source & the output of the ifft block .

Thanks in advance .

2014-06-20 7:42 GMT+03:00 Activecat <address@hidden>:

On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif <address@hidden> wrote:

Sorry , I forgot to say that some packets coming from Twinkle are SIP & ARP packets not only RTP.

Hence , I think I need to receive RAW packets in GNU Radio ( as I have different type of packets:  RTP , ARP , SIP packets)

Note that :

I use 4 laps & 2 USRPs.

1st & 4th lap has twinkle softphone & I will make a call between them.

2nd lap has an OFDM TX implemented by Gnuradio.

3rd lap has an OFDM RX implemented by Gnuradio.

First and 2nd laps are connected by Ethernet cable.

3rd & 4th laps are connected by Ethernet cable.

One USRP is connected to the 2nd lap , the other USRP is connected to the 3rd lap.
2nd lap(GNUradio ,ofdm tx)  will receive the packets from 1st lap(Twinkle) using RAW socket (as I think ) .

2nd lap will send the packets to the 3rd lap by the USRPs.

3rd lap ( Gnuradio , ofdm rx)  will send real time voice packets to 4th lap (Twinkle) using RAW socket(as I think).

Hi Sara,

What you need is only a wireless bridge.
A wireless bridge allows you to connect one network (1st and 2nd lap) to another (3rd and 4th lap) over the airwaves (which is USRP-to-USRP), rather than having to run wire from one room (2nd lap) to another (3rd lap).

I would say you only need to work at the OSI layer 1 (physical layer).  In this case you can ignore the UDP, RTP etc as far as gnuradio is concerned.

In alternative you may implement the wireless bridge using 802.11, but it is not mandatory for you to work at OSI layer 2.

So you may rephrase your question as "how to build wireless bridge using USRPs ?"

Then you may want to work in either transparent "repeater" mode or "bridge" mode. In either case you don't need to work at layer 3 or above.

The basic requirements are just that, you need the USRPs to setup wireless link at full-duplex, and make sure the bandwidth of the wireless channel is sufficient for few concurrent VoIP calls.

Anyway, I may be wrong.