Re: [Discuss-gnuradio] Gtk-WARNING when calling GUI

[Alex Zhang]

try:

sudo apt-get install gtk2-engines-pixbuf


On Fri, Dec 9, 2011 at 2:57 AM, Songsong Gee  wrote:

> Hello,
>
> Is there anyone seeing message like
> Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
> when calling any GUI window?
>
> I'm wondering that this message is caused by Ubuntu 11, or by GR 3.5.x
> before I got this message, I've used Ubuntu 10 and GR 3.4.x
> and I upgraded both OS and GR.
>
> So which one do you think has a potential problem?
>
> --
> Seokseong Jeon, PhD Candidate
> Communication & Networks Lab
> IT Convergence Engineering (ITCE), POSTECH, Korea
> +82 10 8338 1229, gee.songsong at gmail . com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] DPSK Block - Verifying Received Message

[Domenic Magazu III]

All,
   I was playing around with the DPSK block provided with GNU Radio.  I was
able to get my two USRPs talking to each other.  I placed a file sink on
the random source generator (set to transmit 10 random binary digits) and
I'm able to see what was actually sent from that file (command: od -d
filename.bin).  I was curious how I go about verifying that the message in
my filename.bin is received as transmitted on the other end?  I tried
placing a file sink on the DPSK demod block however because the receiver is
constantly pulling in information my file becomes extremely large and it's
difficult to determine where the message would be amongst the other
'noise'.  Does anyone have any ideas on how to verify my transmitted
message is making it to my receiver?

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

[Discuss-gnuradio] PPM Signal Generation

[Matthias Schäfer]

Hi,
is it possible to generate a PPM signal with GNU Radio + USRP2 with a 
bit rate of 1MBit/s?


In particular, I want to transmit Mode-S replies which are modulated 
using PPM on 1090Mhz. In order to do so, I have to send 0.5µs wide 
pulses with time-shifts of 0 µs or 0.5 µs.


The generation of samples on the host is of course no problem, and also 
the 1Gbit link to the SDR should suffice to transfer e.g. 4 
samples/pulse. The question now is, whether the hardware (USRP2 + WBX 
Rev 2) is fast and accurate enough to produce the correct RF-signal.


I played a bit with 2 USRPs, the XCVR2400 (one as sender, one as 
receiver) and GRC but I wasn't able to generate a nice square-signal 
with a frequency of 1Ghz which would be very similar to the one I need.


So I would appreciate any thoughts, ideas and suggestions.

Matthias

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

Re: [Discuss-gnuradio] DPSK Block - Verifying Received Message

[John Malsbury]

Domenic,

Whenever you are transferring data from a transmitter to a receiver it 
is reasonable to use some sort of framing.  If you want  a quick test, 
use a packet encoder and decoder on your transmitter and receiver, 
respectively.  This will packetize the data and eliminate the continuous 
flow of "garbage" data to your file since the decoder will only output 
data from valid packets(w/ header + crc are removed).  Bit errors will 
manifest themselves as a "short file", since bad packets will be 
discarded.  If you run the block in verbose mode there may also be 
reporting for when packets are discarded.


Set the payload length number in the encoder so you have a known 
relationship between the number of bytes missing from the file and the 
number of packet errors.


There are numerous ways to improve this simple test, but this is a start 
for you.  Also, you may want to perform a more fundamental bit error 
test.  See error rate block.


-J



On 12/09/2011 07:29 AM, Domenic Magazu III wrote:

All,
   I was playing around with the DPSK block provided with GNU Radio.  
I was able to get my two USRPs talking to each other.  I placed a file 
sink on the random source generator (set to transmit 10 random binary 
digits) and I'm able to see what was actually sent from that file 
(command: od -d filename.bin).  I was curious how I go about verifying 
that the message in my filename.bin is received as transmitted on the 
other end?  I tried placing a file sink on the DPSK demod block 
however because the receiver is constantly pulling in information my 
file becomes extremely large and it's difficult to determine where the 
message would be amongst the other 'noise'.  Does anyone have any 
ideas on how to verify my transmitted message is making it to my 
receiver?


Thank you
Domenic


___
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] Differences between USRP series

[John Malsbury]

Seokseong Jeon,

Your summary captures some of the differences between the USRP's.  If 
you haven't already, take a look at the link below for more details.  
One thing to note is the USRP2 has been discontinued in favor of the 
N200/N210 series.


http://www.ettus.com/faq

If you are interested in experimenting with MIMO, we recommend the 
N200/210.  The link below summarizes synchronization methods with the 
UHD API.  GNU Radio and GRC also provide very straight forward methods 
to enable MIMO.


http://files.ettus.com/uhd_docs/manual/html/sync.html

Thank you for your interest!

-J


On 12/08/2011 11:44 PM, Songsong Gee wrote:
There are various kind of USRP series, USRP1, USRP2, E100, B100, and 
N200.


At a glance I could find some differences between them.

1. USB connection and Ethernet connection which determines the
data rate between the USRP and a PC.
(and it also makes difference when addressing USRP in GNU Radio.)
2. the number of slots for daughter boards. USRP1 has two and N200
has one, and so on.
3. E series are for the embedded systems.
4. existence of MIMO expansion
5. USRP input and output / interpolation and decimation rate

etc.

and there are many other differences, of course.

Are there any differences that I've missed?
And I'm curious how can I use the MIMO expansion after connecting two 
USRPs with MIMO cable.


--
Seokseong Jeon, PhD Candidate
Communication & Networks Lab
IT Convergence Engineering (ITCE), POSTECH, Korea
+82 10 8338 1229, gee.songsong at gmail . com


___
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] DPSK Block - Verifying Received Message

[Marcus D. Leech]

All excellent advice. I would also add that the gr-digital blocks already do a 
lot of this--framing and the like.  They're a good place to get some clues even 
if you want to roll your own. 


--
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org


On Dec 9, 2011, at 11:21 AM, John Malsbury  wrote:

> Domenic,
> 
> Whenever you are transferring data from a transmitter to a receiver it is 
> reasonable to use some sort of framing.  If you want  a quick test, use a 
> packet encoder and decoder on your transmitter and receiver, respectively.  
> This will packetize the data and eliminate the continuous flow of "garbage" 
> data to your file since the decoder will only output data from valid 
> packets(w/ header + crc are removed).  Bit errors will manifest themselves as 
> a "short file", since bad packets will be discarded.  If you run the 
> block in verbose mode there may also be reporting for when packets are 
> discarded.  
> 
> Set the payload length number in the encoder so you have a known relationship 
> between the number of bytes missing from the file and the number of packet 
> errors.
> 
> There are numerous ways to improve this simple test, but this is a start for 
> you.  Also, you may want to perform a more fundamental bit error test.  See 
> error rate block.
> 
> -J
> 
> 
> 
> On 12/09/2011 07:29 AM, Domenic Magazu III wrote:
>> 
>> All,
>>I was playing around with the DPSK block provided with GNU Radio.  I was 
>> able to get my two USRPs talking to each other.  I placed a file sink on the 
>> random source generator (set to transmit 10 random binary digits) and I'm 
>> able to see what was actually sent from that file (command: od -d 
>> filename.bin).  I was curious how I go about verifying that the message in 
>> my filename.bin is received as   transmitted on the other end?  
>> I tried placing a file sink on the DPSK demod block however because the 
>> receiver is constantly pulling in information my file becomes extremely 
>> large and it's difficult to determine where the message would be amongst the 
>> other 'noise'.  Does anyone have any ideas on how to verify my transmitted 
>> message is making it to my receiver?  
>> 
>> Thank you
>> Domenic
>>  
>> 
>> ___
>> 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] BBN_80211 and UHD

[Evan Merewether]

Has anyone updated (or in the process of updating) the BBN_80211 or FTW_OFDM
project for UHD support?  If you could share them with me, that will save us
the effort of duplicating your work and would be appreciated.

 

Evan

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

Re: [Discuss-gnuradio] DPSK Block - Verifying Received Message

[Paul M. Bendixen]

2011/12/9 John Malsbury 

>  Domenic,
>
> Whenever you are transferring data from a transmitter to a receiver it is
> reasonable to use some sort of framing.  If you want  a quick test, use a
> packet encoder and decoder on your transmitter and receiver, respectively.
> This will packetize the data and eliminate the continuous flow of "garbage"
> data to your file since the decoder will only output data from valid
> packets(w/ header + crc are removed).  Bit errors will manifest themselves
> as a "short file", since bad packets will be discarded.  If you run the
> block in verbose mode there may also be reporting for when packets are
> discarded.
>
> Set the payload length number in the encoder so you have a known
> relationship between the number of bytes missing from the file and the
> number of packet errors.
>
> There are numerous ways to improve this simple test, but this is a start
> for you.  Also, you may want to perform a more fundamental bit error test.
> See error rate block.
>

Just a word of warning:
If you use the package en/decoder and the BER block , it might just go
haywire
The BER block cannot regain from a missing frame (which would be the case
if the framer threw it away)

>
> -J
>
>
>
>
> On 12/09/2011 07:29 AM, Domenic Magazu III wrote:
>
>   All,
>I was playing around with the DPSK block provided with GNU Radio.  I
> was able to get my two USRPs talking to each other.  I placed a file sink
> on the random source generator (set to transmit 10 random binary digits)
> and I'm able to see what was actually sent from that file (command: od -d
> filename.bin).  I was curious how I go about verifying that the message in
> my filename.bin is received as transmitted on the other end?  I tried
> placing a file sink on the DPSK demod block however because the receiver is
> constantly pulling in information my file becomes extremely large and it's
> difficult to determine where the message would be amongst the other
> 'noise'.  Does anyone have any ideas on how to verify my transmitted
> message is making it to my receiver?
>
>  Thank you
> Domenic
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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

Re: [Discuss-gnuradio] DPSK Block - Verifying Received Message

[John Malsbury]

Thanks for adding to the discussion Paul.  I should have made it clear 
that testing w/ the packets should have been independent from the 
"streaming" BER test.


-John

On 12/9/2011 9:48 AM, Paul M. Bendixen wrote:



2011/12/9 John Malsbury >


Domenic,

Whenever you are transferring data from a transmitter to a
receiver it is reasonable to use some sort of framing.  If you
want  a quick test, use a packet encoder and decoder on your
transmitter and receiver, respectively.  This will packetize the
data and eliminate the continuous flow of "garbage" data to your
file since the decoder will only output data from valid packets(w/
header + crc are removed).  Bit errors will manifest themselves as
a "short file", since bad packets will be discarded.  If you run
the block in verbose mode there may also be reporting for when
packets are discarded.

Set the payload length number in the encoder so you have a known
relationship between the number of bytes missing from the file and
the number of packet errors.

There are numerous ways to improve this simple test, but this is a
start for you.  Also, you may want to perform a more fundamental
bit error test.  See error rate block.


Just a word of warning:
If you use the package en/decoder and the BER block , it might just go 
haywire
The BER block cannot regain from a missing frame (which would be the 
case if the framer threw it away)



-J




On 12/09/2011 07:29 AM, Domenic Magazu III wrote:

All,
   I was playing around with the DPSK block provided with GNU
Radio.  I was able to get my two USRPs talking to each other.  I
placed a file sink on the random source generator (set to
transmit 10 random binary digits) and I'm able to see what was
actually sent from that file (command: od -d filename.bin).  I
was curious how I go about verifying that the message in my
filename.bin is received as transmitted on the other end?  I
tried placing a file sink on the DPSK demod block however because
the receiver is constantly pulling in information my file becomes
extremely large and it's difficult to determine where the message
would be amongst the other 'noise'.  Does anyone have any ideas
on how to verify my transmitted message is making it to my receiver?

Thank you
Domenic
___
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



Best
Paul
--
. - - ./. -/. . -/. - . ./- . . ././- ./- . ./. ./- . . -/./- ./. - - 
.- ./- - ./- -/. -/. ./. - . ./. - . - . -/- . - ./- - -/- -//



___
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

[Discuss-gnuradio] grc hardcoded to use xterm as a terminal emulator?

[Timo Juhani Lindfors]

Hi,

I just noticed that grc/python/Generator.py is hardcoded to use xterm as
a terminal emulator. This is somewhat problematic [1] for me so I'd like
to make it configurable, how would you rather see that done? Would
adding a new option (like "no_gui_terminal_emulator") to the flowchart
be too messy?

[1] xterm in ubuntu lucid is still sgid=utmp which causes it to drop
LD_LIBRARY_PATH which I need since I've installed gnuradio to a
temporary location. xterm also does not support pretty scrollbars that
my users expect and does not support freedesktop.org style clipboard
behavior (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588785)
unless I tell them to start xclipboard separately and then tell them to
add some X resources...

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

Re: [Discuss-gnuradio] grc hardcoded to use xterm as a terminal emulator?

[Marcus D. Leech]

On 12/09/2011 02:42 PM, Timo Juhani Lindfors wrote:

Hi,

I just noticed that grc/python/Generator.py is hardcoded to use xterm as
a terminal emulator. This is somewhat problematic [1] for me so I'd like
to make it configurable, how would you rather see that done? Would
adding a new option (like "no_gui_terminal_emulator") to the flowchart
be too messy?


Use an environment variable?

There's already a GRC "prefs" support for the Gnu Radio preferences file 
that's

  normally located in:

~/.gnuradio/config.conf

And .../grc/python/Constants.py already extracts a value for 'doc_dir' 
from the Gnu Radio
  preferences file.  That would seem to be a good potential place to do 
that work.





[1] xterm in ubuntu lucid is still sgid=utmp which causes it to drop
LD_LIBRARY_PATH which I need since I've installed gnuradio to a
temporary location. xterm also does not support pretty scrollbars that
my users expect and does not support freedesktop.org style clipboard
behavior (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588785)
unless I tell them to start xclipboard separately and then tell them to
add some X resources...

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





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

[Discuss-gnuradio] underrun occurs when frequency changing

[Yan Nie]

Dear all,

I am trying to transmit a sequence at various frequencies on USRP N200 with 
LFTX. 

When I use the uhd.single_usrp_source.set_center_freq() to change the frequency 
then insert the the sequence as a message in the msgq buffer in another thread 
other than top_block, underrun occurs. The amplitude of the transmitting signal 
on oscilloscope varies some, some of the signal have the full amplitude that I 
set, some of them only reach half amplitude. The following is the thread that I 
open for the sequence transmitting. 

The mgq are created by: 
data=gr.message_source(gr.sizeof_char, msg_limit)  #where msg_limit is defined 
as 2; 
msgq = data.msgq()  

transmit_loop(tb)

    repeat = 40
    payload_13barker = repeat * '\x01'
    payload_13barker += repeat * '\x01'
    payload_13barker += repeat * '\x01'
    payload_13barker += repeat * '\x00'
    payload_13barker += repeat * '\x00'

    stop_sign = 5*repeat*'\x02'
    i = 0
    while(i<5):
  payload_13barker += stop_sign
      i += 1
    
    msg_13bit = gr.message_from_string(payload_13barker)
    tb._ls.msgq.insert_tail(msg_13bit)
    time.sleep(1.0)
    print "info inserted"
    while 1:
  freq_cnt = 4
  while (freq_cnt < 7):
        i += 1
        if i==40: #this counter is used to slow down the rate 
the transmission frequency changes
                        i = 0
            tx_freq = freq_cnt * 10e6
            tb.set_freq_tx(tx_freq,0.0)
            tb._ls.msgq.insert_tail(msg_13bit)
            time.sleep(1.0)    # suspend to wait for the 
payload insert into buffer
            freq_cnt += 1 

I am curious 
1. what causes the underrun and how to avoid the underrun?
2. How to defined the msgq_limit? Is the underrun cause by the wrongly set of 
the msgq_limit, as I already set to let the program to wait for buffering?

Really appreciate any of your suggestion!

Thanks,
Yan

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

Re: [Discuss-gnuradio] Manipulating Waterfall Display

[Tom Rondeau]

On Wed, Dec 7, 2011 at 1:28 PM, Robert Sorbello wrote:

> Hey Everyone,
>
> I am new to GNURadio, and am at the beginning stages of learning
> Python/C++, just to give you a frame of reference.  I am currently
> working on developing a RTI plot from data collected by the USRP2/USRP
> N210.  After working with the GNURadio Companion, I figured easiest
> approach to this task would be to alter the code generating the
> Waterfall Plot.  The only difference would be to replace each fft slice
> with the power of each sample (acquired by the I and Q values).  The
> number of samples in each slice will represent the number of samples in
> one IPP (Inter-Pulse Period) for the particular radar application. Each
> sample can also be represented as a range gate for distance from the
> antenna.  I have been looking through the code generated by GRC, and
> have made very little progress, so I have a few questions.
>
> 1.) Is there any documentation on how the Waterfall Plot is generated? I
> searched through doxygen, but couldn't find anything.
>
> 2.) What would be the best way to alter the waterfall code for plotting
> the power of each sample instead of the fft?
>
> 3.) Can an input be implemented to the python code that can adjust to
> different IPP settings?
>
> Any advice on these issues will be greatly appreciated.
>
> Thank you very much,
> Rob
>
>
Hi Rob,
Are you working with the wxgui waterfall, or the qtgui waterfall plots? If
you don't know the answer to this, you're most likely using wx (it's the
default).

If it's the wx version, I can't help you much. If it's the qt version, I
can hopefully give you some good advice and guidance on it.

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