Re: [Discuss-gnuradio] Off-line signal processing (GR in slow motion)

[Martin Braun (CEL)]

On Wed, Aug 28, 2013 at 10:33:53PM +, Monahan-Mitchell, Tim wrote:
> Off-line example (3 separate flowgraphs, run one at a time):
> 
> 1. USRP --> File
> 2. File --> AM Radio Demodulation, produces audio data --> File
> 3. File --> Throttle @ audio rate --> Audio Sink 
> 
> Note that #2 can take as long as needed to complete, no issues with loss of 
> data.
> 
> If so, how would I set up flowgraph #2 above?

Hm, I'm not quite sure if I understand your problem. You can simply
connect a file source to the am demod and then to a file sink.

This flowgraph will then run unlimited ('cause no throttle). But that's
OK if the input file is limited in size. Your CPU will be running full
power until there's nothing left to process.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpTZ8sfRx1DT.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Bug in GRC's tcp_source block

[matt . nottingham]

Hi,

I've now come across another issue with version 3.7. If I have a tcp
source block in gnuradio-companion (in client mode), I get a
stacktrace like this:

  Using Volk machine: sse4_a_64_orc
  Traceback (most recent call last):
File "/home/matt/devel/mygnuradio/client2.py", line 86, in 
  tb = client2()
File "/home/matt/devel/mygnuradio/client2.py", line 59, in __init__
  server=False,
File "/usr/lib/python2.7/dist-packages/grc_gnuradio/blks2/tcp.py", line 59, 
in __init__
  self.connect(blocks.file_descriptor_source(itemsize, fd), self)
File "/usr/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig0.py", 
line 766, in make
  return _blocks_swig0.file_descriptor_source_make(*args, **kwargs)
  TypeError: Required argument 'repeat' (pos 3) not found

(for info grc builds the source like this:
  self.blks2_tcp_source_0 = grc_blks2.tcp_source(
 itemsize=gr.sizeof_gr_complex*1,
 addr="127.0.0.1",
 port=7840,
 server=False,
 )
)


>From my quick look at this, it appears that grc_gnuradio/blks2/tcp.py
should be changes so that line 59 goes from:

self.connect(blocks.file_descriptor_source(itemsize, fd), self)

to be:

self.connect(blocks.file_descriptor_source(itemsize, fd, False), self)


as it appears that all source file descriptors need to have a bool that
shows if they should repeat or not - and to me at least, it made no
sense to have a TCP stream repeat.

Thanks,

Matt

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

Re: [Discuss-gnuradio] Bug in GRC's tcp_source block

[Tom Rondeau]

On Thu, Aug 29, 2013 at 4:51 AM,   wrote:
>
> Hi,
>
> I've now come across another issue with version 3.7. If I have a tcp
> source block in gnuradio-companion (in client mode), I get a
> stacktrace like this:
>
>   Using Volk machine: sse4_a_64_orc
>   Traceback (most recent call last):
> File "/home/matt/devel/mygnuradio/client2.py", line 86, in 
>   tb = client2()
> File "/home/matt/devel/mygnuradio/client2.py", line 59, in __init__
>   server=False,
> File "/usr/lib/python2.7/dist-packages/grc_gnuradio/blks2/tcp.py", line 
> 59, in __init__
>   self.connect(blocks.file_descriptor_source(itemsize, fd), self)
> File "/usr/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig0.py", 
> line 766, in make
>   return _blocks_swig0.file_descriptor_source_make(*args, **kwargs)
>   TypeError: Required argument 'repeat' (pos 3) not found
>
> (for info grc builds the source like this:
>   self.blks2_tcp_source_0 = grc_blks2.tcp_source(
>  itemsize=gr.sizeof_gr_complex*1,
>  addr="127.0.0.1",
>  port=7840,
>  server=False,
>  )
> )
>
>
> From my quick look at this, it appears that grc_gnuradio/blks2/tcp.py
> should be changes so that line 59 goes from:
>
> self.connect(blocks.file_descriptor_source(itemsize, fd), self)
>
> to be:
>
> self.connect(blocks.file_descriptor_source(itemsize, fd, False), self)
>
>
> as it appears that all source file descriptors need to have a bool that
> shows if they should repeat or not - and to me at least, it made no
> sense to have a TCP stream repeat.
>
> Thanks,
>
> Matt


Actually, I think the bug is in file_descriptor_source. That final
argument for repeat should default to false, like it did in 3.6. The
default setting wasn't carried over with the refactoring in 3.7. I'll
push this fix in a bit.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Bug in GRC's tcp_source block

[matt . nottingham]

Tom Rondeau writes:
 > On Thu, Aug 29, 2013 at 4:51 AM,   wrote:
 > >
 > > Hi,
 > >
 > > I've now come across another issue with version 3.7. If I have a tcp
 > > source block in gnuradio-companion (in client mode), I get a
 > > stacktrace like this:
 > >
 > >   Using Volk machine: sse4_a_64_orc
 > >   Traceback (most recent call last):
 > > File "/home/matt/devel/mygnuradio/client2.py", line 86, in 
 > >   tb = client2()
 > > File "/home/matt/devel/mygnuradio/client2.py", line 59, in __init__
 > >   server=False,
 > > File "/usr/lib/python2.7/dist-packages/grc_gnuradio/blks2/tcp.py", 
 > > line 59, in __init__
 > >   self.connect(blocks.file_descriptor_source(itemsize, fd), self)
 > > File 
 > > "/usr/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig0.py", line 
 > > 766, in make
 > >   return _blocks_swig0.file_descriptor_source_make(*args, **kwargs)
 > >   TypeError: Required argument 'repeat' (pos 3) not found
 > >
 > > (for info grc builds the source like this:
 > >   self.blks2_tcp_source_0 = grc_blks2.tcp_source(
 > >  itemsize=gr.sizeof_gr_complex*1,
 > >  addr="127.0.0.1",
 > >  port=7840,
 > >  server=False,
 > >  )
 > > )
 > >
 > >
 > > From my quick look at this, it appears that grc_gnuradio/blks2/tcp.py
 > > should be changes so that line 59 goes from:
 > >
 > > self.connect(blocks.file_descriptor_source(itemsize, fd), self)
 > >
 > > to be:
 > >
 > > self.connect(blocks.file_descriptor_source(itemsize, fd, False), 
 > > self)
 > >
 > >
 > > as it appears that all source file descriptors need to have a bool that
 > > shows if they should repeat or not - and to me at least, it made no
 > > sense to have a TCP stream repeat.
 > >
 > > Thanks,
 > >
 > > Matt
 > 
 > 
 > Actually, I think the bug is in file_descriptor_source. That final
 > argument for repeat should default to false, like it did in 3.6. The
 > default setting wasn't carried over with the refactoring in 3.7. I'll
 > push this fix in a bit.
 > 
 > -- 
 > Tom
 > Visit us at GRCon13 Oct. 1 - 4
 > http://www.trondeau.com/grcon13


OK, cool.

Thanks,

Matt

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

[Discuss-gnuradio] mathematics behind probe.level()

[dilip thapa]

Hi,

I want to do energy detection of received signal, And after searching I was 
advised to use probe block to do the sense. (gr.probe_avg_mag_sqrd_f). 

Can anyone explain how this works. How level() method gives the energy level. I 
need mathematic behind this function. Is this calculates based on FFT or what?

 

Please help


 

and please add  my email on reply.(palpa5b...@hotmail.com)

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

Re: [Discuss-gnuradio] mathematics behind probe.level()

[Marcus Leech]

For a complex signal, the instantaneous power level is proportional to (I**2 + Q**2), which you then average.This is precisely what probe_avg_mag_sqrd does.
 
And, you shouldn't refer to it as an "energy level", since you're measuring power, not energy.  Those are different (but related) concepts in physics.
 
Now reducing even further, remember that the ADC is sampling a *voltage* level.  The power flowing through a circuit is proportional to the square of the voltage.
  The samples that are coming into the flow-graph are proportional to the voltage seen by the ADC, so in order to calculate the power, you have to square them.
  Review Ohms law to see that this is true.
 
 
 
on Aug 29, 2013, dilip thapa  wrote:


Hi,
I want to do energy detection of received signal, And after searching I was advised to use probe block to do the sense. (gr.probe_avg_mag_sqrd_f). Can anyone explain how this works. How level() method gives the energy level. I need mathematic behind this function. Is this calculates based on FFT or what?
 
Please help

 
and please add  my email on reply.(palpa5b...@hotmail.com)
dilip
 


___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

Re: [Discuss-gnuradio] Off-line signal processing (GR in slow motion)

[Monahan-Mitchell, Tim]

>> Off-line example (3 separate flowgraphs, run one at a time):
>> 
>> 1. USRP --> File
>> 2. File --> AM Radio Demodulation, produces audio data --> File
>> 3. File --> Throttle @ audio rate --> Audio Sink

As Tim O pointed out, #3 would just be File --> Audio Sink, since the Audio 
Sink consumes at a fixed rate.

>> 
>> Note that #2 can take as long as needed to complete, no issues with loss of 
>> data.
>> 
>> If so, how would I set up flowgraph #2 above?

> Hm, I'm not quite sure if I understand your problem. You can simply connect a 
> file source to the am demod and then to a file sink.

Yes, #2 was meant to depict whatever processing blocks are needed to go from RF 
samples to audio samples.

>> This flowgraph will then run unlimited ('cause no throttle). But that's OK 
>> if the input file is limited in size. Your CPU will be running full power 
>> until there's nothing left to process.

Yes, I understand that part. What I was not sure about was whether the real 
time rate of data passing through the system was required to be able to do 
proper signal processing? Or whether some of the processing blocks are simply 
told what the rate is?

Here is another example: suppose I have a file of audio samples. To determine 
the spectrum of the data , isn't the sampling rate of the data a factor? Or 
must a scalar be applied somewhere (related to the sampling rate) to convert 
relative values to energy per Hz?

If the latter is true, then I'm still unclear on whether something like the 
rx_ofdm example under gr-digital can work, just given a file of samples and no 
throttle block (CPU limitations aside)?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Off-line signal processing (GR in slow motion)

[Tom Rondeau]

On Thu, Aug 29, 2013 at 11:53 AM, Monahan-Mitchell, Tim
 wrote:
>>> Off-line example (3 separate flowgraphs, run one at a time):
>>>
>>> 1. USRP --> File
>>> 2. File --> AM Radio Demodulation, produces audio data --> File
>>> 3. File --> Throttle @ audio rate --> Audio Sink
>
> As Tim O pointed out, #3 would just be File --> Audio Sink, since the Audio 
> Sink consumes at a fixed rate.
>
>>>
>>> Note that #2 can take as long as needed to complete, no issues with loss of 
>>> data.
>>>
>>> If so, how would I set up flowgraph #2 above?
>
>> Hm, I'm not quite sure if I understand your problem. You can simply connect 
>> a file source to the am demod and then to a file sink.
>
> Yes, #2 was meant to depict whatever processing blocks are needed to go from 
> RF samples to audio samples.
>
>>> This flowgraph will then run unlimited ('cause no throttle). But that's OK 
>>> if the input file is limited in size. Your CPU will be running full power 
>>> until there's nothing left to process.
>
> Yes, I understand that part. What I was not sure about was whether the real 
> time rate of data passing through the system was required to be able to do 
> proper signal processing? Or whether some of the processing blocks are simply 
> told what the rate is?
>
> Here is another example: suppose I have a file of audio samples. To determine 
> the spectrum of the data , isn't the sampling rate of the data a factor? Or 
> must a scalar be applied somewhere (related to the sampling rate) to convert 
> relative values to energy per Hz?
>
> If the latter is true, then I'm still unclear on whether something like the 
> rx_ofdm example under gr-digital can work, just given a file of samples and 
> no throttle block (CPU limitations aside)?


GNU Radio doesn't care about sampling rate. It just runs data through
as fast as possible.

Those blocks that accept a sampling rate is for convenience only. In
the end, everything is operated off a normalized sampling rate. So
when you have a signal source with sampling rate 32k and a frequency
of 1k, the math that goes into generating that sine wave is really
working as 1000/32000. We allow you to state the sampling rate in
blocks like this because it allows us to think more naturally about
the frequency without doing the normalization process ourselves. But
in the end, it just how fast it's turning around the unit circle every
sample.

So no, running without throttle has no difference on the signal
processing that's happening.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] mathematics behind probe.level()

[dilip thapa]

Marcus,


Thanks for very nice explanation: 

so I see the code of this block with the help of your reply, and understand 
that how It is computing power for given N samples.

i.e power= (sum of X**2[n])/N where n goes from 0 to N.


And the code contains “noutput_items ” in place of N.


Then what value of N is used here. and how can we change that from python code?




~Dilip
Sent from Windows Mail



From: Marcus Leech
Sent: ‎Thursday‎, ‎August‎ ‎29‎, ‎2013 ‎8‎:‎44‎ ‎PM
To: palpa5b...@hotmail.com
Cc: discuss-gnuradio@gnu.org


For a complex signal, the instantaneous power level is proportional to (I**2 + 
Q**2), which you then average.

This is precisely what probe_avg_mag_sqrd does.

 

And, you shouldn't refer to it as an "energy level", since you're measuring 
power, not energy.  Those are different (but related) concepts in physics.

 

Now reducing even further, remember that the ADC is sampling a *voltage* level. 
 The power flowing through a circuit is proportional to the square of the 
voltage.

  The samples that are coming into the flow-graph are proportional to the 
voltage seen by the ADC, so in order to calculate the power, you have to square 
them.

  Review Ohms law to see that this is true.

 

 

 

on Aug 29, 2013, dilip thapa  wrote:


Hi,

I want to do energy detection of received signal, And after searching I was 
advised to use probe block to do the sense. (gr.probe_avg_mag_sqrd_f). 

Can anyone explain how this works. How level() method gives the energy level. I 
need mathematic behind this function. Is this calculates based on FFT or what?

 

Please help


 

and please add  my email on reply.(palpa5b...@hotmail.com)

dilip

 




___
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] mathematics behind probe.level()

[Marcus Leech]

It uses a single-pole IIR filter.  You can set the alpha value when you create the block, and also, there's a set_alpha() method that is a public method.
 
on Aug 29, 2013, dilip thapa  wrote:


Marcus,
 
Thanks for very nice explanation:
so I see the code of this block with the help of your reply, and understand that how It is computing power for given N samples.
i.e power= (sum of X**2[n])/N where n goes from 0 to N.
 
And the code contains “noutput_items ” in place of N.
 
Then what value of N is used here. and how can we change that from python code?
 

 
~DilipSent from Windows Mail
 


From: Marcus LeechSent: ‎Thursday‎, ‎August‎ ‎29‎, ‎2013 ‎8‎:‎44‎ ‎PMTo: palpa5b...@hotmail.comCc: discuss-gnuradio@gnu.org

 
For a complex signal, the instantaneous power level is proportional to (I**2 + Q**2), which you then average.This is precisely what probe_avg_mag_sqrd does.
 
And, you shouldn't refer to it as an "energy level", since you're measuring power, not energy.  Those are different (but related) concepts in physics.
 
Now reducing even further, remember that the ADC is sampling a *voltage* level.  The power flowing through a circuit is proportional to the square of the voltage.
  The samples that are coming into the flow-graph are proportional to the voltage seen by the ADC, so in order to calculate the power, you have to square them.
  Review Ohms law to see that this is true.
 
 
 
on Aug 29, 2013, dilip thapa  wrote:

Hi,
I want to do energy detection of received signal, And after searching I was advised to use probe block to do the sense. (gr.probe_avg_mag_sqrd_f). Can anyone explain how this works. How level() method gives the energy level. I need mathematic behind this function. Is this calculates based on FFT or what?
 
Please help

 
and please add  my email on reply.(palpa5b...@hotmail.com)
dilip
 

___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] MacPorts GNU Radio Changes

[Michael Dickens]

As of about 2:30 PM/US/ET today, the MacPorts gnuradio ports should work again 
with wx.  Do {{{
sudo port selfupdate
}}} to get the latest MacPorts install and port info.  Do {{{
port outdated
}}} to see what has changed, and, hopefully, some wx ports will appear; I 
bypassed this step, so I'm not sure this is the case.  Even if no wx or 
gnuradio ports appear, you can still upgrade them manually.

The gnuradio port has 2 primary changes:

1) It uses the new wx ports -- wxPython-3.0 and py27-wxPython-3.0 -- which are 
completely redesigned to handle wx more robustly than before.  You -might- have 
to deactivate the prior wx ports to get everything to work (e.g. {{{
sudo port -f deactivate `port installed | grep wx | grep active | sed -e 
"s@(active)@@g"`
}}}) -- it can't hurt to do this, since the new ports actually work out of the 
box.  Then, you can install the new wx ports either by reinstalling gnuradio, 
updating gnuradio, or installing them directly.

2) As of 48fe4d89 (2013-08-27), gnuradio-devel and gnuradio-next can be 
compiled using MacPorts GCC (e.g., gcc48) -- release 3.7.1 is imminent, and it 
will contain this change; release 3.6.5.1 does not contain this change, and I 
have no plans to fix it unless there is demand to do so.  The way to use the 
alternative GCC is: (1) uninstall your current gnuradio install; (2) re-do the 
install, and append "configure.compiler=macports-gcc-4.8" to the command line.  
Please note that, currently, you'll have to reinstall both boost and cppunit 
with the same compiler command line addition (uninstall, then reinstall as with 
gnuradio).  But, once you've done all that, gnuradio works better using 
MacPorts GCC than it does with Apple's GCC (or, clang, for now).

As always, if you try the above and it fails, ping me and I'll help you fix it. 
- MLD


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

Re: [Discuss-gnuradio] LDPC GSoC Project Status

[Perez, Tracie R]

Hello all once again,

I'd like to thank everyone who has given me helpful feedback since my last 
status. I really appreciate the thoughtful comments. 

I solved the issue regarding getting my matrices to work with the encoder 
algorithm. For the parity check matrices, I'm constructing regular LDPC parity 
check matrices per a simple algorithm described in Gallager's original 1963 
thesis on this topic. However, per design, the matrices are never full rank, so 
I then process them to be so. Then, the matrices are ran through a 
pre-processing algorithm to set them up for efficient, low complexity encoding 
per a process described by Richardon and Urbanke. I call the resulting matrix 
an "encoding-ready" parity check matrix, and it takes days to generate each one 
(bigger = more days). I would like to build up to matrices for n=5000 because I 
believe this is the ballpark for codeword lengths used in industry. As my 
scripts create these matrices, I am pushing them to a library of sorts on my 
github repo. Of course the idea is that the time is invested in creating them 
once, and then they can be used as needed after that. 

There are regular parity check matrices already available on the web by Dr. 
MacKay, but they are not full rank, so they won't work with my encoder. By the 
time I reduce them to be full rank, the information rate that they offer is 
unacceptably low. So, this is why I have gone the route of generating my own 
matrices that are compatible with Richardson and Urbanke's encoding algorithm.

Next, I ran into an issue with my decoder failing for large size codewords. 
That tied me up for a few weeks. After much troubleshooting, I discovered that 
the issue stemmed from rounding errors from numpy doing mod 2 operations. I 
won't go into to much detail since I will be porting this algorithm out of 
python to C++ anyway. After manually correcting this rounding issue, my hard 
decision bit-flip decoding algorithm performed really well in the prototype 
python tests that I did. To simulate errors, I manually introduced bit flips 
and checked that the decoder could detect and correct them. I have tested 
codewords up to 2400 bits in length, and the algorithm can correct a few errors 
in 1 or 2 iterations, which is actually much faster than I anticipated. I will 
be testing larger codewords as I construct larger and larger parity check 
matrices.

Now I am at the point where I am converting my python code into C++. After 
thinking about how best to do this, we (Jens, Nick and I) agreed that it made 
sense to fork Nick McCarthy's fecapi repo. So, I have done this, and I will 
create classes that inherit from and use the FEC API classes that he has 
already written. This will hopefully allow me to eventually use the BER curve 
generator to do final tests of my implementation. 

Because there are so many matrix operations, I am using the GNU Scientific 
Library (GSL) in my C++ code. I thought that this would be a reasonable 
approach since GSL is a required dependency for gr-wavelet, and, if I am not 
mistaken, a user would get the GSL as part of the standard install via pybombs. 
I do think that there will be many opportunities to increase efficiency by 
using VOLK, but I don't think that will fall within the scope of this summer's 
project. I will be flagging potential VOLK code replacements with something 
like "FIXME - consider replacing this with VOLK library functions."

As always, I welcome any feedback that you have!

Thanks,
Tracie Perez

On Jul 21, 2013, at 6:36 PM, Perez, Tracie R wrote:

> Hi all,
> 
> I'd just like to share a status of how my LDPC implementation project is 
> going. When the summer started, Manu and I made a list of the LDPC-related 
> algorithms for encoding, decoding, and parity check matrix construction that 
> we had found in our literature review. We then divided them up such that 
> there would be no overlap in our efforts. The algorithms that I put on my 
> list were: 
> 
> 1. Regular and irregular parity check matrix construction functions
> 2. Generating a code that is optimized for PSK
> 3. Constructing quasi-cyclic codes which are especially efficient for encoding
> 4. Performing encoding as described by Richardson & Urbanke in Appendix A of 
> 'Modern Coding Theory' (manipulating the parity-check matrix into an 
> approximate upper triangulation form which reduces complexity during the 
> real-time encoding steps)
> 5. Bit-flip decoding, a hard decision algorithm
> 6. Min-sum algorithm for decoding
> 
> So far, I've written prototype functions for these methods in python, using 
> numpy: #1/regular, #4, and #5.
> 
> Right now, I'm at the stage where I'm trying to link them all together and 
> confirm that the processes perform as expected before moving on to converting 
> them to C++. The challenge that I'm facing is that the parity check matrices 
> being created by my function are not full rank, and so they don't work with 
> the encoding algorithm. I hav

[Discuss-gnuradio] GNU Radio releases 3.7.0.1 and 3.7.1 available for download

[Johnathan Corgan]

GNU Radio releases 3.7.0.1 and 3.7.1 are available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0.1.tar.gz
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.1.tar.gz

MD5 sums:

0a21d3342f58f77f8923803d6bfbb133  gnuradio-3.7.0.1.tar.gz
6c5e67da6ed8724dd900d8e343b64be4  gnuradio-3.7.1.tar.gz

Release 3.7.0.1 is a bug-fix only release based off 3.7.0, while release
3.7.1 has new 3.7 API compatible features in addition to all the same bug
fixes.

Contributors this release:

Alexandru Csete 
Andrej Lajovic 
Andrew F. Davis 
Clayton Smith 
Doug Geiger 
Jiri Pinkava 
Johnathan Corgan 
Josh Blum 
Julien Olivain 
Marcus Müller 
Michael Dickens 
Mike Jameson 
Miklos Maroti 
Nathan West 
Nicholas Corgan 
Nicholas McCarthy 
Philip Balister 
Roy Thompson 
Stefano Banti 
Tim Newman 
Tim O'Shea 
Timo Lindfors 
Tom Rondeau 
Volker Schroer 

Release notes:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_1

Documentation:

http://gnuradio.org/doc/doxygen-3.7.1/index.html
http://gnuradio.org/doc/sphinx-3.7.1/index.html

Detailed release notes follow.

Important new features:

GRC Bus Ports (Nicholas McCarthy)

Bus ports in the GNU Radio Companion (GRC) allow ganging block
input

or output ports into a single port for display and connections.
This

simplifies flowgraph entry when dealing with blocks that work with
an

arbitrary number of
streams.


For further information, see:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Busports

Minor features/updates (3.7.1):

atsc: created atsc_rx.py and removed obsolete scripts (Andrew Davis)
blocks: added interleaved_char_to_complex block (Tim O'Shea)
blocks: Added QA code for all ControlPort probe types. (Tom Rondeau)
blocks: adding a complex VCO block. (Tom Rondeau)
blocks: adding a tags strobing block to help test tag stream. (Tom Rondeau)
blocks: modified tag_debug block to publish number of tags queued (Tom
Rondeau)
build: Windows packages automatically include compiler runtime DLLs
(Nicholas Corgan)
build: installing all cmake files into lib/cmake/gnuradio directory (Tom
Rondeau)
channels: Added hardware impairments blocks from Matt Ettus' GRCon11 talk
(Tom Rondeau)
channels: added second channel model to dynamically change freq/timing
offsets. (Tom Rondeau)
channels: updated quantization demo for new histogram constructor (Tom
Rondeau)
channels: using new qtgui histogram sink in quantization demo. (Tom Rondeau)
digital: added lo_offset and external clock utilisation to OFDM (Mike
Jameson)
digital: added lo_offset and external clock source to narrowband examples
(Mike Jameson)
digital: delay ofdm benchmark_tx exit to allow TX to empty (Mike Jameson)
filter: added optional second input that dynamically adjusts resampling
rate (Tom Rondeau)
grc: Sorts the block tree column at start-up. (Julien Olivain)
grc: Remove *out from sinks, *in from sources (Marcus Müller)
grc: allow set_min_output_buffer on any blocks that have output ports (Tim
O'Shea)
grc: added special variable objects to represent constellations (Tom
Rondeau)
qtgui: Added histogram sink (Tom Rondeau)
runtime: added tag_propagation_policy_t to block_gateway (Marcus Müller)
runtime: Improved display handling for gr-ctrlport-monitor (Tim Newman)
runtime: Added probes for byte, short, and int data types (Tom Rondeau)
runtime: allow setting thread affinity to all blocks under a hier_block2
(Tom Rondeau)
uhd: squashed per-channel stream support (Josh Blum)

Bug Fixes (3.7.1, 3.7.0.1):

analog: agc3_cc: Fix uninitialized variable error. (Philip Balister)
analog: agc3_cc: bug fix for input values of zero (Tim O'Shea)
atsc: Fix bugs in atsc_field_sync_mux (Clayton Smith)
blocks: expose set_period callback for blocks.message_strobe in GRC (Tim
O'Shea)
blocks: moved type conversions to use Volk dispatchers. (Tom Rondeau)
blocks: set file_descriptor_source default to repeat=false (Tom Rondeau)
build: don't install controlport config file in two places (Tom Rondeau)
build: fix for finding and handling ICE 3.5 or 3.4 (Tom Rondeau)
build: fix to allow reconfiguring install prefix (Johnathan Corgan)
build: fixed some differences between handling Ice 3.4 and 3.5. (Tom
Rondeau)
build: fixes FindQwt cmake module to check that Qwt is >= 5.2.0. (Tom
Rondeau)
build: force detection to Python 2.x only (Julien Olivain)
build: more robust FindICE operation with multiple ICE installs (Tom
Rondeau)
build: require Python v2 for build configuration (Jiri Pinkava)
digital: fix digital.cpmmod_bc XML for new constants location (Johnathan
Corgan)
digital: fix for OFDM serializer QA after FFT block fix (Johnathan Corgan)
digital: fix for moving average filter in OFDM equalizer. (Stefano Banti)
digital: ofdm benchmark_rx fft conflict fix (Mike Jameson)
docs: Fixes sphinx docs for user set LD_LIBRARY_PATH (Tom Rondeau)
docs: Minor corrections, fixes to ControlPort documentation. (Tom Rondeau)
docs: Updated and improved the message passing docs page. (Tom Rondeau)
docs: added doc page on Performance Counters.

[Discuss-gnuradio] GRCon13 Hardware Giveaway!

[Tom Rondeau]

We are pleased to announce that we have received a number of hardware
donations for various SDR vendors and will be giving them away at
GRCon!

We will hold a raffle at the end of the conference and all attendees
not affiliated with the hardware manufacturers are eligible to win. We
will provide details at the start of the conference.

So what can you hope to win if you attend the conference?

 - Ettus Research USRP B200
 - Fairwaves UmTRX
 - Great Scott Gadgets HackRF
 - Lime Micro MyriadRF
 - Loctronix A-2300

That is some incredibly good gear!

And keep alert, we might have a few other surprises for you...


-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

[Discuss-gnuradio] read GPSDO data with Gnuradio-Companion

[Francois Quitin]

Had no response to my previous email, so I try to give it another shot: 

 

Hi all, 

I'd like to know if it's possible to read the GPSDO data (more specifically
the GPS time) with GNURadio-companion. I understand there are simple
commands to read this data in C++ or python, and I'd like to know if it's
possible in GRC. 

I'm familiar with programming GRC blocks and working with time-tags. Does
the GPSDO attach some tag on a sample when sending it's pps signal that I
could retrieve in GRC?

Thanks, 

Francois

-- 

Francois Quitin, Ph.D.

 

Research Fellow

School of Electrical & Electronic Engineering

Nanyang Technological University

Singapore

Phone: +65-8502-3690

Email: fqui...@ntu.edu.sg  

 

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

[Discuss-gnuradio] wx gui waterfall sink not working

[deepthi asok]

hi

am using usrp2+WBX ,am doing this simple experiment -
from a signal source i gave 1.5GHz(-20dBm) to usrp2.
in gnu radio companion i gave-UHD:USRP source->wx gui waterfallsink

 The Waterfall plot shows only a blue window without any signal and no
control buttons.
when i gave a wx gui fft sink i can see my input signal in fft spectrum
what could have possibly gone wrong with waterfall sink
(am using gnu radio companion 3.6.2,ubuntu 10.04)

any help is appreciated
-deep
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio