gmane.comp.gnu.radio.general

Re: graphical sink blocks of grc

Tom Rondeau — 2012-05-25T19:58:22

On Fri, May 25, 2012 at 3:47 PM, Nazmul Islam
<mnislam< at >winlab.rutgers.edu> wrote:

This sounds like you might have some old stuff laying around in your
install directory. This won't hurt you, but might cause some confusion
about things that don't actually exist anymore.

Check out "WX GUI Widgets" or you can change (in the "options" block)
to using qtgui, in which case you'll use the "QT GUI Widgets". The
renaming happened when we put in the ability to use qtgui and didn't
want a name clash.

Tom

graphical sink blocks of grc

Nazmul Islam — 2012-05-25T19:47:42

Hi,

I installed the latest version of gnuradio and gnuradio-companion a few
weeks ago. The "Graphical Sinks" option of my grc has two blocks: Eye
Diagram and Fast AutoCorrelation Sink.

I am following a grc tutorial (
http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial1.pdf). The
authors' grc version had more blocks (scope sink, fft sink, waterfall sink,
etc.). Were these options taken out recently?


Thanks,

Nazmul

Re: Recording I-Q stream with uhd_rx_cfile

Tom Rondeau — 2012-05-25T17:40:10

On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam
<mnislam< at >winlab.rutgers.edu> wrote:


Nazmul,
Hard to say from this info. A few things to note on, though. First,
1000 samples isn't that much. There are startup transients in
hardware, so you might just be seeing effects of those. I'd capture
ten thousand or a million and just read out the last 1000.

Also, the transmitter and receiver are running on two different
clocks, so their frequency and phases aren't going to match, unless
you've locked them to the same source. It'd be hard to say what you'll
see, exactly, due to this. That's why we use recovery loops for all of
these things.

What I would recommend is to create a transmitter that transmits a
long string of 1's followed by a long string of 0's (100 or 200 each).
When you plot the last 1000 samples, you should see something that
moves between two amplitudes. I wouldn't trust what you see from one
run to another, so just do it at the same time.

Tom

Re: Carrier Sensing only in gr_packet_sink?

Tom Rondeau — 2012-05-25T17:32:41

That packet sink block is very old and mostly just an example, now.
It's largely been replaced by frame_sink_1 and
digital_correlate_access_code_bb (note that we will be moving
frame_sink_1 into gr-digital in 3.7; there was some talk about
removing packet_sink altogether).

If you follow the benchmark examples in
gr-digital/examples/narrowband, we actually implement the carrier
sensing in there, prior to the modulation as you say.

Hope this helps.

Tom

Re: Build GR w/o GUI

Michael Dickens — 2012-05-25T16:59:52

-DENABLE_GR_QTGUI=ON/OFF

Re: Build GR w/o GUI

Philip Balister — 2012-05-25T16:51:51

wxwidgets are not on the the e100, so no worries there. You will need to
disable the QT stuff though. I'm not certain what the variable is though.

Philip

Build GR w/o GUI

Nowlan, Sean — 2012-05-25T16:37:10

Is there a one-stop-shop command to disable building GNU Radio without the GUI? I want to save build time on E100 and don't need it.

My best guess is "cmake -DENABLE_GR_WXGUI=False ../", but I don't know if there are other dependencies or GUI components that also can be explicitly disabled.

Thanks,
Sean
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio< at >gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: Baseband GPS OTA USRP capture that anyonecan share?

Andrew Davis — 2012-05-25T15:35:44

I didn't see that may 9th post. I could get some samples ( USRP with
rubber duck with clear sky, would that work? ).

Does anyone know how to feed RTKNAVI? What format does the file need to be?

On Fri, May 25, 2012 at 12:06 AM, Chris Beaumont <chris< at >cmsai.com> wrote:

Re: Adding block to an existing module

Martin Braun — 2012-05-25T13:05:38

Using gr-modtool would be the easiest way.
(https://www.cgran.org/wiki/devtools). 

And it's not *that* hard to find.

MB

Adding block to an existing module

Piotr Palka — 2012-05-25T11:48:55

Dear gnuradio list,

I have built a new module using the create-gnuradio-out-of-tree-project command. Now I would like to add new blocks to this module. Writing new .h, .cc and swig-files is not a problem, but obviously I have to adapt some Makefiles etc.

I thought, it would be a good idea to take a look at the howto-write-a-block structure and modify existing Makefiles. But I am not familiar with these things and hope there is an easier way.

Could someone please tell me, what is the best way to add a signal processing block to an existing module? At the moment I am only able to create a new block creating a new module at the same time, which doesn't make much sense. I have searched the web a lot, maybe it is too trivial to find any useful information...

I am currently running Ubuntu 10.04 with gnuradio 3.5.2.1.

Thanks in advance
Piotr

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio< at >gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Carrier Sensing only in gr_packet_sink?

Marius — 2012-05-25T08:32:34

Hi!

I have a short question: in my implementation of a state machine to
implement a parser for a MAC sublayer standard (802.15.4) I used a
Sync-Block. Now I found out that carrier_sense() is only in
gr_packet_sink class. Does this make sense at all? Normally I'd apply
some Carrier Sensing right before modulation, mostly to avoid blocks
wasting performance on iterating over noise. I'm aware that a Squelch
Filter might archive a similar effect, but that still means the other
Signal Block go into general_work() routines.
So, why is carrier_sense() not in gr_sync_block etc.?

Best,
Marius

Re: Baseband GPS OTA USRP capture that anyone can share?

Chris Beaumont — 2012-05-25T04:06:32

Hello,

A while ago (May 9) there was a post to the list about raw GPS data as 
captured by a USRP.

These web pages may or may not be useful, I don't know if the data files 
on the first one are the right format for you (they were not captured by 
a USRP) but they may still be helpful.

http://michelebavaro.blogspot.com/2012/04/spring-news-in-gnss-and-sdr-domain.html

If not, Michele might be able to help point you to where you could find 
data that is.

Also, you should check out this web page:

http://gpspp.sakura.ne.jp/indexe.html

Tomoji Takasu has done quite a bit of amazing stuff with GPS including 
SDR development. (you may have to dig a bit for it but its there)

Between one or the other you should be able to find what you are looking 
for.

On Mon, 2011-05-09 at 10:27 -0500, John Andrews wrote:
 > Hi,
 >
 > Is there is anyone here who has GPS OTA capture using USRP that they
 > are willing to share? I don't have a USRP and I am interested in
 > demodulating the GPS signal.

Re: Persistence causes glAccum exception

Tom Rondeau — 2012-05-25T03:01:32

Yeah, that's why I said "fade away." It'd be a pretty long deprecation
process, I think, on this one.

Tom

Re: Persistence causes glAccum exception

Marcus D. Leech — 2012-05-25T02:51:11

The only heartburn it gives me is thinking about all those flow-graphs 
out there that use wxGUI. [And more important personally, all
   the flow-graphs *I* have that use wxGUI].

Re: Persistence causes glAccum exception

Tom Rondeau — 2012-05-25T02:48:08

I'm really hoping that we can get the qtgui working nicely for
everyone soon and that we can replace all functionality of the wxgui
with it.  And then, yes, I won't shed any tears to let wxgui fade
away.

Tom

Re: Persistence causes glAccum exception

Jared Boone — 2012-05-25T02:45:52


I achieved a similar effect in the ubertooth-specan-ui Python app, built on top of Qt's newer PySide Python library. Perhaps it'll be a useful reference for reimplementation in Qt without relying on OpenGL.

The general technique is to draw the graph into an off-screen image. During each frame update, black is drawn over the existing image, with a small alpha value, which effectively fades the prior image. The new graph is rendered over the top at alpha = 1.0, then the image is copied to the screen. It seems to perform quite well. I presume most video drivers can push the pixels-with-alpha BLTing into the hardware.

http://ubertooth.svn.sourceforge.net/viewvc/ubertooth/trunk/host/specan_ui/ubertooth-specan-ui?view=markup

The meat of this technique is in RenderArea._draw_graph(). I imagine the code would map directly to the C++ Qt API.

I hear the author of Kismet has done something similar in his software, but I don't know what graphics API he built it on.

- Jared

Re: Persistence causes glAccum exception

Marcus D. Leech — 2012-05-25T02:18:07

I couldn't get the VESA/MESA stuff working the other night, so went back 
to fglrx, which is what the Fedora installer chose for my machine.

I keep my update rates quite modest, and I can support multiple wxGUI 
FFT sinks on the same machine.  I'm running two different applications
   24 x 7 that have both Waterfall and FFT sinks, and my machine is only 
lightly loaded.  But I keep the update rates down to 5Hz or so.

Well, the qtGUI stuff is being worked on at the moment, and it should 
have much better performance, and provided it can give a similar
   amount of user-friendly stuff, perhaps at some point, we let the 
wxGUI stuff die.  Unless some brave soul wants to seriously work it over
   and make it a better performer, and eradicate the openGL edge cases 
that it keeps tripping over.

Re: Persistence causes glAccum exception

Andrew Davis — 2012-05-25T02:06:57

Other then the Mesa software only stack it does not work on any Intel
or ATI driver provided stack, but nVidia blob driver DOES support it.
WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often
get locked up i7's so this is a problem ), wxfft realy needs a c++
re-write if anything.

On Thu, May 24, 2012 at 9:44 PM, Marcus D. Leech <mleech< at >ripnet.com> wrote:

Persistence causes glAccum exception

Marcus D. Leech — 2012-05-25T01:44:29

So, I did a quick "audit" this evening of four different machines in my 
house, running both Ubuntu recent and Fedora recent, but with
   different generations of video hardware/motherboards, and tried the 
"Persistence" control on all of them.

EVERY SINGLE ONE OF THEM failed, provoking an OpenGL exception from 
glAccum, which, it turns out, is an optional feature, and at least in
   this little survey, not a single piece of my hardware supported that op.

How many people actually use "persistence"?  (As opposed, I must be 
clear, to "Peak Hold").  I suspect that a workable approach is to,
   for now, remove that feature entirely, but I don't have a good feel 
for who uses it.

Near as I can tell, the "persistence" feature is intended to give a kind 
of storage-scope effect, or high-persistence phosphor effect.
   But the "effect" uses a non-mandatory OpenGL feature (the accumulator 
buffer) which appears, at least on the garden-variety
   video hardware I use, not to be supported.  And to be clear, I'm 
ru

Recording I-Q stream with uhd_rx_cfile

Nazmul Islam — 2012-05-24T23:07:56

Hello,

I want to transmit a continuous stream of 1's or 0's (with bpsk modulation)
and record the received I-Q stream. I am trying to use the
'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code
(gr-uhd/apps) for reception. Thereafter, I use the read_complex_binary code
to read the data in Matlab.

Surprisingly, I am receiving similar type of I-Q stream (around 0.3 + j
0.3) for both 1 and 0 transmission. I am using the following commands:

self._bits = gr.vector_source_b([1,], True)                       (I either
transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I replace
'1' by '0' in the command)

./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1
--non-differential    (I am using non-differential since I want to see the
different amplitude levels for '1's or 0's)

./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat   (Since I am using
bpsk, sample-rate should be equal to bit rate, I assume)

Ideally, the I-Q stream of bpsk should show 180 degree phase shift for

Re: How can I transmit and receive bit level data using the benchmark codes of gnuradio?

Alex Zhang — 2012-05-24T20:29:12

I think Matlab can handle this, depending your PC memory ....You need to
write some Matlab code to read the file which may contain the complex
samples (gr-complex).

On Thu, May 24, 2012 at 3:18 PM, Nazmul Islam <mnislam< at >winlab.rutgers.edu>wrote:


Maybe you can add some control to start and stop the data recording, in
your python code.


 I never tried it yet.  Why not just try to compose these bits to bytes and
then feed to the physical layer? And why do you need to do that?