Re: [Discuss-gnuradio] Exception : Could not connect to ControlPort endpoint

[West, Nathan]

This is definitely a case where the application is not nearly as
user-friendly as it could be. gr-ctrlport-monitor takes two arguments: an
address/hostname and a port. A controlport server must already be running
at that host:port, otherwise there's nothing to connect to.

On Thu, Mar 17, 2016 at 1:50 PM, raf raf  wrote:

> Hello all,
>
> I am trying to run gr-ctrlport-monitor.
>
> I get this error when I lunch a command gr-ctrlport-monitor
>
> ~/.gnuradio$ gr-ctrlport-monitor
> Could not connect to ControlPort endpoint at None:9090.
>
> Exception socket.error: (32, 'Broken pipe') in  ThriftRadioClient.__del__ of
>  0x7f43f4a8cb48>> ignored
>
>
> Can you help me please to fix this error
>
> ___
> 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] (no subject)

[Henry Barton]

Yeah, in my haste I mistakenly clicked on the mailing list which has the same 
icon as another of my contacts.






Sent from Windows Mail





From: Martin Braun
Sent: ‎Thursday‎, ‎March‎ ‎17‎, ‎2016 ‎10‎:‎20‎ ‎PM
To: Henry Barton
Cc: discuss-gnuradio@gnu.org





Congrats! 

... Although this was probably meant for someone else. 

M

On 17 Mar 2016 16:19, "Henry Barton"  wrote:




I studied enough for ch 1-2 and was able to get 100, 87, 100, and 95 on the 4 
assignments.

___
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] diminishing returns with increasing frequency offset

[Martin Braun]

What's your sampling rate? The further you go towards the edge of your
Nyquist zone, the more the anti-aliasing filter might be kicking in.

Cheers,
Martin

On 03/17/2016 10:23 AM, tom x wrote:
> Hi,
> 
> My setup is a USRP N210 receiving from a transmitter sending a few
> packets a second. (The packets are decoded with Bloessl's 802.15.4 PHY
> block if it matters)
> 
> Let's say the transmitter is sending data on frequency f_t.
> 
> I set the USRP to receive on f_t plus an offset f_o.
> The next block is a frequency xlating FIR filter centered at -f_o.
> This is intended to correct the offset.
> 
> I made a slider block for f_o and allowed it to vary between 0 and 3MHz.
> I need an offset of a few MHz for my application. However, the number of
> packets received seems to drops as I increase f_o. I get almost no
> packets after f_o is increased over 0.5MHz.
> 
> The overall purpose of this is to carve two channels out of the received
> bandwidth with two frequency xlating FIR filter blocks, with the USRP
> tuned between the channels and the filter blocks centered at offsets
> that put them on the channel peaks. As explained above, if the offset is
> too big, it stops working. Why do you think this is happening?
> 
> Thanks,
> Tom
> 
> 
> ___
> 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] How to create a python block

[Dennis Glatting]

On Thu, 2016-03-17 at 11:41 -0700, Martin Braun wrote:
> Current GRC on master allows you to type Python code directly into
> the
> flow graph to be executed as a block. Simply insert a 'Python block'.
> 

This is a great help. Thank you.




> M
> 
> On 03/16/2016 02:34 PM, Dennis Glatting wrote:
> > 
> > On Wed, 2016-03-16 at 16:58 -0400, James Humphries wrote:
> > > 
> > > Hi Dennis,
> > > 
> > > Have you seen these:
> > > 
> > > https://gnuradio.org/doc/doxygen/page_python_blocks.html
> > > 
> > > and
> > > 
> > > http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutoria
> > > l_GN
> > > U_Radio_in_Python
> > > 
> > > They have some good info on how to setup your Python block.
> > > 
> > This is where I am confused, not being a Python hack. I didn't want
> > to
> > create the graph by connecting things together in a python script,
> > such
> > as:
> > 
> > src = blocks.vector_source_f (src_data)
> > mult = multiply_py_ff (2)
> > snk = blocks.vector_sink_f ()self.tb.connect (src, mult)
> > self.tb.connect (mult, snk)
> > 
> > Rather I wanted the python block to be part of the GUI run graph.
> > Specifically, my graph looks like this:
> > 
> > 
> > Rx -> Demod C++ --> MITM ---> Mod C++ -> Tx
> > ^   ^   ^  ^^^
> > > 
> > >   |   |  |||
> > |   |  |||
> > Controls|  |||
> > |  |||
> > Fixed extensions|  |||
> > Python extensions -|||
> > ||
> > Controls ---||
> > 
> > My thinking is within the properties field of a block a person
> > could
> > type some python code where the block imports the code and runs it.
> > Sounds like that isn't the workable approach? (The MITM block has
> > canned messages and fixed manipulations based on GUI controls,
> > which is
> > fairly limiting as a penetration test tool.)
> > 
> > When I looked at some examples I saw either C++ blocks or Python
> > blocks
> > but the python code created the whole graph itself.
> > 
> > I think what you are telling me (and looking through the web pages)
> > is
> > I could have an ugly, fixed C++ MITM block /and/ a separate python
> > block (i.e., two MITM blocks) with the python block part of the
> > build,
> > or both could be incorporated into the python block for a better
> > design. Yes?
> > 
> > Sorry, I'm not a python hack so it isn't evident to me.
> > 
> > TIA.
> > 
> > 
> > > 
> > > -Trip
> > > 
> > > On Wed, Mar 16, 2016 at 4:51 PM, Dennis Glatting  > > om>
> > > wrote:
> > > > 
> > > > This is probably a dumb question but someone has to ask them...
> > > > 
> > > > 
> > > > I have a run graph with c++ blocks: a receiver block, a
> > > > transmitter
> > > > block, and a manipulator block. I want to have the manipulator
> > > > block
> > > > editable from the run graph where the user can insert python
> > > > code.
> > > > Specifically:
> > > > 
> > > > 1) The block has two message ports: an "in" port and an "out"
> > > > port.
> > > > 
> > > > 2) A user can write and type python code into the block to
> > > > manipulate
> > > > the message received on the input port and post the manipulated
> > > > message
> > > > on the output port.
> > > > 
> > > > 3) The python code may have to call other functions, such as
> > > > updating a
> > > > hash code.
> > > > 
> > > > How might I do that? I could do a c++ wrap around exec() but I
> > > > believe
> > > > there has to be an easier way since GNURadio is a combination
> > > > of
> > > > python
> > > > and c++.
> > > > 
> > > > The incoming messages arrive at a low frequency and a low data
> > > > rate
> > > > so
> > > > I'm not really concerned about processing time.
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > ___
> > > > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[madengr]

You are not in the same boat, by far.  I'm an EE RF/MW hardware guy with zero
formal software training (other than a FORTRAN undergrad course requirement;
if that hints to my age).  SDR is a rather new field that requires a LOT of
cross discipline; it's software + radio.  I have been  messing with GR for a
few years, and have halted until I teach myself C++, which I'm 1/2 way
through my book.  I have done some fun stuff with GRC and Python, but need
C++ to go further.

For DSP I would suggest Richard Lyons book.  That will cover sampling,
filtering, etc..  Really good book.

For digital comms try Benard Sklar's book.  That will tell you why you want
an RRC filter.  Grad school level book, but it's all in there.

Really just have to buckle down and hit the books  I'm having to do it with
the software side.

Lou



Desmond Crozby wrote
> 
> Hope anyone has the nerves, time and courtesy to write back. I'm certain
> it
> will serve as a nice starting point to future enthusiasts.
> 
> Best,
> Desmond
> 
> ___
> Discuss-gnuradio mailing list

> Discuss-gnuradio@

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/dive-into-gnu-radio-tp58828p58838.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] dive into gnu-radio

[Kevin McQuiggin]

Hi Martijn:

Two cents from me, a relative non-technical newbie, also a long-time amateur 
radio operator.  My educational and professional background is in computing 
science and a bit of math.

I first found gnuradio a few years ago, and had a similar experience to yours.  
I played around with it, did some of the tutorials, but quickly got slain by my 
lack of technical DSP background, and (back then especially) the lack of clear 
documentation on the blocks.

I got discouraged and removed my gnuradio installation.

However, I knew that I wanted to know more, and understand gnuradio better, as 
the power of the package was obvious to me.  I saw this as a learning 
challenge.  I embarked on what ended up being about 1.5 years of reading and 
coding, outside of gnuradio.  

I found a fantastic couple of books, most notably the free "Digital Signal 
Processing: A Guide for Scientists and Engineers".  See http://dspguide.com.  I 
eventually bought a hardcopy of the book.

I used the book to code up some self-learning programs, for example a DTMF 
decoder, and got my head around a lot of the DSP concepts.  More reading 
augmented this, and I returned to gnuradio about a year ago with a $20 RTL 
dongle in hand.

The tutorials now made more sense, and while I was still on a steep learning 
hill, things went well.  I upgraded my hardware to an Ettus B200, and now feel 
a bit on top of things.  Stick with the cheap dongle for awhile.  I initially 
upgraded to the B200 as I wanted to build a transmitter.  However the RX is WAY 
better on the Ettus unit too, it was a fantastic jump and good investment.

If you have time and no particular deadline, I'd recommend this approach.

As for projects, I've built an FM RDS receiver and decoder, an FM SCA receiver, 
an SCA transmitter,  Multi-channel HF CW decoder (via an up converter), and am 
currently working on a clear channel Inmarsat decoder - this one is about half 
done.  My approach is to use gnuradio for the demodulator, then pipe the 
bitstream to a C program over a gnuradio TCP or UDP sink.  The RDS code, for 
example, is almost 1000 lines of C, so these things are not intrinsically 
"easy".  Incredible learning value and sense of satisfaction though when your 
code/flowgraph actually works!

Things like the need for an RRC filter become clear with reading, review of 
(say) RDS specs, and head scratching over a couple of weeks.  Read about 
"matched filters" and you'll understand what the RRC block does.

My recommendation is to recognize that this is a non-trivial field and big 
learning opportunity, and grab a couple of books like the (free) one by Smith 
above.  Read for awhile, then see where you're at.

It does grow on you with research, but I also have to say that my knowledge is 
"stone knives and bear skins" to quote a popular Vulcan, compared to the level 
of knowledge of most of the folks on this list.

Hope these comments help in some way!

73,

Kevin
(VE7ZD)

Sent from my iPad

> On Mar 16, 2016, at 2:10 PM, Martin Braun  wrote:
> 
>> On 03/16/2016 01:33 PM, Martijn Moeling wrote:
>> I feel there is a gap between the knowledge of the experts and the
>> information for newcomers. My questions have been answered pretty
>> quickly but the answers raise even more questions and confuse me.
> 
> This is a common concern, but it's really, really hard for us as a
> community to address comprehensively. There's multiple reasons for that,
> but it all comes down to the fact that writing good tutorials is hard.
> 
> Many of us core GNU Radio members have a DSP/Wireless background and
> then moved into GNU Radio. For people like us, you need completely
> different tutorials than for someone who's not familiar with DSP.
> 
> Now, there's lots of very good books out there that go into DSP and
> wireless communication. They're usually written to address
> university-level students. But how do we condense them into nice and
> easy tutorials? It's hard.
> It gets exacerbated by the fact that writing tutorials becomes harder
> the more familiar you get with a topic. You lose sight of what's hard,
> and what's not. Unless you're a professional tutorial writer, of course
> -- but we have very few of those.
> 
>>> What I need is: 
>>> 1) understand the blocks, their purpose and what they do
>>> 2) learn how to create a minimal scenario using grc
>>> 3) learn how to create blocks of my own
>>> 4) create more complicated scenario.
>>> 
>>> I wanted to ask the same question in stackoverflow, as I have seen
>>> people from the community hanging around there. But, the amount of
>>> shitstorm coming from there is amazing when asking about learning
>>> pointers... They mark the Q as "opinion-based" immediately.
> 
> SO can be tough like that. Also, 'gnuradio' tagged questions don't
> usually get a lot of attention. I'd be happy to see more action on SO,
> but we never really got there.
> 
> Back to your list, 3) is comprehensively covered by the guided

[Discuss-gnuradio] Measuring execution time of functions within block returns strange results.

[Gonzalo Arcos]

Ive been trying to determine which functions and/or code sections are the
more computationally consuming within a work() function of a block.

For doing this in ubuntu, which is my OS, almost all the references i found
recommend to use clock_t clock() found in time.h. This function does not
work with seconds, but with clock ticks, however, it is easy to get the
corresponding time in seconds by using the CLOCKS_PER_SEC constant. So
basically i get the value of clock() before executing a section of code,
save it, then get the value after the section is executed, calculate the
difference, and normalize by clocks_per_Sec.

So far so good, now the problem i am experiencing is that when i manage to
optimize a section of code, so its execution time decreases, other
section's execution time start to increase, and both sections are
independent from each other. This does not make any sense, since i am not
measuring the percentage consumed by each section, but the absolute time of
execution, and if the sections are independent it should not change.

For example, the exact scenario i have is:

clockA = clock();
{
 ..
//Section A
..
}
clockAEnd = clock();
calculatetime(clockA, clockAEnd);



clockB = clock();
{
 ..
//Section B
..
}
clockBEnd = clock();
calculatetime(clockB, clockBEnd);



By optimizing section B, for some reason section A supposedly starts
consuming more execution time, even though it ALWAYS execute before, so
changes in B cannot have any effects whatsoever in A, and also, the
function is run exactly the same number of times when comparing the cases
with optimization to b, and without optimization to b.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] (no subject)

[Henry Barton]

I studied enough for ch 1-2 and was able to get 100, 87, 100, and 95 on the 4 
assignments.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM Training Sequence

[Martin Braun]

Mateusz,

the sync words are both for the Schmidl & Cox synchronization. Also,
they're defined in the frequency domain, so you won't see the 'two
identical parts here'. Rather, you skip every 2nd carrier.

Cheers,
Martin

On 03/17/2016 04:47 AM, Mateusz wrote:
> Hey, I do my Bachelor Thesis on OFDM using GnuRadio.
> 
> I am using the joint system created from tx_ofdm and rx_ofdm examples.
> In simulation I try to use a bigger fft. So far I have managed to send
> and receive for fft_len=128 and fft_len=256, BPSK modulation. I ask to
> help me understand the creation of sync_words for bigger fft.
> 
> I see the influence of the training sequences which I use on the quality
> of transmission. Of course I have read that the synchronization is based
> on "PN Sequence Correlation" and "Maximal Likelihood" papers. I suppose
> that sync_word1 and sync_word2 are based on those algorithms
> respectively. However I don't see "two identical parts of PN sequence"
> like it was described in the Schmidl paper.
> 
> I tried to use the sequences containing 0's where needed, and random
> -1's and 1's elsewhere, but then the timing synchronization error
> (missing trigger signal in sync_sc) occurs more often, than when I use
> the replicas of original sync_words from the OFDM example.
> 
> I attach the file with the training sequences which I have used.
> 
> Regards,
> Mateusz Loch
> 
> 
> ___
> 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] diminishing returns with increasing frequency offset

[tom x]

Hi,

My setup is a USRP N210 receiving from a transmitter sending a few packets
a second. (The packets are decoded with Bloessl's 802.15.4 PHY block if it
matters)

Let's say the transmitter is sending data on frequency f_t.

I set the USRP to receive on f_t plus an offset f_o.
The next block is a frequency xlating FIR filter centered at -f_o.
This is intended to correct the offset.

I made a slider block for f_o and allowed it to vary between 0 and 3MHz. I
need an offset of a few MHz for my application. However, the number of
packets received seems to drops as I increase f_o. I get almost no packets
after f_o is increased over 0.5MHz.

The overall purpose of this is to carve two channels out of the received
bandwidth with two frequency xlating FIR filter blocks, with the USRP tuned
between the channels and the filter blocks centered at offsets that put
them on the channel peaks. As explained above, if the offset is too big, it
stops working. Why do you think this is happening?

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

Re: [Discuss-gnuradio] Data Formatting in GNURadio (WiFi)

[Martin Braun]

Depends on your choice of types. Are you using floating point complex
values, or fixed-point?

M

On 03/16/2016 05:07 PM, Abhinav Jadon wrote:
> Hi,
> I wrote a matlab scripts that generates the wifi packets for a given
> payload.
> The output is of the format 
> I dumped the output in a bin file.
> It is my understanding that the complex type file source reads the input
> (bin) file in a gr_complex data type format ie reading 32 bits from the
> bin file at a time and then converting the first 16bits (corresponding
> to real part/I) and last 16bits (corresponding to img part/Q) to float16
> format and thus with this understanding, I formatted the data
> accordingly while dumping the data into the bin file.
> The issue is I plug that file source on repeat mode to the UHD block.
> The packet is not detected on the receiver side.Is there something wrong
> with my understanding of data formatting ?
> 
> Regards
> 
> 
> ___
> 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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio

[Martin Braun]

To disable gnuradio's forcebuild from the command line, run:

$ pybombs config --package gnuradio forcebuild False

This will persistently disable forcebuilding for GNU Radio.

With --config, you can only change the global config settings (i.e. the
ones in the config: section in your config.yml files). Example:

$ pybombs --config makewidth=8 install gnuradio

This is *non-persistent* and will override any config.yml setting for
the duration of the process.
To see what the options are that you can change with --config, simply run

$ pybombs config

without any other parameters. They include help texts, too.

Note the first command includes the --package switch. If you leave it
out and just call config  , it'll set a global config
option, like --config (but persistent).

M




On 03/17/2016 02:09 PM, Piotr Krysik wrote:
> Hi all,
> 
> How to use "--config" option of pybombs 2. Can someone show an working
> example?
> 
> In pybombs 2 "forcebuild" is set to true for gnuradio by default.
> How to disable "focebuild" for gnuradio from commandline with the
> pybombs command?
> 
> Best Regards,
> Piotr Krysik
> 
> ___
> 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] RX channel 1 out of range for configured RX frontends

[Martin Braun]

You *can* have 2 rx channels in an N210 (by means of dual DDC chains),
but you probably haven't set the subdev spec appropriately (Something
like 'A:0 A:0', depending on your daughterboard, check the UHD manual).

Cheers,
Martin

On 03/18/2016 08:53 AM, Nikos Balkanas wrote:
> Hi,
> 
> You can have only 1 RX and 1 TX channel in a N210. You are asking for 2
> RX channels in your flow. Runtime complains that he can access only 1
> channel (Rx0).
> 
> HTH,
> Nikos​
> 
> On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M  > wrote:
> 
> Hi All,
> I am using GNU Radio Companion 3.7.5 and USRP N210.
> When I implemented a simple flow graph of SIMO system with two
> channels using USRP source block ( attached grc flow graph snapshot
> for reference),
> I am getting following error:
> 
> Traceback (most recent call last):
>   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
> tb = ONE_TWO()
>   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
> channels=range(2),
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1740, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out
> of range for configured RX frontends
> 
> Can anyone help me to fix this error?
> Thanks in advance
> 
> Regards,
> Suganya.M
> 
> 
> ___
> 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

Re: [Discuss-gnuradio] Massive underruns when transmitting with gr-ieee802-11 on an B210 USRP

[Marcus D. Leech]

On 03/17/2016 02:13 PM, Gonzalo Arcos wrote:

-- Detected Device: B210
-- Operating over USB 2.


UHD Warning:
The total sum of rates (20.00 MSps on 1 channels) exceeds the 
maximum capacity of the connection.

This can cause underruns (U).

I refer you to the above messages^^

Your B210 is connected via USB, which cannot sustain the required data rate.



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

Re: [Discuss-gnuradio] gr-ettus AttributeError

[Zhihong Luo]

Nikos,

Thank you for the reply! I did include the device3, and the problem turned
out to be not installing gr-ettus correctly. I did not close the GRC when
installing it, which I think may cause the prblem. After reinstalling it,
it is ok now :)

Zhihong

2016年3月18日星期五，Nikos Balkanas  写道：

> Hi Zhihong,
>
> You are probably an RFNOC newbie like me:(
> There is a D"Device 3" block under refnoc. You need to include that in
> every rfnoc flow. It has no connections.
>
> HTH,
> Nikos
>
> On Fri, Mar 18, 2016 at 2:50 AM, Zhihong Luo  > wrote:
>
>> To provide more information, all I did was: 1, switching UHD to RFNoC
>> branch, cmake, make, make install 2, pulling down the gr-ettus (I have an
>> old gnuradio installed), then cmake,make, make install.
>>
>> I think I might miss some steps, please help point it out :)
>>
>> On Thu, Mar 17, 2016 at 8:32 PM, Zhihong Luo > > wrote:
>>
>>> Hi all,
>>>
>>> I installed the gr-ettus modules and RFNoC version of UHD (
>>> UHD_003.010.rfnoc-316-gb7546712), but when I tried to run the sample GRC,
>>> it runs into this error:
>>>
>>> AttributeError: 'module' object has no attribute 'device3'
>>>
>>> Can someone point out where I may make a mistake? Thanks in advance!
>>>
>>> Zhihong
>>>
>>
>>
>> ___
>> 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] RX channel 1 out of range for configured RX frontends

[Nikos Balkanas]

I stand corrected. Didn't even know that N210s took daugterboards :(​

Nikos

On Fri, Mar 18, 2016 at 6:39 PM, Martin Braun 
wrote:

> You *can* have 2 rx channels in an N210 (by means of dual DDC chains),
> but you probably haven't set the subdev spec appropriately (Something
> like 'A:0 A:0', depending on your daughterboard, check the UHD manual).
>
> Cheers,
> Martin
>
> On 03/18/2016 08:53 AM, Nikos Balkanas wrote:
> > Hi,
> >
> > You can have only 1 RX and 1 TX channel in a N210. You are asking for 2
> > RX channels in your flow. Runtime complains that he can access only 1
> > channel (Rx0).
> >
> > HTH,
> > Nikos​
> >
> > On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M  > > wrote:
> >
> > Hi All,
> > I am using GNU Radio Companion 3.7.5 and USRP N210.
> > When I implemented a simple flow graph of SIMO system with two
> > channels using USRP source block ( attached grc flow graph snapshot
> > for reference),
> > I am getting following error:
> >
> > Traceback (most recent call last):
> >   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
> > tb = ONE_TWO()
> >   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
> > channels=range(2),
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> > line 122, in constructor_interceptor
> > return old_constructor(*args)
> >   File
> > "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line 1740, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out
> > of range for configured RX frontends
> >
> > Can anyone help me to fix this error?
> > Thanks in advance
> >
> > Regards,
> > Suganya.M
> >
> >
> > ___
> > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Nikos Balkanas]

IQ files are binary files with the raw stream and no headers. Depending on
sample resolution, these are complex pairs of either floats or bytes.
Conversion of bytes to floats is given by the code:

float f;
byte b;

f = (b - 127)/128;

HTH
Nikos




On Wed, Mar 16, 2016 at 4:04 PM, Henry Barton  wrote:

> This sounds interesting; I too have been wondering how IQ files worked. I
> thought it must be alternating I bytes and Q bytes, or with >8-bit radios,
> I words and Q words. But maybe the packed byte system is right, since I can
> feed IQ recordings in WAV format directly into GNUradio without stripping
> the headers.
>
>
> > To: ra...@schmid.xxx; discuss-gnuradio@gnu.org
> > From: marcus.muel...@ettus.com
> > Date: Wed, 16 Mar 2016 10:24:02 +0100
> > Subject: Re: [Discuss-gnuradio] lack of understanding the different
> formats to store samples
> >
> > Ok, let "I" and "Q" be single bits each, so each byte would then be
> >
> > IQIQIQIQ
> >
> > if I had to take a guess.
> >
> > You can get get back something that GR commonly deals with by doing
> >
> > packed to unpacked (type=B, bits per chunk = 1, endianness=your machine)
> > -> IChar to Complex
> >
> > Best regards,
> > Marcus
> > On 16.03.2016 08:13, Ralph A. Schmid, dk5ras wrote:
> > > Each byte seems to contain 4 1 bit I/Q samples. This is the text from
> the
> > > readme:
> > >
> > > "The output file size can be reduced by using "-b 1" option to store
> four
> > > 1-bit I/Q samples into a single byte."
> > >
> > > Ralph.
> > >
> > >> -Original Message-
> > >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> > >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf
> Of
> > >> Marcus Müller
> > >> Sent: Friday, March 11, 2016 2:53 PM
> > >> To: discuss-gnuradio@gnu.org
> > >> Subject: Re: [Discuss-gnuradio] lack of understanding the different
> > > formats
> > >> to store samples
> > >>
> > >> In what format are your 1bit samples? I'd assume they are just the
> fact
> > >> whether a byte is 0x00 or 0x01; in that case, just use unpacked to
> packed.
> > >>
> > >> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
> > >>> Hi,
> > >>>
> > >>> Being an RF guy I must admit that I am somehow lost in the different
> > >>> ways how samples are stored in files. I stumbled over this question
> > >>> when I experimented with https://github.com/osqzss/gps-sdr-sim. It
> > >>> works great when using 16 bit samples and using a simple two-block
> grc
> > >>> file, feeding them directly from a file source to the UHD sink.
> > >>> However the 1 bit variant sounds promising, as the files are much
> > >>> smaller this way and also the generation of them runs much faster.
> > >>>
> > >>> It must only be a matter of finding the right blocks and the right
> > >>> settings to convert this, but my google search was highly confusing,
> > >>> most probably due to different names for the same thing.
> > >>>
> > >>> So I do not only ask for how to use "four 1-bit I/Q samples into a
> > >>> single byte" (taken from the readme of the gps-sdr-sim), but for a
> > >>> more general overview how this stuff is done, to be prepared for
> other
> > >>> upcoming questions of this kind :) Up to now I solved those issues by
> > >>> an educated guess or even by try and error, what is not very
> > > satisfying...
> > >>> Ralph.
> > >>>
> > >>>
> > >>> ___
> > >>> 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 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] Two Daughterboards

[olvhammar]

Ok thanks!

Thought the channels referred to the TX/RX and RX2 on one daughterboard 
and not daughterboard_0 and daughterboard_1. It's interesting that up to 
32 channels can be selected considering the limitation for 2 
daughterboards, what am I missing?


Best regards
Simon

On 2016-03-16 22:10, Martin Braun wrote:

Simply drop down a USRP source with 2 channels.

Cheers,
Martin

On 03/16/2016 02:08 PM, olvhammar wrote:

Hi,

I would like to receive samples from two different daughterboards on the
same device (Ettus x310) using one GNURadio flowgraph. What is the
easiest way to accomplish this? Any examples?

Best regards
Simon

___
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] How to create a python block

[Dennis Glatting]

This is probably a dumb question but someone has to ask them...


I have a run graph with c++ blocks: a receiver block, a transmitter
block, and a manipulator block. I want to have the manipulator block
editable from the run graph where the user can insert python code.
Specifically:

1) The block has two message ports: an "in" port and an "out" port.

2) A user can write and type python code into the block to manipulate
the message received on the input port and post the manipulated message
on the output port.

3) The python code may have to call other functions, such as updating a
hash code.

How might I do that? I could do a c++ wrap around exec() but I believe
there has to be an easier way since GNURadio is a combination of python
and c++.

The incoming messages arrive at a low frequency and a low data rate so
I'm not really concerned about processing time.




 


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

[Discuss-gnuradio] Exception : Could not connect to ControlPort endpoint

[raf raf]

Hello all, I am trying to run gr-ctrlport-monitor. I get this error when I 
lunch a command gr-ctrlport-monitor ~/.gnuradio$ gr-ctrlport-monitor Could not 
connect to ControlPort endpoint at None:9090.Exception socket.error: (32, 
'Broken pipe') in > ignoredCan you help me please to fix this error
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to create a python block

[Dennis Glatting]

On Wed, 2016-03-16 at 16:58 -0400, James Humphries wrote:
> Hi Dennis,
> 
> Have you seen these:
> 
> https://gnuradio.org/doc/doxygen/page_python_blocks.html
> 
> and
> 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GN
> U_Radio_in_Python
> 
> They have some good info on how to setup your Python block.
> 

This is where I am confused, not being a Python hack. I didn't want to
create the graph by connecting things together in a python script, such
as:

src = blocks.vector_source_f (src_data)
mult = multiply_py_ff (2)
snk = blocks.vector_sink_f ()self.tb.connect (src, mult)
self.tb.connect (mult, snk)

Rather I wanted the python block to be part of the GUI run graph.
Specifically, my graph looks like this:


Rx -> Demod C++ --> MITM ---> Mod C++ -> Tx
^       ^               ^  ^        ^        ^
|       |               |  |        |        |
|               |  |        |        |
Controls                |  |        |        |
                    |  |        |        |
Fixed extensions|  |        |        |
Python extensions -|        |        |
                                |        |
Controls ---||

My thinking is within the properties field of a block a person could
type some python code where the block imports the code and runs it.
Sounds like that isn't the workable approach? (The MITM block has
canned messages and fixed manipulations based on GUI controls, which is
fairly limiting as a penetration test tool.)

When I looked at some examples I saw either C++ blocks or Python blocks
but the python code created the whole graph itself.

I think what you are telling me (and looking through the web pages) is
I could have an ugly, fixed C++ MITM block /and/ a separate python
block (i.e., two MITM blocks) with the python block part of the build,
or both could be incorporated into the python block for a better
design. Yes?

Sorry, I'm not a python hack so it isn't evident to me.

TIA.


> -Trip
> 
> On Wed, Mar 16, 2016 at 4:51 PM, Dennis Glatting 
> wrote:
> > This is probably a dumb question but someone has to ask them...
> > 
> > 
> > I have a run graph with c++ blocks: a receiver block, a transmitter
> > block, and a manipulator block. I want to have the manipulator
> > block
> > editable from the run graph where the user can insert python code.
> > Specifically:
> > 
> > 1) The block has two message ports: an "in" port and an "out" port.
> > 
> > 2) A user can write and type python code into the block to
> > manipulate
> > the message received on the input port and post the manipulated
> > message
> > on the output port.
> > 
> > 3) The python code may have to call other functions, such as
> > updating a
> > hash code.
> > 
> > How might I do that? I could do a c++ wrap around exec() but I
> > believe
> > there has to be an easier way since GNURadio is a combination of
> > python
> > and c++.
> > 
> > The incoming messages arrive at a low frequency and a low data rate
> > so
> > I'm not really concerned about processing time.
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > ___
> > 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] OOT- Modules version numbering scheme

[Martin Braun]

This is a really good Q. I don't think modtool imposes/suggests
anything, but that's probably worth changing.

Can you please post a feature request on gnuradio.org? Thanks!

Martin

On 03/13/2016 04:33 AM, Volker Schroer wrote:
> Are there recommendations how OOT- module versions should be numbered ?
> gr_modtool provides no version numbering.
> 
> Should there be a relation to the minimium required gnuradio version ?
> 
> I'curious if GrVersion and GR_LIBRARY_FOO should be used?
> 
> Thanks in advance
> -- Volker
> 
> 
> 
> 
> ___
> 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] GSoC Interest in Project: Offline Analysis and Visualization Tools

[Michael Ossmann]

Just in case anyone isn't yet convinced about the power and usefulness
of inspectrum, check out this short demo video showing features in
development:

https://www.youtube.com/watch?v=9QyGKjt8zkE

Mike

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

Re: [Discuss-gnuradio] how to handle sources with variable bitrate

[Anselm Karl]

Thank you. I will look at it!
Am 17.03.2016 19:03 schrieb "Francisco Albani" :

> Hi Anselm.
>
> Go to http://lists.gnu.org/archive/html/discuss-gnuradio/ and search this
> "Asynchronous source with zeros in between"
>
> You will find an email I wrote to this list asking a similar question. I'm
> not pasting a link here because I couldn't find the starting message; the
> thread is split in many parts (I don't know why). I hope you should be able
> to find all the pieces in the search results. If not, please write to me
> and I will find a way of send it to you.
>
> I think my problem was different that yours and my solution will not be
> fit, but it may give you some ideas. The key was to bring the payload in a
> PDU message and to have a block that manages the "padding" before entering
> to the "stream domain".
>
> Bye!
>
>
> 2016-03-17 5:50 GMT-03:00 Anselm Karl :
>
>> Hi, Nikos,
>>
>> adding a buffer / fifo and matching the mean video rate to the rate of my
>> transmission system should work.
>>
>> But i don't really want to match the rates, because i'll have to do that
>> every time i change something on the source. It can be quite an effort,
>> too. (Like interpolation the base-band signal) Or consider a asynchronous
>> source (something like a serial terminal) with large intervals with no data.
>>
>> With the "zero stuffing solution" you just have to make sure, that the
>> transmission is fast enough for the source, "plug in" the source and
>> everything should be fine.
>>
>> I've done some gnu radio blocks. But i don't now how to tell the work
>> function how many samples the down stream block needs. In my understanding
>> the work functions gets some input samples and calculates some output
>> samples out of them. It's like the block gets actively written to and
>> passively read from. And i would need it the other way.
>>
>> BR,
>> Anselm
>>
>>
>>
>> 2016-03-17 9:17 GMT+01:00 Nikos Balkanas :
>>
>>> Hi,
>>>
>>> Have you tried using a FIFO block in your flow? There a few around and
>>> it seems to me it would normalize your flow.
>>>
>>> BR,
>>> Nikos
>>>
>>> On Thu, Mar 17, 2016 at 10:01 AM, Anselm Karl <
>>> anselmkarl.in...@googlemail.com> wrote:
>>>
 Hi all,

 i want to transmitt a video stream with gnuradio and usrps. There are
 some examples on the web and i got it working with vlc.

 The problem is, that the playback is quite choppey. This is because the
 digital transmission over the usrps has a fixed rate but the encoded video
 has a variable rate. If i set the transmission rate higher than the (mean)
 rate of the video, i get a lot of underruns on the tranmitting usrp (=
 chopped of rf signal). Which is bad because the transmission designed to be
 continous (for example the clockloop, ...).

 The transmission is based on fixed size fec code blocks starting with
 an preambel. A possible solution could be to stuff zeros between two blocks
 while waiting on the (video) source. On the receiver this stuffed zeros
 would be trown away automatically.

 That "zero stuffing" could be realized with a block, that puts out N
 (N= payload size of one block) input samples (first sample marked with a
 tag) at one "piece" or (if it has no N input samples in some internal
 buffer) it puts out zeros). Based on the tag a downstream block could mux
 in the preambel and everything would be fine.

 But here is my question:
 I don´t know how to write a block, that always has output samples
 available. Is there i kind of a non-blocking block template?


 Best regards,

 *Anselm*



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


>>>
>>
>>
>> --
>> Mit freundlichen Grüßen
>>
>> *Anselm Karl*
>>
>>
>>
>> ___
>> 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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio

[Martin Braun]

Yep, but you can always install the latest with pip. From the manual:

If you do want to install the latest version from git, but still use
pip, you
run the following command:

$ [sudo] pip install [--upgrade]
git+https://github.com/gnuradio/pybombs.git


M

On 03/19/2016 12:44 PM, Piotr Krysik wrote:
> The "--package" parameter seems to be added recently as pybombs
> installed with pip doesn't have this option yet.
> 
> Best Regards,
> Piotr
> 
> W dniu 19.03.2016 o 17:59, Piotr Krysik pisze:
>> Thank you Martin!
>>
>>
>> W dniu 18.03.2016 o 18:54, Martin Braun pisze:
>>> To disable gnuradio's forcebuild from the command line, run:
>>>
>>> $ pybombs config --package gnuradio forcebuild False
>>>
>>> This will persistently disable forcebuilding for GNU Radio.
>>>
>>> With --config, you can only change the global config settings (i.e. the
>>> ones in the config: section in your config.yml files). Example:
>>>
>>> $ pybombs --config makewidth=8 install gnuradio
>>>
>>> This is *non-persistent* and will override any config.yml setting for
>>> the duration of the process.
>>> To see what the options are that you can change with --config, simply run
>>>
>>> $ pybombs config
>>>
>>> without any other parameters. They include help texts, too.
>>>
>>> Note the first command includes the --package switch. If you leave it
>>> out and just call config  , it'll set a global config
>>> option, like --config (but persistent).
>>>
>>> M
>>>
>>>
>>>
>>>
>>> On 03/17/2016 02:09 PM, Piotr Krysik wrote:
 Hi all,

 How to use "--config" option of pybombs 2. Can someone show an working
 example?

 In pybombs 2 "forcebuild" is set to true for gnuradio by default.
 How to disable "focebuild" for gnuradio from commandline with the
 pybombs command?

 Best Regards,
 Piotr Krysik

 ___
 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 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] Recorded Bluetooth Samples

[sumitstop]

Does anyone have recorded samples of bluetooth. I was working with
gr-bluetooth. Some of the traces supplied with the package are ending
abruptly without any output. So I was thinking to try with new traces. 

I don't have immediate access to my USRPs. So if anyone have them, please
share. 

TIA

Sumit



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Recorded-Bluetooth-Samples-tp58852.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

[tom x]

Hi,

This previous post by me should give more info:
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00286.html
I've replaced the polyphase channelizer with one Frequency Xlating FIR
filter for each channel.
The first problem (described above) is that centering the filter too far
from the capture frequency means nothing gets through.
To solve this I would like to increase the sample rate but, as mentioned,
the PHY block only output packets with samp_rate = 4MHz.
 I looked inside the 802.15.4 PHY block for some dependence on 4 MHz, and
indeed, the samp_rate block is set to 4 MHz.
None of the other blocks use it though, here is a picture of the RX chain:
http://i.imgur.com/0Ccwnr1.png?1
Maybe there is an implicit dependence on 4MHz, in the parameters set by the
Clock Recovery block? I am not sure.
If there's any other relevant info I can give, let me know.

Thanks,
Tom

On Fri, Mar 18, 2016 at 7:33 PM, Martin Braun 
wrote:

> Tom,
>
> you'll need to tell us more about what you're doing and what you've tried.
>
> Cheers,
> Martin
>
> On 03/17/2016 03:36 PM, tom x wrote:
> > It's strange but the only sampling rate that works is 4 MHz; Packets are
> > not decoded when the sampling rate is set above this rate.
> >
> > Thanks,
> > Tom
> >
> > On Thu, Mar 17, 2016 at 7:33 PM, Martin Braun  > > wrote:
> >
> > What's your sampling rate? The further you go towards the edge of
> your
> > Nyquist zone, the more the anti-aliasing filter might be kicking in.
> >
> > Cheers,
> > Martin
> >
> > On 03/17/2016 10:23 AM, tom x wrote:
> > > Hi,
> > >
> > > My setup is a USRP N210 receiving from a transmitter sending a few
> > > packets a second. (The packets are decoded with Bloessl's 802.15.4
> PHY
> > > block if it matters)
> > >
> > > Let's say the transmitter is sending data on frequency f_t.
> > >
> > > I set the USRP to receive on f_t plus an offset f_o.
> > > The next block is a frequency xlating FIR filter centered at -f_o.
> > > This is intended to correct the offset.
> > >
> > > I made a slider block for f_o and allowed it to vary between 0 and
> > 3MHz.
> > > I need an offset of a few MHz for my application. However, the
> > number of
> > > packets received seems to drops as I increase f_o. I get almost no
> > > packets after f_o is increased over 0.5MHz.
> > >
> > > The overall purpose of this is to carve two channels out of the
> > received
> > > bandwidth with two frequency xlating FIR filter blocks, with the
> USRP
> > > tuned between the channels and the filter blocks centered at
> offsets
> > > that put them on the channel peaks. As explained above, if the
> > offset is
> > > too big, it stops working. Why do you think this is happening?
> > >
> > > Thanks,
> > > Tom
> > >
> > >
> > > ___
> > > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to create a python block

[Martin Braun]

Current GRC on master allows you to type Python code directly into the
flow graph to be executed as a block. Simply insert a 'Python block'.

M

On 03/16/2016 02:34 PM, Dennis Glatting wrote:
> On Wed, 2016-03-16 at 16:58 -0400, James Humphries wrote:
>> Hi Dennis,
>>
>> Have you seen these:
>>
>> https://gnuradio.org/doc/doxygen/page_python_blocks.html
>>
>> and
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GN
>> U_Radio_in_Python
>>
>> They have some good info on how to setup your Python block.
>>
> 
> This is where I am confused, not being a Python hack. I didn't want to
> create the graph by connecting things together in a python script, such
> as:
> 
> src = blocks.vector_source_f (src_data)
> mult = multiply_py_ff (2)
> snk = blocks.vector_sink_f ()self.tb.connect (src, mult)
> self.tb.connect (mult, snk)
> 
> Rather I wanted the python block to be part of the GUI run graph.
> Specifically, my graph looks like this:
> 
> 
> Rx -> Demod C++ --> MITM ---> Mod C++ -> Tx
> ^   ^   ^  ^^^
> |   |   |  |||
> |   |  |||
> Controls|  |||
> |  |||
> Fixed extensions|  |||
> Python extensions -|||
> ||
> Controls ---||
> 
> My thinking is within the properties field of a block a person could
> type some python code where the block imports the code and runs it.
> Sounds like that isn't the workable approach? (The MITM block has
> canned messages and fixed manipulations based on GUI controls, which is
> fairly limiting as a penetration test tool.)
> 
> When I looked at some examples I saw either C++ blocks or Python blocks
> but the python code created the whole graph itself.
> 
> I think what you are telling me (and looking through the web pages) is
> I could have an ugly, fixed C++ MITM block /and/ a separate python
> block (i.e., two MITM blocks) with the python block part of the build,
> or both could be incorporated into the python block for a better
> design. Yes?
> 
> Sorry, I'm not a python hack so it isn't evident to me.
> 
> TIA.
> 
> 
>> -Trip
>>
>> On Wed, Mar 16, 2016 at 4:51 PM, Dennis Glatting 
>> wrote:
>>> This is probably a dumb question but someone has to ask them...
>>>
>>>
>>> I have a run graph with c++ blocks: a receiver block, a transmitter
>>> block, and a manipulator block. I want to have the manipulator
>>> block
>>> editable from the run graph where the user can insert python code.
>>> Specifically:
>>>
>>> 1) The block has two message ports: an "in" port and an "out" port.
>>>
>>> 2) A user can write and type python code into the block to
>>> manipulate
>>> the message received on the input port and post the manipulated
>>> message
>>> on the output port.
>>>
>>> 3) The python code may have to call other functions, such as
>>> updating a
>>> hash code.
>>>
>>> How might I do that? I could do a c++ wrap around exec() but I
>>> believe
>>> there has to be an easier way since GNURadio is a combination of
>>> python
>>> and c++.
>>>
>>> The incoming messages arrive at a low frequency and a low data rate
>>> so
>>> I'm not really concerned about processing time.
>>>
>>>
>>>
>>>
>>>  
>>>
>>>
>>> ___
>>> 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

Re: [Discuss-gnuradio] dive into gnu-radio

[Nikos Balkanas]

Hi Kevin,

Your link is good, but the exact title is "The scientist and engineer's
giude to Digital Signal Processing"
Coming from a similar background, it has been my favorite over the past 6
mos:)

BR,
Nikos

On Fri, Mar 18, 2016 at 5:10 AM, Kevin McQuiggin  wrote:

> Hi Martijn:
>
> Two cents from me, a relative non-technical newbie, also a long-time
> amateur radio operator.  My educational and professional background is in
> computing science and a bit of math.
>
> I first found gnuradio a few years ago, and had a similar experience to
> yours.  I played around with it, did some of the tutorials, but quickly got
> slain by my lack of technical DSP background, and (back then especially)
> the lack of clear documentation on the blocks.
>
> I got discouraged and removed my gnuradio installation.
>
> However, I knew that I wanted to know more, and understand gnuradio
> better, as the power of the package was obvious to me.  I saw this as a
> learning challenge.  I embarked on what ended up being about 1.5 years of
> reading and coding, outside of gnuradio.
>
> I found a fantastic couple of books, most notably the free "Digital Signal
> Processing: A Guide for Scientists and Engineers".  See
> http://dspguide.com.  I eventually bought a hardcopy of the book.
>
> I used the book to code up some self-learning programs, for example a DTMF
> decoder, and got my head around a lot of the DSP concepts.  More reading
> augmented this, and I returned to gnuradio about a year ago with a $20 RTL
> dongle in hand.
>
> The tutorials now made more sense, and while I was still on a steep
> learning hill, things went well.  I upgraded my hardware to an Ettus B200,
> and now feel a bit on top of things.  Stick with the cheap dongle for
> awhile.  I initially upgraded to the B200 as I wanted to build a
> transmitter.  However the RX is WAY better on the Ettus unit too, it was a
> fantastic jump and good investment.
>
> If you have time and no particular deadline, I'd recommend this approach.
>
> As for projects, I've built an FM RDS receiver and decoder, an FM SCA
> receiver, an SCA transmitter,  Multi-channel HF CW decoder (via an up
> converter), and am currently working on a clear channel Inmarsat decoder -
> this one is about half done.  My approach is to use gnuradio for the
> demodulator, then pipe the bitstream to a C program over a gnuradio TCP or
> UDP sink.  The RDS code, for example, is almost 1000 lines of C, so these
> things are not intrinsically "easy".  Incredible learning value and sense
> of satisfaction though when your code/flowgraph actually works!
>
> Things like the need for an RRC filter become clear with reading, review
> of (say) RDS specs, and head scratching over a couple of weeks.  Read about
> "matched filters" and you'll understand what the RRC block does.
>
> My recommendation is to recognize that this is a non-trivial field and big
> learning opportunity, and grab a couple of books like the (free) one by
> Smith above.  Read for awhile, then see where you're at.
>
> It does grow on you with research, but I also have to say that my
> knowledge is "stone knives and bear skins" to quote a popular Vulcan,
> compared to the level of knowledge of most of the folks on this list.
>
> Hope these comments help in some way!
>
> 73,
>
> Kevin
> (VE7ZD)
>
> Sent from my iPad
>
> > On Mar 16, 2016, at 2:10 PM, Martin Braun 
> wrote:
> >
> >> On 03/16/2016 01:33 PM, Martijn Moeling wrote:
> >> I feel there is a gap between the knowledge of the experts and the
> >> information for newcomers. My questions have been answered pretty
> >> quickly but the answers raise even more questions and confuse me.
> >
> > This is a common concern, but it's really, really hard for us as a
> > community to address comprehensively. There's multiple reasons for that,
> > but it all comes down to the fact that writing good tutorials is hard.
> >
> > Many of us core GNU Radio members have a DSP/Wireless background and
> > then moved into GNU Radio. For people like us, you need completely
> > different tutorials than for someone who's not familiar with DSP.
> >
> > Now, there's lots of very good books out there that go into DSP and
> > wireless communication. They're usually written to address
> > university-level students. But how do we condense them into nice and
> > easy tutorials? It's hard.
> > It gets exacerbated by the fact that writing tutorials becomes harder
> > the more familiar you get with a topic. You lose sight of what's hard,
> > and what's not. Unless you're a professional tutorial writer, of course
> > -- but we have very few of those.
> >
> >>> What I need is:
> >>> 1) understand the blocks, their purpose and what they do
> >>> 2) learn how to create a minimal scenario using grc
> >>> 3) learn how to create blocks of my own
> >>> 4) create more complicated scenario.
> >>>
> >>> I wanted to ask the same question in stackoverflow, as I have seen
> >>> people from the 

Re: [Discuss-gnuradio] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio

[Piotr Krysik]

The "--package" parameter seems to be added recently as pybombs
installed with pip doesn't have this option yet.

Best Regards,
Piotr

W dniu 19.03.2016 o 17:59, Piotr Krysik pisze:
> Thank you Martin!
>
>
> W dniu 18.03.2016 o 18:54, Martin Braun pisze:
>> To disable gnuradio's forcebuild from the command line, run:
>>
>> $ pybombs config --package gnuradio forcebuild False
>>
>> This will persistently disable forcebuilding for GNU Radio.
>>
>> With --config, you can only change the global config settings (i.e. the
>> ones in the config: section in your config.yml files). Example:
>>
>> $ pybombs --config makewidth=8 install gnuradio
>>
>> This is *non-persistent* and will override any config.yml setting for
>> the duration of the process.
>> To see what the options are that you can change with --config, simply run
>>
>> $ pybombs config
>>
>> without any other parameters. They include help texts, too.
>>
>> Note the first command includes the --package switch. If you leave it
>> out and just call config  , it'll set a global config
>> option, like --config (but persistent).
>>
>> M
>>
>>
>>
>>
>> On 03/17/2016 02:09 PM, Piotr Krysik wrote:
>>> Hi all,
>>>
>>> How to use "--config" option of pybombs 2. Can someone show an working
>>> example?
>>>
>>> In pybombs 2 "forcebuild" is set to true for gnuradio by default.
>>> How to disable "focebuild" for gnuradio from commandline with the
>>> pybombs command?
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Patrick Sathyanathan]

Sorry, typo "...as Marcus D. Leech points out..."
 
--Patrick
 
From: wp...@hotmail.com
To: rfeng...@me.com; discuss-gnuradio@gnu.org; hup...@gmail.com
Date: Wed, 16 Mar 2016 20:44:23 -0700
Subject: Re: [Discuss-gnuradio] dive into gnu-radio




Hi Desmond,
 
I have a similar CS background combined with a youthful interest in radios from 
the distant past. I initially approached GNUradio with a similar attitude, i.e. 
it's just software, I can figure out what it does. But sadly that is not true, 
and as Martin Leech points out in a different reply on this thread, GNUradio 
combines expertise from many different disciplines and you need some level of 
familiarity with all of them to extract the maximum utility from the package. 
With my knowledge the mechanics of writing an OOT module and getting it to show 
up in GRC is fairly simple. It's the knowledge of radio signals and digital 
signal processing where I have the most difficulty. To address DSP I bought the 
Richard Lyons books and am working my way through it. I strongly recommend that 
book for the harmony between theory and practice in presentation. I am 
simultaneously going through an online course on electrodynamics hoping that 
when I'm done I will have the ability to use GNUradio efficiently in 
interesting ways.
 
--Patrick
 
> Date: Wed, 16 Mar 2016 13:55:55 -0700
> From: rfeng...@me.com
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dive into gnu-radio
> 
> You are not in the same boat, by far.  I'm an EE RF/MW hardware guy with zero
> formal software training (other than a FORTRAN undergrad course requirement;
> if that hints to my age).  SDR is a rather new field that requires a LOT of
> cross discipline; it's software + radio.  I have been  messing with GR for a
> few years, and have halted until I teach myself C++, which I'm 1/2 way
> through my book.  I have done some fun stuff with GRC and Python, but need
> C++ to go further.
> 
> For DSP I would suggest Richard Lyons book.  That will cover sampling,
> filtering, etc..  Really good book.
> 
> For digital comms try Benard Sklar's book.  That will tell you why you want
> an RRC filter.  Grad school level book, but it's all in there.
> 
> Really just have to buckle down and hit the books  I'm having to do it with
> the software side.
> 
> Lou
> 
> 
> 
> Desmond Crozby wrote
> > 
> > Hope anyone has the nerves, time and courtesy to write back. I'm certain
> > it
> > will serve as a nice starting point to future enthusiasts.
> > 
> > Best,
> > Desmond
> > 
> > ___
> > Discuss-gnuradio mailing list
> 
> > Discuss-gnuradio@
> 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/dive-into-gnu-radio-tp58828p58838.html
> Sent from the GnuRadio mailing list archive at Nabble.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 
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RX channel 1 out of range for configured RX frontends

[Nikos Balkanas]

Hi,

You can have only 1 RX and 1 TX channel in a N210. You are asking for 2 RX
channels in your flow. Runtime complains that he can access only 1 channel
(Rx0).

HTH,
Nikos​

On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M  wrote:

> Hi All,
> I am using GNU Radio Companion 3.7.5 and USRP N210.
> When I implemented a simple flow graph of SIMO system with two channels
> using USRP source block ( attached grc flow graph snapshot for reference),
> I am getting following error:
>
> Traceback (most recent call last):
>   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
> tb = ONE_TWO()
>   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
> channels=range(2),
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1740, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
> range for configured RX frontends
>
> Can anyone help me to fix this error?
> Thanks in advance
>
> Regards,
> Suganya.M
>
>
> ___
> 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] OFDM tx rx error

[Jingyi Sun]

Hi,

I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and
receive packets over the air.  Both work over a simulated channel, but when
I actually transmit and receive over the air, I get the error:

*"Detected a packet larger than max frame size (100 symbols)"*

I saw the previous thread on this called "OFDM transmitter receiver" which
goes as follows, but I don't really know what to make of this...

I tried to run *sysctl kernel.shmmax *in terminal, but I got the message
"No such file or directory". I'm also not sure what kernel.shmmax is.

These are my parameters:

fft length= 64

cyclic prefix = 16
packet length = 96
no. of occupied carriers = 53
no. of pilot carriers = 4


I'm very new to gnuradio, and any insights into this would be appreciated!!


Thanks,
Jenny

PS sorry if this is redundant. I didn't get my email through the list so
I'm assuming it didn't go through the first time.
--

*From*:  Martin Braun
*Subject*:  Re: [Discuss-gnuradio] OFDM transmitter receiver
*Date*:  Tue, 26 Aug 2014 11:10:53 +0200
*User-agent*:  Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.6.0
--

Try and not kill the context in a mailing list thread; these are also
archived and are used by others for referral.

Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
there's a problem here. I suggest you have a look at the buffer sizes to
track down this problem.

M

On 08/25/2014 03:31 PM, Martin Braun wrote:
>* What's your kernel.shmmax value? (run sysctl kernel.shmmax)*
>
>* M*
>
>* On 08/25/2014 12:47 PM, sreena p h wrote:*
>*> Hi*
>*> I used the ofdm transmitter receiver blocks to create a simple system as*
>*> shown in the attachment. I used the system parameters as those used in*
>*> the example transmitter and receiver grcs. Now I get error that*
>*> 'Detected a packet larger than max frame size (80 symbols)'. I would*
>*> like to know how the max frame size is set and should I add more*
>*> information to the grc. *
>*>*
>*> My transmitter- receiver parameters*
>*>*
>*> fft length= 64*
>*> cyclic prefix = 16*
>*> packet length = 96*
>*> no. of occupied carriers = 48*
>*> no. of pilot carriers = 4*
>*>*
>*>*
>*>*
>*> ___*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM tx rx error

[Jingyi Sun]

Hi,

I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and
receive packets over the air.  Both work over a simulated channel, but when
I actually transmit and receive over the air, I get the error:

*"Detected a packet larger than max frame size (100 symbols)"*

I saw the previous thread on this called "OFDM transmitter receiver" which
goes as follows, but I don't really know what to make of this...

I tried to run *sysctl kernel.shmmax *in terminal, but I got the message
"No such file or directory". I'm also not sure what kernel.shmmax is.

These are my parameters:

fft length= 64

cyclic prefix = 16
packet length = 96
no. of occupied carriers = 53
no. of pilot carriers = 4


I'm very new to gnuradio, and any insights into this would be appreciated!!


Thanks,
Jenny

--

*From*:  Martin Braun
*Subject*:  Re: [Discuss-gnuradio] OFDM transmitter receiver
*Date*:  Tue, 26 Aug 2014 11:10:53 +0200
*User-agent*:  Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.6.0
--

Try and not kill the context in a mailing list thread; these are also
archived and are used by others for referral.

Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
there's a problem here. I suggest you have a look at the buffer sizes to
track down this problem.

M

On 08/25/2014 03:31 PM, Martin Braun wrote:
>* What's your kernel.shmmax value? (run sysctl kernel.shmmax)*
>
>* M*
>
>* On 08/25/2014 12:47 PM, sreena p h wrote:*
>*> Hi*
>*> I used the ofdm transmitter receiver blocks to create a simple system as*
>*> shown in the attachment. I used the system parameters as those used in*
>*> the example transmitter and receiver grcs. Now I get error that*
>*> 'Detected a packet larger than max frame size (80 symbols)'. I would*
>*> like to know how the max frame size is set and should I add more*
>*> information to the grc. *
>*>*
>*> My transmitter- receiver parameters*
>*>*
>*> fft length= 64*
>*> cyclic prefix = 16*
>*> packet length = 96*
>*> no. of occupied carriers = 48*
>*> no. of pilot carriers = 4*
>*>*
>*>*
>*>*
>*> ___*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[Nate Temple]

Hi Henry,

Here are a few open source applications you may find useful to reference to 
build your tool.

rtl_power + heatmap.py (c/python) - Hard coded to use the RTL-SDRs
https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_power.c
http://kmkeen.com/rtl-power/

rtl_power port that uses FFTW - https://github.com/AD-Vega/rtl-power-fftw

inspectrum (c++) - https://github.com/miek/inspectrum

Such Samples by Tim O'Shea - GR Based Sample Data File Visualization
https://oshearesearch.com/2015/05/22/such-samples-a-gnu-radio-tool-for-sample-data-visualization/
https://oshearesearch.com/2015/12/08/such-samples-2/

- Nate


> On Mar 19, 2016, at 11:05 AM, Henry Barton  wrote:
> 
> So there’s no “read x samples, divide by y, do such-and-such, and you have a 
> frequency-domain array” that I can average over time?
> 
> Sent from Windows Mail
> 
> From: Nikos Balkanas
> Sent: ‎Saturday‎, ‎March‎ ‎19‎, ‎2016 ‎1‎:‎31‎ ‎PM
> To: James Humphries
> Cc: Henry Barton, discuss-gnuradio@gnu.org
> 
> Hi,
> 
> I missed your second part. gr-fosphor is realtime, so It will follow whatever 
> frequencies you have. Frequency hops show as frequency bands in a frequency 
> spectrum.
> The frequency spread of a single plot, is your sampling frequency.
> 
> HTH,
> Nikos​
> 
> On Sat, Mar 19, 2016 at 7:22 PM, James Humphries  
> wrote:
> Hi Henry,
> 
> There is a script, read_complex_binary.m, that is included with gnuradio. You 
> can use that with Octave or Matlab to read the I/Q recordings from a file as 
> a time vector.
> 
> -Trip
> 
> On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:
> Is there any simple formula for plotting spectrum (finding the intensity of 
> each frequency component, Hertz by Hertz) from IQ recordings? Specifically I 
> need to know how to read an IQ file and somehow dissect clusters of samples. 
> I’ve written programs that deal with large amounts of data from files, so I 
> think this shouldn't be too hard. I want to write my program so that it takes 
> in a multi-hour IQ file and averages it like the 24-hour band averaging on 
> the University of Twente WebSDR site. This would allow users to average an IQ 
> file over time and see the most active frequencies and times. There’s no 
> utility for this yet, and I’d like to write it and release it on my blog.
> 
> On a side note: is it possible to go “frame-by-frame” in an IQ file? For 
> example, to follow the hops of a 900-MHz FHSS device.
> 
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[Nikos Balkanas]

Hi,

With gr-fosphor you just playback the file and it loops until you stop it.
Plot supports averages, max and mins. Since I/Q files do not contain the
actual frequency, you'll have to calibrate the plot, which is 1 sample
frequency wide.

gr-fosphor runs on opencl.

HTH
Nikos
​

On Sat, Mar 19, 2016 at 8:05 PM, Henry Barton  wrote:

> So there’s no “read x samples, divide by y, do such-and-such, and you have
> a frequency-domain array” that I can average over time?
>
> Sent from Windows Mail
>
> *From:* Nikos Balkanas 
> *Sent:* ‎Saturday‎, ‎March‎ ‎19‎, ‎2016 ‎1‎:‎31‎ ‎PM
> *To:* James Humphries 
> *Cc:* Henry Barton , discuss-gnuradio@gnu.org
>
> Hi,
>
> I missed your second part. gr-fosphor is realtime, so It will follow
> whatever frequencies you have. Frequency hops show as frequency bands in a
> frequency spectrum.
> The frequency spread of a single plot, is your sampling frequency.
>
> HTH,
> Nikos​
>
> On Sat, Mar 19, 2016 at 7:22 PM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> Hi Henry,
>>
>> There is a script, read_complex_binary.m, that is included with gnuradio.
>> You can use that with Octave or Matlab to read the I/Q recordings from a
>> file as a time vector.
>>
>> -Trip
>>
>> On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:
>>
>>> Is there any simple formula for plotting spectrum (finding the intensity
>>> of each frequency component, Hertz by Hertz) from IQ recordings?
>>> Specifically I need to know how to read an IQ file and somehow dissect
>>> clusters of samples. I’ve written programs that deal with large amounts of
>>> data from files, so I think this shouldn't be too hard. I want to write my
>>> program so that it takes in a multi-hour IQ file and averages it like the
>>> 24-hour band averaging on the University of Twente WebSDR site. This would
>>> allow users to average an IQ file over time and see the most active
>>> frequencies and times. There’s no utility for this yet, and I’d like to
>>> write it and release it on my blog.
>>>
>>> On a side note: is it possible to go “frame-by-frame” in an IQ file? For
>>> example, to follow the hops of a 900-MHz FHSS device.
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RX channel 1 out of range for configured RX frontends

[Marcus Müller]

Yes, the N210 take daughterboards, and in fact, they only take one RX
and one TX daughterboard, or a single "full-sized duplex board".
Point is that with the Basic* and LF* boards, you can either use the I &
Q signal lines combinedly as a single complex stream, or isolatedly as
two real streams. However, as the latter totally "breaks standard
behaviour", you have to specify a subdevice specification explaining how
you want your channels to be mapped.

Best regards,
Macus

On 03/18/2016 06:06 PM, Nikos Balkanas wrote:
> I stand corrected. Didn't even know that N210s took daugterboards :(​
>
> Nikos
>
> On Fri, Mar 18, 2016 at 6:39 PM, Martin Braun  > wrote:
>
> You *can* have 2 rx channels in an N210 (by means of dual DDC chains),
> but you probably haven't set the subdev spec appropriately (Something
> like 'A:0 A:0', depending on your daughterboard, check the UHD
> manual).
>
> Cheers,
> Martin
>
> On 03/18/2016 08:53 AM, Nikos Balkanas wrote:
> > Hi,
> >
> > You can have only 1 RX and 1 TX channel in a N210. You are
> asking for 2
> > RX channels in your flow. Runtime complains that he can access
> only 1
> > channel (Rx0).
> >
> > HTH,
> > Nikos​
> >
> > On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M
> 
> > >>
> wrote:
> >
> > Hi All,
> > I am using GNU Radio Companion 3.7.5 and USRP N210.
> > When I implemented a simple flow graph of SIMO system with two
> > channels using USRP source block ( attached grc flow graph
> snapshot
> > for reference),
> > I am getting following error:
> >
> > Traceback (most recent call last):
> >   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
> > tb = ONE_TWO()
> >   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
> > channels=range(2),
> >   File
> >   
>  "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> > line 122, in constructor_interceptor
> > return old_constructor(*args)
> >   File
> >   
>  "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line 1740, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError: LookupError: IndexError: multi_usrp: RX
> channel 1 out
> > of range for configured RX frontends
> >
> > Can anyone help me to fix this error?
> > Thanks in advance
> >
> > Regards,
> > Suganya.M
> >
> >
> > ___
> > 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 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] Handling of IQ files

[Marcus D. Leech]

On 03/19/2016 02:05 PM, Henry Barton wrote:
So there’s no “read x samples, divide by y, do such-and-such, and you 
have a frequency-domain array” that I can average over time?


Sent from Windows Mail

Gnu Radio has various types of FFT blocks, filters, decimators, etc, 
etc.But there is no big, blue 'Do that thing that Henry Barton wants 
to do'
  button.  It's a development framework for developing DSP 
applications, largely in the radio space.  One could *use* Gnu Radio to
  *build* a "signal analysis workbench", but Gnu Radio isn't in and of 
itself, "a signal analysis workbench".


Just as GCC isn't "that cool spreadsheet app I'd love to have", but it 
can certainly be *used* to *build* "that cool spreadsheet app I'd love

  to have".



*From:* Nikos Balkanas 
*Sent:* ‎Saturday‎, ‎March‎ ‎19‎, ‎2016 ‎1‎:‎31‎ ‎PM
*To:* James Humphries 
*Cc:* Henry Barton , 
discuss-gnuradio@gnu.org 


Hi,

I missed your second part. gr-fosphor is realtime, so It will follow 
whatever frequencies you have. Frequency hops show as frequency bands 
in a frequency spectrum.

The frequency spread of a single plot, is your sampling frequency.

HTH,
Nikos​

On Sat, Mar 19, 2016 at 7:22 PM, James Humphries 
> wrote:


Hi Henry,

There is a script, read_complex_binary.m, that is included with
gnuradio. You can use that with Octave or Matlab to read the I/Q
recordings from a file as a time vector.

-Trip

On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton > wrote:

Is there any simple formula for plotting spectrum (finding the
intensity of each frequency component, Hertz by Hertz) from IQ
recordings? Specifically I need to know how to read an IQ file
and somehow dissect clusters of samples. I’ve written programs
that deal with large amounts of data from files, so I think
this shouldn't be too hard. I want to write my program so that
it takes in a multi-hour IQ file and averages it like the
24-hour band averaging on the University of Twente WebSDR
site. This would allow users to average an IQ file over time
and see the most active frequencies and times. There’s no
utility for this yet, and I’d like to write it and release it
on my blog.

On a side note: is it possible to go “frame-by-frame” in an IQ
file? For example, to follow the hops of a 900-MHz FHSS device.

___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] (no subject)

[Martin Braun]

Congrats!

... Although this was probably meant for someone else.

M
On 17 Mar 2016 16:19, "Henry Barton"  wrote:

> I studied enough for ch 1-2 and was able to get 100, 87, 100, and 95 on
> the 4 assignments.
>
> ___
> 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] Handling of IQ files

[Henry Barton]

So there’s no “read x samples, divide by y, do such-and-such, and you have a 
frequency-domain array” that I can average over time?






Sent from Windows Mail





From: Nikos Balkanas
Sent: ‎Saturday‎, ‎March‎ ‎19‎, ‎2016 ‎1‎:‎31‎ ‎PM
To: James Humphries
Cc: Henry Barton, discuss-gnuradio@gnu.org






Hi,




I missed your second part. gr-fosphor is realtime, so It will follow whatever 
frequencies you have. Frequency hops show as frequency bands in a frequency 
spectrum.

The frequency spread of a single plot, is your sampling frequency.




HTH,

Nikos​



On Sat, Mar 19, 2016 at 7:22 PM, James Humphries  
wrote:


Hi Henry,



There is a script, read_complex_binary.m, that is included with gnuradio. You 
can use that with Octave or Matlab to read the I/Q recordings from a file as a 
time vector.




-Trip



On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:




Is there any simple formula for plotting spectrum (finding the intensity of 
each frequency component, Hertz by Hertz) from IQ recordings? Specifically I 
need to know how to read an IQ file and somehow dissect clusters of samples. 
I’ve written programs that deal with large amounts of data from files, so I 
think this shouldn't be too hard. I want to write my program so that it takes 
in a multi-hour IQ file and averages it like the 24-hour band averaging on the 
University of Twente WebSDR site. This would allow users to average an IQ file 
over time and see the most active frequencies and times. There’s no utility for 
this yet, and I’d like to write it and release it on my blog.






On a side note: is it possible to go “frame-by-frame” in an IQ file? For 
example, to follow the hops of a 900-MHz FHSS device.

___
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

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Nikos Balkanas]

Hi Meny,

I imagine that's exactly what you need. Not only locate disaster victims,
but also encourage them. You could always modify openbts code to not
register or communicate with them, but what of the victim, thinking that it
connected to a network and can't ask for help?

BR,
Nikos

On Tue, Mar 15, 2016 at 6:14 PM, Meny Sidar  wrote:

> Marcus,
> Thanks again. Very helpful as always.
> Of course those are 2 completely different approaches, but this one can
> also be useful to me.
> I'll start looking in to it right now.
>
> Thanks!
>
> 2016-03-15 18:02 GMT+02:00 Marcus Müller :
>
>> That is direction finding, not distance estimation based on signal power.
>> Two totally different approaches. You'll need at least two antennas for
>> direction estimation.
>>
>> Meny, you're an engineer, read up on the theory; it's actually fun to see
>> these signal and geometric equations fall into place.
>>
>> In this case, Walter Kaminsky (who made that device from the video) holds
>> a granted patent [1] on this specific device, and as a skimming of the
>> abstract of that patent shows, direction finding is done by phase
>> comparison. You'll find more details in the patent and if you look up
>> direction finding in the literature/the internet.
>> Direction finding through phase difference isn't such a complex concept
>> mathematically, but non-trivial to implement in hardware (which is why
>> Walter was granted a patent on a device that implements a rather well-known
>> application); but if you have phase-coherent receivers, also not impossibly
>> hard to build such a system with GNU Radio. It all boils down to writing a
>> direction estimator. There's a *lot* of approaches and algorithms out
>> there, but I'd recommend you start with something intuitive – maybe finding
>> the relative phase of a received signal by estimating the phases of
>> signals, and based on these phase relationship estimate the angle of the
>> wavefront relative to your antenna array.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://www.google.de/patents/US6239747
>>
>>
>> On 03/15/2016 03:17 PM, Meny Sidar wrote:
>>
>> Thank you for your comments.
>> Marcus, sorry for bugging you with this issue.
>> I am well aware of the previous discussions with you, and have learned
>> from them as well as from other people.
>> however, when i come across something like this for example:
>> https://www.youtube.com/watch?v=ZUqzdrB1o2U
>> i keep thinking that there is some kind of heat signature in the spectrum
>> that the cellular produces (please correct me if im wrong)
>> how else can you explain this works?
>>
>> I know my approch is not ideal, and i'm not ruling out opening a bts base
>> station,
>> but i cant find a way to make phones register to my station
>> automatically..
>>
>> thanks again for your comments guys,
>> really appreciate it.
>>
>> Meny
>>
>> 2016-03-15 4:11 GMT+02:00 Nikos Balkanas :
>>
>>> Indeed, there is phone locator protocol, and a service offered as by
>>> some companies. They work through provider contracts. The problem is that
>>> you have to know the phone number beforehand and the carrier. Not very
>>> useful in a disaster case :(
>>>
>>> BR,
>>> Nikos
>>>
>>> On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
 True, at least unless you send them something they have to react
 to. Which the phone will only do if you're the infrastructure, and usually
 implies you authenticate as such[2]. Which will hence most likely only work
 if the cellular providers cooperate with you.

 ​[...snip...]​



 On 03/14/2016 03:54 PM, Meny Sidar wrote:

 Hi guys,

 I am currently working on a project for my university, where i'm trying
 to locate cellular phones using SDR (USRP B210).
 The idea of the project is to be able to find survivors/victims in
 disaster areas, such as earthquakes, by assuming they have their cellular
 on them.

 What i did so far, is a program that calculates and outputs in a loop
 the power transmitted from a cellular phone from it's uplink channel. that
 can tell me my distance to it.
 problem is, that cellular phones are usually in idle mode and not
 transmitting at all.
 So it works, but only if the phone is currently transmitting to the
 network (phone call, internet, etc..)

 I'm trying to find a solution for this,
 There has to be a way of knowing that some kind of RF
 transmitter/receiver is near me...
 If anyone can shed some light on this subject, what can i do or if i
 need to go in another way, i'll be very grateful!
 right now i'm stuck.

 Thanks a lot,
 Meny


 ___
 Discuss-gnuradio mailing 
 

Re: [Discuss-gnuradio] gr-gsm python problem "ImportError: No module named osmosdr"

[Andrej Rode]

Hello Uli, 

> -
> ~/GSM/gr-gsm/apps$ ./grgsm_livemon
> Traceback (most recent call last):
>   File "./grgsm_livemon", line 29, in 
> import osmosdr
> ImportError: No module named osmosdr
> --

This error looks like the path you installed gr-osmosdr is not included in 
your PYTHONPATH.

You probably should add '/usr/local/lib/python2.7/site-packages' or generally 
speaking '$INSTALL_DIR/lib/python2.7/site-packages' to your $PYTHONPATH. 

Best Regards, 
Andrej



signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[Nikos Balkanas]

Hi,

I missed your second part. gr-fosphor is realtime, so It will follow
whatever frequencies you have. Frequency hops show as frequency bands in a
frequency spectrum.
The frequency spread of a single plot, is your sampling frequency.

HTH,
Nikos​

On Sat, Mar 19, 2016 at 7:22 PM, James Humphries 
wrote:

> Hi Henry,
>
> There is a script, read_complex_binary.m, that is included with gnuradio.
> You can use that with Octave or Matlab to read the I/Q recordings from a
> file as a time vector.
>
> -Trip
>
> On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:
>
>> Is there any simple formula for plotting spectrum (finding the intensity
>> of each frequency component, Hertz by Hertz) from IQ recordings?
>> Specifically I need to know how to read an IQ file and somehow dissect
>> clusters of samples. I’ve written programs that deal with large amounts of
>> data from files, so I think this shouldn't be too hard. I want to write my
>> program so that it takes in a multi-hour IQ file and averages it like the
>> 24-hour band averaging on the University of Twente WebSDR site. This would
>> allow users to average an IQ file over time and see the most active
>> frequencies and times. There’s no utility for this yet, and I’d like to
>> write it and release it on my blog.
>>
>> On a side note: is it possible to go “frame-by-frame” in an IQ file? For
>> example, to follow the hops of a 900-MHz FHSS device.
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Handling of IQ files

[James Humphries]

Hi Henry,

There is a script, read_complex_binary.m, that is included with gnuradio.
You can use that with Octave or Matlab to read the I/Q recordings from a
file as a time vector.

-Trip

On Sat, Mar 19, 2016 at 12:43 PM, Henry Barton  wrote:

> Is there any simple formula for plotting spectrum (finding the intensity
> of each frequency component, Hertz by Hertz) from IQ recordings?
> Specifically I need to know how to read an IQ file and somehow dissect
> clusters of samples. I’ve written programs that deal with large amounts of
> data from files, so I think this shouldn't be too hard. I want to write my
> program so that it takes in a multi-hour IQ file and averages it like the
> 24-hour band averaging on the University of Twente WebSDR site. This would
> allow users to average an IQ file over time and see the most active
> frequencies and times. There’s no utility for this yet, and I’d like to
> write it and release it on my blog.
>
> On a side note: is it possible to go “frame-by-frame” in an IQ file? For
> example, to follow the hops of a 900-MHz FHSS device.
>
> ___
> 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] gr-gsm python problem "ImportError: No module named osmosdr"

[Hcx HCX]

Hi fellows,

I am relatively new in gnuradio that I took from github (version 3.7.9) Further
I have taken osmocom and gr-osmosdr from github also libvolk-1.21.


The installation worked fine. I am using Pyxthon-2.7 on BACKBOX-LINUX 4.2 kernel
3.19.0-51-generic.

So far so good. My problem I havent found a Solution for yet is this Error
Message I get when I start ./grgsm_livemon
-
~/GSM/gr-gsm/apps$ ./grgsm_livemon
Traceback (most recent call last):
  File "./grgsm_livemon", line 29, in 
import osmosdr
ImportError: No module named osmosdr
--

I neither couldn't find nor install this module using import or pip. I must
confess that I am anything but a python programmer so I reinstalled the packages
above for serveral times without success. So I beg for your help now. What do I
have to do to get grgsm (former airprobe) runnig on gnuradio 3.7.9?

Many thanks in advance & regards,

Uli

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

Re: [Discuss-gnuradio] Handling of IQ files

[Nikos Balkanas]

​Hi,

Yes. gr-fosphor will do that for you. It's main takes as input a complex
float I/Q file from usrp.

HTH
Nikos

On Sat, Mar 19, 2016 at 6:43 PM, Henry Barton  wrote:

> Is there any simple formula for plotting spectrum (finding the intensity
> of each frequency component, Hertz by Hertz) from IQ recordings?
> Specifically I need to know how to read an IQ file and somehow dissect
> clusters of samples. I’ve written programs that deal with large amounts of
> data from files, so I think this shouldn't be too hard. I want to write my
> program so that it takes in a multi-hour IQ file and averages it like the
> 24-hour band averaging on the University of Twente WebSDR site. This would
> allow users to average an IQ file over time and see the most active
> frequencies and times. There’s no utility for this yet, and I’d like to
> write it and release it on my blog.
>
> On a side note: is it possible to go “frame-by-frame” in an IQ file? For
> example, to follow the hops of a 900-MHz FHSS device.
>
> ___
> 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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio

[Piotr Krysik]

Thank you Martin!


W dniu 18.03.2016 o 18:54, Martin Braun pisze:
> To disable gnuradio's forcebuild from the command line, run:
>
> $ pybombs config --package gnuradio forcebuild False
>
> This will persistently disable forcebuilding for GNU Radio.
>
> With --config, you can only change the global config settings (i.e. the
> ones in the config: section in your config.yml files). Example:
>
> $ pybombs --config makewidth=8 install gnuradio
>
> This is *non-persistent* and will override any config.yml setting for
> the duration of the process.
> To see what the options are that you can change with --config, simply run
>
> $ pybombs config
>
> without any other parameters. They include help texts, too.
>
> Note the first command includes the --package switch. If you leave it
> out and just call config  , it'll set a global config
> option, like --config (but persistent).
>
> M
>
>
>
>
> On 03/17/2016 02:09 PM, Piotr Krysik wrote:
>> Hi all,
>>
>> How to use "--config" option of pybombs 2. Can someone show an working
>> example?
>>
>> In pybombs 2 "forcebuild" is set to true for gnuradio by default.
>> How to disable "focebuild" for gnuradio from commandline with the
>> pybombs command?
>>
>> Best Regards,
>> Piotr Krysik
>>
>> ___
>> 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

Re: [Discuss-gnuradio] GSoC Proposal

[Parth Sane]

Hi Daniel,
The problem is I haven’t used GNU radio very much and also don’t understand its 
internals properly. Also like you said there is no proper task definition. I do 
want to participate but the problem here, is I frankly don’t know what to 
propose! Do I suggest new features, do I help other contributors to create more 
HAM friendly radio interfaces? Do I integrate Softrock radio (Si570) software 
support into GNU(If it’s already not there!)? I’m confused. Also to have full 
disclosure I want people to know that I have already submitted a proposal for 
Jenkins.
Regards,
Parth Sane
> On 19-Mar-2016, at 10:08 PM, Daniel Pocock  wrote:
> 
> 
> Parth, have you decided if you want to apply or do you need more information?
> 
> You are correct, the project description is not clear or complete.  Ham radio 
> is a hobby and in that spirit I don't want to tell you exactly what to do, I 
> want you to make suggestions about goals and deliverables for the project and 
> explain how you will complete them in the period of time for GSoC
> 
> Please make sure you complete two applications, one under Debian and another 
> under GNU Radio.  You can submit the same proposal details to each 
> organization.
> 
> I'm at FOSSASIA in Singapore this weekend and I'll be happy to discuss the 
> project in person with any applicants who are also here.  Otherwise, please 
> feel free to email any questions and I'll try to help you.
> 
> Regards,
> 
> Daniel
> 
> 
> On 15/03/16 23:52, Marcus Müller wrote:
>> Dear Parth,
>> 
>> from the GNU Radio side of things, I can only stress what Martin Braun said 
>> on this mailing list on multiple occassions: Read the whole GNU Radio wiki 
>> Page on GSoC; get yourself familiar with GNU Radio (google for GNU Radio 
>> Guided Tutorials), match yourself to one of the proposed topics from the 
>> wiki, write an excellent proposal and also be visible in the community, e.g. 
>> by having pull requests (documentation can *always* be improved), or an 
>> out-of-tree module that does something unique. Show that you're both able to 
>> build something great within the GNU Radio ecosystem and are willing to 
>> participate in the community process!
>> 
>> Best regards,
>> Marcus
>> 
>> On 03/15/2016 03:02 PM, Parth Sane wrote:
>>> Hi Guys,
>>> I’m interested in participating in GSoC 2016 with GNU radio and Debian. 
>>> I’ve looked at the page at the Debian ideas page. Its not very clear to me 
>>> what tasks can be done as a part of GSoC 2016. I’m good at Java,C++,have 
>>> used a fair bit of git and I do have ham radio licenses across USA and 
>>> India. I’m a newbie at python, but I can manage it. So please do reply so 
>>> as to help with project proposal ideas!
>>> Regards,
>>> Parth Sane
>>> VU3TTL/KD2KER
>>> 
>>> 
>>> ___
>>> 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
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Handling of IQ files

[Henry Barton]

Is there any simple formula for plotting spectrum (finding the intensity of 
each frequency component, Hertz by Hertz) from IQ recordings? Specifically I 
need to know how to read an IQ file and somehow dissect clusters of samples. 
I’ve written programs that deal with large amounts of data from files, so I 
think this shouldn't be too hard. I want to write my program so that it takes 
in a multi-hour IQ file and averages it like the 24-hour band averaging on the 
University of Twente WebSDR site. This would allow users to average an IQ file 
over time and see the most active frequencies and times. There’s no utility for 
this yet, and I’d like to write it and release it on my blog.






On a side note: is it possible to go “frame-by-frame” in an IQ file? For 
example, to follow the hops of a 900-MHz FHSS device.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoC Proposal

[Daniel Pocock]

Parth, have you decided if you want to apply or do you need more
information?

You are correct, the project description is not clear or complete.  Ham
radio is a hobby and in that spirit I don't want to tell you exactly
what to do, I want you to make suggestions about goals and deliverables
for the project and explain how you will complete them in the period of
time for GSoC

Please make sure you complete two applications, one under Debian and
another under GNU Radio.  You can submit the same proposal details to
each organization.

I'm at FOSSASIA in Singapore this weekend and I'll be happy to discuss
the project in person with any applicants who are also here.  Otherwise,
please feel free to email any questions and I'll try to help you.

Regards,

Daniel


On 15/03/16 23:52, Marcus Müller wrote:
> Dear Parth,
>
> from the GNU Radio side of things, I can only stress what Martin Braun
> said on this mailing list on multiple occassions: Read the whole GNU
> Radio wiki Page on GSoC; get yourself familiar with GNU Radio (google
> for GNU Radio Guided Tutorials), match yourself to one of the proposed
> topics from the wiki, write an excellent proposal and also be visible
> in the community, e.g. by having pull requests (documentation can
> *always* be improved), or an out-of-tree module that does something
> unique. Show that you're both able to build something great within the
> GNU Radio ecosystem and are willing to participate in the community
> process!
>
> Best regards,
> Marcus
>
> On 03/15/2016 03:02 PM, Parth Sane wrote:
>> Hi Guys,
>> I’m interested in participating in GSoC 2016 with GNU radio and
>> Debian. I’ve looked at the page at the Debian ideas page
>> .
>> Its not very clear to me what tasks can be done as a part of GSoC
>> 2016. I’m good at Java,C++,have used a fair bit of git and I do have
>> ham radio licenses across USA and India. I’m a newbie at python, but
>> I can manage it. So please do reply so as to help with project
>> proposal ideas!
>> Regards,
>> Parth Sane
>> VU3TTL/KD2KER
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

This works! Thanks a lot!

Ralph.


>-Original Message-
>From: Marcus Müller [mailto:marcus.muel...@ettus.com]
>Sent: Wednesday, March 16, 2016 10:24
>To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
>Subject: Re: [Discuss-gnuradio] lack of understanding the different formats
to
>store samples
>
>Ok, let "I" and "Q" be single bits each, so each byte would then be
>
>IQIQIQIQ
>
>if I had to take a guess.
>
>You can get get back something that GR commonly deals with by doing
>
>packed to unpacked (type=B, bits per chunk = 1, endianness=your machine)
>-> IChar to Complex
>
>Best regards,
>Marcus
>On 16.03.2016 08:13, Ralph A. Schmid, dk5ras wrote:
>> Each byte seems to contain 4 1 bit I/Q samples. This is the text from
>> the
>> readme:
>>
>> "The output file size can be reduced by using "-b 1" option to store
>> four 1-bit I/Q samples into a single byte."
>>
>> Ralph.
>>
>>> -Original Message-
>>> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
>>> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf
>>> Of Marcus Müller
>>> Sent: Friday, March 11, 2016 2:53 PM
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] lack of understanding the different
>> formats
>>> to store samples
>>>
>>> In what format are your 1bit samples? I'd assume they are just the
>>> fact whether a byte is 0x00 or 0x01; in that case, just use unpacked to
packed.
>>>
>>> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
 Hi,

 Being an RF guy I must admit that I am somehow lost in the different
 ways how samples are stored in files. I stumbled over this question
 when I experimented with https://github.com/osqzss/gps-sdr-sim. It
 works great when using 16 bit samples and using a simple two-block
 grc file, feeding them directly from a file source to the UHD sink.
 However the 1 bit variant sounds promising, as the files are much
 smaller this way and also the generation of them runs much faster.

 It must only be a matter of finding the right blocks and the right
 settings to convert this, but my google search was highly confusing,
 most probably due to different names for the same thing.

 So I do not only ask for how to use "four 1-bit I/Q samples into a
 single byte" (taken from the readme of the gps-sdr-sim), but for a
 more general overview how this stuff is done, to be prepared for
 other upcoming questions of this kind :) Up to now I solved those
 issues by an educated guess or even by try and error, what is not
 very
>> satisfying...
 Ralph.


 ___
 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

Re: [Discuss-gnuradio] Massive underruns when transmitting with gr-ieee802-11 on an B210 USRP

[Marcus Müller]

What the the other Marcus intended to stress was that you're connected
using USB __2__, which is too slow. Use a USB __3__ host controller.
Sadly, not all work equally well. Generally, if you can, use an Intel
host controller as integrated with many modern mainboards; with my
oldish laptop, I'm having O.K. experiences with a Renesas Technology
Corp. uPD720202 based USB3 Expresscard expansion.

Best regards,
Marcus

On 03/17/2016 07:22 PM, Marcus D. Leech wrote:
> On 03/17/2016 02:13 PM, Gonzalo Arcos wrote:
>> -- Detected Device: B210
>> -- Operating over USB 2.
>> 
>> 
>> UHD Warning:
>> The total sum of rates (20.00 MSps on 1 channels) exceeds the
>> maximum capacity of the connection.
>> This can cause underruns (U).
> I refer you to the above messages^^
>
> Your B210 is connected via USB, which cannot sustain the required data
> rate.
>
>
>
> ___
> 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] Lock onto QPSK signal

[Henry Barton]

When I said “is it like selective fading” you wrote “That.” What does “That.” 
mean?


>No way 24 MHz are going to be flat in frequency domain

Does that mean that the transmitted result will not be smooth in a waterfall, 
but have high power and low power areas? I would expect a wideband SDR like the 
bladeRF to be uneven over its frequency range. At least this is Phase-Shift 
Keying and not QAM, since QAM depends on amplitude.


My project uses an x16 chip rate, because the base rate is exactly 1.5 
Msymbols/sec with FEC and Reed-Solomon. That makes exactly 24 MHz which fits 
nicely in the 26-MHz-wide 900 MHz ISM band.






Sent from Windows Mail





From: Marcus Müller
Sent: ‎Wednesday‎, ‎March‎ ‎16‎, ‎2016 ‎10‎:‎34‎ ‎AM
To: discuss-gnuradio@gnu.org




Hi Henry,


On 16.03.2016 15:24, Henry Barton wrote:



Wow, thanks for the comprehensive reply. You covered a lot of material and I 
like how simple you make it.
Did I? I pretty much went ahead and threw assumptions at you like "hey, that's 
a dot product, and you'll know how to deal with that" :)






>"amont of similarity between the RX signal shifted in time by 휏 and the right 
>spreading sequence". Look for the peak. That's your timing offset.

I guess that means if I have an x16 chip rate, I try applying the spreading 
code to the RX signal at different symbol shifts. So I might have a buffer of 
received symbols and shift it 1 symbol each time as I try the spreading code on 
it, then see which produces the strongest result?
Pretty much! You can also oversample to get a more fine-tuned result. 






>still "pretty" orthogonal when out of sync

I hadn't even considered that. So turning on your transmitter by chance at just 
the right time can make your orthogonal code ruin others' signals?
Nah, spreading codes used usually are pretty good, but yes, there's compromises 
to be made when your code can't be infinitely long but you want to have a lot 
of users etc.






>frequency-selective channels

What's that? Is it like selective fading?
That.



I don't need high throughput; my project aims to transmit 2.064 Mbit/sec in a 
24 MHz channel in the 900 MHz band.
No way 24 MHz are going to be flat in frequency domain :)



I use QPSK/4QAM because it has 1/2 the bandwidth of BPSK while still being much 
more error-resistant than high-order QAM.
Sounds like a good choice; so 2.064 Mb/s/(2b/S) = 1.032 MS/s, so I guess you're 
aiming for a spreading factor > 10?

Cheers,
Marcus
 












To: discuss-gnuradio@gnu.org
From: marcus.muel...@ettus.com
Date: Wed, 16 Mar 2016 14:03:32 +0100
Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal

Hi Henry,

Interesting questions!


On 16.03.2016 03:48, Henry Barton wrote:




Hi, does anyone know of any good tutorials that explain how to lock onto the 
clock of a QPSK signal and/or correlate? I know this is all very simple in 
GNUradio, but I hope someone knows of a website or, preferably, a video series 
that will explain this.
Have you read the GNU Radio Guided Tutorials[1]? Chapter 7 (you should really 
read 1-5 before) deals with PSK reception and timing recovery.
A video series? Hm; to be honest, that does sound like you want to attend a 
full course on the basics and some lectures on advanced methods of digital 
communications. I do think there's some good lecture recordings out there[2], 
but inherently, they are pretty sequential, so although you'll learn a lot, 
you'd still have to have the perseverance to spend quite some hours till you 
come to the point of clock sync for CDMA.

Personally: I'm not very much of a "I learn from videos" person. I do like the 
kind of introduction where someone stands in front and derives the methods and 
formulas "live" on a blackboard, but somehow, my concentration suffers when 
watching a video while mentally (and sometimes, on paper) take notes, at least 
for complex mathematical stuff. I'd rather go and loan a book from a local 
library. I think Sklar's Digital Communications would be the go-to ressource on 
CDMA clock sync.




 

If I have 10 different QPSK users, spreaded and on the same frequency, that 
would make CDMA. 
Assuming these 10 users used sufficiently orthogonal spreading sequences!



Assuming no manufacturing tolerance or frequency drift, all the clocks on the 
transmitters would be perfectly the same.
aside from a phase offset



What I’m trying to understand is:

 

1.   No two separate transmitters can ever be perfectly in sync. Even if 
the clocks were 100% accurate, User 1 might start his transmitter at 10:00:00 
AM while User 2 starts his at 10:00:00.250 AM. The signals would be a little 
out of sync with each other. How would I pick one out in DSP?
OK, what I describe in the following is somewhat like a 
textbook/naive/classical approach; in practice, devices are smarter.

Well, in CDMA, if you build the dot product of your received signal and User 
A's spreading sequency, you'll get a large magnitude as a result, if the signal 

[Discuss-gnuradio] Need Mentor review of GSOC 2016 proposal

[Tanero Juthero]

I will love that my proposal be reviewed by mentors,and I will be
appreciate a lot, if I am told as many things wrong with it as possible
especially in the project development part,and lots of suggestions too on
ways to improve and optimized codes for the chosen project.I am a bit
late,but I strongly believe what you have to say will help me much and do
better.Here is the link
https://github.com/tanerochris/gsoc-2016/blob/master/%20gsoc_2016_application.pdf
.Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Massive underruns when transmitting with gr-ieee802-11 on an B210 USRP

[Gonzalo Arcos]

Hello,

I have been working with the gr-ieee802-11 project for some time but always
in software, and now i managed to acquire B210 USRPs to do some testing on
air. I am testing the transmitter only, and sniffing from the medium with
another pc that has a wi-fi card using TCPDump.

I am experiencing massive overruns on the transmiter when using a pdu of
more than 10 bytes. This results in tcpdump not detecting the frames
transmitted when the USRP is being overrun. However, when transmitting a
frame of 5 bytes, for example, the output from GNU Radio is clean from 'U's
and tcpdump detects every frame correctly.
These sizes also vary on the modulation scheme used, if i use 64 QAM 3/4 i
am able to transmit more than 10 bytes with no overruns, however, in BPSK
1/2 the limit is 10, which suggest that has to do with the number of
symbols transmitted.

I attach an extract of the output of GNU Radio during an execution:

-- Detected Device: B210
-- Operating over USB 2.


UHD Warning:
The total sum of rates (20.00 MSps on 1 channels) exceeds the
maximum capacity of the connection.
This can cause underruns (U).
.
.
UUU

I understand that the message states that the capacity of my connection is
not sufficient, however, it does not specify how to solve it, or either if
it is a configuration problem of the OS / USRP, or a hardware limitation of
either the USRP or the PC. I am currently using USB 2.0 to connect the USRP
to my computer, which is an Ubuntu 14.04.
Is there a setting from the OS that should be tweaked? How can i fix this
problem?

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

Re: [Discuss-gnuradio] dive into gnu-radio

[Tom Coleman]

> On Mar 16, 2016, at 3:36 PM, Desmond Crozby  wrote:
> 
> …

> I saw this reading suggestion: 
> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading 
>  , but 
> the list is extensive and grouped by topic, basically I don't know where to 
> start from.
> 

Software Radio in General
Has anyone bothered to check these links lately?


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

Re: [Discuss-gnuradio] Measuring execution time of functions within block returns strange results.

[Marcus Müller]

Hi Gonzalo,

On 16.03.2016 15:12, Gonzalo Arcos wrote:
> Ive been trying to determine which functions and/or code sections are
> the more computationally consuming within a work() function of a block.
Don't do that yourself. There's the performance counters built into GNU
Radio, which allow you to perform the overall consumed work() time, and
if you need to look deeper into your program:
Get the perf tools. Build your project using "cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo ..", and then

perf top -a python yourflowgraph.py
perf report

Best regards,
Marcus


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

[Discuss-gnuradio] OFDM benchmark optimal parameter

[SangHyoeg Kim]

Hi, I am using ofdm/benchmark example with USRP N210 and CBX 40Mhz 
daughterboard. 

I tried to know optimal parameter(bandwidth, fft length, occupied tones, packet 
size) for maximum throughput and minimum error rates. 

How can I reach maximum throughput by adjusting parameter or modifying code ?

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

Re: [Discuss-gnuradio] Lock onto QPSK signa

[Landsman, Arik]

Hi Henry,

To add to Marcus's comments, there are two main methods in gnuradio for clock 
recovery of QPSK. in all cases you would need a costas loop block, and some way 
to recover symbol timing *before* costas (either a polyphase clock sync or an 
M). These are built into the psk demod block, along with a few others - a 
great starting point is to check the python for it.

Since CDMA I assume your radio would need to communicate while in motion, which 
implies a fast-moving channel - so doppler would need to be constantly 
corrected. An FLL would do this but it may need encoding to make the spectrum 
look uniform. I suppose the cmda spreading codes would do that as a freebie.

Marcus mentioned a few web resources - if he hasn't mentioned 
gr-digital/examples has good examples.

So two ways for clock/symbol recovery:

diff encoding - easiest to implement in general, but comes with a 2x BER 
penalty. psk mod/demod block are ready-to-go blocks Tom R had put together.
preamble (syncword) recovery - a bit more difficult, but in theory better BER 
at low SNR (that is when it works right.. debugging mine right now). I had no 
luck with QPSK so far, but there are examples of BPSK that work.

before jumping into CDMA (worth noting that 5G will be likely FDMA - turns out 
CDMA throughput in real systems is lower than estimated at first for 4G), you 
may want to have a single QPSK tx-rx pair working first. Adding "users" to your 
system requires resolving networking sync issues (as both you and Marcus 
noted), and operate under the assumption that each MS can reliably connect to 
the Basestation for a typical channel response. Lots of good papers on IEEE, 
including some review papers that give more of a summary.

MIT's open course offers their Digital Comm course online - great stuff if you 
endure 1hr videos :)
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-450-principles-of-digital-communications-i-fall-2006/video-lectures/lecture-21-doppler-spread/


diff encoding will get you started sooner, just use the psk mod/demod blocks. 
Should largely work out of the box.

Best Regards,
Arik


-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 28
Date: Wed, 16 Mar 2016 15:33:00 +0100
From: Marcus M?ller 
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal
Message-ID: <56e96e9c.5080...@ettus.com>
Content-Type: text/plain; charset="utf-8"

Hi Henry,

On 16.03.2016 15:24, Henry Barton wrote:
> Wow, thanks for the comprehensive reply. You covered a lot of material
> and I like how simple you make it.
Did I? I pretty much went ahead and threw assumptions at you like "hey,
that's a dot product, and you'll know how to deal with that" :)
>
> >"amont of similarity between the RX signal shifted in time by ? and
> the right spreading sequence". Look for the peak. That's your timing
> offset.
> I guess that means if I have an x16 chip rate, I try applying the
> spreading code to the RX signal at different symbol shifts. So I might
> have a buffer of received symbols and shift it 1 symbol each time as I
> try the spreading code on it, then see which produces the strongest
> result?
Pretty much! You can also oversample to get a more fine-tuned result.
>
> >still "pretty" orthogonal when out of sync
> I hadn't even considered that. So turning on your transmitter by
> chance at just the right time can make your orthogonal code ruin
> others' signals?
Nah, spreading codes used usually are pretty good, but yes, there's
compromises to be made when your code can't be infinitely long but you
want to have a lot of users etc.
>
> >frequency-selective channels
> What's that? Is it like selective fading?
That.
> I don't need high throughput; my project aims to transmit 2.064
> Mbit/sec in a 24 MHz channel in the 900 MHz band.
No way 24 MHz are going to be flat in frequency domain :)
> I use QPSK/4QAM because it has 1/2 the bandwidth of BPSK while still
> being much more error-resistant than high-order QAM.
Sounds like a good choice; so 2.064 Mb/s/(2b/S) = 1.032 MS/s, so I guess
you're aiming for a spreading factor > 10?

Cheers,
Marcus
>
>
>
>
> 
> To: discuss-gnuradio@gnu.org
> From: marcus.muel...@ettus.com
> Date: Wed, 16 Mar 2016 14:03:32 +0100
> Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal
>
> Hi Henry,
>
> Interesting questions!
>
> On 16.03.2016 03:48, Henry Barton wrote:
>
> Hi, does anyone know of any good tutorials that explain how to
> lock onto the clock of a QPSK signal and/or correlate? I know this
> is all very simple in GNUradio, but I hope someone knows of a
> website or, preferably, a video series that will explain this.
>
> Have you read the GNU Radio Guided Tutorials[1]? Chapter 

Re: [Discuss-gnuradio] RX channel 1 out of range for configured RX frontends

[SUGANYA M]

Hi Nikos,
Thanks for replying me. Now, I understood the reason for that error and
corrected it and the execution goes well.

Thank you,
Suganya.M


On Fri, Mar 18, 2016 at 9:23 PM, Nikos Balkanas  wrote:

> Hi,
>
> You can have only 1 RX and 1 TX channel in a N210. You are asking for 2 RX
> channels in your flow. Runtime complains that he can access only 1 channel
> (Rx0).
>
> HTH,
> Nikos​
>
> On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M  wrote:
>
>> Hi All,
>> I am using GNU Radio Companion 3.7.5 and USRP N210.
>> When I implemented a simple flow graph of SIMO system with two channels
>> using USRP source block ( attached grc flow graph snapshot for reference),
>> I am getting following error:
>>
>> Traceback (most recent call last):
>>   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
>> tb = ONE_TWO()
>>   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
>> channels=range(2),
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>> line 122, in constructor_interceptor
>> return old_constructor(*args)
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 1740, in make
>> return _uhd_swig.usrp_source_make(*args)
>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of
>> range for configured RX frontends
>>
>> Can anyone help me to fix this error?
>> Thanks in advance
>>
>> Regards,
>> Suganya.M
>>
>>
>> ___
>> 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] benchmark_tx and rx : too many FALSE packet

[Marcus Müller]

Hi SangHyuk

On 16.03.2016 02:21, SangHyuk Kim wrote:
> Dear Nathan,
>
> I know QAM is the fastest modulation because it can carry more bits
> per symbol. This is a reason why I use QAM modulation.
>
> As bits per symbol level is higher, bit error rates will be increased.
> I expected it returns feasible error rate. However, error rates were
> too high. So I wondered "is this normal case or what is it I'm missing".
Well, how do you figure it is "too high"?

I mean, the math is all there: A packet of length N symbols for which we
assume that the error probability is identical and independent fails
when at least one of these flips (assuming CRC is collision free, which
we can easily do).
The packet error probability is then the complementary to the packet
success probility, which is the product of the individual symbol error
probabilities. These being IID (as assumed above), this packet success
probability is instantly clear:
$P_\text{packet good} = (P_\text{symbol good})^N$.

Now, let's assume we're foing 16-QAM. One can, based on a noise model
(which typically has Gaussian noise amplitude) derive the error
probabilities for all 16 QAM points (using the Q function), average
that, and come to a formula that gives one symbol error probabilty
$P_\text{symbol wrong} = 1-P_\text{symbol good}$. Not going to do that
here. Every digital communication textbook does that. Usually a shortcut
is taken and only the probabilities of switching to the nearest
neighboring constellation points are considered. That approximation
holds well for QAM.

The approximate solution given in such calculation is typically (you
should really do some literature research on your own)

$P_\text{symbol wrong} \approx 3\, Q\left(\frac{2}{\sqrt
5}\sqrt{\frac{E_b}{N_0}}\right)$

with $Q(x)$ being the probality that a normal Gaussian random variable
takes a value larger than $x$,
$\frac{E_b}{N_0}$ being the bit energy to noise power density ratio;
that should be defined as
$\frac{E_b}{N_0} = \text{SNR} \cdot
\frac{B_\text{signal}}{r_\text{bits}}$, i.e. the SNR on the channel
times the spectrum-per-bit-rate.

You do the math; is the packet error rate really so much higher than
what you'd expect under these formulas? If it really is by more than a
factor of 2, this is worth looking into any further. If it is not: well,
you won't be much better with an SNR like that.

Just a quick example: If your channel's SNR and your modulation / pulse
shaping choices lead to a symbol error probability of $10^{-4}$ (which
is pretty good), and your packets are 1500B long, and you're using
16QAM, i.e. 4b/Symbol, then your packet has $N=3000$ symbols:

$P_\text{packet good} = (P_\text{symbol good})^N =
(1-10^{-4})^3000\approx 74\%$


Best regards,
Marcus

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

Re: [Discuss-gnuradio] FFT Window function

[Martin Braun]

The best way is probably to track the window in a separate variable and
keep that around.

Cheers,
Martin

On 03/18/2016 02:46 AM, Simon Olvhammar wrote:
> Hi,
> 
> I would like to read the current set window function from python, e.g.
> blackman-harris, hanning.
> There doesn't seem to be any fft.get.window() command? Any other way?
> 
> Best regards
> Simon
> 
> 
> ___
> 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] FFT Window function

[Simon Olvhammar]

Hi,

I would like to read the current set window function from python, e.g.
blackman-harris, hanning.
There doesn't seem to be any fft.get.window() command? Any other way?

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

Re: [Discuss-gnuradio] How to create a python block

[Chris Kuethe]

Here's one example of a block implemented in python
https://github.com/drmpeg/gr-paint/pull/4/commits/6f3356c9816402961e75082f0ab9aa5b5b0eb338

Perhaps you want something like Tim O'Shea's lambda blocks?
https://oshearesearch.com/2015/05/23/gnu-radio-message-lambda-blocks/

Balint does strange any wonderful things with "Any" blocks:
http://wiki.spench.net/wiki/GRC_Any_Blocks

Hopefully one of these does what you need.
-C

On Wed, Mar 16, 2016 at 2:34 PM, Dennis Glatting  wrote:
> On Wed, 2016-03-16 at 16:58 -0400, James Humphries wrote:
>> Hi Dennis,
>>
>> Have you seen these:
>>
>> https://gnuradio.org/doc/doxygen/page_python_blocks.html
>>
>> and
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GN
>> U_Radio_in_Python
>>
>> They have some good info on how to setup your Python block.
>>
>
> This is where I am confused, not being a Python hack. I didn't want to
> create the graph by connecting things together in a python script, such
> as:
>
> src = blocks.vector_source_f (src_data)
> mult = multiply_py_ff (2)
> snk = blocks.vector_sink_f ()self.tb.connect (src, mult)
> self.tb.connect (mult, snk)
>
> Rather I wanted the python block to be part of the GUI run graph.
> Specifically, my graph looks like this:
>
>
> Rx -> Demod C++ --> MITM ---> Mod C++ -> Tx
> ^   ^   ^  ^^^
> |   |   |  |||
> |   |  |||
> Controls|  |||
> |  |||
> Fixed extensions|  |||
> Python extensions -|||
> ||
> Controls ---||
>
> My thinking is within the properties field of a block a person could
> type some python code where the block imports the code and runs it.
> Sounds like that isn't the workable approach? (The MITM block has
> canned messages and fixed manipulations based on GUI controls, which is
> fairly limiting as a penetration test tool.)
>
> When I looked at some examples I saw either C++ blocks or Python blocks
> but the python code created the whole graph itself.
>
> I think what you are telling me (and looking through the web pages) is
> I could have an ugly, fixed C++ MITM block /and/ a separate python
> block (i.e., two MITM blocks) with the python block part of the build,
> or both could be incorporated into the python block for a better
> design. Yes?
>
> Sorry, I'm not a python hack so it isn't evident to me.
>
> TIA.
>
>
>> -Trip
>>
>> On Wed, Mar 16, 2016 at 4:51 PM, Dennis Glatting 
>> wrote:
>> > This is probably a dumb question but someone has to ask them...
>> >
>> >
>> > I have a run graph with c++ blocks: a receiver block, a transmitter
>> > block, and a manipulator block. I want to have the manipulator
>> > block
>> > editable from the run graph where the user can insert python code.
>> > Specifically:
>> >
>> > 1) The block has two message ports: an "in" port and an "out" port.
>> >
>> > 2) A user can write and type python code into the block to
>> > manipulate
>> > the message received on the input port and post the manipulated
>> > message
>> > on the output port.
>> >
>> > 3) The python code may have to call other functions, such as
>> > updating a
>> > hash code.
>> >
>> > How might I do that? I could do a c++ wrap around exec() but I
>> > believe
>> > there has to be an easier way since GNURadio is a combination of
>> > python
>> > and c++.
>> >
>> > The incoming messages arrive at a low frequency and a low data rate
>> > so
>> > I'm not really concerned about processing time.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > 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



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] DOPPLER SHIFT

[Marcus Müller]

Hi Ernest,
I saw your first mail, too, but I was really busy at that time.

Now, what your error message indicates is that gpredict wasn't properly
installed. Not having used that myself, I can't really be of much help,
but you should first of all check that if you run a python2 prompt,
"import gpredict" doesn't fail with the same error.

Best regards,
Marcus

On 03/18/2016 12:43 PM, ERNEST MATEY wrote:
> Hi All,
>
> I am trying to track Satellite for CW  signal receiving and analysis
> on my GNURadio.  
> I know I need some tracking with Doppler shift. 
> What is the best way to do this?
>
> Now, I have GPredict installed hoping to use it. 
> I have added the GPredict doppler block to my GRC library blocks and
> added the block to my flow graph hoping to get Doppler shift from my
> engaged GPredict 
> I have set my Ports correctly but I have an error.
>
> ImportError: No module named gpredict. 
>
> What can I do?  
>
> I also learnt I can control my receiver ( Hackrf) frequency dir‎ectly
> from Gpredict using Hamlib. Will this work?  
> I tried to install Hamlib but installation says will delete some GRC
> files before Hamlib will work‎. I don't want to temper with my healthy
> running GRC 
>
> What can I do for my Doppler Shift?
>
> I am on Ubuntu 14 and I am very new to these thing
>
> Thank you for sharing your expertise.
> God Bless you!  
>
>
>
>
> Sent from my BlackBerry 10 smartphone.
>
>
>
>
>
> ___
> 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] Dev Call March: Moved to the 31st

[Martin Braun]

Hi everyone,

apologies for the late notice, but we have to move the dev call to the
31st (two weeks from now), since too many of the usual suspects are out
and about today.

We'll send out another announcement once it's closer.

Cheers,
Martin

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

Re: [Discuss-gnuradio] dive into gnu-radio

[Anon Lister]

(oops, didn't reply list).

Ahahaha. I was thinking of that block when I made my last comment.

On Wed, Mar 16, 2016 at 8:40 PM, Anon Lister  wrote:

> Ahahaha. I was thinking of that block when I made my last comment.
>
> On Wed, Mar 16, 2016 at 8:34 PM, Timothée COCAULT <
> timothee.coca...@gmail.com> wrote:
>
>> Hi,
>>
>> 2016-03-16 20:36 GMT+01:00 Desmond Crozby :
>>
>>> What I need is:
>>> 1) understand the blocks, their purpose and what they do
>>> 2) learn how to create a minimal scenario using grc
>>> 3) learn how to create blocks of my own
>>> 4) create more complicated scenario.
>>>
>>> I think there is cruel lack of explanation (not documentation) for the
>> GNU Radio blocks.
>> The example that struck me is the M clock recovery block.
>> The resources available are the code, the documentation, and the paper
>> cited in the documentation (not available for free though).
>> However, the best resource I found was a blog post [1] giving some notes,
>> facts and illustration on how this block works.
>> It's not an in-depth view of the algorithm used, but gives some hints on
>> how to use the block in practice.
>>
>> This is really the kind of things I would love to see (and contribute !)
>> for each block, but AFAIK, there is no place in the gnuradio ecosystem for
>> such documentation.
>>
>> [1]
>> https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/
>>
>>
>>
>> 2016-03-16 22:10 GMT+01:00 Martin Braun :
>>
>>> Now, there's lots of very good books out there that go into DSP and
>>> wireless communication. They're usually written to address
>>> university-level students. But how do we condense them into nice and
>>> easy tutorials? It's hard.
>>>
>>
>> Now concerning learning DSP theory, I feel that "book knowledge" or
>> tutorials isn't enough for using GNU Radio.
>> For example, sometimes I can't stay if my signal looks good or if it's
>> just noise. If my demodulation flowgraph doesn't work, I don't know which
>> step messed up, how to check if my data makes sense, which parameter I
>> should change.
>>
>> This is the kind of things you get by seeing experimented people tackle
>> real life problems.
>> I watched a workshop of Balint Seeber (at DEF CON) and learned some great
>> things on DSP, analysis, and GNU Radio.
>> These kind of resources are really great, and I'd love to see more of
>> them.
>>
>> Cheers,
>>
>> Timothée.
>>
>> 2016-03-16 22:53 GMT+01:00 Tom Coleman :
>>
>>>
>>> On Mar 16, 2016, at 3:36 PM, Desmond Crozby  wrote:
>>>
>>> …
>>>
>>>
>>> I saw this reading suggestion:
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading ,
>>> but the list is extensive and grouped by topic, basically I don't know
>>> where to start from.
>>>
>>>
>>> Software Radio in General
>>> Has anyone bothered to check these links lately?
>>>
>>>
>>>
>>> ___
>>> 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

Re: [Discuss-gnuradio] how to handle sources with variable bitrate

[Nikos Balkanas]

Hi,

Have you tried using a FIFO block in your flow? There a few around and it
seems to me it would normalize your flow.

BR,
Nikos

On Thu, Mar 17, 2016 at 10:01 AM, Anselm Karl <
anselmkarl.in...@googlemail.com> wrote:

> Hi all,
>
> i want to transmitt a video stream with gnuradio and usrps. There are some
> examples on the web and i got it working with vlc.
>
> The problem is, that the playback is quite choppey. This is because the
> digital transmission over the usrps has a fixed rate but the encoded video
> has a variable rate. If i set the transmission rate higher than the (mean)
> rate of the video, i get a lot of underruns on the tranmitting usrp (=
> chopped of rf signal). Which is bad because the transmission designed to be
> continous (for example the clockloop, ...).
>
> The transmission is based on fixed size fec code blocks starting with an
> preambel. A possible solution could be to stuff zeros between two blocks
> while waiting on the (video) source. On the receiver this stuffed zeros
> would be trown away automatically.
>
> That "zero stuffing" could be realized with a block, that puts out N (N=
> payload size of one block) input samples (first sample marked with a tag)
> at one "piece" or (if it has no N input samples in some internal buffer) it
> puts out zeros). Based on the tag a downstream block could mux in the
> preambel and everything would be fine.
>
> But here is my question:
> I don´t know how to write a block, that always has output samples
> available. Is there i kind of a non-blocking block template?
>
>
> Best regards,
>
> *Anselm*
>
>
>
> ___
> 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] declare_sample_delay cannot handle large delay?

[Martin Braun]

I haven't looked at the code, but it maybe a problem if the sample delay
is larger than the number of samples per work() call (because of pruning).

This sounds like a bug -- can you please post an issue on gnuradio.org?
Thanks!

M

On 03/14/2016 02:00 PM, Liyang Zhang wrote:
> Hi all,
> 
> I am playing with gnuradio and USRP but find something “weird”.
> I am using a custom block with history samples. Since delay on stream tags is 
> introduced, I use declare_sample_delay to offset it. So in the constructor of 
> my custom block it is like:
> set_history(hist_len+1);
> declare_sample_delay(hist_len);
> 
> In experiments I found that it works well when hist_len is small. But if I 
> set it to a rather large value (e.g., 1000), the output just lose all the 
> tags the block is supposed to pass.
> So I presume the scheduler cannot handle large delay?
> 
> Thanks.
> 
> -
> Liyang Zhang
> PhD Candidate
> Department of Electrical and Computer Engineering
> Northeastern University
> Email: liyan...@ece.neu.edu
> 
> 
> 
> 
> ___
> 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] diminishing returns with increasing frequency offset

[tom x]

Hi,

Bastian,

I tried doubling both, the sample rate to 8MHz and Omega to 4, but still no
progress. The setup is simply the 802.15.4 PHY block connected to a USRP
source, listening for an over the air transmission. Can you give some
insight on how you picked the other MM Clock Recovery params? Is there any
other dependence in the PHY block? The papers and guides I looked at
explain what the MM params are but don't give much intuition for choosing
them.

Additionally, based on posts in this thread:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-07/msg00585.html ,
 I thought it would be better to replace the MM CR block with a polyphase
clock sync block, as "M block isn't great in fading environments", and I
would like to receive possibly weak signals,
 Again, works for 4 MHz sample rate and 2 samples per symbol, but not 8 MHz
rate and 4 samples per signal. What do you think?

Thanks for reading,
Tom


On Sat, Mar 19, 2016 at 12:57 AM, Bastian Bloessl 
wrote:

> Hi,
>
> > On 18 Mar 2016, at 20:01, tom x  wrote:
> >
> >
> > Maybe there is an implicit dependence on 4MHz, in the parameters set by
> the Clock Recovery block? I am not sure.
> > If there's any other relevant info I can give, let me know.
>
> The omega parameter of the MM Clock Recovery defines the samples per
> symbol (here samples per chip). With a  chip rate of 2Mcps and a sample
> rate of 4MHz, it is currently set to 2. You will have to adjust this.
>
> Best,
> Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sample rate of file souce/sink

[Jesse Reich]

Thank you Marcus and Ed. I finally had a chance to look back at my GRC
flowgraph. Same data types in and out (complex for all blocks). And since I
have been trying to figure this out for awhile, I've taken away all other
blocks other than RTL-SDR Source -> File Sink and then File Sink ->
throttle -> QT Gui Sink.

I figured it out and turns out to be embarassingly simple after all. It
turns out I should've been paying attention to the output saying "invalid
sample rate: 10 Hz". It doesn't say what the sample rate was defaulting
too. But setting both rates in file sink and file source flowgraphs to
sample rates that are known to work (2e6) led to a playback that matches
real time.

Again, thank you both very much. Probably one of the best things about GRC
is the support everyone offers on this list serve.

Jesse

On Wed, Mar 16, 2016 at 9:25 AM Marcus Müller 
wrote:

> Hi Jesse,
>
> this is not embarassingly simple!
> So, the point is that GNU Radio is really totally agnostic when it comes
> to sampling rates. For all the blocks, sample streams are really nothing
> but a sequence of numbers. Whether the signal was physically sampled at
> 1MS/s or 1S/s doesn't matter; the only thing that matters is e.g. how long
> one event is in unit of samples (e.g. the signal source doesn't really use
> the sampling rate for anything but to calculate how long on period of
> cosine is – a signal source with a cosine frequency of 1kHz and a sampling
> rate of 32kHz will produce exactly the same signal as one with a sampling
> rate of 1 and a cosine frequency of 1/32; there's really no difference in
> behaviour).
>
> The architecture of GNU Radio implies that every block processes the input
> he has as fast as possible to produce output, with which the next block
> works as fast as possible and so on; the fact that there's a limit in
> processing speed of your file source comes because somewhere, a downstream
> block has a full input buffer, so the block before that can't produce
> samples, because there would be no space to put them.
>
> Now, if all your blocks were infinitely fast at processing samples, the
> job of the block providing this (that is a very common mechanism in
> buffered architectures, it's usually called *backpressure*) would always
> fall to the throttle block (whose only job is to do exactly that - only
> copy as many samples over per iteration as allowed to keep the
> time-averaged sampling rate at the specified limit).
>
> Now, if there's another block that effectively limits the rate of samples
> going through the flow graph, e.g. a complicated calculation that is
> CPU-bound, then that will put up its own backpressure. Together with the
> backpressure of the throttle block, that might decrease average rate even
> below the throttle's rate.
>
> For a deeper understanding of why this happens it would be necessary to
> look at your actual playback flowgraph and the blocks involved.
>
> Best regards,
> Marcus
>
> On 16.03.2016 02:29, Jesse Reich wrote:
>
> This is probably embarrassingly simple but I can't seem to find the answer
> anywhere. I just recorded a signal to a file sink with a sample rate of
> 100k. I go to use that file as a source with a throttle set to 100k and it
> seems to playback at approximately 1/10 the speed. When I step up the
> throttle sample rate to 1M it seems to be closer to real-time. What am I
> missing??
>
> Thanks,
> Jesse
>
>
> ___
> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Usman Haider]

Hi Community,

I have made my proposal for the subject GSoC idea. Please have a look and
give feedback. Thanks for your time.

https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf

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

[Discuss-gnuradio] GSOC '16: Signal Intelligence (gr-sigint) draft proposal

[Richardson, Christopher (richarc2)]

Hi,

I am just wondering if anyone could possibly take a
look at my draft GSOC '16 proposal for the gr-sigint idea.

https://www.dropbox.com/s/w2lf23kzj951rce/proposal.pdf?dl=1

Kind regards,

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

Re: [Discuss-gnuradio] how to handle sources with variable bitrate

[Francisco Albani]

Hi Anselm.

Go to http://lists.gnu.org/archive/html/discuss-gnuradio/ and search this
"Asynchronous source with zeros in between"

You will find an email I wrote to this list asking a similar question. I'm
not pasting a link here because I couldn't find the starting message; the
thread is split in many parts (I don't know why). I hope you should be able
to find all the pieces in the search results. If not, please write to me
and I will find a way of send it to you.

I think my problem was different that yours and my solution will not be
fit, but it may give you some ideas. The key was to bring the payload in a
PDU message and to have a block that manages the "padding" before entering
to the "stream domain".

Bye!


2016-03-17 5:50 GMT-03:00 Anselm Karl :

> Hi, Nikos,
>
> adding a buffer / fifo and matching the mean video rate to the rate of my
> transmission system should work.
>
> But i don't really want to match the rates, because i'll have to do that
> every time i change something on the source. It can be quite an effort,
> too. (Like interpolation the base-band signal) Or consider a asynchronous
> source (something like a serial terminal) with large intervals with no data.
>
> With the "zero stuffing solution" you just have to make sure, that the
> transmission is fast enough for the source, "plug in" the source and
> everything should be fine.
>
> I've done some gnu radio blocks. But i don't now how to tell the work
> function how many samples the down stream block needs. In my understanding
> the work functions gets some input samples and calculates some output
> samples out of them. It's like the block gets actively written to and
> passively read from. And i would need it the other way.
>
> BR,
> Anselm
>
>
>
> 2016-03-17 9:17 GMT+01:00 Nikos Balkanas :
>
>> Hi,
>>
>> Have you tried using a FIFO block in your flow? There a few around and it
>> seems to me it would normalize your flow.
>>
>> BR,
>> Nikos
>>
>> On Thu, Mar 17, 2016 at 10:01 AM, Anselm Karl <
>> anselmkarl.in...@googlemail.com> wrote:
>>
>>> Hi all,
>>>
>>> i want to transmitt a video stream with gnuradio and usrps. There are
>>> some examples on the web and i got it working with vlc.
>>>
>>> The problem is, that the playback is quite choppey. This is because the
>>> digital transmission over the usrps has a fixed rate but the encoded video
>>> has a variable rate. If i set the transmission rate higher than the (mean)
>>> rate of the video, i get a lot of underruns on the tranmitting usrp (=
>>> chopped of rf signal). Which is bad because the transmission designed to be
>>> continous (for example the clockloop, ...).
>>>
>>> The transmission is based on fixed size fec code blocks starting with an
>>> preambel. A possible solution could be to stuff zeros between two blocks
>>> while waiting on the (video) source. On the receiver this stuffed zeros
>>> would be trown away automatically.
>>>
>>> That "zero stuffing" could be realized with a block, that puts out N (N=
>>> payload size of one block) input samples (first sample marked with a tag)
>>> at one "piece" or (if it has no N input samples in some internal buffer) it
>>> puts out zeros). Based on the tag a downstream block could mux in the
>>> preambel and everything would be fine.
>>>
>>> But here is my question:
>>> I don´t know how to write a block, that always has output samples
>>> available. Is there i kind of a non-blocking block template?
>>>
>>>
>>> Best regards,
>>>
>>> *Anselm*
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
>
> --
> Mit freundlichen Grüßen
>
> *Anselm Karl*
>
>
>
> ___
> 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] dive into gnu-radio

[Martijn Moeling]

In reply to Kevin:

Your path seems pretty similar to mine, I started a few years ago with a RTL 
dongle and got away with receiving in a few SDR programs available for Mac. 
After getting bored by that I installed gnu radio and seemingly quickly I got 
success with getting set-up what I needed. Since everybody can receive but we 
hams can transmit to I fell in love with the b200mini and bought one. So 
created some transmitters (like wbfm stereo with RDS) and as long as it was 
"broadcasting" this worked very well. With a 80W amp I was heard and RDS was 
decoded remotely.

My next step was to make a simplex nbfm trx so I could use my setup for 
communicating over a repeater. I never got this to work as I do not seem to be 
able to get the RX/TX switching to work within Grc. I searched and got answers 
from this list quickly, Tagged stream. Although I understand the concept, I 
never got this working and I have the feeling I miss something. I have a hard 
time formulating the question. 

The mentioning of the RRC filter is something different and sure I need to get 
more theoretical background but my math skills are far away from what is 
needed, currently I combine my extremely demanding job with math learning. 

As a ham operator, I am interested in a multi mode/band SDR solution which I 
can expand with digital modes one by one, up to the point where I can transmit 
analog ATV from say a connected frame grabber and I opted for this as my 
learning curve. Doing so by looking at examples, related theory etc.

If I only could get my b200mini to switch between RX and TX for simplex 
operations I would be a happy man for now.. (Off topic for this thread). But 
all examples I found claiming to do so never worked with my setup. (Most seem 
to switch to null sinks to stop transmitting)

General:
I completely agree with all of the two cents everyone has send. Although not 
everybody is getting that deep into it to make use of gnu radio, as said I want 
my usrp to replace my dedicated rigs.

Martijn



Verstuurd vanaf mijn iPad

> Op 18 mrt. 2016 om 04:10 heeft Kevin McQuiggin  het volgende 
> geschreven:
> 
> Hi Martijn:
> 
> Two cents from me, a relative non-technical newbie, also a long-time amateur 
> radio operator.  My educational and professional background is in computing 
> science and a bit of math.
> 
> I first found gnuradio a few years ago, and had a similar experience to 
> yours.  I played around with it, did some of the tutorials, but quickly got 
> slain by my lack of technical DSP background, and (back then especially) the 
> lack of clear documentation on the blocks.
> 
> I got discouraged and removed my gnuradio installation.
> 
> However, I knew that I wanted to know more, and understand gnuradio better, 
> as the power of the package was obvious to me.  I saw this as a learning 
> challenge.  I embarked on what ended up being about 1.5 years of reading and 
> coding, outside of gnuradio.  
> 
> I found a fantastic couple of books, most notably the free "Digital Signal 
> Processing: A Guide for Scientists and Engineers".  See http://dspguide.com.  
> I eventually bought a hardcopy of the book.
> 
> I used the book to code up some self-learning programs, for example a DTMF 
> decoder, and got my head around a lot of the DSP concepts.  More reading 
> augmented this, and I returned to gnuradio about a year ago with a $20 RTL 
> dongle in hand.
> 
> The tutorials now made more sense, and while I was still on a steep learning 
> hill, things went well.  I upgraded my hardware to an Ettus B200, and now 
> feel a bit on top of things.  Stick with the cheap dongle for awhile.  I 
> initially upgraded to the B200 as I wanted to build a transmitter.  However 
> the RX is WAY better on the Ettus unit too, it was a fantastic jump and good 
> investment.
> 
> If you have time and no particular deadline, I'd recommend this approach.
> 
> As for projects, I've built an FM RDS receiver and decoder, an FM SCA 
> receiver, an SCA transmitter,  Multi-channel HF CW decoder (via an up 
> converter), and am currently working on a clear channel Inmarsat decoder - 
> this one is about half done.  My approach is to use gnuradio for the 
> demodulator, then pipe the bitstream to a C program over a gnuradio TCP or 
> UDP sink.  The RDS code, for example, is almost 1000 lines of C, so these 
> things are not intrinsically "easy".  Incredible learning value and sense of 
> satisfaction though when your code/flowgraph actually works!
> 
> Things like the need for an RRC filter become clear with reading, review of 
> (say) RDS specs, and head scratching over a couple of weeks.  Read about 
> "matched filters" and you'll understand what the RRC block does.
> 
> My recommendation is to recognize that this is a non-trivial field and big 
> learning opportunity, and grab a couple of books like the (free) one by Smith 
> above.  Read for awhile, then see where you're at.
> 
> It does grow on you with 

[Discuss-gnuradio] Data Formatting in GNURadio (WiFi)

[Abhinav Jadon]

Hi,
I wrote a matlab scripts that generates the wifi packets for a given
payload.
The output is of the format 
I dumped the output in a bin file.
It is my understanding that the complex type file source reads the input
(bin) file in a gr_complex data type format ie reading 32 bits from the bin
file at a time and then converting the first 16bits (corresponding to real
part/I) and last 16bits (corresponding to img part/Q) to float16 format and
thus with this understanding, I formatted the data accordingly while
dumping the data into the bin file.
The issue is I plug that file source on repeat mode to the UHD block. The
packet is not detected on the receiver side.Is there something wrong with
my understanding of data formatting ?

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

Re: [Discuss-gnuradio] Sample rate of file souce/sink

[Marcus Müller]

Hi Jesse,

this is not embarassingly simple!
So, the point is that GNU Radio is really totally agnostic when it comes
to sampling rates. For all the blocks, sample streams are really nothing
but a sequence of numbers. Whether the signal was physically sampled at
1MS/s or 1S/s doesn't matter; the only thing that matters is e.g. how
long one event is in unit of samples (e.g. the signal source doesn't
really use the sampling rate for anything but to calculate how long on
period of cosine is – a signal source with a cosine frequency of 1kHz
and a sampling rate of 32kHz will produce exactly the same signal as one
with a sampling rate of 1 and a cosine frequency of 1/32; there's really
no difference in behaviour).

The architecture of GNU Radio implies that every block processes the
input he has as fast as possible to produce output, with which the next
block works as fast as possible and so on; the fact that there's a limit
in processing speed of your file source comes because somewhere, a
downstream block has a full input buffer, so the block before that can't
produce samples, because there would be no space to put them.

Now, if all your blocks were infinitely fast at processing samples, the
job of the block providing this (that is a very common mechanism in
buffered architectures, it's usually called /backpressure/) would always
fall to the throttle block (whose only job is to do exactly that - only
copy as many samples over per iteration as allowed to keep the
time-averaged sampling rate at the specified limit).

Now, if there's another block that effectively limits the rate of
samples going through the flow graph, e.g. a complicated calculation
that is CPU-bound, then that will put up its own backpressure. Together
with the backpressure of the throttle block, that might decrease average
rate even below the throttle's rate.

For a deeper understanding of why this happens it would be necessary to
look at your actual playback flowgraph and the blocks involved.

Best regards,
Marcus
On 16.03.2016 02:29, Jesse Reich wrote:
> This is probably embarrassingly simple but I can't seem to find the
> answer anywhere. I just recorded a signal to a file sink with a sample
> rate of 100k. I go to use that file as a source with a throttle set to
> 100k and it seems to playback at approximately 1/10 the speed. When I
> step up the throttle sample rate to 1M it seems to be closer to
> real-time. What am I missing??
>
> Thanks,
> Jesse
>
>
> ___
> 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] Lock onto QPSK signal

[Marcus Müller]

Hi Henry,

On 16.03.2016 15:24, Henry Barton wrote:
> Wow, thanks for the comprehensive reply. You covered a lot of material
> and I like how simple you make it.
Did I? I pretty much went ahead and threw assumptions at you like "hey,
that's a dot product, and you'll know how to deal with that" :)
>
> >"amont of similarity between the RX signal shifted in time by 휏 and
> the right spreading sequence". Look for the peak. That's your timing
> offset.
> I guess that means if I have an x16 chip rate, I try applying the
> spreading code to the RX signal at different symbol shifts. So I might
> have a buffer of received symbols and shift it 1 symbol each time as I
> try the spreading code on it, then see which produces the strongest
> result?
Pretty much! You can also oversample to get a more fine-tuned result.
>
> >still "pretty" orthogonal when out of sync
> I hadn't even considered that. So turning on your transmitter by
> chance at just the right time can make your orthogonal code ruin
> others' signals?
Nah, spreading codes used usually are pretty good, but yes, there's
compromises to be made when your code can't be infinitely long but you
want to have a lot of users etc.
>
> >frequency-selective channels
> What's that? Is it like selective fading?
That.
> I don't need high throughput; my project aims to transmit 2.064
> Mbit/sec in a 24 MHz channel in the 900 MHz band.
No way 24 MHz are going to be flat in frequency domain :)
> I use QPSK/4QAM because it has 1/2 the bandwidth of BPSK while still
> being much more error-resistant than high-order QAM.
Sounds like a good choice; so 2.064 Mb/s/(2b/S) = 1.032 MS/s, so I guess
you're aiming for a spreading factor > 10?

Cheers,
Marcus
>
>
>
>
> 
> To: discuss-gnuradio@gnu.org
> From: marcus.muel...@ettus.com
> Date: Wed, 16 Mar 2016 14:03:32 +0100
> Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal
>
> Hi Henry,
>
> Interesting questions!
>
> On 16.03.2016 03:48, Henry Barton wrote:
>
> Hi, does anyone know of any good tutorials that explain how to
> lock onto the clock of a QPSK signal and/or correlate? I know this
> is all very simple in GNUradio, but I hope someone knows of a
> website or, preferably, a video series that will explain this.
>
> Have you read the GNU Radio Guided Tutorials[1]? Chapter 7 (you should
> really read 1-5 before) deals with PSK reception and timing recovery.
> A video series? Hm; to be honest, that does sound like you want to
> attend a full course on the basics and some lectures on advanced
> methods of digital communications. I do think there's some good
> lecture recordings out there[2], but inherently, they are pretty
> sequential, so although you'll learn a lot, you'd still have to have
> the perseverance to spend quite some hours till you come to the point
> of clock sync for CDMA.
>
> Personally: I'm not very much of a "I learn from videos" person. I do
> like the kind of introduction where someone stands in front and
> derives the methods and formulas "live" on a blackboard, but somehow,
> my concentration suffers when watching a video while mentally (and
> sometimes, on paper) take notes, at least for complex mathematical
> stuff. I'd rather go and loan a book from a local library. I /think/
> Sklar's /Digital Communications/ would be the go-to ressource on CDMA
> clock sync.
>
>  
>
> If I have 10 different QPSK users, spreaded and on the same
> frequency, that would make CDMA.
>
> Assuming these 10 users used sufficiently orthogonal spreading sequences!
>
> Assuming no manufacturing tolerance or frequency drift, all the
> clocks on the transmitters would be perfectly the same.
>
> aside from a phase offset
>
> What I’m trying to understand is:
>
>  
>
> 1.   No two separate transmitters can ever be perfectly in
> sync. Even if the clocks were 100% accurate, User 1 might start
> his transmitter at 10:00:00 AM while User 2 starts his at
> 10:00:00.250 AM. The signals would be a little out of sync with
> each other. How would I pick one out in DSP?
>
> OK, what I describe in the following is somewhat like a
> textbook/naive/classical approach; in practice, devices /are/ smarter.
>
> Well, in CDMA, if you build the dot product of your received signal
> and User A's spreading sequency, you'll get a large magnitude as a
> result, if the signal actually contains A's TX. On the other hand, the
> spreading sequences of A and any other user are orthogonal, i.e. the
> dot product is zero. Assuming interference is linear (i.e. RX signal
> after channel(signal from A + signal from B) = RX signal after
> channel(signal from A) + RX signal after channel(signal from B)), and
> assuming the spreading sequences were chosen that they are not only
> perfectly orthogonal when in sync, but still "pretty" orthogonal when
> out of sync, this works reasonably well. That's a property that a few
> known 

Re: [Discuss-gnuradio] Lock onto QPSK signal

[Marcus Müller]

Hi Henry,

Interesting questions!

On 16.03.2016 03:48, Henry Barton wrote:
>
> Hi, does anyone know of any good tutorials that explain how to lock
> onto the clock of a QPSK signal and/or correlate? I know this is all
> very simple in GNUradio, but I hope someone knows of a website or,
> preferably, a video series that will explain this.
>
Have you read the GNU Radio Guided Tutorials[1]? Chapter 7 (you should
really read 1-5 before) deals with PSK reception and timing recovery.
A video series? Hm; to be honest, that does sound like you want to
attend a full course on the basics and some lectures on advanced methods
of digital communications. I do think there's some good lecture
recordings out there[2], but inherently, they are pretty sequential, so
although you'll learn a lot, you'd still have to have the perseverance
to spend quite some hours till you come to the point of clock sync for CDMA.

Personally: I'm not very much of a "I learn from videos" person. I do
like the kind of introduction where someone stands in front and derives
the methods and formulas "live" on a blackboard, but somehow, my
concentration suffers when watching a video while mentally (and
sometimes, on paper) take notes, at least for complex mathematical
stuff. I'd rather go and loan a book from a local library. I /think/
Sklar's /Digital Communications/ would be the go-to ressource on CDMA
clock sync.

>  
>
> If I have 10 different QPSK users, spreaded and on the same frequency,
> that would make CDMA.
>
Assuming these 10 users used sufficiently orthogonal spreading sequences!
>
> Assuming no manufacturing tolerance or frequency drift, all the clocks
> on the transmitters would be perfectly the same.
>
aside from a phase offset
>
> What I’m trying to understand is:
>
>  
>
> 1.   No two separate transmitters can ever be perfectly in sync.
> Even if the clocks were 100% accurate, User 1 might start his
> transmitter at 10:00:00 AM while User 2 starts his at 10:00:00.250 AM.
> The signals would be a little out of sync with each other. How would I
> pick one out in DSP?
>
OK, what I describe in the following is somewhat like a
textbook/naive/classical approach; in practice, devices /are/ smarter.

Well, in CDMA, if you build the dot product of your received signal and
User A's spreading sequency, you'll get a large magnitude as a result,
if the signal actually contains A's TX. On the other hand, the spreading
sequences of A and any other user are orthogonal, i.e. the dot product
is zero. Assuming interference is linear (i.e. RX signal after
channel(signal from A + signal from B) = RX signal after channel(signal
from A) + RX signal after channel(signal from B)), and assuming the
spreading sequences were chosen that they are not only perfectly
orthogonal when in sync, but still "pretty" orthogonal when out of sync,
this works reasonably well. That's a property that a few known spreading
sequences fulfill.

Knowing that the "other" users' signals won't interfere with the result
much, you just correlate your RX signal (that you think might contain
User A's signal) with User A's spreading sequence. That'll give you a
function describing "amont of similarity between the RX signal shifted
in time by 휏 and the right spreading sequence". Look for the peak.
That's your timing offset.

Note that correlation means "take signal A and multiply point wise with
signal B, sum up, note down, then shift first signal a bit and repeat",
which is "(), 휏=[0, N)" in DSP if you want so,
and obviously has length(B)*N multiplications and summations – not an
overly fun thing to do in real-time (N will roughly be length(B)).
Hence, fast correlation based on multiplying in frequency domain
(signal->FFT->multiplication->FFT) is often used.
>
> 2.   I’ve heard of “clock recovery”, which implies to me that you
> “look” at a signal to find its clock, but surely you must have at
> least a very close idea of the desired clock before you can begin, right?
>
Well, yes. If you don't know the clock offset at all, you wouldn't know
how much bandwidth to observe, and then you couldn't select a suitable
sampling rate etc.
Often, sync procedures have multiple steps, e.g. a rough frequency
estimation (done by something like "let's look where there's a ca X Hz
wide occupied piece of spectrum and find its center"), a fine frequency
control and timing recovery.
For CDMA, you can rely on the symbol-duration periodicity of the
autocorrelation.
>
> If you had 3 different CDMA signals  but different chip rates, they
> could probably coexist nicely, but how would you pick out the faster
> signal or the slower one? (see picture)
>
If your chip rates are actually somehow fixedly related and you can make
sure that the different chips still are mutually orthogonal, yes.
In practice, the CDMA orthogonality breaks down for "bad" combinations
especially for frequency-selective channels (which is probably one of
the central reasons why CDMA was abandoned after 3G 

Re: [Discuss-gnuradio] packetized data transmission

[SangHyuk Kim]

Hi,

I'm using gnuradio/gr-digital/example/ofdm/benchmark_tx.py and
benchmark_rx.py

You can send and receive packet using the example with some parameters
(bandwidth, frequency, etc.)

Also similar example are on
gnuradio/gr-digital/example/narrowband/benchmark_tx(rx).py.

Two benchmark examples use different parameters and purpose also different.

I hope it will help you.


2016-03-16 23:53 GMT+09:00 Anurag Gupta :

> I am using GNU RADIO with SDR kits for my project in which I need to send
> packetized data from the transmitter to the receiver . I want to measure
> quality degradation parameters like packet loss,throughput. Please give me
> some idea to implement this.
>
> --
>
> *Thanks and Regards,Anurag Gupta*
>
> ___
> 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] dive into gnu-radio

[Desmond Crozby]

Hello,

This might be a discussion that you have faced multiple times, but please
bear with me until the end of this email. (I know how busy guys approach
emails coming from the mailing list).

I am a guy who recently got to know about gnu-radio, and it raised interest
in me. To get into the topic, I followed the suggestions in the website and
started from the guided tutorials:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials. So far I
managed to complete the tutorial series up to the C++ programming section.

Throughout the tutorials I managed to understand the basic concepts and
terminology about gnu-radio. Also using the GRC is fine. Unfortunately, I
am a computer scientists and I have little to no background in digital
signal processing and electrical engineering. Hence, for me it is quite
hard to figure out the purpose of the blocks. Of course, as a computer guy
it is easy to follow the tutorials, because they basically show what
changes to be done where, but the semantic behind those changes, as well as
the semantic behind the arrangement of the blocks remains a mystery to me.

So far in my work I have dealt with topics related to the higher layers in
computer networks, but now I want to play around with lower layers too. I
am sure in the community there are guys who have similar background, and
have to follow an inverse track -- from upper layers, downwards. What is
some good starting point?

If you say the tutorials are, I will have to disagree, because I completed
everything successfully, but if one asks me what happens in those modules,
or what each block does, I would not be able to answer for my life.
Besides, in the programming tutorials where one is taught how to create OOT
things got even more complicated.

I don't want to be misunderstood, I am not saying the tutorials are bad.
Obviously someone invested the time and effort to create them, but I fancy
more the "learning by doing" way of tutorials. Those which include explicit
tasks, starting from a minimal working example. The OMNeT++ TicToc tutorial
is a very nice reference, or the Codecademy way of teaching.

To go back to the initial Q, what is the go-to approach for someone of CS
background who wants to become efficient in gnu-radio. Books? Online
material?

I saw this reading suggestion:
https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading , but
the list is extensive and grouped by topic, basically I don't know where to
start from.

What I need is:
1) understand the blocks, their purpose and what they do
2) learn how to create a minimal scenario using grc
3) learn how to create blocks of my own
4) create more complicated scenario.

I wanted to ask the same question in stackoverflow, as I have seen people
from the community hanging around there. But, the amount of shitstorm
coming from there is amazing when asking about learning pointers... They
mark the Q as "opinion-based" immediately.

Hope anyone has the nerves, time and courtesy to write back. I'm certain it
will serve as a nice starting point to future enthusiasts.

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

Re: [Discuss-gnuradio] dive into gnu-radio

[Desmond Crozby]

Hello Guys,

I am really happy to see my question generated some quality discussion. It
is encouraging and I hope other guys stumbling upon the post will
contribute two cents or so.

One thing I can do is to take your suggestions and start with the course
materials and the textbooks. Then, classify them based on suitability and
to some extent create the "gnu-radio for the CS guys" intro starter pack.

The only way to have more people who would like to help with documentation
and alike is to create some entry point to the community so it grows. Of
course, becoming more inclusive will create ground for emails starting with:

Hi Sir,
> 
> Sincerely yours,


But yeah, what can you do...

Regards,
D

On Thu, Mar 17, 2016 at 9:27 AM, Andrej Rode 
wrote:

> Hi Desmond and everyone else,
>
> > With my knowledge the mechanics of
> > writing an OOT module and getting it to show up in GRC is fairly simple.
> > It's the knowledge of radio signals and digital signal processing where I
> > have the most difficulty.
>
> as a EE student I can recommend getting familiar with the concepts taught
> in
> the lectures 'Signals & Systems', 'Digital Communications I+II' and maybe
> 'Digital Signal Processing'. Material as well as recordings can be found at
> [0]. Before looking through the lectures you should now there are some
> requirements in mathematics you should know. For someone with a
> (university)
> background in CS I think there should be a way to get in touch with
> integral
> transforms/discrete integral transforms and the concept behind
> digital/discrete thinking.
>
> Concering literature I would recommend to look for a book with a title
> 'Signals and Systems', unfortunatly I can only name a german book for
> recommendation for this one.  If you are familiar with the basic concept of
> signal processing you could try to get your hands on 'Digital
> Communications'
> by John G. Proakis. It is written in a very mathematical way but you
> should be
> able to understand the concepts behind it and then verify them by looking
> through GNU Radio blocks or writing some blocks yourself.
>
> That is what I can recommend you from an EE students' point of view. I
> started
> dealing with signal processing about two years ago. And I think with a
> background in some kind of university mathematics you should be able to
> grasp
> the basic concepts of digital signal processing in about a half year or
> less.
> Most of the thinks in DSP are based on math and so are the blocks/Code in
> GNU
> Radio.
>
> If there is something missing or I am wrong, correct me :)
>
> Best Regards,
> Andrej
>
> [0]
> http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/
>
>
> ___
> 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 runtime error "Reference Clock PLL failed to lock to GPSDO source"

[Nikos Balkanas]

Hi,

Recently I have come across these flow runtime errors. This host flow (not
rfnoc) will generate and execute fine, but after sometime this error
appears (baudline is never started):

-- [0/FIFO_0] sr_write(126, 00C1EA12, 0)
Traceback (most recent call last):
File "/home/nikos/Desktop/FFT.py", line 168, in 
main()
File "/home/nikos/Desktop/FFT.py", line 156, in main
tb = top_block_cls()
File "/home/nikos/Desktop/FFT.py", line 78, in __init__
self.uhd_usrp_source_0.set_clock_source("gpsdo", 0)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3033, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self, *args, **kwargs)
RuntimeError: RuntimeError: Reference Clock PLL failed to lock to gpsdo
source.
Got bus address:
"unix:abstract=/tmp/dbus-x6BbkjOd9B,guid=04195e4b45c39426139a985156e8cb3f"
Connected to accessibility bus at:
"unix:abstract=/tmp/dbus-x6BbkjOd9B,guid=04195e4b45c39426139a985156e8cb3f"
Registered DEC: true

>>> Done (return code 1)

grc file and top_block attached. Any advise would be appreciated.
TIA,
Nikos


FFT.grc
Description: Binary data


FFT.py
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Andrej Rode]

Hi Desmond and everyone else, 

> With my knowledge the mechanics of
> writing an OOT module and getting it to show up in GRC is fairly simple.
> It's the knowledge of radio signals and digital signal processing where I
> have the most difficulty.

as a EE student I can recommend getting familiar with the concepts taught in 
the lectures 'Signals & Systems', 'Digital Communications I+II' and maybe 
'Digital Signal Processing'. Material as well as recordings can be found at 
[0]. Before looking through the lectures you should now there are some 
requirements in mathematics you should know. For someone with a (university) 
background in CS I think there should be a way to get in touch with integral 
transforms/discrete integral transforms and the concept behind 
digital/discrete thinking.

Concering literature I would recommend to look for a book with a title 
'Signals and Systems', unfortunatly I can only name a german book for 
recommendation for this one.  If you are familiar with the basic concept of 
signal processing you could try to get your hands on 'Digital Communications' 
by John G. Proakis. It is written in a very mathematical way but you should be 
able to understand the concepts behind it and then verify them by looking 
through GNU Radio blocks or writing some blocks yourself. 

That is what I can recommend you from an EE students' point of view. I started 
dealing with signal processing about two years ago. And I think with a 
background in some kind of university mathematics you should be able to grasp 
the basic concepts of digital signal processing in about a half year or less.
Most of the thinks in DSP are based on math and so are the blocks/Code in GNU 
Radio.

If there is something missing or I am wrong, correct me :)

Best Regards, 
Andrej

[0] http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/


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

[Discuss-gnuradio] how to handle sources with variable bitrate

[Anselm Karl]

Hi all,

i want to transmitt a video stream with gnuradio and usrps. There are some
examples on the web and i got it working with vlc.

The problem is, that the playback is quite choppey. This is because the
digital transmission over the usrps has a fixed rate but the encoded video
has a variable rate. If i set the transmission rate higher than the (mean)
rate of the video, i get a lot of underruns on the tranmitting usrp (=
chopped of rf signal). Which is bad because the transmission designed to be
continous (for example the clockloop, ...).

The transmission is based on fixed size fec code blocks starting with an
preambel. A possible solution could be to stuff zeros between two blocks
while waiting on the (video) source. On the receiver this stuffed zeros
would be trown away automatically.

That "zero stuffing" could be realized with a block, that puts out N (N=
payload size of one block) input samples (first sample marked with a tag)
at one "piece" or (if it has no N input samples in some internal buffer) it
puts out zeros). Based on the tag a downstream block could mux in the
preambel and everything would be fine.

But here is my question:
I don´t know how to write a block, that always has output samples
available. Is there i kind of a non-blocking block template?


Best regards,

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

Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

[Marcus Müller]

Hi SangHyuk

On 16.03.2016 02:21, SangHyuk Kim wrote:
> Dear Nathan,
>
> I know QAM is the fastest modulation because it can carry more bits
> per symbol. This is a reason why I use QAM modulation.
>
> As bits per symbol level is higher, bit error rates will be increased.
> I expected it returns feasible error rate. However, error rates were
> too high. So I wondered "is this normal case or what is it I'm missing".
Well, how do you figure it is "too high"?

I mean, the math is all there: A packet of length N symbols for which we
assume that the error probability is identical and independent fails
when at least one of these flips (assuming CRC is collision free, which
we can easily do).
The packet error probability is then the complementary to the packet
success probility, which is the product of the individual symbol error
probabilities. These being IID (as assumed above), this packet success
probability is instantly clear:
$P_\text{packet good} = (P_\text{symbol good})^N$.


Just a quick example: If your channel's SNR and your modulation / pulse
shaping choices lead to a symbol error probability of $10^{-4}$ (which
is pretty good), and your packets are 1500B long, and you're using
16QAM, i.e. 4b/Symbol, then your packet has $N=3000$ symbols:

$P_\text{packet good} = (P_\text{symbol good})^N =
(1-10^{-4})^{3000}\approx 74\%$

But what symbol error probabilities are realistic?

Let's assume we're doing 16-QAM. One can, based on a noise model (which
typically has Gaussian noise amplitude) derive the error probabilities
for all 16 QAM points (using the Q function) that another point is
detected instead, average that, and come to a formula that gives one
symbol error probabilty $P_\text{symbol wrong} = 1-P_\text{symbol
good}$. Not going to do that here. Many digital communication textbooks
do that, and if you're used to dealing with probabilities, you can do
that on your own. Usually a shortcut is taken and only the probabilities
of switching to the nearest neighboring constellation points are
considered. That approximation holds well for QAM.

The approximate solution given in such calculation is typically (you
should really do some literature research on your own) something like

$P_\text{symbol wrong} \approx 3\, Q\left(\frac{2}{\sqrt
5}\sqrt{\frac{E_b}{N_0}}\right)$

with the Q-Function $Q(x)$ being the probality that a normal Gaussian
random variable takes a value larger than $x$,
$\frac{E_b}{N_0}$ being the bit energy to noise power density ratio;
that should be defined as
$\frac{E_b}{N_0} = \text{SNR} \cdot
\frac{B_\text{signal}}{r_\text{bits}}$, i.e. the SNR on the channel
times the spectrum-per-bit-rate.

You do the math; is the packet error rate really so much higher than
what you'd expect under these formulas? If it really is by more than a
factor of 2, this is worth looking into any further. If it is not: well,
you won't be much better with an SNR like that.

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

Re: [Discuss-gnuradio] How to create a python block

[Martin Braun]

GNU Radio supports Python blocks out-of-the-box. You can use gr_modtool
to create them, if you like. Also check out our qa codes for some
examples (including message based blocks).

Cheers,
M

On 03/16/2016 01:51 PM, Dennis Glatting wrote:
> This is probably a dumb question but someone has to ask them...
> 
> 
> I have a run graph with c++ blocks: a receiver block, a transmitter
> block, and a manipulator block. I want to have the manipulator block
> editable from the run graph where the user can insert python code.
> Specifically:
> 
> 1) The block has two message ports: an "in" port and an "out" port.
> 
> 2) A user can write and type python code into the block to manipulate
> the message received on the input port and post the manipulated message
> on the output port.
> 
> 3) The python code may have to call other functions, such as updating a
> hash code.
> 
> How might I do that? I could do a c++ wrap around exec() but I believe
> there has to be an easier way since GNURadio is a combination of python
> and c++.
> 
> The incoming messages arrive at a low frequency and a low data rate so
> I'm not really concerned about processing time.
> 
> 
> 
> 
>  
> 
> 
> ___
> 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] diminishing returns with increasing frequency offset

[tom x]

It's strange but the only sampling rate that works is 4 MHz; Packets are
not decoded when the sampling rate is set above this rate.

Thanks,
Tom

On Thu, Mar 17, 2016 at 7:33 PM, Martin Braun 
wrote:

> What's your sampling rate? The further you go towards the edge of your
> Nyquist zone, the more the anti-aliasing filter might be kicking in.
>
> Cheers,
> Martin
>
> On 03/17/2016 10:23 AM, tom x wrote:
> > Hi,
> >
> > My setup is a USRP N210 receiving from a transmitter sending a few
> > packets a second. (The packets are decoded with Bloessl's 802.15.4 PHY
> > block if it matters)
> >
> > Let's say the transmitter is sending data on frequency f_t.
> >
> > I set the USRP to receive on f_t plus an offset f_o.
> > The next block is a frequency xlating FIR filter centered at -f_o.
> > This is intended to correct the offset.
> >
> > I made a slider block for f_o and allowed it to vary between 0 and 3MHz.
> > I need an offset of a few MHz for my application. However, the number of
> > packets received seems to drops as I increase f_o. I get almost no
> > packets after f_o is increased over 0.5MHz.
> >
> > The overall purpose of this is to carve two channels out of the received
> > bandwidth with two frequency xlating FIR filter blocks, with the USRP
> > tuned between the channels and the filter blocks centered at offsets
> > that put them on the channel peaks. As explained above, if the offset is
> > too big, it stops working. Why do you think this is happening?
> >
> > Thanks,
> > Tom
> >
> >
> > ___
> > 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

Re: [Discuss-gnuradio] RX channel 1 out of range for configured RX frontends

[Marcus D. Leech]

On 03/18/2016 02:33 PM, Marcus Müller wrote:
Yes, the N210 take daughterboards, and in fact, they only take one RX 
and one TX daughterboard, or a single "full-sized duplex board".
Point is that with the Basic* and LF* boards, you can either use the I 
& Q signal lines combinedly as a single complex stream, or isolatedly 
as two real streams. However, as the latter totally "breaks standard 
behaviour", you have to specify a subdevice specification explaining 
how you want your channels to be mapped.


Best regards,
Macus
With the notable exception of the TVRX2, which has a low-IF, so can (and 
does) exercise both DDC channels in the N2xx, giving you two

  independently-tunable channels.




On 03/18/2016 06:06 PM, Nikos Balkanas wrote:

I stand corrected. Didn't even know that N210s took daugterboards :(​

Nikos

On Fri, Mar 18, 2016 at 6:39 PM, Martin Braun > wrote:


You *can* have 2 rx channels in an N210 (by means of dual DDC
chains),
but you probably haven't set the subdev spec appropriately (Something
like 'A:0 A:0', depending on your daughterboard, check the UHD
manual).

Cheers,
Martin

On 03/18/2016 08:53 AM, Nikos Balkanas wrote:
> Hi,
>
> You can have only 1 RX and 1 TX channel in a N210. You are
asking for 2
> RX channels in your flow. Runtime complains that he can access
only 1
> channel (Rx0).
>
> HTH,
> Nikos​
>
> On Fri, Mar 18, 2016 at 5:39 PM, SUGANYA M  >>
wrote:
>
> Hi All,
> I am using GNU Radio Companion 3.7.5 and USRP N210.
> When I implemented a simple flow graph of SIMO system with two
> channels using USRP source block ( attached grc flow graph
snapshot
> for reference),
> I am getting following error:
>
> Traceback (most recent call last):
>   File "/home/student/SUGAN/ONE_TWO.py", line 130, in 
> tb = ONE_TWO()
>   File "/home/student/SUGAN/ONE_TWO.py", line 72, in __init__
> channels=range(2),
>   File
>  "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
>   File
>  "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 1740, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: IndexError: multi_usrp: RX
channel 1 out
> of range for configured RX frontends
>
> Can anyone help me to fix this error?
> Thanks in advance
>
> Regards,
> Suganya.M
>
>
> ___
> 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 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

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Henry Barton]

This sounds interesting; I too have been wondering how IQ files worked. I 
thought it must be alternating I bytes and Q bytes, or with >8-bit radios, I 
words and Q words. But maybe the packed byte system is right, since I can feed 
IQ recordings in WAV format directly into GNUradio without stripping the 
headers.> To: ra...@schmid.xxx; discuss-gnuradio@gnu.org
> From: marcus.muel...@ettus.com
> Date: Wed, 16 Mar 2016 10:24:02 +0100
> Subject: Re: [Discuss-gnuradio] lack of understanding the different formats 
> to store samples
> 
> Ok, let "I" and "Q" be single bits each, so each byte would then be
> 
> IQIQIQIQ
> 
> if I had to take a guess.
> 
> You can get get back something that GR commonly deals with by doing
> 
> packed to unpacked (type=B, bits per chunk = 1, endianness=your machine)
> -> IChar to Complex
> 
> Best regards,
> Marcus
> On 16.03.2016 08:13, Ralph A. Schmid, dk5ras wrote:
> > Each byte seems to contain 4 1 bit I/Q samples. This is the text from the
> > readme:
> >
> > "The output file size can be reduced by using "-b 1" option to store four
> > 1-bit I/Q samples into a single byte."
> >
> > Ralph.
> >
> >> -Original Message-
> >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> >> Marcus Müller
> >> Sent: Friday, March 11, 2016 2:53 PM
> >> To: discuss-gnuradio@gnu.org
> >> Subject: Re: [Discuss-gnuradio] lack of understanding the different
> > formats
> >> to store samples
> >>
> >> In what format are your 1bit samples? I'd assume they are just the fact
> >> whether a byte is 0x00 or 0x01; in that case, just use unpacked to packed.
> >>
> >> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
> >>> Hi,
> >>>
> >>> Being an RF guy I must admit that I am somehow lost in the different
> >>> ways how samples are stored in files. I stumbled over this question
> >>> when I experimented with https://github.com/osqzss/gps-sdr-sim. It
> >>> works great when using 16 bit samples and using a simple two-block grc
> >>> file, feeding them directly from a file source to the UHD sink.
> >>> However the 1 bit variant sounds promising, as the files are much
> >>> smaller this way and also the generation of them runs much faster.
> >>>
> >>> It must only be a matter of finding the right blocks and the right
> >>> settings to convert this, but my google search was highly confusing,
> >>> most probably due to different names for the same thing.
> >>>
> >>> So I do not only ask for how to use "four 1-bit I/Q samples into a
> >>> single byte" (taken from the readme of the gps-sdr-sim), but for a
> >>> more general overview how this stuff is done, to be prepared for other
> >>> upcoming questions of this kind :) Up to now I solved those issues by
> >>> an educated guess or even by try and error, what is not very
> > satisfying...
> >>> Ralph.
> >>>
> >>>
> >>> ___
> >>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Two Daughterboards

[Martin Braun]

Simply drop down a USRP source with 2 channels.

Cheers,
Martin

On 03/16/2016 02:08 PM, olvhammar wrote:
> Hi,
> 
> I would like to receive samples from two different daughterboards on the
> same device (Ettus x310) using one GNURadio flowgraph. What is the
> easiest way to accomplish this? Any examples?
> 
> Best regards
> Simon
> 
> ___
> 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] OFDM Training Sequence

[Mateusz]

Hey, I do my Bachelor Thesis on OFDM using GnuRadio.

I am using the joint system created from tx_ofdm and rx_ofdm examples. 
In simulation I try to use a bigger fft. So far I have managed to send 
and receive for fft_len=128 and fft_len=256, BPSK modulation. I ask to 
help me understand the creation of sync_words for bigger fft.


I see the influence of the training sequences which I use on the quality 
of transmission. Of course I have read that the synchronization is based 
on "PN Sequence Correlation" and "Maximal Likelihood" papers. I suppose 
that sync_word1 and sync_word2 are based on those algorithms 
respectively. However I don't see "two identical parts of PN sequence" 
like it was described in the Schmidl paper.


I tried to use the sequences containing 0's where needed, and random 
-1's and 1's elsewhere, but then the timing synchronization error 
(missing trigger signal in sync_sc) occurs more often, than when I use 
the replicas of original sync_words from the OFDM example.


I attach the file with the training sequences which I have used.

Regards,
Mateusz Loch
--sync word1 64-- (from tx_ofdm example), 6x0., 13x(0.,scaled_rand), 6x0.
[0., 0., 0., 0., 0., 0., 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 
-1.41421356, 
0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 
1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 0., 0., 
0., 0., 0.]

--sync word2-- (from tx_ofdm example), 64 6x0, 26x(rand+0j), 1x0, 26xrand, 5x0
[0j, 0j, 0j, 0j, 0j, 0j, (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), (1+0j), 
(1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), 
(1+0j), (-1+0j), 0j, (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), 
(-1+0j), 0j, 0j, 0j, 0j, 0j]

--sync word1 128--  recreated from sync64, 12x0, 26x(0.+scaled_rand), 12x0 
[0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 
0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]

--sync word2 128-- recreated from sync64, 12x0, 52x(rand+0j), 1x0, 52xrand, 11x0
[0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 
(-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), 
(1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), 
(1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (1+0j), (-1+0j), 0j, (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j),
 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j]

--sync word1 256-- recreated from sync64, 24x0, 52x(0., scaled_rand), 24x0
[0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 
0., 0., 0., 0., 0.,
0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356,  
0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356,  0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 

[Discuss-gnuradio] Two Daughterboards

[olvhammar]

Hi,

I would like to receive samples from two different daughterboards on the 
same device (Ettus x310) using one GNURadio flowgraph. What is the 
easiest way to accomplish this? Any examples?


Best regards
Simon

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

Re: [Discuss-gnuradio] dive into gnu-radio

[Patrick Sathyanathan]

Hi Desmond,
 
I have a similar CS background combined with a youthful interest in radios from 
the distant past. I initially approached GNUradio with a similar attitude, i.e. 
it's just software, I can figure out what it does. But sadly that is not true, 
and as Martin Leech points out in a different reply on this thread, GNUradio 
combines expertise from many different disciplines and you need some level of 
familiarity with all of them to extract the maximum utility from the package. 
With my knowledge the mechanics of writing an OOT module and getting it to show 
up in GRC is fairly simple. It's the knowledge of radio signals and digital 
signal processing where I have the most difficulty. To address DSP I bought the 
Richard Lyons books and am working my way through it. I strongly recommend that 
book for the harmony between theory and practice in presentation. I am 
simultaneously going through an online course on electrodynamics hoping that 
when I'm done I will have the ability to use GNUradio efficiently in 
interesting ways.
 
--Patrick
 
> Date: Wed, 16 Mar 2016 13:55:55 -0700
> From: rfeng...@me.com
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dive into gnu-radio
> 
> You are not in the same boat, by far.  I'm an EE RF/MW hardware guy with zero
> formal software training (other than a FORTRAN undergrad course requirement;
> if that hints to my age).  SDR is a rather new field that requires a LOT of
> cross discipline; it's software + radio.  I have been  messing with GR for a
> few years, and have halted until I teach myself C++, which I'm 1/2 way
> through my book.  I have done some fun stuff with GRC and Python, but need
> C++ to go further.
> 
> For DSP I would suggest Richard Lyons book.  That will cover sampling,
> filtering, etc..  Really good book.
> 
> For digital comms try Benard Sklar's book.  That will tell you why you want
> an RRC filter.  Grad school level book, but it's all in there.
> 
> Really just have to buckle down and hit the books  I'm having to do it with
> the software side.
> 
> Lou
> 
> 
> 
> Desmond Crozby wrote
> > 
> > Hope anyone has the nerves, time and courtesy to write back. I'm certain
> > it
> > will serve as a nice starting point to future enthusiasts.
> > 
> > Best,
> > Desmond
> > 
> > ___
> > Discuss-gnuradio mailing list
> 
> > Discuss-gnuradio@
> 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/dive-into-gnu-radio-tp58828p58838.html
> Sent from the GnuRadio mailing list archive at Nabble.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] dive into gnu-radio

[Marcus D. Leech]

On 03/16/2016 08:34 PM, Timothée COCAULT wrote:


I think there is cruel lack of explanation (not documentation) for the 
GNU Radio blocks.
Reminds me of a Dylan Thomas piece "A Book with everything about wasps, 
except why."


Gnu Radio is "embedded" in a number of different complex disciplines, 
like it or not.  There's no getting around it.  One might as well
  declare that the 2nd law of thermodynamics is awfully inconvenient, 
so let's just wish it away.


There is a difference, I think, between the usability of a tool, and the 
ease-of-understanding of the discipline for which the tool was
  created.  Some of the documentation complaints are, quite rightly, 
about usability of the tool.  Some are, I would posit, about the
  steep learning curves of the relevant disciplines.The Gnu Radio 
development team is well-placed to make great progress in the
  former, and less, I would assert, in the latter.It may be "nice" 
if every block included the equivalent of a chapter or two
  treatise on the subject matter at hand, as if from a college-level 
textbook, but I don't see that happening, unless someone
  (a technical writer) puts in the time to do it.  It would a poor 
substitute for curling up with the appropriate reading material
  oneself in front of a fire, with a cup of Joe, and ones favorite dog 
at ones feet.


Let me use one of my semi-famous "proximate analogies".   When you 
acquire an eCad system for the first time, to layout circuits and
  circuit boards, ones frustration is usually about the tool. Becoming 
frustrated that it requires that you understand simple concepts
  like current and voltage, what an op-amp is, and how to use one, and 
what the truth-tables are for a 74LS74 (and again, why you would
  use one), is not likely to happen.  One doesn't expect ones tooling 
to substitute for the necessary background knowledge.  I cannot imagine
  anyone sitting down in front of a VLSI design tool for the first 
time, and loudly exclaiming that the "documentation sucks" because it turns
  out that being successful with the tool requires that you understand 
a bit (or a lot, really) about VLSI design as a technical discipline.


But I see folks arrive, every day, at Gnu Radio, expecting that no 
relevant background should be required, that if they aren't immediately
  successful with the tool, that it must be the tools fault. Granted, 
some of Gnu Radio's documentation could use improvement, and in
  fact my decades of experience in technology would suggest that no 
documentation is EVER "good enough".  Because we're all different,
  and we all learn in different ways.But I think it's exceedingly 
important to understand the difference between "tool usage" documentation,
  and "a substitute for a 4 year EECS degree".This isn't elitism or 
snobbery, it's just that expecting the tool itself to be a substitute for
  the necessary background just isn't reasonable.  The Gnu Radio 
project doesn't have a large team of technical writers, textbook writers,
  course-ware writers, etc, etc just waiting to contribute.  The 
emerging Gnu Radio *ecosystem*, however, may be a good place to turn.
  Yearly Gnu Radio conferences, folks like Jonathan Corgan who run 
intro-to-SDR courses, the excellent work of folks like Michael Ossmann.

  Online forums like www.dsprelated.com, www.complextoreal.com.

The Gnu Radio project cannot possibly be your "one-stop shop" for all 
things related to radio, DSP, real-time software design, etc, etc.

  It's just not practical.





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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Ben Hilburn]

Hi all -

As I mentioned in the thread regarding the website updates, we recently
discovered that changes to the gnuradio.org DNS caused some MX record
issues, and many of you didn't actually receive the introduction e-mails
that Johnathan and I sent out. If you didn't receive them and are
interested in reading them, you can find them here:

   - News Item: http://gnuradio.org/redmine/news/63
   - My Statement:
   http://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00349.html
   - Johnathan's Statement:
   http://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00350.html

Also, as Martin shared yesterday, we had to postpone the developers' call
due to travel. The next dev call will be *Thurs 31 March*.

As always, if you have any questions, please feel free to send me a note.
Thanks!

Cheers,
Ben

On Mon, Mar 14, 2016 at 10:11 AM, Tom Rondeau  wrote:

> I've been running the GNU Radio project for over five years. In this time,
> we've dramatically expanded its capabilities, prominence, and performance.
> We have attracted great developers and a fantastic user base. And we have
> built the highly successful and growing annual GNU Radio conference.
>
> I feel that I have accomplished a great deal of what I was hoping to when
> I took over this role. Part of my job (and much of the fun) was being
> hands-on with the code almost daily. But there's a lot more to do in GNU
> Radio, and it is time for a new vision to move it forward to where we see
> it going next.
>
> While I was thinking about this role change, the opportunity arose for me
> to become a DARPA program manager, which is one of the most exciting
> opportunities I can imagine. I will still be working on radio,
> communications, and, of course, software radio, and I still hope to support
> the project and continue working with the community we have in whatever
> ways that I can. But this new position gives me an opportunity to pursue
> engineering, science, technology, and research in areas and ways that I
> haven't been able to do in my current role.
>
> I am pleased to announce our new leadership team, who are already very
> familiar to many of you. Ben Hilburn will be taking over as Project Lead
> while Johnathan Corgan will become the Chief Architect in charge of the
> codebase. They have already been doing a great job of building up their
> team structure and their vision for the next stages of this project, which
> is exactly what we need to grow and move the project forward.
>
> The transition is already happening, and we can all consider Ben and
> Johnathan to have taken up their roles today. I will still be actively
> involved in GNU Radio over the next couple of months until I start my new
> position at the end of May.
>
> You'll be hearing more details from them soon. But I hope that everyone
> knows how proud I am of this project and what we're doing here as well as
> my confidence in Ben, Johnathan, and what is coming next.
>
> Thank you all!
>
> Tom
>
>
> ___
> 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] lack of understanding the different formats to store samples

[Marcus Müller]

Exactly that's the case; the "normal" complex type of GNU Radio is
really just 32bit floats
IQIQIQIQ...
ie. a single complex is nothing but two consecutive floating point numbers.

WAV files come in all types, encodings and storage quantizations.
Typically, the header/tail are much shorter than the data, so if you can
deal with how the data is put into your specific WAV, yeah, ignore the
header.
For everything else, refer to the wav_file_source (which has only
compatibility with very specific WAVs), or learn all the fun that's in
that container format.

Cheers,
Marcus

On 16.03.2016 15:04, Henry Barton wrote:
> This sounds interesting; I too have been wondering how IQ files
> worked. I thought it must be alternating I bytes and Q bytes, or with
> >8-bit radios, I words and Q words. But maybe the packed byte system
> is right, since I can feed IQ recordings in WAV format directly into
> GNUradio without stripping the headers.
>
>
> > To: ra...@schmid.xxx; discuss-gnuradio@gnu.org
> > From: marcus.muel...@ettus.com
> > Date: Wed, 16 Mar 2016 10:24:02 +0100
> > Subject: Re: [Discuss-gnuradio] lack of understanding the different
> formats to store samples
> >
> > Ok, let "I" and "Q" be single bits each, so each byte would then be
> >
> > IQIQIQIQ
> >
> > if I had to take a guess.
> >
> > You can get get back something that GR commonly deals with by doing
> >
> > packed to unpacked (type=B, bits per chunk = 1, endianness=your machine)
> > -> IChar to Complex
> >
> > Best regards,
> > Marcus
> > On 16.03.2016 08:13, Ralph A. Schmid, dk5ras wrote:
> > > Each byte seems to contain 4 1 bit I/Q samples. This is the text
> from the
> > > readme:
> > >
> > > "The output file size can be reduced by using "-b 1" option to
> store four
> > > 1-bit I/Q samples into a single byte."
> > >
> > > Ralph.
> > >
> > >> -Original Message-
> > >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> > >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On
> Behalf Of
> > >> Marcus Müller
> > >> Sent: Friday, March 11, 2016 2:53 PM
> > >> To: discuss-gnuradio@gnu.org
> > >> Subject: Re: [Discuss-gnuradio] lack of understanding the different
> > > formats
> > >> to store samples
> > >>
> > >> In what format are your 1bit samples? I'd assume they are just
> the fact
> > >> whether a byte is 0x00 or 0x01; in that case, just use unpacked
> to packed.
> > >>
> > >> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
> > >>> Hi,
> > >>>
> > >>> Being an RF guy I must admit that I am somehow lost in the different
> > >>> ways how samples are stored in files. I stumbled over this question
> > >>> when I experimented with https://github.com/osqzss/gps-sdr-sim. It
> > >>> works great when using 16 bit samples and using a simple
> two-block grc
> > >>> file, feeding them directly from a file source to the UHD sink.
> > >>> However the 1 bit variant sounds promising, as the files are much
> > >>> smaller this way and also the generation of them runs much faster.
> > >>>
> > >>> It must only be a matter of finding the right blocks and the right
> > >>> settings to convert this, but my google search was highly confusing,
> > >>> most probably due to different names for the same thing.
> > >>>
> > >>> So I do not only ask for how to use "four 1-bit I/Q samples into a
> > >>> single byte" (taken from the readme of the gps-sdr-sim), but for a
> > >>> more general overview how this stuff is done, to be prepared for
> other
> > >>> upcoming questions of this kind :) Up to now I solved those
> issues by
> > >>> an educated guess or even by try and error, what is not very
> > > satisfying...
> > >>> Ralph.
> > >>>
> > >>>
> > >>> ___
> > >>> 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 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] dive into gnu-radio

[Anon Lister]

Also coming from a formal software engineering background, I found Michael
Ossman's SDR with HackRF(https://greatscottgadgets.com/sdr/) series very
informative. It has "homework" sections and starts with very little in
assumptions of your prior knowledge. You dont need a hackrf, any sdr,
including $15 RTL stick will do for most things. Or you can use GR to
follow along and you'll get quite a bit out even without an SDR.  Sofar it
doesn't go very deep, but he covers demodulation of FM and getting data off
a Wireless Key Fob from a car, which uses OOK modulation, and he adds new
lessons every now and then.  This will not tell you when you need to use a
particular type of filter, but its good at getting you thinking about the
problem your trying to solve. You mentioned wanting to go lower in the
protocol stack. Modern digital communications are usually complicated
protocols utilizing several types of modulations. I would start with older
or simpler protocols first, but either way this will involve knowledge of
digital modulations. Most of the time people recommend starting from the
analog side, but I find the digital side easier from a CS background. I
would also start by familiarizing yourself with basic digital modulations
OOK, ASK, FSK, PSK, then move onto their variants, such as MSK, QPSK, QAM,
etc(https://en.wikipedia.org/wiki/Modulation#Digital_modulation_methods).
GR has blocks for almost all the basic modulators and demodulators built
in. Basically all of these are ways to map a stream of bits onto the
communication medium. If you start with a stream of bits, ask yourself how
each of the above modulations would get those bits from point a to point
b.  Try implementing them in GR. Setup something like  ->
 -> channel model -> < demodulator >   -> . The key
here is the channel model. Its an awesome learning tool because it will
allow you to model some typical problems of communication systems. When you
lower the signal-to-noise ratio, for example you'll find you may need to
add new blocks to compensate for the loss of signal quality. If you ask
these more pointed questions, such as which block would help compensate for
X,  the list, I'm sure, will be willing to help you along. Also, make sure
you attach constellation and FFT sinks everywhere, then you can actually
see the effects of various blocks on your data stream (The QT GUI sink has
most built in). Normally with digital modulations you map bits to a symbol
of some kind, these symbols are usually displayed in a constellation sink.
Observe the effect of channel model parameters on the constellation plot of
your data, and the integrity of your output file. Attach sliders to
basically any parameter in any block and adjust them at run time to see the
effect on your stream.

As to documentation, as Martin said, documentation is amazingly hard when
you know the things involved. Think of typical code comments you've seen as
a developer. How many times do you see Function X(param1, param2, param3);
And above it a comment, #Does X on param1 and param2 using param3. Alot of
GR blocks have some documentation, they usually state what the block does
in math, which is great, if your coming from that background, but they dont
include things like "You will probably need to use this block when your
constellation looks like  or to correct for ." Even given that,
the documentation on the blocks themselves is somewhat helpful. It is on
the last tab in the properties window for all the blocks. The best person
to contribute to the documentation is probably you. As you learn things,
write it down, why you think it worked or didn't, and then revise as you go
along and offer it up for inclusion in the wiki.


On Mar 16, 2016 5:54 PM, "Tom Coleman"  wrote:

>
> On Mar 16, 2016, at 3:36 PM, Desmond Crozby  wrote:
>
> …
>
>
> I saw this reading suggestion:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading ,
> but the list is extensive and grouped by topic, basically I don't know
> where to start from.
>
>
> Software Radio in General
> Has anyone bothered to check these links lately?
>
>
>
> ___
> 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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio

[Piotr Krysik]

Hi all,

How to use "--config" option of pybombs 2. Can someone show an working
example?

In pybombs 2 "forcebuild" is set to true for gnuradio by default.
How to disable "focebuild" for gnuradio from commandline with the
pybombs command?

Best Regards,
Piotr Krysik

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