Re: [Discuss-gnuradio] FSK demodulation

[Marcus Müller]

Hi Marc,

> Currently, I am trying to implement correlation receiver using FIR
filters. I am looking into polyphase filterbank channelizer to implement
correlation, but currently unable to do so because I currently do not
know how to assign taps for channelizer.

I should have pointed you at Tom's article on PFB channelizers and
synthesizers [1].
> Oversampling at baseband ? I am currently sampling at 1Msps (usrp sink
> sampling rate) for a tone spacing of 125KHz. You mean after the USRP sink
> block I should upsample again and then do the correlation?  Or you mean
> something else ? Please forgive me for asking too many question, I am still
> learning.
don't worry; this list is meant for GNU Radio discussion, I think things
like exploring possibilities to do certain tasks in GNU Radio fit
nicely, especially because you are considering using something "cool and
new" like the PFBs in your approach. GNU Radio can always use more
people actually trying to implement stuff!

So: Oversampling is what you do when getting more samples out of your
ADC than nyquist forces you to do. If you do 125k spacing 4FSK, then you
have a total bandwidth of 750kHz + X, so 1MS/s is "just enough"; anyway,
if you sample with let's say 3.125MS/s, than you'll have more samples.
Within that received bandwidth, you will have the same signal as before,
but now correlating against your known tone will give you a higher value
than with only 1MS/s, and because noise stays uncorrelated, this will
increase SNR. This is processing gain!

>> ... encourage you to read a lot of books [1] and papers on this.


> Thanks for the link, nice stuff.
If you find something interesting, don't hesitate to add a new heading
like "FSK demodulator technology" and add the references there; I think
this list is something that could use broader usage :)
>> Assuming you don't want phase jumps between symbols, why not just use
>> the VCO block to generate frequencies out of your input values?
> Wow! modulation is easy using VCO. A question, why would someone want phase
> jump between symbols?
In FSK systems, you'd usually want to avoid that, because phase jumps
lead to spectral components that are not at  the frequency you shifted to.
With PSK, phase jumps is your only way to encode data, and with QAM
"half" of the information is encoded in phase. However, you usually see
a pulse shaper after these, because transmitting a real phase
discontinuity is somewhat physically impossible[2]. So these modulations
get the spectrum of a phase-jumping system, smoothed by the spectral
shape of the pulse shaping.

Greetings,
Marcus

[1]
http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html
[2] Basically, imagine the baseband signal as a sequence of rectangles
in time; now, the fourier transform of a rectangle is a sin(x)/x, and
that has a support that doesn't fit into a limited bandwidth.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] prototype for make() does not match any in class

[Hoang Ngo Khac]

Dear all,

I'm writing an out-of-tree C++ block performing some PSK mapping method
(BPSK, QPSK. 16PSK, 256PSK). I got this error when running make command:

/home/khachoang/gr-Hoang/lib/Digital_Mapper_impl.cc:36:5: error: prototype
> for ‘gr::Hoang::Digital_Mapper::sptr gr::Hoang::Digital_Mapper::make(int)’
> does not match any in class ‘gr::Hoang::Digital_Mapper’
> /home/khachoang/gr-Hoang/include/Hoang/Digital_Mapper.h:49:19: error:
> candidate is: static gr::Hoang::Digital_Mapper::sptr
> gr::Hoang::Digital_Mapper::make()


I have tried but still do not know where this error from. Could anyone help
me to fix it?

My header file:

#ifndef INCLUDED_HOANG_DIGITAL_MAPPER_IMPL_H
> #define INCLUDED_HOANG_DIGITAL_MAPPER_IMPL_H
> #include 
> #include 
> #include 
> #include 
> #include 
> namespace gr {
>   namespace Hoang {
> class Digital_Mapper_impl : public Digital_Mapper
> {
>  private:
> int d_mapping_mode;
> std::vector d_symbols_psk;
>  public:
>   Digital_Mapper_impl(int mapping_mode);
>   ~Digital_Mapper_impl();
>   // Where all the action really happens
>   void forecast (int noutput_items, gr_vector_int
> &ninput_items_required);
>   int general_work(int noutput_items,
>gr_vector_int &ninput_items_v,
>gr_vector_const_void_star &input_items,
>gr_vector_void_star &output_items);
> };
>   } // namespace Hoang
> } // namespace gr
> #endif /* INCLUDED_HOANG_DIGITAL_MAPPER_IMPL_H */


My implementation file:

#ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
> #include 
> #include "Digital_Mapper_impl.h"
> #include 
> #include 
> #include 
> #include 
> namespace gr {
>   namespace Hoang {
> Digital_Mapper::sptr
> Digital_Mapper::make(int mapping_mode)
> {
>   return gnuradio::get_initial_sptr
> (new Digital_Mapper_impl(mapping_mode));
> }
> Digital_Mapper_impl::Digital_Mapper_impl(int mapping_mode)
>   : gr::block("Digital_Mapper",
>   gr::io_signature::make(1, 1, sizeof(char)),
>   gr::io_signature::make(1, 1, sizeof(gr_complex))),
> d_mapping_mode(mapping_mode), d_symbols_psk(mapping_mode,gr_complex(0,0))
> {
> printf("init::Digital_Mapper\n");
>
> int i = 0;
> int pi = 3.14159265359
> while (i < mapping_mode) {
> float theta = 2*pi*i/mapping_mode;
> d_symbols_psk[i] = gr_complex(cos(theta), sin(theta));
> i++;
> }
> set_output_multiple(mapping_mode);
> }
> /*
>  * Our virtual destructor.
>  */
> Digital_Mapper_impl::~Digital_Mapper_impl()
> {
> }
> void
> Digital_Mapper_impl::forecast (int noutput_items, gr_vector_int
> &ninput_items_required)
> {
> /* <+forecast+> e.g. ninput_items_required[0] = noutput_items */
> }
> int
> Digital_Mapper_impl::general_work (int noutput_items,
>gr_vector_int &ninput_items_v,
>gr_vector_const_void_star &input_items,
>gr_vector_void_star &output_items)
> {
> int ninput_items = ninput_items_v[0];
> unsigned char *in = (unsigned char *) input_items[0];
> gr_complex *out = (gr_complex *) output_items[0];
>
> int ni = 0;
> int no = 0;
> unsigned char byte = 0x0;
> unsigned char exceed = d_mapping_mode - 1;
> while (ni < ninput_items && no < noutput_items)
> {
> byte = in[ni];
> for (int i = 0;i <= 8*log(2)/log(d_mapping_mode)-1;i++) {
> int pos = i*log(d_mapping_mode)/log(2);
> /*if (mapping_mode == 0)*/ out[no + i] = d_symbols_psk[((byte >> pos) &
> exceed)];
> }
> ni++;
> no += 8/log(d_mapping_mode);
> }
> consume_each(ni);
> return no;
> }
>   } /* namespace Hoang */
> } /* namespace gr */


My xml file:


> 
>   Digital Mapper
>   Hoang_Digital_Mapper
>   Hoang
>   import Hoang
>   Hoang.Digital_Mapper($mapping_mode)
>   
> Mapping Mode
> mapping_mode
> 2
> enum
> 
>   BPSK
>   2
> 
> 
>   QPSK
>   4
> 
> 
>   16PSK
>   16
> 
> 
>   256PSK
>   256
> 
>   
>   
> byte_in
> byte
>   
>   
> sym_out
> complex
>   
> 


Many thanks.
Hoang

-- 
*Hoang Ngo-Khac*
Vietnam National University, Hanoi (VNU-H)
Univ. of Engineering and Technology (UET)
Faculty of Electronics and Telecommunications (FET)
Alternative email:  hoangnk...@vnu.edu.vn
Mobilephone:  +84.163.682.7874
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] prototype for make() does not match any in class

[Activecat]

On Thu, Jun 19, 2014 at 3:47 PM, Hoang Ngo Khac 
wrote:

> Dear all,
>
> I'm writing an out-of-tree C++ block performing some PSK mapping method
> (BPSK, QPSK. 16PSK, 256PSK). I got this error when running make command:
>
>  /home/khachoang/gr-Hoang/lib/Digital_Mapper_impl.cc:36:5: error:
>> prototype for ‘gr::Hoang::Digital_Mapper::sptr
>> gr::Hoang::Digital_Mapper::make(int)’ does not match any in class
>> ‘gr::Hoang::Digital_Mapper’
>> /home/khachoang/gr-Hoang/include/Hoang/Digital_Mapper.h:49:19: error:
>> candidate is: static gr::Hoang::Digital_Mapper::sptr
>> gr::Hoang::Digital_Mapper::make()
>
>

Chances are, when you created this block using gr_modtool, you didn't
specify any argument.
But later you decided to add the argument "int mapping_mode", you did this
by amending "Digital_Mapper_impl.h" and "Digital_Mapper_impl.cc" but
forgotten to look into the file "include/Hoang/Digital_Mapper.h"

If this is the case, the easiest solution is to remove and recreate this
block, both by using gr_modtool, but ensure to specify the argument "int
maping_mode" during the block creation wizard.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] RAW source

[Sara Chérif]

Hi,
I want to capture packets coming from Twinkle Soft phone in gnuradio, these
packet are RTP packets .
But in gnuradio , there is only UDP or TCP source ! I can't find Raw source
to correspond to the RTP packets.
 Is there an alternative to RAW source in GNUradio ?
Thanks.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Marcus D. Leech]

On 06/19/2014 07:54 AM, Sara Chérif wrote:

Hi,
I want to capture packets coming from Twinkle Soft phone in gnuradio, 
these packet are RTP packets .
But in gnuradio , there is only UDP or TCP source ! I can't find Raw 
source to correspond to the RTP packets.

 Is there an alternative to RAW source in GNUradio ?
Thanks.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RTP is usually carried over UDP

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Sara,

RTP is a complex networking protocol, so you will have to write a
decoder for this, and also for the numerous audio formats that may be
contained within, if you want GNU Radio to actually do something with
the speech within. If you only want to look at the packets as bytes of
payload, as Marcus said, just use a UDP source.

GNU Radio is about signal processing much more than about
application-specific protocol decoding; both problems are
fundamentally different.

Given the "modern" PDU capabilities, decoding network protocol data is
not entirely impossible, but it's still cumbersome.
Allow me a comparison: decoding an RTP stream including the numerous
audio payloads that might be contained using GNU Radio is comparably
elegant as demodulating FM radio with a webserver.

But: there are numerous open source RTP decoder libraries available,
and that's what twinklephone uses to decode the packets.

I think the right thing to do is use a library which decodes RTP and
the contained compressed audio and gives you PCM samples, and feed
this sample stream into GNU Radio. This could be done inside a GNU
Radio block, but I think it would be easier to just use an external
executable and let that stream audio into your flowgraph, for example
using a UDP or TCP socket, or a named pipe. Considering that, with
some ALSA hackery, you can have a loopback audio device, you could
even just use the soft phone of your choice to generate audio samples
that you capture using the GNU Radio audio source.

Greetings,
Marcus

On 19.06.2014 14:11, Marcus D. Leech wrote:
> On 06/19/2014 07:54 AM, Sara Chérif wrote:
>> Hi, I want to capture packets coming from Twinkle Soft phone in
>> gnuradio, these packet are RTP packets . But in gnuradio , there
>> is only UDP or TCP source ! I can't find Raw source to correspond
>> to the RTP packets. Is there an alternative to RAW source in
>> GNUradio ? Thanks.
>> 
>> 
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> RTP is usually carried over UDP
> 
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJToth9AAoJEBQ6EdjyzlHtlkYH/3L15S8wnBoq4rtE4woyhiGB
6GebGSmhb2co2I2yy3eFil0FITdDgamZDhv2S1TAe2Hk5O0hNUAQ6MJ1XO8p5G4X
zwMdmJ4RwV3owaG59Cf3wWl9gWilOY65blk3DVcek0Q6/fMg42peNrHheEDZmZAo
Zk3QbWmkRImgiYM3od1Jg4+Ho5S4LLGJVUzCIIEHC5qWTHt25Pq8803cvscaRvVE
LLmtXj1GFofatOPbR6520zNMhObpknWvqfVyvFlUWSOlpTN0FR3nO/KJeXxsGVq+
3UMVcZpU9tk2RRj/UoYDqppK2eDp3VvV4HCsbVt5zJq8xxbuVGEotn1P8XTsHOo=
=4etW
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Activecat]

On Thu, Jun 19, 2014 at 8:11 PM, Marcus D. Leech  wrote:

>  On 06/19/2014 07:54 AM, Sara Chérif wrote:
>
>  Hi,
> I want to capture packets coming from Twinkle Soft phone in gnuradio,
> these packet are RTP packets .
>  But in gnuradio , there is only UDP or TCP source ! I can't find Raw
> source to correspond to the RTP packets.
>   Is there an alternative to RAW source in GNUradio ?
>  Thanks.
>  
>
> RTP is usually carried over UDP
>
>

Just to be more detailed, RTP is a Session Layer (OSI Layer 5) protocol [1]
that lies on top of UDP (an OSI Layer 4 protocol).

1. http://en.wikipedia.org/wiki/OSI_model
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Sara Chérif]

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).

If I want only to make a call & send and receive the voip real time packets
, Do I have then to write a specific block as this mentioned decoder ?

Thanks in Advance.


2014-06-19 15:33 GMT+03:00 Marcus Müller :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Sara,
>
> RTP is a complex networking protocol, so you will have to write a
> decoder for this, and also for the numerous audio formats that may be
> contained within, if you want GNU Radio to actually do something with
> the speech within. If you only want to look at the packets as bytes of
> payload, as Marcus said, just use a UDP source.
>
> GNU Radio is about signal processing much more than about
> application-specific protocol decoding; both problems are
> fundamentally different.
>
> Given the "modern" PDU capabilities, decoding network protocol data is
> not entirely impossible, but it's still cumbersome.
> Allow me a comparison: decoding an RTP stream including the numerous
> audio payloads that might be contained using GNU Radio is comparably
> elegant as demodulating FM radio with a webserver.
>
> But: there are numerous open source RTP decoder libraries available,
> and that's what twinklephone uses to decode the packets.
>
> I think the right thing to do is use a library which decodes RTP and
> the contained compressed audio and gives you PCM samples, and feed
> this sample stream into GNU Radio. This could be done inside a GNU
> Radio block, but I think it would be easier to just use an external
> executable and let that stream audio into your flowgraph, for example
> using a UDP or TCP socket, or a named pipe. Considering that, with
> some ALSA hackery, you can have a loopback audio device, you could
> even just use the soft phone of your choice to generate audio samples
> that you capture using the GNU Radio audio source.
>
> Greetings,
> Marcus
>
> On 19.06.2014 14:11, Marcus D. Leech wrote:
> > On 06/19/2014 07:54 AM, Sara Chérif wrote:
> >> Hi, I want to capture packets coming from Twinkle Soft phone in
> >> gnuradio, these packet are RTP packets . But in gnuradio , there
> >> is only UDP or TCP source ! I can't find Raw source to correspond
> >> to the RTP packets. Is there an alternative to RAW source in
> >> GNUradio ? Thanks.
> >>
> >>
> >> ___ Discuss-gnuradio
> >> mailing list Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > RTP is usually carried over UDP
> >
> >
> >
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJToth9AAoJEBQ6EdjyzlHtlkYH/3L15S8wnBoq4rtE4woyhiGB
> 6GebGSmhb2co2I2yy3eFil0FITdDgamZDhv2S1TAe2Hk5O0hNUAQ6MJ1XO8p5G4X
> zwMdmJ4RwV3owaG59Cf3wWl9gWilOY65blk3DVcek0Q6/fMg42peNrHheEDZmZAo
> Zk3QbWmkRImgiYM3od1Jg4+Ho5S4LLGJVUzCIIEHC5qWTHt25Pq8803cvscaRvVE
> LLmtXj1GFofatOPbR6520zNMhObpknWvqfVyvFlUWSOlpTN0FR3nO/KJeXxsGVq+
> 3UMVcZpU9tk2RRj/UoYDqppK2eDp3VvV4HCsbVt5zJq8xxbuVGEotn1P8XTsHOo=
> =4etW
> -END PGP SIGNATURE-
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Marcus D. Leech]

On 06/19/2014 09:32 AM, Sara Chérif 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)


The thing is, Gnu Radio is largely about the *PHY* layer in the protocol 
stack (I say "largely" because it takes excursions into

  non-PHY territory from time to time).

The key point is that Gnu Radio *isn't* about packet-decoding and 
related machinery, but rather about *signal processing*.
  Granted, the "end game" of that signal processing often ends up in 
packetized bits, but Gnu Radio isn't about the
  semantic "meaning" of those bits--it's up to other bits and pieces to 
make sense of that.


For example, if you implemented an 802.11 "stack", you'd (on the receive 
side) inject the demodulated (and framed) bits
  into a virtual network interface in your operating system, which 
would treat them like any other bits arriving from

  a network interface.



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).


If I want only to make a call & send and receive the voip real time 
packets , Do I have then to write a specific block as this mentioned 
decoder ?


Thanks in Advance.


2014-06-19 15:33 GMT+03:00 Marcus Müller >:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Sara,

RTP is a complex networking protocol, so you will have to write a
decoder for this, and also for the numerous audio formats that may be
contained within, if you want GNU Radio to actually do something with
the speech within. If you only want to look at the packets as bytes of
payload, as Marcus said, just use a UDP source.

GNU Radio is about signal processing much more than about
application-specific protocol decoding; both problems are
fundamentally different.

Given the "modern" PDU capabilities, decoding network protocol data is
not entirely impossible, but it's still cumbersome.
Allow me a comparison: decoding an RTP stream including the numerous
audio payloads that might be contained using GNU Radio is comparably
elegant as demodulating FM radio with a webserver.

But: there are numerous open source RTP decoder libraries available,
and that's what twinklephone uses to decode the packets.

I think the right thing to do is use a library which decodes RTP and
the contained compressed audio and gives you PCM samples, and feed
this sample stream into GNU Radio. This could be done inside a GNU
Radio block, but I think it would be easier to just use an external
executable and let that stream audio into your flowgraph, for example
using a UDP or TCP socket, or a named pipe. Considering that, with
some ALSA hackery, you can have a loopback audio device, you could
even just use the soft phone of your choice to generate audio samples
that you capture using the GNU Radio audio source.

Greetings,
Marcus

On 19.06.2014 14:11, Marcus D. Leech wrote:
> On 06/19/2014 07:54 AM, Sara Chérif wrote:
>> Hi, I want to capture packets coming from Twinkle Soft phone in
>> gnuradio, these packet are RTP packets . But in gnuradio , there
>> is only UDP or TCP source ! I can't find Raw source to correspond
>> to the RTP packets. Is there an alternative to RAW source in
>> GNUradio ? Thanks.
>>
>>
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org

>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> RTP is usually carried over UDP
>
>
>
>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJToth9AAoJEBQ6EdjyzlHtlkYH/3L15S8wnBoq4rtE4woyhiGB
6GebGSmhb2co2I2yy3eFil0FITdDgamZDhv2S1TAe2Hk5O0hNUAQ6MJ1XO8p5G4X
zwMdmJ4RwV3owaG59Cf3wWl9gWilOY65blk3DVcek0Q6/fMg42peNrHheEDZmZAo
Zk3QbWmkRImgiYM3od1Jg4+Ho5S4LLGJVUzCIIEHC5qWTHt25Pq8803cvscaRvVE
LLmtXj1GF

Re: [Discuss-gnuradio] RAW source

[Marcus Müller]

Hi Sara,

in the stack of usual VoIP systems, there is no such thing as a "RAW"
package.
What you seem to want is the common transport layer for ARP, SIP and RTP
to go over the air.
I'm not really sure why you would want ARP, as that is something two
VoIP devices usually can't communicate over (because it's one layer
under the internet layer, and basically only exists for local networks);
ARP is only necessary when you want to know the ethernet MAC address
belonging to an IP address, which you don't need to do in your case;
just tell your routing table that packets for that other IP address have
to go over your wireless link...

Aside from ARP, the common layer would be IP.

Problem here is that all of your protocols are two-way protocols: you
cannot just send packets in one direction and hope everything will work,
there has to be some back channel. How would your TX soft phone know the
other end picked up your call?

So what you must do is two-fold:
1. Implement a link-layer, and instruct your operating system to
transport the IP pakets over that and
2. implement a back channel.

Notes:
2.: this might need another OFDM channel in the opposite direction, or,
with some firewall/ low level routing magic, another ethernet link, just
used for the back channel.

1.: there's still gr-digital/examples/ofdm/tunnel.py from the "old" OFDM
framework, which has become somewhat infamous :) but looking at that
code, you should be able to figure out how to use your OFDM
implementation with TUN/TAP devices. Also look at gr-ieee802-11, which
*is* a working OFDM layer with a TAP (that's ethernet layer) device
interface.


Greetings,
Marcus

On 19.06.2014 15:32, Sara Chérif 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).
>
> If I want only to make a call & send and receive the voip real time
packets
> , Do I have then to write a specific block as this mentioned decoder ?
>
> Thanks in Advance.
>
>
> 2014-06-19 15:33 GMT+03:00 Marcus Müller :
>
> Hi Sara,
>
> RTP is a complex networking protocol, so you will have to write a
> decoder for this, and also for the numerous audio formats that may be
> contained within, if you want GNU Radio to actually do something with
> the speech within. If you only want to look at the packets as bytes of
> payload, as Marcus said, just use a UDP source.
>
> GNU Radio is about signal processing much more than about
> application-specific protocol decoding; both problems are
> fundamentally different.
>
> Given the "modern" PDU capabilities, decoding network protocol data is
> not entirely impossible, but it's still cumbersome.
> Allow me a comparison: decoding an RTP stream including the numerous
> audio payloads that might be contained using GNU Radio is comparably
> elegant as demodulating FM radio with a webserver.
>
> But: there are numerous open source RTP decoder libraries available,
> and that's what twinklephone uses to decode the packets.
>
> I think the right thing to do is use a library which decodes RTP and
> the contained compressed audio and gives you PCM samples, and feed
> this sample stream into GNU Radio. This could be done inside a GNU
> Radio block, but I think it would be easier to just use an external
> executable and let that stream audio into your flowgraph, for example
> using a UDP or TCP socket, or a named pipe. Considering that, with
> some ALSA hackery, you can have a loopback audio device, you could
> even just use the soft phone of your choice to generate audio samples
> that you capture using the GNU Radio audio source.
>
> Greetings,
> Marcus
>
> On 19.06.2014 14:11, Marcus D. Leech wrote:
> >>> On 06/19/2014 07:54 AM, Sara Chérif wrote:
>  Hi, I want to capture packets coming from Twinkle Soft phone in
>  gnuradio, these packet are RTP packets . But in gnuradio , there
>  is only UDP or TCP source ! I can't find Raw source to correspond
>  to the RTP packets. Is there an alternative to RAW source in
>  GNUradio ? Thanks.
> 
> 
>  ___ Discuss-gnuradio
>  mailing list Discuss-gnuradio@gnu.org
>  https://lists.

Re: [Discuss-gnuradio] Question about gnuradio-companion

[Andy Walls]

> On Mon, May 6, 2013 at 10:34 AM, Bennett, David S. (Scott)
>  wrote:
> >>
> >> Yes, you're using the absolute path. I was just checking to see if you 
> >> might
> >> have been trying to create a file in a write-protected directory or a 
> >> place 
> >> that
> >> didn't actually exist, which could have been a result of using a relative 
> >> path
> >> and having GRC point to a place you weren't expecting.
> >>
> >> But with this info, I'm not sure. That's not an error that GNU Radio is
> >> producing; it's the OS. If you replace the file sink with something else 
> >> (like a
> >> null sink), do you get the same error? I'm just checking here to see if 
> >> it's 
> >> a
> >> problem with the file you are trying to open or maybe complaining about
> >> something else.
> >>
> >> Tom
> >
> > I just replaced the file sync with a null sync, and I still get that error 
> > in 
> > gnuradio companion.  But as before if I execute the python script companion 
> > generates, it executes fine.  So I'm not sure what's going on.
> >
> > In doing some additional troubleshooting over the last few minutes, though, 
> > I 
> > hooked up a WX GUI FFT sync just to see if I could see something in the 
> > band 
> > I was looking at.  I had forgotten that I set the "generate options" to "No 
> > GUI" since I wasn't using a GUI.  So it didn't execute properly.  
> > Curiously, 
> > when I changed that option to WX GUI, and the FFT then worked, I went back 
> > and replaced it with the null sync, and now strangely it works.  And now 
> > the 
> > file sink works as well.  So there must be something in the generate 
> > options 
> > that behaves differently in companion than in python.
> >
> > This seems to be an adequate workaround.  Is there anything inherently 
> > wrong 
> > with setting GUI options when you're not using a GUI?
> >
> > Thanks,
> > Scott
> 
> You shouldn't have to work around this, though. Sounds like something
> small but funky going on in your system. But to your other question,
> no, there's nothing wrong with using a GUI option with no GUI
> components. It'll just pop up a small dialog box somewhere, though,
> and that could be annoying. May also be a problem if trying to
> remotely log in and run the app.
> 
> Tom

I just ran into Scott's problem.

The problem is not that gnuradio-companion's popen() of .../top_block.py
is failing, it's that the popen() of the xterm executable, xterm, is
failing.

gnuradio-companion tries to open an xterm when you have a "No GUI" top
block.

$ sudo yum install xterm 

solved the problem for me.

Regards,
Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] sample time alignment in GRC

[Lapointe, Benjamin - 1008 - MITLL]

Nicholas,

Thanks for your message, I implemented your changes to my top_block.py file, 
but was unable to get the two data streams from the X310s to start sampling at 
the same time.  I verified with the print statements that python was doing the 
time conversions and math correctly.

I used a WX Scope Sinc and analyzed recorded data in MATLAB to look at time 
offsets in the two data streams.  I also set the 1 second waits to 2 second 
waits.  I generally saw time offsets in the range of 5 to 25 samples (1 to 5 
usec with 5MHz output), and one occurrence of ~200 sample offset between the 
two sample streams.  Nicholas, how did you verify sample time alignment?

I attached my top_block python file, in case anyone has time to look at it.
Any other ideas/comments?

Thanks!
-Ben

From: Linnenkamp, Nicholas [mailto:nlinnenk...@appcomsci.com]
Sent: Tuesday, June 17, 2014 1:54 PM
To: Robert Kossler; Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
Subject: RE: [USRP-users] sample time alignment in GRC

Ben/Rob,

I addressed the issue of getting time aligned samples going for USRP devices 
sometime back.  I had similar issues until I did a deep dive and worked out 
some of the problems.  There is a bit more to the process than just setting 
sync and reference sources.

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-April/009277.html

That contains code for getting gnu-radio to perform the required initialization 
for the devices so that they sample at the same time.  Perhaps someone from the 
gnuradio camp can figure out how to do it automagically.

Nicholas

From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Robert Kossler via USRP-users
Sent: Tuesday, June 17, 2014 10:28 AM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: usrp-us...@lists.ettus.com; 
discuss-gnuradio@gnu.org
Subject: Re: [USRP-users] sample time alignment in GRC

Hi Ben,
I am having a similar (but not identical issue).  I have a single X310 for 
which I am trying to make sure both channels are time aligned.  I have tried 
both the internal PPS signal and an external PPS signal.  I noticed 
channel-to-channel time delays of 1, 2, or 3 "clock" cycles (at clock rate, not 
sample rate) which varied from run to run.   My measurements were done with a 
modified "rx_samples_to_file" program and Matlab processing.  I have not yet 
duplicated using GRC.
Rob


On Tue, Jun 17, 2014 at 9:58 AM, Lapointe, Benjamin - 1008 - MITLL via 
USRP-users mailto:usrp-us...@lists.ettus.com>> 
wrote:
Hi All,

I am still having trouble time aligning sample streams from two USRP X310 
devices.  In GRC I noticed a random time offset from run to run in the two data 
streams using a WX GUI Scope Sink.  Looking at recorded data in MATLAB I also 
see a random time offset from run to run in the two data streams (8, 18, and 24 
sample offset).  I verified that the two data streams that I am inputting into 
the X310 devices are time aligned using a physical scope.

My GRC setup:

USRP Source 1 (with internal GPSDO-MINI)

-  Sync = unknown PPS

-  Mb0: Clock Source = Default

-  Mb0: Time Source = Default
USRP Source 2

-  Sync = unknown PPS

-  Mb0: Clock Source = External

-  Mb0: Time Source = External

For looking at the data streams I have USRP Source -> Complex to Mag -> WX GUI 
Scope Sink.
For recording the data streams I have USRP Source -> Head (5K) -> File Sink 
(Unbuffered: OFF)

Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable.
PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” 
SMA cable.
RF input to USRP devices is a pulsed RF signal, to make it easier to look at 
time offset.
GPS on USRP 1 is locked; however, I work with tall buildings completely 
surrounding me and so I don’t know the strength of the GPS lock.
I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but 
until then..

Does anyone have any other ideas for getting time-aligned samples from run to 
run in GRC, or what I am doing wrong? I would expect at most a minimal constant 
time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked.

Thanks!
-ben

From: Marcus Leech [mailto:mle...@ripnet.com]
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] sample time alignment in GRC

Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and 
all of them should use time synch of
  "unknown PPS".

Also, there has been a bug in the scope sink (dunno if fixed) where samples are 
*not* time-aligned in the scope sink.  The except
  is that a complex-pair will be time-aligned internally, but not necessarily 
to other streams being displayed.



on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL 
ma

[Discuss-gnuradio] Dev Call June

[Martin Braun]

Hi everyone,

this months dev call recording can be found here:
https://www.youtube.com/watch?v=VcJAOudR9Cw

Minutes and action items are here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20140619

Next call is July 17th, same time as usual (19:00 CEST, 1700 UTC).

Cheers,
Martin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Tampa area GNU Radio users?

[Johnathan Corgan]

I'll be in Tampa, FL all next week.  If there are any local area GNU
Radio users, it would be great to meet up.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] sample time alignment in GRC

[Andy Walls]

> From: Lapointe, Benjamin - 1008 - MITLL
> Date: Thu, 19 Jun 2014 16:39:55 +
> 
> Nicholas,
> 
>  
> 
> Thanks for your message, I implemented your changes to my top_block.py
> file, but was unable to get the two data streams from the X310s to
> start sampling at the same time.  I verified with the print statements
> that python was doing the time conversions and math correctly. 
> 
>  
> 
> I used a WX Scope Sinc and analyzed recorded data in MATLAB to look at
> time offsets in the two data streams.  I also set the 1 second waits
> to 2 second waits.  I generally saw time offsets in the range of 5 to
> 25 samples (1 to 5 usec with 5MHz output), and one occurrence of ~200
> sample offset between the two sample streams.  Nicholas, how did you
> verify sample time alignment?
> 
>  
> 
> I attached my top_block python file, in case anyone has time to look
> at it. 
> 
> Any other ideas/comments?

FWIW,

I wrote a custom block that monitors the X310 USRP w/GPSDO time at the
PPS and resets the X310 time, if they are off by more than 1
microsecond.

I often get my debug output looking like this:

uhd_foo_impl::run(): Setting USRP time to 1401798161 seconds on next PPS
uhd_foo_impl::run(): USRP time was 1401798159.993764020  seconds on 
last PPS

uhd_foo_impl::run(): Setting USRP time to 1401802468 seconds on next PPS
uhd_foo_impl::run(): USRP time was 1401802467.01295  seconds on 
last PPS

The first pair of lines always happens right at block start up.  The UHD
driver does an initial time setting from the GPSDO, but I'm guessing it
must do some hardware magic with the X310 to cause it to lose 3 to 6
milliseconds.

The second pair of lines occasionally happens, usually after the first
power on of the X310.  I do not know the cause.  This particular example
is odd, in that the jump happened 72 minutes later.  It usually happens
sooner.


BTW, GPS units can throw in leap seconds unannounced in two cases:

1. When GPS ground stations add or remove a leap second to the GPS-UTC
offset at the end of June or December.

2. When your GPS has an old GPS-UTC offset in NVRAM at power on, and
then gets the correct GPS-UTC offset from the almanac which it downloads
from the GPS satellites up to 12.5 minutes after power up.

Regards,
Andy


> Thanks!
> 
> -Ben



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] SWIG and QT (QT4_WRAP_CPP issues)

[Stefan Wunsch]

Hi!

I try to add a QT GUI to my OOT module (gr-radar). I have some issues
with including the QT stuff in cmake and swig.

The problem is this error:

## /gr-radar/swig/../lib/range_velocity_diagram.h:45: Error: Syntax
error in input(3).
## make[2]: *** [swig/radar_swigPYTHON_wrap.cxx] Error 1
## make[1]: *** [swig/CMakeFiles/pygen_swig_9a820.dir/all] Error 2

The line 45 refers to
## public slots:
Whole class definition is appended.[0]

If I build my module without 'public slots:' line but WITH the Q_OBJECT
line everything runs fine and I get a new QT window. So I suppose that
the additional class range_velocity_diagram is included correctly in
cmake and swig. Also I think the Q_OBJECT macro is accepted by cmake and
swig.

I have looked at gr-qtgui and added QT4_WRAP_CPP to get the Q_OBJECT
macro running. My changes in CMakeLists.txt (lib directory):

set(QTGUI_MOC_HEADERS range_velocity_diagram.h)
QT4_WRAP_CPP(QTGUI_MOC_OUTFILES ${QTGUI_MOC_HEADERS})
add_library(gnuradio-radar SHARED ${radar_sources} ${QTGUI_MOC_OUTFILES})

Do I need to add more to get swig running with the QT slots and signals?
I am correct with the assumption that cmake and swig accepts the
Q_OBJECT macro?

Best regards
Stefan

[0] Class definition range_velocity_diagram
class range_velocity_diagram : public QWidget
{
Q_OBJECT;

public:
range_velocity_diagram();
~range_velocity_diagram();

private:
QwtPlot* d_plot;
QwtPlotCurve* d_curve;

public slots:

};

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SWIG and QT (QT4_WRAP_CPP issues)

[Sylvain Munaut]

Hi,


> Do I need to add more to get swig running with the QT slots and signals?
> I am correct with the assumption that cmake and swig accepts the
> Q_OBJECT macro?

Why do you even need to get those through swig ?

Last time I did a Qt block, all the Qt stuff was hidden from swig,
there was only theses in the header :

---
  virtual void exec_() = 0;
  virtual QWidget* qwidget() = 0;

#ifdef ENABLE_PYTHON
  virtual PyObject* pyqwidget() = 0;
#else
  virtual void* pyqwidget() = 0;
#endif

  QApplication *d_qApplication


and nothing more, all the rest was hidden and never went through swig.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SWIG and QT (QT4_WRAP_CPP issues)

[Stefan Wunsch]

Sylvain solved it in a sec ;) There is no need to get the classes with
the qt stuff through swig. Solution is including the additional qt
classes only in cmake and wrap them with QT4_WRAP_CPP cause of the
Q_OBJECT macro but dont care about them in the *_swig.i file.

Am 19.06.2014 23:31, schrieb Stefan Wunsch:
> Hi!
> 
> I try to add a QT GUI to my OOT module (gr-radar). I have some issues
> with including the QT stuff in cmake and swig.
> 
> The problem is this error:
> 
> ## /gr-radar/swig/../lib/range_velocity_diagram.h:45: Error: Syntax
> error in input(3).
> ## make[2]: *** [swig/radar_swigPYTHON_wrap.cxx] Error 1
> ## make[1]: *** [swig/CMakeFiles/pygen_swig_9a820.dir/all] Error 2
> 
> The line 45 refers to
> ## public slots:
> Whole class definition is appended.[0]
> 
> If I build my module without 'public slots:' line but WITH the Q_OBJECT
> line everything runs fine and I get a new QT window. So I suppose that
> the additional class range_velocity_diagram is included correctly in
> cmake and swig. Also I think the Q_OBJECT macro is accepted by cmake and
> swig.
> 
> I have looked at gr-qtgui and added QT4_WRAP_CPP to get the Q_OBJECT
> macro running. My changes in CMakeLists.txt (lib directory):
> 
> set(QTGUI_MOC_HEADERS range_velocity_diagram.h)
> QT4_WRAP_CPP(QTGUI_MOC_OUTFILES ${QTGUI_MOC_HEADERS})
> add_library(gnuradio-radar SHARED ${radar_sources} ${QTGUI_MOC_OUTFILES})
> 
> Do I need to add more to get swig running with the QT slots and signals?
> I am correct with the assumption that cmake and swig accepts the
> Q_OBJECT macro?
> 
> Best regards
> Stefan
> 
> [0] Class definition range_velocity_diagram
> class range_velocity_diagram : public QWidget
> {
> Q_OBJECT;
> 
> public:
>   range_velocity_diagram();
>   ~range_velocity_diagram();
>   
> private:
>   QwtPlot* d_plot;
>   QwtPlotCurve* d_curve;
>   
> public slots:
> 
> };
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RAW source

[Activecat]

On Thu, Jun 19, 2014 at 9:32 PM, Sara Chérif  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.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio