Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

[Jeon]

Thanks for your answers, Ron and Marcus.

I posted this question since my module is using both Reed Solomon (
https://github.com/pjkundert/ezpwd-reed-solomon) and Convolutional Code
(IT++).
And I saw that CC is extremely slower than RS. Thus, I posted this
question, but I made a question too short and lack some information.
(Of course, this is because mechanism of RS is much much simpler than that
of CC.
Or it could be because ezpwd RS which I am using is optimized well, but
IT++ CC is not.)

To improve my OOT's performance, thus, I need to replace IT++ with other
some heavily optimized library or module.
I remember that...one of gr-fec, gr-dtv, gr-trellis can do this for me.

Now I wonder which gr module supports some arbitrary polynomials and code
rate.
Specifically, I want one of three set of polynomials:

- Polynomial 1 (g0 = 133, g1 = 171, g2 = 165)
- Polynomial 2 (g0 = 131, g1 = 145, g2 = 133)
- Polynomial 3 (g0 = 131, g1 = 171, g2 = 133)

(Common: Code rate 1/4, 2/3 and 1/3, where 1/4 = repeat of code rate 1/2)

The reason that I try to implement one of three is,
document describing specification has some wrong points.
Text says polynomial 1, but figure shows polynomial 2.

One thing is hopeful:

I think that polynomial 3 seems a sort of widely used one
and that it has been already implemented by someone in GNU Radio,
which has been heavily optimized... I hope...

(While I am writing this, I've checked that gr-fec can do CC with arbitrary
polynomials.
gnuradio/gr-fec/examples/fecapi_cc_decodres.grc
I still don't know optimization.)

I will keep looking into those gr-fec, dtv, trellis modules.
If someone have suggestions, I will appreciate it.

Thanks a lot.

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

Re: [Discuss-gnuradio] Question about correlate_access_code_bb_impl

[bob wole]

On Mon, Sep 21, 2015 at 7:38 PM, Tom Rondeau  wrote:

> On Mon, Sep 21, 2015 at 6:40 AM, bob wole  wrote:
>
>> I am studying the code of correlate_access_code_bb_impl.cc for
>> understanding its working. I see that the block is derive from "block"
>> class of gr as written in correlate_access_code_bb_ts.h file
>>
>>
>> class DIGITAL_API correlate_access_code_bb_ts : virtual public block
>>
>>
>> I read earlier that blocks derived from "block"/"gr::block"  should
>> implement forecast() method, but I did not see any implementation of
>> forecast() in  code of correlate_access_code_bb_impl.cc.
>>
>> Can somebody please tell me why ?
>>
>> --
>> Bob
>>
>
>
> First, you have a misunderstanding of the header/source relationship.
> There are a number of correlate* blocks in GNU Radio (and an unwritten plan
> to organize them better in the future). The correlate_access_code_bb is one
> block, and this is a gr::sync_block. The correlate_access_code_bb_ts is
> another block, and this one is a gr::block.
>
> If you look at the code for block.cc, you'll see it implements a forecast
> function already:
>
>   void
>   block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
>   {
> unsigned ninputs = ninput_items_required.size ();
> for(unsigned i = 0; i < ninputs; i++)
>   ninput_items_required[i] = noutput_items + history() - 1;
>   }
>
>
> That means that any block that derives from gr::block gets this behavior,
> which tells the scheduler that given noutput_items, the block needs this
> many input items to produce that output amount. This is a satisfactory
> condition for many blocks, so no, you don't /have/ to overload forecast in
> your derived block if this condition meets your block's behavior.
>
> Tom
>
>
Hi Tom,

Sorry, actually there were typos in my email. I was talking about the block
"correlate_access_code_bb_ts" all the time instead of
"correlate_access_code_bb". Thanks for clearing things and being helpful as
always.


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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

I'm running 14.04 and yes I have Internet access (that was part of the
aforementioned "drama")

I ran the update/upgrade and reran the script and now things are "different"

This seems like it may take a while. I'll report back when it's done.

Hmm.. so far one error - it couldn't find libzmq1-dev; I don't know
what that'll mean

Thanks!

Mike



On Mon, Sep 21, 2015 at 11:27 PM, James Humphries
 wrote:
> Hi Mike,
>
> Did you update your package manager? Usually helps when I get errors.
>
> sudo apt-get update && sudo apt-get upgrade
>
> Also, make sure build-essential is installed (Do this after update and
> upgrade).
>
> sudo apt-get install build-essential
>
> -Trip
>
> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer  wrote:
>>
>> All,
>> I recently asked the list some questions about getting GNU Radio up
>> and running on a Windows machine (using cygwin). It became obvious
>> there would be a lot of hurdles, for which the community would not be
>> able to offer much help. So...
>>
>> I have installed Ubuntu on a PC ( in a dual boot configuration with
>> Win7 ) <-- this is its own drama LOL
>>
>> I tried to follow the "Installing GNU Radio step(s) outlined on
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
>> using the script via
>> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
>> ./build-gnuradio && ./build-gnuradio
>>
>> and I get a bunch of errors :
>> Checking for package libfontconfig1-dev
>> Failed to find package 'libfontconfig1-dev' in known package repositories
>> SOME THINGS MAY NOT BUILD AS A RESULT
>> Checking for package libxrender-dev
>> Failed to find package 'libxrender-dev' in known package repositories
>> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
>>
>> etc..
>>
>> It appears that a major step is missing or broken.  Can someone help me on
>> this?
>>
>> Thanks!
>>
>> Mike
>>
>> ___
>> 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] GNU Radio installation script

[James Humphries]

Hi Mike,

Did you update your package manager? Usually helps when I get errors.

sudo apt-get update && sudo apt-get upgrade

Also, make sure build-essential is installed (Do this after update and
upgrade).

sudo apt-get install build-essential

-Trip

On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer  wrote:

> All,
> I recently asked the list some questions about getting GNU Radio up
> and running on a Windows machine (using cygwin). It became obvious
> there would be a lot of hurdles, for which the community would not be
> able to offer much help. So...
>
> I have installed Ubuntu on a PC ( in a dual boot configuration with
> Win7 ) <-- this is its own drama LOL
>
> I tried to follow the "Installing GNU Radio step(s) outlined on
> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
> using the script via
> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
> ./build-gnuradio && ./build-gnuradio
>
> and I get a bunch of errors :
> Checking for package libfontconfig1-dev
> Failed to find package 'libfontconfig1-dev' in known package repositories
> SOME THINGS MAY NOT BUILD AS A RESULT
> Checking for package libxrender-dev
> Failed to find package 'libxrender-dev' in known package repositories
> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
>
> etc..
>
> It appears that a major step is missing or broken.  Can someone help me on
> this?
>
> Thanks!
>
> Mike
>
> ___
> 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] GNU Radio installation script

[Marcus D. Leech]

On 09/21/2015 11:13 PM, Mike Gilmer wrote:

All,
I recently asked the list some questions about getting GNU Radio up
and running on a Windows machine (using cygwin). It became obvious
there would be a lot of hurdles, for which the community would not be
able to offer much help. So...

I have installed Ubuntu on a PC ( in a dual boot configuration with
Win7 ) <-- this is its own drama LOL

I tried to follow the "Installing GNU Radio step(s) outlined on
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
using the script via
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio

and I get a bunch of errors :
Checking for package libfontconfig1-dev
Failed to find package 'libfontconfig1-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT
Checking for package libxrender-dev
Failed to find package 'libxrender-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption

etc..

It appears that a major step is missing or broken.  Can someone help me on this?

Thanks!

Mike

What version of Ubuntu?  A normal configuration?   Does it have internet 
access while it's doing this?





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

[Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

All,
I recently asked the list some questions about getting GNU Radio up
and running on a Windows machine (using cygwin). It became obvious
there would be a lot of hurdles, for which the community would not be
able to offer much help. So...

I have installed Ubuntu on a PC ( in a dual boot configuration with
Win7 ) <-- this is its own drama LOL

I tried to follow the "Installing GNU Radio step(s) outlined on
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
using the script via
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio

and I get a bunch of errors :
Checking for package libfontconfig1-dev
Failed to find package 'libfontconfig1-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT
Checking for package libxrender-dev
Failed to find package 'libxrender-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption

etc..

It appears that a major step is missing or broken.  Can someone help me on this?

Thanks!

Mike

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

[Discuss-gnuradio] AGC_FF Code Implementation

[Richard Bell]

Hello all,

I would like to see how agc_ff is implemented, but there is some gnuradio
magic going on that's beyond me. The agc_ff_impl.cc in analog/lib doesn't
do anything but call scaleN. How do I find the actual implementation code
for this block? I see a kernel::agc_ff(paramters) call in the
initialization list, but I'm not sure what happens there.

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

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Rama V]

Hi,
As advised, the problem has been solved to a little extent where I have got
the below results by giving the commands as

Sender : ./benchmark_tx.py -f 2.435G --tx-gain=25
Receiver: ./benchmark_rx.py -f 2.435G --rx-gain 50

ok: True  pktno: 1971  n_rcvd: 1687  n_right: 358
ok: False  pktno: 1972  n_rcvd: 1688  n_right: 358
ok: False  pktno: 1973  n_rcvd: 1689  n_right: 358
ok: False  pktno: 1974  n_rcvd: 1690  n_right: 358
ok: True  pktno: 1975  n_rcvd: 1691  n_right: 359
ok: False  pktno: 1976  n_rcvd: 1692  n_right: 359
ok: True  pktno: 1977  n_rcvd: 1693  n_right: 360
ok: False  pktno: 1978  n_rcvd: 1694  n_right: 360
ok: True  pktno: 1979  n_rcvd: 1695  n_right: 361
ok: True  pktno: 1980  n_rcvd: 1696  n_right: 362
ok: False  pktno: 1981  n_rcvd: 1697  n_right: 362
ok: True  pktno: 1982  n_rcvd: 1698  n_right: 363
ok: False  pktno: 1983  n_rcvd: 1699  n_right: 363
ok: True  pktno: 1984  n_rcvd: 1700  n_right: 364
ok: False  pktno: 1985  n_rcvd: 1701  n_right: 364
ok: True  pktno: 1986  n_rcvd: 1702  n_right: 365
ok: False  pktno: 1987  n_rcvd: 1703  n_right: 365
ok: True  pktno: 1988  n_rcvd: 1704  n_right: 366

This is because I have changed my folder to /digital/ofdm, I have started
to receive packets. But I guess this is only 50% efficient in receiving
packets. Not all of them have been receiving properly. kindly advise if I
need to figure out the combination settings till most of them receive
properly? Because even though I did not set any sample rate, the
transmitter sent the information. Please help. Please excuse me if I am
being naive in asking these.

Regards,
Dave

On Mon, Sep 21, 2015 at 11:00 AM, Rama V  wrote:

> Hi,
> Thanks Marcus. I will do as you have advised and approach if any
> uncertainties.
>
> Regards,
> Dave
>
> On Mon, Sep 21, 2015 at 10:16 AM, Marcus Müller 
> wrote:
>
>> Hi Dave,
>>
>> you shouldn't be modifying the python files before you understand what
>> they do exactly. Please revert your edits, because it will be impossible to
>> help you if you don't use the same scripts as we do, obviously. We've
>> talked about this[1].
>>
>> So:
>>
>> Sender : benchmark_tx.py -f 2.435G -r 250k
>> Receiver : benchmark_rx.py -f 2.435G
>>
>> That's wrong! Now, your transmitter sends 250,000 bits per second, but
>> your receiver expects 100.000 (the default value, which doesn't work with
>> your hardware), so that's not good. Use the same setting for both
>> benchmark_tx and benchmark_rx.
>>
>> So all you say is I need to change and play with the sampling rates and
>> --tx-amplitude  until the received packet becomes 'n_rcvd=1'
>>
>> No. RF is not "hey, there's this correct setting, let's apply it
>> everywhere"; you'll have to figure out which combination settings work
>> best. Generally, I'd leave the  --tx-amplitude untouched, because 0.25 is a
>> sane value for the digital samples; what you want is analog gain, not
>> digital scaling.
>>
>> You should really set a TX gain and a RX gain. Try around with a few
>> different gain settings for RX and TX gain -- a good approach would be to
>> set something like 25 dB TX gain, and around 50 dB RX gain, if you place
>> your TX and RX antennas far enough from each other. Notice that I'm
>> assuming you're using antennas, and no direct connection! If you're using a
>> direct cable between TX and RX, please use an attenuator, because you might
>> otherwise damage your hardware.
>>
>> To find out how to change the gains, please read the output of
>> benchmark_tx.py --help
>> and of
>> benchmark_rx.py --help
>>
>>
>> Best regards,
>> Marcus
>>
>>
>> [1]
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00124.html
>>
>> On 21.09.2015 16:48, Rama V wrote:
>>
>> I have tried the following commands in the terminal
>>
>> Sender : benchmark_tx.py -f 2.435G -r 250k
>> Receiver : benchmark_rx.py -f 2.435G
>>
>> But the data packets are not being sent correctly. I have been receiving
>> the packets as ok=false. I have tried modifying benchmark  python scripts.
>> Can I do the modification of those scripts or evrything needs to be given
>> in the command line. Please excuse me as I am slightly unable to
>> understand. Thanks
>>
>> Regards,
>> Dave
>> On Sep 18, 2015 2:21 PM, "Rama V" < 
>> ramav...@gmail.com> wrote:
>>
>>> Thanks for the reply Michael. I will look into that as you have advised.
>>> So all you say is I need to change and play with the sampling rates and
>>> --tx-amplitude  until the received packet becomes 'n_rcvd=1' and CRC check
>>> changes to 'ok=true' from the narrowband folder?
>>>
>>> Regards,
>>> Dave
>>>
>>> On Fri, Sep 18, 2015 at 12:40 PM, Michael Dickens <
>>> michael.dick...@ettus.com> wrote:
>>>
 Hi Dave - I'm thinking that you are confusing "--samples-per-symbol"
 for the sample rate. I t

Re: [Discuss-gnuradio] Soundcards / alsa block / sample rates

[Marcus Müller]

What device string are you using?

On 21.09.2015 22:32, Andreas Ladanyi wrote:
> Hi Tom,
>  
> > I'm not sure that I understand. What "alsa block"? Are you talking
> about the audio source/sink blocks? And I'm assuming you mean inside GRC?
>  
> Yes, sorry, I mean the audio sink block which talks to the alsa system.
>  
> >The sample rate of this blocks is a combo box that is editable, which
> means you can set your own value there. The drop-down selections are
> just a handful of known sample rates.
>  
> Yes, but i couldnt change the sample rate to 192k. So the block seems
> not to negotiate / recognize the possible sample rates. So i asking
> myself how i could set the correct sample rate of 192k or how it could
> be detected and used by the audio sink automatically.
>  
> Andy
>  
>
>
> ___
> 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] Soundcards / alsa block / sample rates

[Andreas Ladanyi]

Hi Tom,

 
> I'm not sure that I understand. What "alsa block"? Are you talking about the audio source/sink blocks? And I'm assuming you mean inside GRC?
 

Yes, sorry, I mean the audio sink block which talks to the alsa system.
 
>The sample rate of this blocks is a combo box that is editable, which means you can set your own value there. The drop-down selections are just a handful of known sample rates.

 

Yes, but i couldnt change the sample rate to 192k. So the block seems not to negotiate / recognize the possible sample rates. So i asking myself how i could set the correct sample rate of 192k or how it could be detected and used by the audio sink automatically.
 
Andy
 

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

Re: [Discuss-gnuradio] Gnuradio ASK/OOK Binary sequence

[Nick Foster]

Well, if you want a basically working "cheat sheet", I already wrote a
Gnuradio receiver for those keyfob transmitters:

https://github.com/bistromath/keyfob

It hasn't been updated in years, so it's still on the old Automake system.
It won't compile, but the source should get you started.

--n

On Mon, Sep 21, 2015 at 12:17 PM 0x00-0xff <0x00-0...@stienstra.me> wrote:

>
> Thanks, I've already red those pdf's.
> The adsb grc doesn't help me enough :)
>
> I'm getting large binary files with 0's and 1's which doesn't resemble
> the binary sequence I'm looking for...
>
>
> On 2015-09-20 22:33, Chris Kuethe wrote:
> > Check out gr-adsb
> > (https://github.com/wnagele/gr-adsb/tree/master/examples) - the
> > example flowgraph uses a threshold block to produce 0's and 1's. From
> > there you can unpack bits to bytes, add a constant of 48 (numerical
> > value of ascii '0') and come out with a character stream of '0' and
> > '1', which you can then feed into a file sink (opening /dev/stdout)
> >
> > Also check out these tutorials:
> > http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf
> > https://nccgroup.github.io/RFTM/
> >
> https://cansecwest.com/slides/2015/From_Baseband_to_bitstream_Andy_Davis.pdf
> >
> >
> > On Sun, Sep 20, 2015 at 1:13 PM, 0x00-0xff <0x00-0...@stienstra.me>
> > wrote:
> >> Hi guys,
> >>
> >> After trying several tutorials en demo's... I need your help.
> >>
> >> I'm trying to get the binary stream from a ASK/OOK modulated signal
> >> (keyfobs
> >> on 433mhz).
> >> I've been able to manually write down the sequence and retransmit it:
> >> https://github.com/0x00-0xFF/gr-x10
> >>
> >> How do I get the 0's and 1's on /dev/stdout (or file).
> >> The tutorials I've seen, give me a load of 0's  and 1's that do not
> >> match
> >> the sequence I see in baudline or wx_scope
> >>
> >> What I realy (realy) want is, to save multiple received ASK/OOK
> >> signals into
> >> a file with corresponding frequency.
> >> But any help is appreciated ;)
> >>
> >> Kind regards,
> >>
> >> 0x00_0xFF
> >>
> >> ___
> >> 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] Gnuradio ASK/OOK Binary sequence

[0x00-0xff]

Thanks, I've already red those pdf's.
The adsb grc doesn't help me enough :)

I'm getting large binary files with 0's and 1's which doesn't resemble 
the binary sequence I'm looking for...



On 2015-09-20 22:33, Chris Kuethe wrote:

Check out gr-adsb
(https://github.com/wnagele/gr-adsb/tree/master/examples) - the
example flowgraph uses a threshold block to produce 0's and 1's. From
there you can unpack bits to bytes, add a constant of 48 (numerical
value of ascii '0') and come out with a character stream of '0' and
'1', which you can then feed into a file sink (opening /dev/stdout)

Also check out these tutorials:
http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf
https://nccgroup.github.io/RFTM/
https://cansecwest.com/slides/2015/From_Baseband_to_bitstream_Andy_Davis.pdf


On Sun, Sep 20, 2015 at 1:13 PM, 0x00-0xff <0x00-0...@stienstra.me> 
wrote:

Hi guys,

After trying several tutorials en demo's... I need your help.

I'm trying to get the binary stream from a ASK/OOK modulated signal 
(keyfobs

on 433mhz).
I've been able to manually write down the sequence and retransmit it:
https://github.com/0x00-0xFF/gr-x10

How do I get the 0's and 1's on /dev/stdout (or file).
The tutorials I've seen, give me a load of 0's  and 1's that do not 
match

the sequence I see in baudline or wx_scope

What I realy (realy) want is, to save multiple received ASK/OOK 
signals into

a file with corresponding frequency.
But any help is appreciated ;)

Kind regards,

0x00_0xFF

___
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] [RFNoC] Updates, Renames, Merges

[Martin Braun]

To all RFNoC fans,

we just pushed a big update to the rfnoc-devel branch. Most importantly,
this pulls in all recent UHD features; rfnoc-devel thus has all the
goodies in our current master branch plus all the RFNoC extensions.

*Software Changes*

If you 'git pull' rfnoc-devel, you'll see a huge number of new commits.
Most of them were actually from regular UHD development, but there's one
important change on the software side: The include directory structure
was rectified, all include files now are in

#include 

instead of uhd/usrp/rfnoc, which never really made sense. If you have
software that includes UHD files, this is the command I used to update
my code (run at your own risk, and adapt the glob as required).

$ sed -i -e 's!usrp/rfnoc/!rfnoc/!' **/*.{cc,h}

Furthermore, we had an annoying bug where the B2x0 didn't work on
rfnoc-devel which was taken care of.

Please note you'll also need to update gr-ettus.

*FPGA Changes*

Most importantly, rfnoc-devel now uses Vivado 2015.2, like our master
branch. Please make sure to update your environments to reflect this.

Otherwise, there were no major changes, mostly bugfixes, so your FPGA
codes should still work fine.

Thanks everyone for using RFNoC, and don't hesitate to come back here
with questions!

Cheers,
Martin

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

[Discuss-gnuradio] More possible ways to help contribute

[Tom Rondeau]

Late last week, I provided links to two spreadsheets that I'm using to help
us track progress in a couple of areas and invited anyone willing and able
to participate. During our monthly developer call, Johnathan Corgan
reminded me that we are also looking to move any Python code into C++ (and
wrapped into Python via SWIG). I have just made a new spreadsheet to help
us track this effort, as well:

https://docs.google.com/spreadsheets/d/1R_y0uu2pxgo26jlg4xV5O_8X7P67x3JgSotzTXRkRL0/edit?usp=sharing

I'm largely using these for record keeping of these issues as we progress,
but I also imagine that these might give some people useful ideas for where
they can step in and help the project.

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

[Discuss-gnuradio] New SDR Student Competition at Virginia Tech

[Tom Rondeau]

Hey everyone,

This came across my desk this weekend. It's a new competition, sponsored by
Wireless at Virginia Tech, on spectrum sharing. It's students only, but a
chance to work on some cool new ideas in spectrum sharing and wireless
coexistence.

More details here:

http://radiocontest.wireless.vt.edu/


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

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

Hi Dave,

you shouldn't be modifying the python files before you understand what
they do exactly. Please revert your edits, because it will be impossible
to help you if you don't use the same scripts as we do, obviously. We've
talked about this[1].

So:
> Sender : benchmark_tx.py -f 2.435G -r 250k
> Receiver : benchmark_rx.py -f 2.435G 
That's wrong! Now, your transmitter sends 250,000 bits per second, but
your receiver expects 100.000 (the default value, which doesn't work
with your hardware), so that's not good. Use the same setting for both
benchmark_tx and benchmark_rx.

> So all you say is I need to change and play with the sampling rates
> and --tx-amplitude  until the received packet becomes 'n_rcvd=1'
No. RF is not "hey, there's this correct setting, let's apply it
everywhere"; you'll have to figure out which combination settings work
best. Generally, I'd leave the  --tx-amplitude untouched, because 0.25
is a sane value for the digital samples; what you want is analog gain,
not digital scaling.

You should really set a TX gain and a RX gain. Try around with a few
different gain settings for RX and TX gain -- a good approach would be
to set something like 25 dB TX gain, and around 50 dB RX gain, if you
place your TX and RX antennas far enough from each other. Notice that
I'm assuming you're using antennas, and no direct connection! If you're
using a direct cable between TX and RX, please use an attenuator,
because you might otherwise damage your hardware.

To find out how to change the gains, please read the output of
benchmark_tx.py --help
and of
benchmark_rx.py --help


Best regards,
Marcus


[1] http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00124.html
On 21.09.2015 16:48, Rama V wrote:
>
> I have tried the following commands in the terminal
>
> Sender : benchmark_tx.py -f 2.435G -r 250k
> Receiver : benchmark_rx.py -f 2.435G
>
> But the data packets are not being sent correctly. I have been
> receiving the packets as ok=false. I have tried modifying benchmark 
> python scripts. Can I do the modification of those scripts or
> evrything needs to be given in the command line. Please excuse me as I
> am slightly unable to understand. Thanks
>
> Regards,
> Dave
>
> On Sep 18, 2015 2:21 PM, "Rama V"  > wrote:
>
> Thanks for the reply Michael. I will look into that as you have
> advised. So all you say is I need to change and play with the
> sampling rates and --tx-amplitude  until the received packet
> becomes 'n_rcvd=1' and CRC check changes to 'ok=true' from the
> narrowband folder?
>
> Regards,
> Dave 
>
> On Fri, Sep 18, 2015 at 12:40 PM, Michael Dickens
> mailto:michael.dick...@ettus.com>> wrote:
>
> Hi Dave - I'm thinking that you are confusing
> "--samples-per-symbol" for the sample rate. I think the option
> you're looking for is "-r". Look at the "--help" for those
> examples when you get a chance. - MLD
>  
> On Thu, Sep 17, 2015, at 02:01 PM, Rama V wrote:
>>
>> Thank you very much Michael. I will follow up on your advice.
>> I am sorry that I wasn't able to understand some parts in GNU
>> RADIO and didn't specify enough information.  Regarding the
>> question, I have been doing the benchmark in the digital/
>> narrowband/ folder. The exact commands I have been working on are
>>
>> Sender: benchmark_tx.py -f 2.435G --tx-gain 25
>> --samples-per-symbol 25
>>
>> Receiver: benchmark_rx.py -f 2.435G
>>
>> When I give 250kS/s, my laptop freezes. USRP is XCVR2450. So
>> I started to give less Samples like 50kS/s so that they
>> communicate with each other without errors. But I couldn't
>> figure out the solution to that. So I just have a doubt
>> whether I need to modify benchmark scripts or is it enough
>> for the parameters I give in the command line. Thanks for the
>> help. Please advice
>>
>  
>
>
>
>
> ___
> 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] Fwd: Re: Transmission error

[Rama V]

I have tried the following commands in the terminal

Sender : benchmark_tx.py -f 2.435G -r 250k
Receiver : benchmark_rx.py -f 2.435G

But the data packets are not being sent correctly. I have been receiving
the packets as ok=false. I have tried modifying benchmark  python scripts.
Can I do the modification of those scripts or evrything needs to be given
in the command line. Please excuse me as I am slightly unable to
understand. Thanks

Regards,
Dave
On Sep 18, 2015 2:21 PM, "Rama V"  wrote:

> Thanks for the reply Michael. I will look into that as you have advised.
> So all you say is I need to change and play with the sampling rates and
> --tx-amplitude  until the received packet becomes 'n_rcvd=1' and CRC check
> changes to 'ok=true' from the narrowband folder?
>
> Regards,
> Dave
>
> On Fri, Sep 18, 2015 at 12:40 PM, Michael Dickens <
> michael.dick...@ettus.com> wrote:
>
>> Hi Dave - I'm thinking that you are confusing "--samples-per-symbol" for
>> the sample rate. I think the option you're looking for is "-r". Look at the
>> "--help" for those examples when you get a chance. - MLD
>>
>> On Thu, Sep 17, 2015, at 02:01 PM, Rama V wrote:
>>
>> Thank you very much Michael. I will follow up on your advice. I am sorry
>> that I wasn't able to understand some parts in GNU RADIO and didn't specify
>> enough information.  Regarding the question, I have been doing the
>> benchmark in the digital/ narrowband/ folder. The exact commands I have
>> been working on are
>>
>> Sender: benchmark_tx.py -f 2.435G --tx-gain 25 --samples-per-symbol 25
>>
>> Receiver: benchmark_rx.py -f 2.435G
>>
>> When I give 250kS/s, my laptop freezes. USRP is XCVR2450. So I started to
>> give less Samples like 50kS/s so that they communicate with each other
>> without errors. But I couldn't figure out the solution to that. So I just
>> have a doubt whether I need to modify benchmark scripts or is it enough for
>> the parameters I give in the command line. Thanks for the help. Please
>> advice
>>
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about correlate_access_code_bb_impl

[Tom Rondeau]

On Mon, Sep 21, 2015 at 6:40 AM, bob wole  wrote:

> I am studying the code of correlate_access_code_bb_impl.cc for
> understanding its working. I see that the block is derive from "block"
> class of gr as written in correlate_access_code_bb_ts.h file
>
>
> class DIGITAL_API correlate_access_code_bb_ts : virtual public block
>
>
> I read earlier that blocks derived from "block"/"gr::block"  should
> implement forecast() method, but I did not see any implementation of
> forecast() in  code of correlate_access_code_bb_impl.cc.
>
> Can somebody please tell me why ?
>
> --
> Bob
>


First, you have a misunderstanding of the header/source relationship. There
are a number of correlate* blocks in GNU Radio (and an unwritten plan to
organize them better in the future). The correlate_access_code_bb is one
block, and this is a gr::sync_block. The correlate_access_code_bb_ts is
another block, and this one is a gr::block.

If you look at the code for block.cc, you'll see it implements a forecast
function already:

  void
  block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
  {
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
  ninput_items_required[i] = noutput_items + history() - 1;
  }


That means that any block that derives from gr::block gets this behavior,
which tells the scheduler that given noutput_items, the block needs this
many input items to produce that output amount. This is a satisfactory
condition for many blocks, so no, you don't /have/ to overload forecast in
your derived block if this condition meets your block's behavior.

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

Re: [Discuss-gnuradio] Possibly ways to help contribute

[Tom Rondeau]

On Sun, Sep 20, 2015 at 8:08 PM, Andy Walls 
wrote:

>
> > Hello GNU Radio dev community! I wanted to pass on some information
> > for you that might be a good way for you to help contribute to our
> > project. Thanks to Pete Mathys during out GRCon15 Hackfest, we now
> > have a list of blocks with minimal or no documentation. I've put
> > together a Google spreadsheet that lists all of the blocks in
> > question. For anyone looking to help us fix the documentation, this
> > would be a good place to start.
> >
> >
> > One of the issues is that many of these blocks are Python-based as
> > hierarchical blocks. Some have full documentation that is not properly
> > getting exported into GRC. So it might not be a case of documentation
> > but helping identify how to get that information out there.
> >
> >
> https://docs.google.com/spreadsheets/d/1Tb4nRjz8ruhzq-TlpkKFsByWI92fsON2cqR5HOolIwE/edit?usp=sharing
> >
> >
> > Another area to contribute is to help us identify areas where we can
> > better apply VOLK. Another spreadsheet that I've created lists all of
> > the public classes in GNU Radio. We wish to identify which
> > classes/blocks could be redone using VOLK. And if so, what VOLK
> > kernels should we use as well as an indicator for if the use of VOLK
> > is done in that block. This can hopefully serve as a checklist for the
> > project in general and a good way for people to contribute and help
> > get our code moving faster.
> >
> >
> https://docs.google.com/spreadsheets/d/1zKBi3xmihD2Tv7ME0qsKOzC6QjV5FtzIk6mqpHbNlCI/edit?usp=sharing
>
>
> I started my edits on this spreadsheet.  Only lines 2-15 so far, but
> I'll try to skim the blocks and knock out more comments as I find time.
>
> http://i.imgur.com/rmnoAmW.jpg
>
> Regards,
> Andy
>

Thanks, Andy. Great start!

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

Re: [Discuss-gnuradio] Soundcards / alsa block / sample rates

[Tom Rondeau]

On Sun, Sep 20, 2015 at 3:46 PM, Andreas Ladanyi 
wrote:

> i use a soundcard which could sample at a sample rate of 192 kbits. if i
> have a look at the alsa block i could see options up to sample rate of 48k.
> Because i could set the sample rate in the alsa block i think that the alsa
> block is able to set sample rate of a soundcard. So how could i tell
> gnuradios alsa block (or another block) to set the sample rate to 192k ?
>
> cheers,
> Andy
>


I'm not sure that I understand. What "alsa block"? Are you talking about
the audio source/sink blocks? And I'm assuming you mean inside GRC?

The sample rate of this blocks is a combo box that is editable, which means
you can set your own value there. The drop-down selections are just a
handful of known sample rates.

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

[Discuss-gnuradio] Question about correlate_access_code_bb_impl

[bob wole]

I am studying the code of correlate_access_code_bb_impl.cc for
understanding its working. I see that the block is derive from "block"
class of gr as written in correlate_access_code_bb_ts.h file


class DIGITAL_API correlate_access_code_bb_ts : virtual public block


I read earlier that blocks derived from "block"/"gr::block"  should
implement forecast() method, but I did not see any implementation of
forecast() in  code of correlate_access_code_bb_impl.cc.

Can somebody please tell me why ?

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

Re: [Discuss-gnuradio] change frequency in gr-ieee802-15-4 example transceiver_OQPSK.py

[Marcus Müller]

Hi Jaeho,

there's three blocks that use the "freq" variable from that WX GUI slider:

* the USRP source
* the USRP sink
* the FFT sink

The first two have an input message port; you can connect a
message-emitting block to these, and send PMTs containing commands to
these [1]. The WX FFT sink doesn't have such an input port, but frankly,
that doesn't matter, because it only needs the center frequency to
display it [2]

To test your case, try a "Message strobe" block, with the message set to
something like

pmt.pmt_to_python.python_to_pmt({"freq":2.4e9})


Obviously, that will just periodically set the /same/ frequency (2.4GHz)
over and over again. However, as soon as you have verified that works,
you can just write your own (python or C++) block that has no stream in-
or outputs, but spawns a new thread that periodically sends a message
out; see [1] for the syntax you'd need to use to add exact timing to the
command dictionaries.

Best regards,
Marcus

[1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
[2] if that bothers you, replace all the WX things in your flow graph by
Qt elements; you can enable message ports on these
On 21.09.2015 08:11, Jaeho wrote:
> Hello. I am using Ubuntu 15.04 now.
> I have a question about transceiver_OQPSK.py source code.
> I success to run this source code on USRP X300.
> The thing that i want to do next is changing frequency
> automatically(randomly).
> Originally, this code choose frequency using radio button GUI to change
> frequency.
> But, i hope to change frequency automatically without any GUI working.
> For example, if I run this code, then frequency is changed periodically and
> have random value.
>
> Which block should I use to change value automatically in GRC 
> or how can i modify in python code.
>
> Please give me advice.
> Thank you
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/change-frequency-in-gr-ieee802-15-4-example-transceiver-OQPSK-py-tp56164.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] ofdm demod could not demodulate

[Marcus Müller]

Hi Gnoob16,

it would be interesting to see your actual OFDM demodulator flowgraph,
as well as the spectrum you see on the Qt frequency sink in your picture.
However, the fact that the OFDM demod doesn't output anything usually
simply means that it doesn't detect any packets coming in; are you sure
your RF sink/source's settings are correct? A ~4MHz sampling rate with a
2kHz RF bandwidth doesn't seem to make too much sense to me :)

Best regards,
Marcus

On 19.09.2015 11:26, gnoob16 wrote:
>  
>
> hi this is my ofdm transmitter... the thing here is that the ofdm signal
> could not get demodulated at all... the qt frequency sink displays nothing
> when connected after the ofdm demodulator...
>
> im using zedboard with the adi fmcomms...
>
> thanks!
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/ofdm-demod-could-not-demodulate-tp56156.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] help

[Marcus Müller]

Hi Mahongroo,

You wrote
> help
I think we'd like to help you if you could explain with what you'd need
help :)

Best regards,
Marcus

On 20.09.2015 11:30, mahongroo wrote:
> help
>
>
> 发自网易邮箱手机版
>
>
> On 2015-09-20 00:00 , discuss-gnuradio-requ...@gnu.org
>  Wrote:
>
> Send Discuss-gnuradio mailing list submissions to
>  discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
>  discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
>  discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>   1. Re: Fwd: Re: Transmission error (Michael Dickens)
>   2. Re: Fwd: Re: Transmission error (Rama V)
>   3. ofdm demod could not demodulate (gnoob16)
>
>
> --
>
>
> Message: 1
> Date: Fri, 18 Sep 2015 13:40:53 -0400
> From: Michael Dickens 
> To: Rama V 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Fwd: Re: Transmission error
> Message-ID:
>
>  <1442598053.2651508.387507145.0a8a6...@webmail.messagingengine.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Dave - I'm thinking that you are confusing
> "--samples-per-symbol" for
> the sample rate. I think the option you're looking for is "-r".
> Look at
> the "--help" for those examples when you get a chance. - MLD
>
> On Thu, Sep 17, 2015, at 02:01 PM, Rama V wrote:
> > Thank you very much Michael. I will follow up on your advice. I am
> > sorry that I wasn't able to understand some parts in GNU RADIO and
> > didn't specify enough information.? Regarding the question, I have
> > been doing the benchmark in the digital/ narrowband/ folder. The
> exact
> > commands I have been working on are
>
>
> > Sender: benchmark_tx.py -f 2.435G --tx-gain 25 --samples-per-
> > symbol 25
>
>
> > Receiver: benchmark_rx.py -f 2.435G
>
>
> > When I give 250kS/s, my laptop freezes. USRP is XCVR2450. So I
> started
> > to give less Samples like 50kS/s so that they communicate with each
> > other without errors. But I couldn't figure out the solution to
> that.
> > So I just have a doubt whether I need to modify benchmark
> scripts or
> > is it enough for the parameters I give in the command line.
> Thanks for
> > the help. Please advice
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 
> 
> 
> ;
>
>
> --
>
> Message: 2
> Date: Fri, 18 Sep 2015 14:21:43 -0500
> From: Rama V 
> To: Michael Dickens 
> Cc: "discuss-gnuradio@gnu.org" 
> Subject: Re: [Discuss-gnuradio] Fwd: Re: Transmission error
> Message-ID:
>
>  
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the reply Michael. I will look into that as you have
> advised. So
> all you say is I need to change and play with the sampling rates and
> --tx-amplitude  until the received packet becomes 'n_rcvd=1' and
> CRC check
> changes to 'ok=true' from the narrowband folder?
>
> Regards,
> Dave
>
> On Fri, Sep 18, 2015 at 12:40 PM, Michael Dickens
>  > wrote:
>
> > Hi Dave - I'm thinking that you are confusing
> "--samples-per-symbol" for
> > the sample rate. I think the option you're looking for is "-r".
> Look at the
> > "--help" for those examples when you get a chance. - MLD
> >
> > On Thu, Sep 17, 2015, at 02:01 PM, Rama V wrote:
> >
> > Thank you very much Michael. I will follow up on your advice. I
> am sorry
> > that I wasn't able to understand some parts in GNU RADIO and
> didn't specify
> > enough information.  Regarding the question, I have been doing the
> > benchmark in the digital/ narrowband/ folder. The exact commands
> I have
> > been working on are
> >
> > Sender: benchmark_tx.py -f 2.435G --tx-gain 25
> --samples-per-symbol 25
> >
> > Receiver: benchmark_rx.py -f 2.435G
> >
> > When I give 250kS/s, my laptop freezes. USRP is XCVR2450. So I
> started to
> > give less Samples like 50kS/s so that they communicate with each
> other
> > without errors. But I couldn't figure out the solution to that.
> So I just
> > have a doubt whether I need to modify benchmark scripts