Re: [Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[mlustig]

I tried the Burst Tagger block. Reading on-line it seems that the key tags 
should be tx_eob and tx_sob

I implemented this way:


I can see the Tags in the stream using Tag debugger, but nothing is happening 
to the UHD sink which keeps transmitting. 

Anybody? 

Thanks,


-- Miki



On Dec 4, 2013, at 8:04 AM, Marcus D. Leech [via GnuRadio] 
 wrote:

> On 12/04/2013 10:49 AM, Michael Lustig wrote: 
> > I see,interesting. 
> > 
> > So how do you send an SOB tag within gnu radio companion? 
> > I'm new to this and could not find any documentation on grc that made sense 
> > to me. 
> > 
> > -- Miki, KK6MRI, from mobile 
> There's a burst-tagger block: 
> 
> http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1burst__tagger.html
> 
> I can't for the life of me remember how to form the SOB/EOB tags that 
> UHD needs.  But perhaps someone who has actually used the EOB/SOB stuff 
>could chime in. 
> 
> 
> 
> -- 
> Marcus Leech 
> Principal Investigator 
> Shirleys Bay Radio Astronomy Consortium 
> http://www.sbrac.org
> 
> 
> ___ 
> Discuss-gnuradio mailing list 
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://gnuradio.4.n7.nabble.com/How-to-turn-off-TX-of-UHD-sink-in-gnuradio-companion-tp45134p45179.html
> To unsubscribe from How to turn-off TX of UHD sink in gnuradio companion?, 
> click here.
> NAML



PastedGraphic-8.tiff (101K) 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-to-turn-off-TX-of-UHD-sink-in-gnuradio-companion-tp45134p45196.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] version 3.7 gr.remez problem

[Tom Rondeau]

On Wed, Dec 4, 2013 at 7:39 PM, kdag  wrote:
> hi, in this file:
> /usr/local/lib/python2.7/dist-packages/gnuradio/optfir.py
>
> there is a definition for a remez filter that uses the gr.remez function. It
> seems it,s not here anymore in the new version. How can I replace it?
>
> any hints appreciated since both the IRC channel and the search engine
> haven't really helped.
>
> tx!

Well, I have to say that I'm a bit hurt by this email. After all, I
did answer your question on IRC. Though you came back later with
another question, and also though you have given us very little
information to go on to help you.

First, as I explained on IRC, that function was renamed pm_remez and
is found in the filter module (from gnuradio import filter;
filter.pm_remez).

>From the looks of things, you have older code installed and now are
trying to use GNU Radio 3.7.x. We always recommend to remove any
previous installed files when updating to a new GNU Radio API version
(e.g., from 3.6 to 3.7). The new optfir.py file uses the pm_remez
function.

There many other changes that are similarly semantic between the
versions. You can get more information about the changes here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

Tom

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

Re: [Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Stefan Gofferje]

On 12/04/2013 06:35 PM, Marcus Müller wrote:
> While you're at it - why do you download tarballs instead of simply
> taking the git route, giving you the recent version; or even trying
> the pyBOMBS way, which might even install dependencies for you
> (honestly, I don't know if it works with Suse, though, or tries to
> build all tools and requirements from source instead of fetching
> packages where applicable).

I just wanted to get it to run first. I'm not familiar with GnuRadio yet
ad very often, if you download from GIT, you get some unstable stuff, so
unless I know a project, I tend to stick to some release-files.

-S


-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] version 3.7 gr.remez problem

[kdag]

hi, in this file:
/usr/local/lib/python2.7/dist-packages/gnuradio/optfir.py

there is a definition for a remez filter that uses the gr.remez function.
It seems it,s not here anymore in the new version. How can I replace it?

any hints appreciated since both the IRC channel and the search engine
haven't really helped.

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

Re: [Discuss-gnuradio] Error 28

[Marcus D. Leech]

Useful list! Thank you!
That code comes from "errno", which are the integer return codes from 
system calls.


Many Linuxes have a "perror" command line tool that can translate these 
into text:


perror 28

Might have worked for you.  Although, it's considered "polite" for 
programs, when getting an error return from a kernel call to
  use the programmatic equivalent of "perror" on return codes to give a 
more meaningful result.





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


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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Philip Balister]

On 12/04/2013 05:26 PM, Monahan-Mitchell, Tim wrote:
>> The volk test is failing on my gnuradio build on a Beaglebone Black
>> (armv7h) running Arch Linux Arm.
>>
>> # make test
>> start   1: qa_volk_test_all
>> *** 2 failures detected in test suite "Master Test Suite"1/177 Test   #1:
>> qa_volk_test_all .***Failed9.88 sec
> 
>> Full output of ctest -V _R qa_volk_test_all is attatched.
> 
> which version of GNU Radio? These bugs were fixed on Nov. 19 and will be 
> a part of the 3.7.2.1 release.
> See bugs #582 and #583 on our Issues page.
> Tom
> 
 After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
 ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached 
 in the first message of this thread. So there is something still going on 
 here. Is it possible some external component needs to be updated, that is 
 outside of what's in the GR git tree?
> 
 The output I originally logged in Bug #583 differs from our latest 
 results, but the behavior is the same (in1/in2 values appear to match).
 The output I originally logged in Bug #582 (for ARM target) remains the 
 same (in1/in2 values differ by 1).
>>> I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
>>> from the latest git checkout (was testing Balister's new OE manifest
>>> and SDK) and everything is working great here.
>  
>>> When you say you did a "fresh build", what does that really mean? One
>>> of the quirks of volk is that cmake /has/ to be rerun when these kinds
>>> of changes are made. Best really to clean up everything to make sure
>>> you're doing everything from a clean checkout. "git reset --hard; git
>>> pull origin master; git clean -dxf;". Then rerun cmake and make from a
>>> clean build directory.
>  
>>> The above might be overkill, so if you want a quicker test, start with
>>> the clean git pull of the latest head and just make sure to rerun
>>> cmake and make, not necessarily from an empty directory.
> 
> Hi, Tom,
> I tried these steps:
> - Uninstalled gnuradio (make uninstall).
> - apt-get update + apt-get upgrade for my ARM7 target (Ubuntu 13.04),
>   which updated quite a bit of stuff.
> - Deleted my gnuradio tree and re-cloned it.
> - Checkout maint branch.
> - Built as I have been doing.
> - Same problem :(
> 
> Hi, Philip,
>> Building gnuradio on an arm is silly :)
> I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86 
> prowess. :)
> 
>> I am wondering if the QA failure is relates, to the use of the hard float 
>> ABI.
> For me, whenever I have tried to specify hard or soft float ABI, cmake fails. 
> If I don't specify it, it just works...
> 
>> I'm switching my OE builds to armthf now so I can compare my results with 
>> Tom's.
> Thanks!

I'm working on a real fix for the qa code (not just symlinking until it
works) Hopefully, I can confirm hard float status tomorrow.

Philip

> 
> Tim 
> 
> 

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

Re: [Discuss-gnuradio] Error 28

[Paul B. Huter]

Useful list! Thank you!


On Wed, Dec 4, 2013 at 5:35 PM, Mark Cottrell
wrote:

> On Thu, Dec 5, 2013 at 12:04 PM, Paul B. Huter wrote:
>
>> I have a USRP source going direct to a file sink, and it runs really
>> well, except for an error. Does anyone know what the following means?:
>>
>> thread[thread-per-block[1]: ]: file_sink write
>> failed with error 28
>>
>
> it means that you're out of space (
> http://www.virtsync.com/c-error-codes-include-errno) on the device
>
>
>>
>> I am writing to a RAMDisk, if that helps with a solution.
>>
>> Thank you.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> --
> This email, including any attachments, is only for the intended recipient.
> It is subject to copyright, is confidential and may be the subject of legal
> or other privilege, none of which is waived or lost by reason of this
> transmission.
> If you are not an intended recipient, you may not use, disseminate,
> distribute or reproduce such email, any attachments, or any part thereof.
> If you have received a message in error, please notify the sender
> immediately and erase all copies of the message and any attachments.
> Unfortunately, we cannot warrant that the email has not been altered or
> corrupted during transmission nor can we guarantee that any email or any
> attachments are free from computer viruses or other conditions which may
> damage or interfere with recipient data, hardware or software. The
> recipient relies upon its own procedures and assumes all risk of use and of
> opening any attachments.
> --
>
> ___
> 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] Error 28

[Mark Cottrell]

On Thu, Dec 5, 2013 at 12:04 PM, Paul B. Huter wrote:

> I have a USRP source going direct to a file sink, and it runs really well,
> except for an error. Does anyone know what the following means?:
>
> thread[thread-per-block[1]: ]: file_sink write failed
> with error 28
>

it means that you're out of space (
http://www.virtsync.com/c-error-codes-include-errno) on the device


>
> I am writing to a RAMDisk, if that helps with a solution.
>
> Thank you.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

-- 

--
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
--
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error 28

[Paul B. Huter]

I have a USRP source going direct to a file sink, and it runs really well,
except for an error. Does anyone know what the following means?:

thread[thread-per-block[1]: ]: file_sink write failed
with error 28

I am writing to a RAMDisk, if that helps with a solution.

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Monahan-Mitchell, Tim]

> The volk test is failing on my gnuradio build on a Beaglebone Black
> (armv7h) running Arch Linux Arm.
>
> # make test
> start   1: qa_volk_test_all
> *** 2 failures detected in test suite "Master Test Suite"1/177 Test   #1:
> qa_volk_test_all .***Failed9.88 sec

> Full output of ctest -V _R qa_volk_test_all is attatched.

 which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a 
 part of the 3.7.2.1 release.
 See bugs #582 and #583 on our Issues page.
 Tom

>>> After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
>>> ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached 
>>> in the first message of this thread. So there is something still going on 
>>> here. Is it possible some external component needs to be updated, that is 
>>> outside of what's in the GR git tree?

>>> The output I originally logged in Bug #583 differs from our latest results, 
>>> but the behavior is the same (in1/in2 values appear to match).
>>> The output I originally logged in Bug #582 (for ARM target) remains the 
>>> same (in1/in2 values differ by 1).
>> I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
>> from the latest git checkout (was testing Balister's new OE manifest
>> and SDK) and everything is working great here.
 
>> When you say you did a "fresh build", what does that really mean? One
>> of the quirks of volk is that cmake /has/ to be rerun when these kinds
>> of changes are made. Best really to clean up everything to make sure
>> you're doing everything from a clean checkout. "git reset --hard; git
>> pull origin master; git clean -dxf;". Then rerun cmake and make from a
>> clean build directory.
 
>> The above might be overkill, so if you want a quicker test, start with
>> the clean git pull of the latest head and just make sure to rerun
>> cmake and make, not necessarily from an empty directory.

Hi, Tom,
I tried these steps:
- Uninstalled gnuradio (make uninstall).
- apt-get update + apt-get upgrade for my ARM7 target (Ubuntu 13.04),
  which updated quite a bit of stuff.
- Deleted my gnuradio tree and re-cloned it.
- Checkout maint branch.
- Built as I have been doing.
- Same problem :(

Hi, Philip,
> Building gnuradio on an arm is silly :)
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86 
prowess. :)

> I am wondering if the QA failure is relates, to the use of the hard float ABI.
For me, whenever I have tried to specify hard or soft float ABI, cmake fails. 
If I don't specify it, it just works...

> I'm switching my OE builds to armthf now so I can compare my results with 
> Tom's.
Thanks!

Tim 

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

Re: [Discuss-gnuradio] About DPSK mod and demod

[Henry Jin]

On Wed, Dec 4, 2013 at 12:13 PM, Michael Berman 
 wrote:

> Looking at your flowchart in the original post, you have an Unpacked to
> Packed block after the demodulator, with bit's per symbol of 1.  This
> doesn't seem right to me.  I have never tried this with a random source
> like you have it setup, however there should be an Unpacked to Packed block
> prior to the modulator and a Packed to Unpacked block after the
> demodulator.  These should also have bits per chunck values that correspond
> with the bits per symbol of the modulator and demodulator.  You need to
> feed in the data in a chunk with the correct amount of bits that correspond
> to the bits per symbol of the modulation scheme being used.  In the
> example, it looks like you are using QPSK, and therefore the bits per chunk
> should be 2 (which is log2(number of constellation points)).  The modulator
> and demodulator work with chunks of data where each chuck corresponds to a
> symbol.
>

*If not using the random source, what other sources do you think it's
better? I know GLFSR source also perfectly fits into this scenario. You
also mentioned I have to attach a Unpacked to Packed block prior to the
modulator. But since in my flow, I already set the random source with
maximum being 256. That means it's already outputting packed bytes. Thus,
IMO, Unpacked to Packed block is not needed based on my settings. The
reason I set the Bits per Chunk value as 1 in the Unpacked to Packed block
after demodulation is that I notice in the source code, it says the output
of the demodulation block is unpacked byte with only one LSB being valid.
So In my understanding, it is independent of what modulations (BPSK, QPSK,
etc) I'm using. *


>
> For the Samples per Symbol, if I were transmitting over the air, I would
> raise this value to a little bit more than 2, just to ensure the receiver
> can lock onto the changes with given noise before the symbol changes again.
>  In this case of looping the modulator strait into the demodulator, this
> should work fine.
>

*Thanks for the advice, I will take it. *


>
> One more thing I would look at would be the Error Rate block source.  I
> have never used this block, but in my thinking about it in this flowchart,
> I would source it from the throttle instead of the random source.  This may
> help with keeping the data a little more somewhat aligned.
>
>
*Yes, this could make things clearer. But maybe it makes no difference. I
remember in one of Tom's tutorial, he said as long as there is one throttle
in the flow, then all the units are throttled.*

>
>
> Michael
>
>
> On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin  wrote:
>
>> I tried again replacing the DPSK module with PSK module. Still cannot get
>> the correct data. The parameter for Error Rate "Bits per Symbol" is changed
>> to 8 since every bit carries information in my flow. The sizes of the files
>> from the two file sinks are exactly the same, except with different data.
>>
>>
>> On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster wrote:
>>
>>> Can you try using the PSK mod/demod blocks with differential=Yes instead
>>> of the DPSK mod/demod blocks? I found an issue today with the DPSK
>>> mod/demod blocks which results in them not actually using differential
>>> encoding.
>>>
>>> --n
>>>
>>>
>>> On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin  wrote:
>>>
 Hi,

 I tried to build a simple flow graph of DPSK modulation and
 demodulation. The result is verified using the Error Rate module. The link
 shows the flow I'm using.


 https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png

 I know that the output of demod module is unpacked bytes, so an
 "unpacked to packed" module is attached after demodulation. However, the
 BER is close to 50%, which surely indicates something wrong. I further
 analyzed the two inputs of the Error Rate module by writing info to the
 file sink. It clearly shows the discrepancy. So I just wonder what is wrong
 with this flow graph. Could someone please help me?

 Also, as I noticed, in the output file generated after "unpacked to
 packed" module, there are many consecutive 0s at the start of the file.
 Does that indicate something?

  Suggestions are greatly appreciated!

 Henry

 ___
 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] About DPSK mod and demod

[Michael Berman]

Looking at your flowchart in the original post, you have an Unpacked to
Packed block after the demodulator, with bit's per symbol of 1.  This
doesn't seem right to me.  I have never tried this with a random source
like you have it setup, however there should be an Unpacked to Packed block
prior to the modulator and a Packed to Unpacked block after the
demodulator.  These should also have bits per chunck values that correspond
with the bits per symbol of the modulator and demodulator.  You need to
feed in the data in a chunk with the correct amount of bits that correspond
to the bits per symbol of the modulation scheme being used.  In the
example, it looks like you are using QPSK, and therefore the bits per chunk
should be 2 (which is log2(number of constellation points)).  The modulator
and demodulator work with chunks of data where each chuck corresponds to a
symbol.

For the Samples per Symbol, if I were transmitting over the air, I would
raise this value to a little bit more than 2, just to ensure the receiver
can lock onto the changes with given noise before the symbol changes again.
 In this case of looping the modulator strait into the demodulator, this
should work fine.

One more thing I would look at would be the Error Rate block source.  I
have never used this block, but in my thinking about it in this flowchart,
I would source it from the throttle instead of the random source.  This may
help with keeping the data a little more somewhat aligned.

Michael


On Wed, Dec 4, 2013 at 9:52 AM, Henry Jin  wrote:

> I tried again replacing the DPSK module with PSK module. Still cannot get
> the correct data. The parameter for Error Rate "Bits per Symbol" is changed
> to 8 since every bit carries information in my flow. The sizes of the files
> from the two file sinks are exactly the same, except with different data.
>
>
> On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster  wrote:
>
>> Can you try using the PSK mod/demod blocks with differential=Yes instead
>> of the DPSK mod/demod blocks? I found an issue today with the DPSK
>> mod/demod blocks which results in them not actually using differential
>> encoding.
>>
>> --n
>>
>>
>> On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin  wrote:
>>
>>> Hi,
>>>
>>> I tried to build a simple flow graph of DPSK modulation and
>>> demodulation. The result is verified using the Error Rate module. The link
>>> shows the flow I'm using.
>>>
>>>
>>> https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png
>>>
>>> I know that the output of demod module is unpacked bytes, so an
>>> "unpacked to packed" module is attached after demodulation. However, the
>>> BER is close to 50%, which surely indicates something wrong. I further
>>> analyzed the two inputs of the Error Rate module by writing info to the
>>> file sink. It clearly shows the discrepancy. So I just wonder what is wrong
>>> with this flow graph. Could someone please help me?
>>>
>>> Also, as I noticed, in the output file generated after "unpacked to
>>> packed" module, there are many consecutive 0s at the start of the file.
>>> Does that indicate something?
>>>
>>>  Suggestions are greatly appreciated!
>>>
>>> Henry
>>>
>>> ___
>>> 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] About DPSK mod and demod

[Tom Rondeau]

On Wed, Dec 4, 2013 at 12:52 PM, Henry Jin  wrote:
> I tried again replacing the DPSK module with PSK module. Still cannot get
> the correct data. The parameter for Error Rate "Bits per Symbol" is changed
> to 8 since every bit carries information in my flow. The sizes of the files
> from the two file sinks are exactly the same, except with different data.

Bits/symbol refers to the constellation. BPSK is 1 bit/sym, QPSK is 2
bit/sym, etc.

Tom


> On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster  wrote:
>>
>> Can you try using the PSK mod/demod blocks with differential=Yes instead
>> of the DPSK mod/demod blocks? I found an issue today with the DPSK mod/demod
>> blocks which results in them not actually using differential encoding.
>>
>> --n
>>
>>
>> On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin  wrote:
>>>
>>> Hi,
>>>
>>> I tried to build a simple flow graph of DPSK modulation and demodulation.
>>> The result is verified using the Error Rate module. The link shows the flow
>>> I'm using.
>>>
>>>
>>> https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png
>>>
>>> I know that the output of demod module is unpacked bytes, so an "unpacked
>>> to packed" module is attached after demodulation. However, the BER is close
>>> to 50%, which surely indicates something wrong. I further analyzed the two
>>> inputs of the Error Rate module by writing info to the file sink. It clearly
>>> shows the discrepancy. So I just wonder what is wrong with this flow graph.
>>> Could someone please help me?
>>>
>>> Also, as I noticed, in the output file generated after "unpacked to
>>> packed" module, there are many consecutive 0s at the start of the file. Does
>>> that indicate something?
>>>
>>> Suggestions are greatly appreciated!
>>>
>>> Henry
>>>
>>> ___
>>> 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] About DPSK mod and demod

[Henry Jin]

I tried again replacing the DPSK module with PSK module. Still cannot get
the correct data. The parameter for Error Rate "Bits per Symbol" is changed
to 8 since every bit carries information in my flow. The sizes of the files
from the two file sinks are exactly the same, except with different data.


On Tue, Dec 3, 2013 at 10:11 PM, Nick Foster  wrote:

> Can you try using the PSK mod/demod blocks with differential=Yes instead
> of the DPSK mod/demod blocks? I found an issue today with the DPSK
> mod/demod blocks which results in them not actually using differential
> encoding.
>
> --n
>
>
> On Tue, Dec 3, 2013 at 9:00 PM, Henry Jin  wrote:
>
>> Hi,
>>
>> I tried to build a simple flow graph of DPSK modulation and demodulation.
>> The result is verified using the Error Rate module. The link shows the flow
>> I'm using.
>>
>>
>> https://www.dropbox.com/s/jwmmttyi4es4alf/Screenshot%20from%202013-12-03%2021%3A50%3A58.png
>>
>> I know that the output of demod module is unpacked bytes, so an "unpacked
>> to packed" module is attached after demodulation. However, the BER is close
>> to 50%, which surely indicates something wrong. I further analyzed the two
>> inputs of the Error Rate module by writing info to the file sink. It
>> clearly shows the discrepancy. So I just wonder what is wrong with this
>> flow graph. Could someone please help me?
>>
>> Also, as I noticed, in the output file generated after "unpacked to
>> packed" module, there are many consecutive 0s at the start of the file.
>> Does that indicate something?
>>
>>  Suggestions are greatly appreciated!
>>
>> Henry
>>
>> ___
>> 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] Install: qa_volk_test_all fails on armv7

[Philip Balister]

On 12/04/2013 09:45 AM, Tom Rondeau wrote:
> On Tue, Dec 3, 2013 at 3:13 PM, Monahan-Mitchell, Tim
>  wrote:
 The volk test is failing on my gnuradio build on a Beaglebone Black
 (armv7h) running Arch Linux Arm.

 # make test
 start   1: qa_volk_test_all
 *** 2 failures detected in test suite "Master Test Suite"1/177 Test   #1:
 qa_volk_test_all .***Failed9.88 sec
>>
 Full output of ctest -V _R qa_volk_test_all is attatched.
>>
>>> which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a 
>>> part of the 3.7.2.1 release.
>>> See bugs #582 and #583 on our Issues page.
>>> Tom
>>
>> After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
>> ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached 
>> in the first message of this thread. So there is something still going on 
>> here. Is it possible some external component needs to be updated, that is 
>> outside of what's in the GR git tree?
>>
>> The output I originally logged in Bug #583 differs from our latest results, 
>> but the behavior is the same (in1/in2 values appear to match).
>>
>> The output I originally logged in Bug #582 (for ARM target) remains the same 
>> (in1/in2 values differ by 1).
>>
>> Regards,
>> Tim
> 
> I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
> from the latest git checkout (was testing Balister's new OE manifest
> and SDK) and everything is working great here.
> 
> When you say you did a "fresh build", what does that really mean? One
> of the quirks of volk is that cmake /has/ to be rerun when these kinds
> of changes are made. Best really to clean up everything to make sure
> you're doing everything from a clean checkout. "git reset --hard; git
> pull origin master; git clean -dxf;". Then rerun cmake and make from a
> clean build directory.
> 
> The above might be overkill, so if you want a quicker test, start with
> the clean git pull of the latest head and just make sure to rerun
> cmake and make, not necessarily from an empty directory.

Building gnuradio on an arm is silly :) (OK, mayb eif you have an armv8
server, but these do not exists yet) I am building gnuradio on a quad
A15 (limping across the OOM's). At the same time I built the toolchain
form an imge, installed the toolchain, configured and compiled gnuradio
on my x86.

Once we solve the mystery of the hardcoded paths in the QA code and work
out installing on the target from a cross build, things will be really nice.

On the subject of the email, I am wondering if the QA failure is relates
to the use of the hard float ABI. I'm switching my OE builds to armthf
now so I can compare my results with Tom's.

Philip

> 
> 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] Prevented in-tree build. This is bad practice. ???

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

While you're at it - why do you download tarballs instead of simply
taking the git route, giving you the recent version; or even trying
the pyBOMBS way, which might even install dependencies for you
(honestly, I don't know if it works with Suse, though, or tries to
build all tools and requirements from source instead of fetching
packages where applicable).


On 04.12.2013 17:28, Stefan Gofferje wrote:
> On 12/04/2013 02:04 PM, Martin Braun (CEL) wrote:
>> OK, that's unusual and I can't reproduce it here even by copy &
>> pasting the commands and doing exactly the same. You could try
>> 3.7.2.1 (although I couldn't say why 3.7.2 wouldn't work) and
>> using other build directories.
> 
> I downloaded the file new and deleted everything and created the
> dirs new again and then it worked - basically. Typical
> Suse-phenomenon - tons of dependencies not found... Luckily, I
> found a 3.7.3-git version on OSBS which runs fine so far.
> 
> -S
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSn1nHAAoJEAFxB7BbsDrLlnoH/jHueKKfVLZyJpGTxbJ0QUCh
LGX8Akz3Ek74QCtJ3sGtjnMZr4GFXHDNQUYVXaXhC1CyZA99SVzZXKqzOpYafcii
ngnOS9xy//En7HKB2Qqs0bROSSFMrSiUTV00MXwFySrowl/VJlxR/3hTm1cgBzGL
UzxxP/WlF7yHQuERjV2+BYJE9kMAlB0hqYDy657Lw5mN2Dpr3JRtTAkvwEsXzEwK
ILI1to/pCU5cIDcTbBwt+2whRhP3ZHo1NGhHlLbKeQiMS1GgGuYoEVjCVoKjNnEq
MPgu8ahV082x2ZsIV7hD71UjoVqEtswzJDJSnaFt5FuLz9Pmn/66tMbeS7vQhVs=
=r0Eu
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Stefan Gofferje]

On 12/04/2013 02:04 PM, Martin Braun (CEL) wrote:
> OK, that's unusual and I can't reproduce it here even by copy & pasting
> the commands and doing exactly the same. You could try 3.7.2.1 (although
> I couldn't say why 3.7.2 wouldn't work) and using other build
> directories.

I downloaded the file new and deleted everything and created the dirs
new again and then it worked - basically. Typical Suse-phenomenon - tons
of dependencies not found...
Luckily, I found a 3.7.3-git version on OSBS which runs fine so far.

-S

-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[Marcus D. Leech]

On 12/04/2013 10:49 AM, Michael Lustig wrote:

I see,interesting.

So how do you send an SOB tag within gnu radio companion?
I'm new to this and could not find any documentation on grc that made sense to 
me.

-- Miki, KK6MRI, from mobile

There's a burst-tagger block:

http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1burst__tagger.html

I can't for the life of me remember how to form the SOB/EOB tags that 
UHD needs.  But perhaps someone who has actually used the EOB/SOB stuff

  could chime in.



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


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

[Discuss-gnuradio] How to get the output from constellation receiver to match modulators symbol rate

[chris 0]

Hi,

I currently have the constellation modulator set @ 2 samples / symbol.

The constellation receiver is giving me all the bits as output (it's not
down-sampling the bits, if that's the correct word), so i'm getting
duplicate bits, anyone got any idea how get the receiver to match the
symbol rate of the modulator.

cheers

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

Re: [Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[Michael Lustig]

I see,interesting.

So how do you send an SOB tag within gnu radio companion?
I'm new to this and could not find any documentation on grc that made sense to 
me.

-- Miki, KK6MRI, from mobile 



> On Dec 4, 2013, at 6:51 AM, "Marcus D. Leech"  wrote:
> 
>> On 12/04/2013 09:46 AM, Tom Rondeau wrote:
>> 
>> One easy way is to use the mute block and have it controllable from a
>> check box GUI element.
>> 
>> Tom
> Unless the mute block causes an EOB tag to be sent downstream to the UHD 
> sink, that won't have the desired effect.
> 
> When doing half-duplex, sharing a common RF port, the USRP needs to know when 
> you've ended a "burst", so that it can
>  switch the antenna port between the RX and TX.  And again when you start 
> transmitting, it'll need a SOB tag to cause
>  the TX state machine to wake-up.
> 
> The usual mode implemented by gr-uhd is continuous streaming on TX.
> 
> 
> 
> 
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] QT GUI Sink: Waterfall much faster than standalone waterfall and time domain display crashes

[Stefan Gofferje]

On 12/04/2013 04:35 PM, Tom Rondeau wrote:
>> 1.) The waterfall display in the QT GUI sink seems to be about twice as
>> fast as the standalone QT GUI Waterfall sink. That's nothing bad but I'd
>> be curious where this come from.
> 
> You can change the rate by adjusting the Update Period in the
> waterfall's properties.

Sorry, with the same rate configured, of course :).

> When reporting errors like this, please also provide the version of
> GNU Radio you are using. Most likely, you are on 3.7.2. This sounds
> like buy #615, which is fixed in the latest 3.7.2.1 bug release.

My mistake, sorry. According to the package info it is 3.7.2-1.1 but
gnuradio-companion --version says 3.7.2. Hard to tell, what's the actual
version. I use the official Opensuse Ham radio repo.

-S


-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT Playback

[Tom Rondeau]

On Wed, Dec 4, 2013 at 6:39 AM, Paul B. Huter  wrote:
> There must be something with my record, because my 20 seconds of running
> only produces about a 180MB file. I am not seeing any indications of dropped
> data, though. I am recording to a RAMDisk, but I get the same results
> recording to my HDD.
>
> Does anyone have recommendations for how to ensure I get my data recorded? I
> really think that if I cam record the data, playback will be more what I am
> looking for.
>
> Paul B. Huter

You can also use the static plotting tools that come with GNU Radio,
which can be better for short files than trying to run them "live" in
GRC. Look into using gr_time_plot_c, gr_psd_plot_c, and
gr_spectrogram_plot_c. Use the "-h" flag to bring up the help screen
to set various parameters.

Tom



> On Dec 4, 2013 1:20 AM, "Marcus Müller"  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi Paul!
>>
>> I'm gonna go ahead and rearrange parts of your message for the ease of
>> reply:
>> > My datafile was recorded for about 20 seconds at a sample rate of
>> > 50Msps through a low-pass filter to only capture 0-30MHz.
>> 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?) should be
>> plenty enough, so my guess was totally astray.
>>
>> > Looking at the configuration for my FFT, and changing 'Refresh
>> > Rate' from the default '15' to '1M' gives me some extra playback.
>> what gui toolkit are you using? wx or qt?
>> However, a refresh rate of one million frames per second... doesn't
>> even remotely make sense. Since there is no way that your file source
>> can supply 1024Msps for the GUI sink, even without throttling, I don't
>> know what the (wx or qt or whatever) FFT sink does in that case. I'd
>> have to read the source code...
>>
>> > I like the way the waterfall looks, but I'm having the same issue
>> > as the FFT.
>>
>> Ok, this is confusing. The waterfall sink should basically be able to
>> have one pixel of display per sample going in. And with 1 billion
>> samples going in, there shouldn't really be repitions visible, unless
>> your data is repetitive.
>>
>> > Is there some correlation between data rate on the record and FFT
>> > refresh rate?
>> No. Refresh rate is just the display refresh rate, i.e. the speed at
>> which the GUI updates its visualization.
>>
>> > How is 'FFT Size' used (right now I have that at '1024')?
>> Um this is kinda awkward - it's the size of the FFT; how the samples
>> are internally processed prior to being transformed depends on the
>> actual FFT sink implementation.
>>
>> > On a related note - is there a way to get the FFT to start out in
>> > 'Autoscale', or do I need to hit the button every time?
>>
>> No. "Autoscale" is (as far as I know and can remember right now) not a
>> /mode/ for the qt nor the wx gui fft sink, but scales the display to
>> fit the data that is display /the moment the button is clicked/. So,
>> since data can only be available at run time, you can't do that before
>> running the flow graph. However, at least for the qt implementation,
>> you can set y max/y min, if you know it beforehand.
>>
>> So: Verify your data is really about 1 billion samples long and not
>> only a few thousand; if your waterfall looks periodic, your recorded
>> signal is periodic.
>>
>> Greetings,
>> Marcus
>>
>> On 03.12.2013 22:45, Paul B. Huter wrote:
>> >
>> > Is there some correlation between data rate on the record and FFT
>> > refresh rate? How is 'FFT Size' used (right now I have that at
>> > '1024')? On a related note - is there a way to get the FFT to start
>> > out in 'Autoscale', or do I need to hit the button every time?
>> >
>> > Thanks!
>> >
>> >
>> > On Tue, Dec 3, 2013 at 3:01 PM, Marcus Müller 
>> > wrote:
>> >
>> > Most probably your data is simply to short in relation to the fft
>> > length and the amount of samples your specific graphical FFT
>> > amplitude sink drops for display. Please review you fft length,
>> > update rate, and try out different fft GUIs (qt/wx).
>> >
>> > You could zeropad your data generously to notice the repitition.
>> > However, I think with what you're describing you might be better
>> > off with a waterfall graph; try them, they're fun :)
>> >
>> > Greetings, Marcus
>> >
>> > On 03.12.2013 21:45, Paul B. Huter wrote:
>>  When I play my data file back through a throttle and
>>  frequency translating FIR filter to an FFT sink with repeat
>>  OFF, it seems to just show a static plot. However, with
>>  repeat ON, I get playback, but I can't tell when data ends
>>  and starts back over. Is there a way for me to know when it
>>  repeats? Or, is there a way to get playback with repeat
>>  turned off?
>> 
>>  Thanks.
>> 
>>  Paul B. Huter
>> 
>> 
>> 
>>  ___
>>  Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
>>  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> >>
>> >> _

Re: [Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[Marcus D. Leech]

On 12/04/2013 09:46 AM, Tom Rondeau wrote:


One easy way is to use the mute block and have it controllable from a
check box GUI element.

Tom

Unless the mute block causes an EOB tag to be sent downstream to the UHD 
sink, that won't have the desired effect.


When doing half-duplex, sharing a common RF port, the USRP needs to know 
when you've ended a "burst", so that it can
  switch the antenna port between the RX and TX.  And again when you 
start transmitting, it'll need a SOB tag to cause

  the TX state machine to wake-up.

The usual mode implemented by gr-uhd is continuous streaming on TX.




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


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

Re: [Discuss-gnuradio] Python chaos

[Tom Rondeau]

On Wed, Dec 4, 2013 at 4:49 AM, Stefan Gofferje  wrote:
> Well, joy was short... I added a QT GUI range item and...
>
> Traceback (most recent call last):
>   File "/home/sgofferj/top_block.py", line 16, in 
> import PyQt4.Qwt5 as Qwt
> ImportError: No module named Qwt5
>
> libqwt5 *is* installed and there's no "qwt5" package in any repo I know
> off...


You must also have python-qwt5 (or PyQWT) installed to use these widgets.

And to respond to the above comment from the OpenSUSE mailing list you
posted, this is /not/ reinventing the wheel. We are doing something
completely different with Qwt than what PyQwt does to make all of the
blocks work in C++. We make our own QWT widgets in C++ and then export
those. But we also use PyQWT for things that are naturally supported
there.

Plus, PyQWT has stopped development and has even stated that they will
not support QWT6, which is a shame and will eventually cause us and
anyone else trying to use PyQWT real issues in the future. I've been
looking for an alternative to it.

Tom

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

Re: [Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[Tom Rondeau]

On Wed, Dec 4, 2013 at 3:37 AM, mlustig  wrote:
> Hi --
>
> I just got my USRP B200. I'm able to receive and transmit with it. It is
> very nice!
> I have one issue. In gnuradio-companion I pipe an FM modulated signal into
> UHD sink with the TX/RX output.
> I would like to have a button that turns the TX off to allow RX on the same
> port. I can not find a way to do that within gnuradio-companion. Anybody has
> an idea?
>
> My workaround right now is to turn the transmit gain down, and change the
> center frequency of the transmit away while receiving in RX2 port. This is a
> "full duplex" mode, but I would really like a half-duplex on the RX/TX.
>
> Thanks!
>
> -- Miki

One easy way is to use the mute block and have it controllable from a
check box GUI element.

Tom

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Tom Rondeau]

On Tue, Dec 3, 2013 at 3:13 PM, Monahan-Mitchell, Tim
 wrote:
>>> The volk test is failing on my gnuradio build on a Beaglebone Black
>>> (armv7h) running Arch Linux Arm.
>>>
>>> # make test
>>> start   1: qa_volk_test_all
>>> *** 2 failures detected in test suite "Master Test Suite"1/177 Test   #1:
>>> qa_volk_test_all .***Failed9.88 sec
>
>>> Full output of ctest -V _R qa_volk_test_all is attatched.
>
>> which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a 
>> part of the 3.7.2.1 release.
>> See bugs #582 and #583 on our Issues page.
>> Tom
>
> After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
> ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached in 
> the first message of this thread. So there is something still going on here. 
> Is it possible some external component needs to be updated, that is outside 
> of what's in the GR git tree?
>
> The output I originally logged in Bug #583 differs from our latest results, 
> but the behavior is the same (in1/in2 values appear to match).
>
> The output I originally logged in Bug #582 (for ARM target) remains the same 
> (in1/in2 values differ by 1).
>
> Regards,
> Tim

I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
from the latest git checkout (was testing Balister's new OE manifest
and SDK) and everything is working great here.

When you say you did a "fresh build", what does that really mean? One
of the quirks of volk is that cmake /has/ to be rerun when these kinds
of changes are made. Best really to clean up everything to make sure
you're doing everything from a clean checkout. "git reset --hard; git
pull origin master; git clean -dxf;". Then rerun cmake and make from a
clean build directory.

The above might be overkill, so if you want a quicker test, start with
the clean git pull of the latest head and just make sure to rerun
cmake and make, not necessarily from an empty directory.

Tom

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

Re: [Discuss-gnuradio] Bug in DBPSK blocks

[Tom Rondeau]

On Tue, Dec 3, 2013 at 1:52 PM, Nick Foster  wrote:
> Hi all,
>
> There's a bug in the block for the DBPSK modulator. The "differential" param
> isn't set to True in dbpsk_mod; it's just left to default, and differential
> defaults to False in the bpsk_mod block. So it really acts like a BPSK
> modulator. QPSK was the same. Here's a patch.

Thanks for the report and patch, Nick. I should get to it today, but
in the meantime, I opened ticket #624 in case it slips my timeline
today. In the future, best to put these things up on the Issues
tracker.

> diff --git a/gr-digital/python/digital/bpsk.py
> b/gr-digital/python/digital/bpsk.py
> index 57cf253..92f3254 100644
> --- a/gr-digital/python/digital/bpsk.py
> +++ b/gr-digital/python/digital/bpsk.py
> @@ -117,7 +117,7 @@ class dbpsk_mod(bpsk_mod):
>
>  def __init__(self, mod_code=None, *args, **kwargs):
>
> -super(dbpsk_mod, self).__init__(*args, **kwargs)
> +super(dbpsk_mod, self).__init__(differential=True, *args, **kwargs)
>
>  #
> /
>  #   DBPSK demodulator
> @@ -139,7 +139,7 @@ class dbpsk_demod(bpsk_demod):
>
>  def __init__(self, mod_code=None, *args, **kwargs):
>
> -super(dbpsk_demod, self).__init__(*args, **kwargs)
> +super(dbpsk_demod, self).__init__(differential=True, *args,
> **kwargs)
>
>  #
>  # Add these to the mod/demod registry
> diff --git a/gr-digital/python/digital/qpsk.py
> b/gr-digital/python/digital/qpsk.py
> index 859d981..1ed3357 100644
> --- a/gr-digital/python/digital/qpsk.py
> +++ b/gr-digital/python/digital/qpsk.py
> @@ -149,7 +149,7 @@ class dqpsk_mod(qpsk_mod):
>  __doc__ += shared_mod_args
>
>  def __init__(self, mod_code=_def_mod_code, *args, **kwargs):
> -super(dqpsk_mod, self).__init__(mod_code,
> +super(dqpsk_mod, self).__init__(mod_code, True,
>  *args, **kwargs)
>
>  #
> /
> @@ -171,7 +171,7 @@ class dqpsk_demod(qpsk_demod):
>  __doc__ += shared_demod_args
>
>  def __init__(self, mod_code=_def_mod_code, *args, **kwargs):
> -super(dqpsk_demod, self).__init__(mod_code,
> +super(dqpsk_demod, self).__init__(mod_code, True,
>*args, **kwargs)
>
>  #
>
> Incidentally, I question the need for the DBPSK mod GRC block now that we
> have the generic PSK mod GRC block. Might make sense to deprecate it.
>
> --n

I quite agree. I have a note to myself to clean this up with 3.8.

Tom

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

Re: [Discuss-gnuradio] QT GUI Sink: Waterfall much faster than standalone waterfall and time domain display crashes

[Tom Rondeau]

On Wed, Dec 4, 2013 at 6:18 AM, Stefan Gofferje  wrote:
> Hi,
>
> so I got gnuradio basically running and started to experiment. 2 things,
> I noticed:
>
> 1.) The waterfall display in the QT GUI sink seems to be about twice as
> fast as the standalone QT GUI Waterfall sink. That's nothing bad but I'd
> be curious where this come from.

You can change the rate by adjusting the Update Period in the
waterfall's properties.

> 2.) When I choose the Time Domain Display tab in the QT GUI sink, the
> window just closes. Nothing on the console, like error messages, etc...
> Just *puff* gone... Is there a know bug with that?
>
> -S

When reporting errors like this, please also provide the version of
GNU Radio you are using. Most likely, you are on 3.7.2. This sounds
like buy #615, which is fixed in the latest 3.7.2.1 bug release.

Tom

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

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Artem Pisarenko]

I realized what's the problem !!! Enlightenment has come accidentally :D

Block performing blocking calls based on time calculations can't schedule
processing correctly, if there are other blocking calls present in cycle. In
other words, two blocks disturb each other, and no matter whether they
time-synchronized or not. Also I've beent thought a little and realized that
it's not even possible to make block recovering from that (operating in
current gnu radio scheduler implementation).

So, I guess final solution is to make two versions of my source block:
time-synchronous ans time-asynchronous. Or define this property via
parameter.

Thanks all for responses !




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45168.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] gr-ieee802-11: connecting two usrp devices

[Nasi]

 Hi,

Thanks for reply!
>
>Did you play around with the gain and see if that helps?
That did not help. The problem is that in the file '' the code always checks 
for the value:

if(result.checksum() != 558161692) {
dout << "checksum wrong -- dropping" << std::endl;
return;
}
 
I am not familiar with CRC. Why does it check always for 558161692?
Another important and strange thing is that in the transmitted frames CRC is 
always different than the receiver side CRC value (I print them to see that). 
>
>Is frame detection working or are you just streaming samples into the 
>flow graph that make absolutely no sense?
I did not change anything in the flow graph: the message strobe is connected 
with -> OFDM MAC block.
How can I activate frame detection? I thought that is by default. I run ofdm_rx 
file usually. May that is the reason...
>
>> Decode MAC: input 7
>> Decode MAC: frame start -- len 153 symbols 7 encoding 6
>
>What are you sending? Is it correct until this point?
>This is a QAM64 2/3 modulated 153 byte frame. Did you send this?
Not actually. I send BPSK 1/2 always. How can it be like this?
>
>Did you try other modulation and coding schemes?
I will try. I go mad because of this does not work.


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

Re: [Discuss-gnuradio] Switching between simulated channels

[Aylons Hazzud]

Oops... found this:

https://github.com/guruofquality/grex/wiki/Blocks#wiki-stream-selector

Looks like exactly what I was looking for. Still accepting tips, though.

2013/12/4 Aylons Hazzud :
> I have been using GNURadio lately as a simulation library, kind of
> expading SciPy for static analysis while making some real-time
> analysis for parameter tweaks now and then. It's working great.
>
> However, I have a problem I would like to solve better: I have a
> switching data input, where the same data comes from two slightly
> different channels (a block diagram can be seen here:
> http://www.ohwr.org/attachments/2013/RFFE_Chain.png)
>
> I want to simulate this channel in GNURadio/Scipy so I can rapidly
> test new approaches for normalizing the inputs. My first thought would
> be to simply simulate both channels, record the data, interleave them
> using standard python/scipy tools, and use the resultant vector as a
> source.
>
> However, I believe there should be a better way to do this in
> GNURadio. Is there any (out-of-tree?) "switching block", which could
> demultiplex a signal to two different channels at a fixed rate (or
> according to the value of an input signal), and the dual "mux  block"?
>
> If there isn't, I would love if anyone could guide on how to build a
> block like this, or point to a similar block from which I could get
> inspiration to build mine. BTW, this would be my first GNURadio block
> which isn't just a hierarchical block.
>
> Thanks,
> Aylons

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

Re: [Discuss-gnuradio] QAM Modulation-Demodulation in Loopback

[Brian Padalino]

On Wed, Dec 4, 2013 at 5:46 AM, Kartik Seth  wrote:
> I had already done simulation for PSK as well as QAM in GNURadio and
> everything worked fine, even after using Channel Model block in between.
>
> When using with bladeRF in loopback the issues with 8PSK and QAM are coming.
> I can see the constellation in scope sink(if that gives any insight) but
> nothing is demodulated correctly. Moreover, once in a while data is
> demodulated(after many executions of same flowgraph).
>
> So  either there are some issues with Demod blocks or with the hardware
> (assuming flowgraph is correct).
>
> Has anyone tried this before and can confirm that this works?
> It would be helpful if someone can try this on their end and provide
> feedback.

If you put your flowgraph online somewhere that I can grab, I'd give it a shot.

Maybe push it up to github and send a link to that?

Given that you've tried it out with even the channel model between the
blocks, it's probably a configuration item or hardware misbehaving.

Brian

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

[Discuss-gnuradio] Switching between simulated channels

[Aylons Hazzud]

I have been using GNURadio lately as a simulation library, kind of
expading SciPy for static analysis while making some real-time
analysis for parameter tweaks now and then. It's working great.

However, I have a problem I would like to solve better: I have a
switching data input, where the same data comes from two slightly
different channels (a block diagram can be seen here:
http://www.ohwr.org/attachments/2013/RFFE_Chain.png)

I want to simulate this channel in GNURadio/Scipy so I can rapidly
test new approaches for normalizing the inputs. My first thought would
be to simply simulate both channels, record the data, interleave them
using standard python/scipy tools, and use the resultant vector as a
source.

However, I believe there should be a better way to do this in
GNURadio. Is there any (out-of-tree?) "switching block", which could
demultiplex a signal to two different channels at a fixed rate (or
according to the value of an input signal), and the dual "mux  block"?

If there isn't, I would love if anyone could guide on how to build a
block like this, or point to a similar block from which I could get
inspiration to build mine. BTW, this would be my first GNURadio block
which isn't just a hierarchical block.

Thanks,
Aylons

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

Re: [Discuss-gnuradio] LTE framework receiver gr-lte

[Ralph A. Schmid, dk5ras]

Well, I'm an RF guy, not a programmer, sorry :) But maybe even a dumb script 
could check the path and modify the file accordingly? Would also be an ugly 
hack, but at least almost no one would notice :)

Ralph.

> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Johannes Demel
> Sent: Wednesday, 4 December, 2013 08:28
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] LTE framework receiver gr-lte


> 
> Hi Ralph,
> 
> If you come up with a sane solution for this, let me know. This hack is a 
> result of getting stuck in CMake hell while being in a hurry.
> 
> Johannes
> 
> On 03.12.2013 20:25, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> >> the library path to libfftw3f is actually hardcoded in the makefile.
> >> search for
> >>   SET(FFTW3f /usr/lib/x86_64-linux-gnu/libfftw3f.so)
> >> in gr37-lte/lib/CMakeLists.txt
> >> and replace it with the the proper library location for your system.
> >> for example:
> >>   SET(FFTW3f /usr/lib64/libfftw3f.so)
> >
> > Ah, I see, the comment for this tells something about an ugly hack,
> > and it seems I fell for it :)
> >
> >> best regards,
> >> Martin
> >
> > Thanks!
> >
> > 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] FFT Playback

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How do you downsample 50 to 30 Msps? With a fractional resampler?
That's highly demanding of your CPU! Do it with the recorded data, not
before, if you can afford the memory.

On 04.12.2013 13:47, Paul B. Huter wrote:
> Without the low pass filter, I was getting a sequence of D's. The
> low pass filter uses a Volk machine, and downsamples the 50M to 30M
> with a 5M transition size. I am using the GUI companion on Linux,
> but I vaguely recall that I may have had better luck recording when
> I just created a Python script on a PC. I will try the script (on
> Linux) this afternoon, and I will also try running at 25M
> downsampled to 10M.
> 
> In the meantime, any additional comments/suggestions would be
> appreciated.
> 
> Thanks.
> 
> Paul B. Huter On Dec 4, 2013 6:29 AM, "Marcus Müller"
>  wrote:
> 
> With most hardware interfaces, you get notifications when your 
> driver/interface starts dropping samples -- with UHD you'd see
> loads of 'O' indicating overflows. If you don't see that, there is
> something really wrong. How does your data acquisition take place?
> 50Msps is really a lot for an average PC if you do filtering; I
> don't know how your low pass filter looks, but I think it's
> probably causing to much computational load for your computer to
> process the incoming samples in real time.
> 
> Greetings, Marcus
> 
> On 04.12.2013 12:39, Paul B. Huter wrote:
 There must be something with my record, because my 20 seconds
 of running only produces about a 180MB file. I am not seeing
 any indications of dropped data, though. I am recording to a
 RAMDisk, but I get the same results recording to my HDD.
 
 Does anyone have recommendations for how to ensure I get my
 data recorded? I really think that if I cam record the data,
 playback will be more what I am looking for.
 
 Paul B. Huter On Dec 4, 2013 1:20 AM, "Marcus Müller" 
  wrote:
 
 Hi Paul!
 
 I'm gonna go ahead and rearrange parts of your message for
 the ease of reply:
>>> My datafile was recorded for about 20 seconds at a
>>> sample rate of 50Msps through a low-pass filter to only
>>> capture 0-30MHz.
 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?)
 should be plenty enough, so my guess was totally astray.
 
>>> Looking at the configuration for my FFT, and changing 
>>> 'Refresh Rate' from the default '15' to '1M' gives me
>>> some extra playback.
 what gui toolkit are you using? wx or qt? However, a refresh
 rate of one million frames per second... doesn't even
 remotely make sense. Since there is no way that your file
 source can supply 1024Msps for the GUI sink, even without
 throttling, I don't know what the (wx or qt or whatever) FFT
 sink does in that case. I'd have to read the source code...
 
>>> I like the way the waterfall looks, but I'm having the
>>> same issue as the FFT.
 
 Ok, this is confusing. The waterfall sink should basically be
 able to have one pixel of display per sample going in. And
 with 1 billion samples going in, there shouldn't really be
 repitions visible, unless your data is repetitive.
 
>>> Is there some correlation between data rate on the
>>> record and FFT refresh rate?
 No. Refresh rate is just the display refresh rate, i.e. the
 speed at which the GUI updates its visualization.
 
>>> How is 'FFT Size' used (right now I have that at
>>> '1024')?
 Um this is kinda awkward - it's the size of the FFT; how the 
 samples are internally processed prior to being transformed
 depends on the actual FFT sink implementation.
 
>>> On a related note - is there a way to get the FFT to
>>> start out in 'Autoscale', or do I need to hit the
>>> button every time?
 
 No. "Autoscale" is (as far as I know and can remember right
 now) not a /mode/ for the qt nor the wx gui fft sink, but
 scales the display to fit the data that is display /the
 moment the button is clicked/. So, since data can only be
 available at run time, you can't do that before running the
 flow graph. However, at least for the qt implementation, you
 can set y max/y min, if you know it beforehand.
 
 So: Verify your data is really about 1 billion samples long
 and not only a few thousand; if your waterfall looks
 periodic, your recorded signal is periodic.
 
 Greetings, Marcus
 
 On 03.12.2013 22:45, Paul B. Huter wrote:
>>> 
>>> Is there some correlation between data rate on the
>>> record and FFT refresh rate? How is 'FFT Size' used
>>> (right now I have that at '1024')? On a related note -
>>> is there a way to get the FFT to start out in
>>> 'Autoscale', or do I need to hit the button every
>>> time?
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Tue, Dec 3, 2013 at 3:01 PM, Marcus M

Re: [Discuss-gnuradio] FFT Playback

[Paul B. Huter]

Without the low pass filter, I was getting a sequence of D's. The low pass
filter uses a Volk machine, and downsamples the 50M to 30M with a 5M
transition size. I am using the GUI companion on Linux, but I vaguely
recall that I may have had better luck recording when I just created a
Python script on a PC. I will try the script (on Linux) this afternoon, and
I will also try running at 25M downsampled to 10M.

In the meantime, any additional comments/suggestions would be appreciated.

Thanks.

Paul B. Huter
On Dec 4, 2013 6:29 AM, "Marcus Müller"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> With most hardware interfaces, you get notifications when your
> driver/interface starts dropping samples -- with UHD you'd see loads
> of 'O' indicating overflows.
> If you don't see that, there is something really wrong. How does your
> data acquisition take place? 50Msps is really a lot for an average PC
> if you do filtering; I don't know how your low pass filter looks, but
> I think it's probably causing to much computational load for your
> computer to process the incoming samples in real time.
>
> Greetings,
> Marcus
>
> On 04.12.2013 12:39, Paul B. Huter wrote:
> > There must be something with my record, because my 20 seconds of
> > running only produces about a 180MB file. I am not seeing any
> > indications of dropped data, though. I am recording to a RAMDisk,
> > but I get the same results recording to my HDD.
> >
> > Does anyone have recommendations for how to ensure I get my data
> > recorded? I really think that if I cam record the data, playback
> > will be more what I am looking for.
> >
> > Paul B. Huter On Dec 4, 2013 1:20 AM, "Marcus Müller"
> >  wrote:
> >
> > Hi Paul!
> >
> > I'm gonna go ahead and rearrange parts of your message for the ease
> > of reply:
>  My datafile was recorded for about 20 seconds at a sample
>  rate of 50Msps through a low-pass filter to only capture
>  0-30MHz.
> > 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?) should
> > be plenty enough, so my guess was totally astray.
> >
>  Looking at the configuration for my FFT, and changing
>  'Refresh Rate' from the default '15' to '1M' gives me some
>  extra playback.
> > what gui toolkit are you using? wx or qt? However, a refresh rate
> > of one million frames per second... doesn't even remotely make
> > sense. Since there is no way that your file source can supply
> > 1024Msps for the GUI sink, even without throttling, I don't know
> > what the (wx or qt or whatever) FFT sink does in that case. I'd
> > have to read the source code...
> >
>  I like the way the waterfall looks, but I'm having the same
>  issue as the FFT.
> >
> > Ok, this is confusing. The waterfall sink should basically be able
> > to have one pixel of display per sample going in. And with 1
> > billion samples going in, there shouldn't really be repitions
> > visible, unless your data is repetitive.
> >
>  Is there some correlation between data rate on the record and
>  FFT refresh rate?
> > No. Refresh rate is just the display refresh rate, i.e. the speed
> > at which the GUI updates its visualization.
> >
>  How is 'FFT Size' used (right now I have that at '1024')?
> > Um this is kinda awkward - it's the size of the FFT; how the
> > samples are internally processed prior to being transformed depends
> > on the actual FFT sink implementation.
> >
>  On a related note - is there a way to get the FFT to start
>  out in 'Autoscale', or do I need to hit the button every
>  time?
> >
> > No. "Autoscale" is (as far as I know and can remember right now)
> > not a /mode/ for the qt nor the wx gui fft sink, but scales the
> > display to fit the data that is display /the moment the button is
> > clicked/. So, since data can only be available at run time, you
> > can't do that before running the flow graph. However, at least for
> > the qt implementation, you can set y max/y min, if you know it
> > beforehand.
> >
> > So: Verify your data is really about 1 billion samples long and
> > not only a few thousand; if your waterfall looks periodic, your
> > recorded signal is periodic.
> >
> > Greetings, Marcus
> >
> > On 03.12.2013 22:45, Paul B. Huter wrote:
> 
>  Is there some correlation between data rate on the record and
>  FFT refresh rate? How is 'FFT Size' used (right now I have
>  that at '1024')? On a related note - is there a way to get
>  the FFT to start out in 'Autoscale', or do I need to hit the
>  button every time?
> 
>  Thanks!
> 
> 
>  On Tue, Dec 3, 2013 at 3:01 PM, Marcus Müller
>   wrote:
> 
>  Most probably your data is simply to short in relation to the
>  fft length and the amount of samples your specific graphical
>  FFT amplitude sink drops for display. Please review you fft
>  length, update rate, and try out different fft GUIs (qt/wx).
> 
>  You could zeropad your data generously to notice 

Re: [Discuss-gnuradio] QT GUI Sink: Waterfall much faster than standalone waterfall and time domain display crashes

[Stefan Gofferje]

On 12/04/2013 02:06 PM, Martin Braun (CEL) wrote:
>> 2.) When I choose the Time Domain Display tab in the QT GUI sink, the
>> window just closes. Nothing on the console, like error messages, etc...
>> Just *puff* gone... Is there a know bug with that?
> 
> Have you tried calling the .py-file generated by GRC on the command
> line? I've had some problems with segfaults caused by QT not being
> displayed inside GNU Radio.

Now I have. Also exits but this time I get an error message, saying
"Floating point exception".

-S

-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

if it's just a single source->sink system, then your buffers are too
large or your computer is way slow.


On 04.12.2013 12:41, Artem Pisarenko wrote:
> 
>> Yes. GNU Radio is a buffered streaming architecture, so as long
>> as the production / consumption rates are equal on average, it
>> should work. If they vary over time or really differ, then you'll
>> end up with over/underruns
> 
> This is exactly the problem. Rates are equal, but there are
> over/underruns, even in simple "audio source -> audio sink" graph.
> 
> 
>> Remember: there is no real realtime in general purpose signal 
>> processing with GR.
> 
> Does it mean that I will not able to run in realtime simple graph
> with 48kHz signal source, Qt GUI Sink and audio sink on modern
> computer ?
> 
> 
>> ah ok. But: stop() stops the flowgraph.
> 
> No. Read my first post.
> 
> 
>> Greetings, and happy hacking!
> 
> Thanks. :) While hacking seems to be interesting, I prefer
> professional, official supported and documented approaches.
> 
> 
> 
> 
> -- View this message in context:
> http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45153.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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnyDAAAoJEAFxB7BbsDrLM88H+weT0I3j7fC3lGRzagh2MobO
kWSD2Bs1ds4l8LeoeNQN1E3iP2Rqsyj7sx2trLjAuMFjM3F9mJaKkHG32Jlp4WXw
HftPTjgjSKj2YhipFpK4xx6N80lgbOo9vp0/VcmorkxVtgX281dJ9YpmWpzoysKX
jmoV8/iA0gl65KCmKmBHzWNoNnzt5qbzJtklOmRKYZ/yBf04+0lyJIlw8APoFPlm
vp94EwLBMR3CcPbwGnaX0taSYayoBjGvPPoew2I9vTAgxeAflBADGVBQmCoWc1IU
HIMfU9f2tU+UkA0xIZJVMkHXD3X6nNkwSLnrikFqYrSSpPReafMWflxR0iQmzwQ=
=+ozc
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] FFT Playback

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With most hardware interfaces, you get notifications when your
driver/interface starts dropping samples -- with UHD you'd see loads
of 'O' indicating overflows.
If you don't see that, there is something really wrong. How does your
data acquisition take place? 50Msps is really a lot for an average PC
if you do filtering; I don't know how your low pass filter looks, but
I think it's probably causing to much computational load for your
computer to process the incoming samples in real time.

Greetings,
Marcus

On 04.12.2013 12:39, Paul B. Huter wrote:
> There must be something with my record, because my 20 seconds of
> running only produces about a 180MB file. I am not seeing any
> indications of dropped data, though. I am recording to a RAMDisk,
> but I get the same results recording to my HDD.
> 
> Does anyone have recommendations for how to ensure I get my data
> recorded? I really think that if I cam record the data, playback
> will be more what I am looking for.
> 
> Paul B. Huter On Dec 4, 2013 1:20 AM, "Marcus Müller"
>  wrote:
> 
> Hi Paul!
> 
> I'm gonna go ahead and rearrange parts of your message for the ease
> of reply:
 My datafile was recorded for about 20 seconds at a sample
 rate of 50Msps through a low-pass filter to only capture
 0-30MHz.
> 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?) should
> be plenty enough, so my guess was totally astray.
> 
 Looking at the configuration for my FFT, and changing
 'Refresh Rate' from the default '15' to '1M' gives me some
 extra playback.
> what gui toolkit are you using? wx or qt? However, a refresh rate
> of one million frames per second... doesn't even remotely make
> sense. Since there is no way that your file source can supply
> 1024Msps for the GUI sink, even without throttling, I don't know
> what the (wx or qt or whatever) FFT sink does in that case. I'd 
> have to read the source code...
> 
 I like the way the waterfall looks, but I'm having the same
 issue as the FFT.
> 
> Ok, this is confusing. The waterfall sink should basically be able
> to have one pixel of display per sample going in. And with 1
> billion samples going in, there shouldn't really be repitions
> visible, unless your data is repetitive.
> 
 Is there some correlation between data rate on the record and
 FFT refresh rate?
> No. Refresh rate is just the display refresh rate, i.e. the speed
> at which the GUI updates its visualization.
> 
 How is 'FFT Size' used (right now I have that at '1024')?
> Um this is kinda awkward - it's the size of the FFT; how the
> samples are internally processed prior to being transformed depends
> on the actual FFT sink implementation.
> 
 On a related note - is there a way to get the FFT to start
 out in 'Autoscale', or do I need to hit the button every
 time?
> 
> No. "Autoscale" is (as far as I know and can remember right now)
> not a /mode/ for the qt nor the wx gui fft sink, but scales the
> display to fit the data that is display /the moment the button is
> clicked/. So, since data can only be available at run time, you
> can't do that before running the flow graph. However, at least for
> the qt implementation, you can set y max/y min, if you know it
> beforehand.
> 
> So: Verify your data is really about 1 billion samples long and
> not only a few thousand; if your waterfall looks periodic, your
> recorded signal is periodic.
> 
> Greetings, Marcus
> 
> On 03.12.2013 22:45, Paul B. Huter wrote:
 
 Is there some correlation between data rate on the record and
 FFT refresh rate? How is 'FFT Size' used (right now I have
 that at '1024')? On a related note - is there a way to get
 the FFT to start out in 'Autoscale', or do I need to hit the
 button every time?
 
 Thanks!
 
 
 On Tue, Dec 3, 2013 at 3:01 PM, Marcus Müller
  wrote:
 
 Most probably your data is simply to short in relation to the
 fft length and the amount of samples your specific graphical
 FFT amplitude sink drops for display. Please review you fft
 length, update rate, and try out different fft GUIs (qt/wx).
 
 You could zeropad your data generously to notice the
 repitition. However, I think with what you're describing you
 might be better off with a waterfall graph; try them, they're
 fun :)
 
 Greetings, Marcus
 
 On 03.12.2013 21:45, Paul B. Huter wrote:
>>> When I play my data file back through a throttle and 
>>> frequency translating FIR filter to an FFT sink with
>>> repeat OFF, it seems to just show a static plot.
>>> However, with repeat ON, I get playback, but I can't
>>> tell when data ends and starts back over. Is there a
>>> way for me to know when it repeats? Or, is there a way
>>> to get playback with repeat turned off?
>>> 
>>> Thanks.
>>> 
>>> Paul B. Huter
>>> 
>>> 
>>> 
>>> __

Re: [Discuss-gnuradio] E110 problem executing simple code

[maiconkist]

Hi,

I executed am opkg update; opkg upgrade. Now all is working (a LOT of
packages were update). 

I had updated all two days ago, probably some problem happened and I did not
notice.

Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/E110-problem-executing-simple-code-tp45110p45157.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] Prevented in-tree build. This is bad practice. ???

[Martin Braun (CEL)]

On Wed, Dec 04, 2013 at 12:23:24PM +0200, Stefan Gofferje wrote:
> On 12/04/2013 12:03 PM, Martin Braun (CEL) wrote:
> > Also remember, this thread isn't only for your benefit, but for others
> > with similar problems who might read this now or find it in the archives
> > later.
> 
> Point taken. However, I was not in-tree in that case unless I understand
> the expression "in-tree" wrong. It does mean "inside the directory where
> all the source files are", doesn't it?

Yes, although the error message is triggered when it finds specific
files inside the tree, even if you actually call cmake from outside the
tree. So if you do an in-tree build first, then realize your error, and
try the out-of-tree build afterwards, you still see the same error.

> > Now, the most common cause for your problem is leftover cmake files.
> > As I said, clean out the source dir before continuing.
> 
> > I'm assuming you're able to ignore my suggestion in that case and clean
> > the directory using other methods.
> 
> rm -rf gnuradio-3.7.2
> rm -rf gr-build
> tar xzf gnuradio-3.7.2.tar.gz
> md gr-build
> cd gr-build
> cmake ../gnuradio-3.7.2
> 
> => same result

OK, that's unusual and I can't reproduce it here even by copy & pasting
the commands and doing exactly the same. You could try 3.7.2.1 (although
I couldn't say why 3.7.2 wouldn't work) and using other build
directories.

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


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

Re: [Discuss-gnuradio] QT GUI Sink: Waterfall much faster than standalone waterfall and time domain display crashes

[Martin Braun (CEL)]

On Wed, Dec 04, 2013 at 01:18:56PM +0200, Stefan Gofferje wrote:
> so I got gnuradio basically running and started to experiment. 2 things,
> I noticed:
> 
> 1.) The waterfall display in the QT GUI sink seems to be about twice as
> fast as the standalone QT GUI Waterfall sink. That's nothing bad but I'd
> be curious where this come from.
> 
> 2.) When I choose the Time Domain Display tab in the QT GUI sink, the
> window just closes. Nothing on the console, like error messages, etc...
> Just *puff* gone... Is there a know bug with that?

Have you tried calling the .py-file generated by GRC on the command
line? I've had some problems with segfaults caused by QT not being
displayed inside GNU Radio.

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


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

Re: [Discuss-gnuradio] two RX paths

[Nemanja Savic]

So everything worked fine except I got the following warning:

UHD Warning:
Mixing real and quadrature rx subdevices is not supported.
The Q input to the real source(s) will be non-zero.

Which is probably due to my wish to use WBX with IQ and only one channel
from LFTX. Is there any way to overcome this problem, and is there any
explanation why this happens, cause when I use only LFTX, and particularly
one channel (let say I), the Q is automatically produced within FPGA and I
finally get complex baseband. Havung this in mind, why would UHD complain
about real and wuadrature subdevices.

Cheers,
Nemanja


On Wed, Dec 4, 2013 at 12:20 PM, Nemanja Savic  wrote:

> Everything is OK, I have just put "B:A A:0" in the subdevice field.
>
>
> On Wed, Dec 4, 2013 at 10:47 AM, Nemanja Savic  wrote:
>
>> I did following: I made simple flow graph and used USRP source first with
>> two channels and LFTX mboard. But the follwong error occurs:
>>
>>   File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 105, in
>> __init__
>> self.uhd_usrp_source_0_0_1.set_center_freq(43390, 1)
>>   File
>> "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
>> 1872, in set_center_freq
>> return _uhd_swig.uhd_usrp_source_sptr_set_center_freq(self, *args)
>> RuntimeError: vector::_M_range_check
>>
>>
>> When I tried with setting two mboards, with LFTX A channel subdevice in
>> the first channel (B:A option_ and WBX on the second channel I get
>> following error:
>>
>>   File "./top_block.py", line 101, in __init__
>> self.uhd_usrp_source_0_0_1.set_subdev_spec("A:0", 1)
>>   File
>> "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
>> 1831, in set_subdev_spec
>> return _uhd_swig.uhd_usrp_source_sptr_set_subdev_spec(self, *args,
>> **kwargs)
>> RuntimeError: vector::_M_range_check
>>
>> And as far as I have seen GRC doesn't put anything in the field
>> device_addr for changing FPGA image.
>>
>>
>> On Tue, Dec 3, 2013 at 6:03 PM, Marcus D. Leech wrote:
>>
>>> On 12/03/2013 12:00 PM, Nemanja Savic wrote:
>>>
 Thank you Marcus again,

 I changed device address, in both places, but the same problem appears.
 I see that it loads now 4rx image, but the problem remains.

 self.uhd_usrp_source_1 = uhd.usrp_source(
 device_addr="fpga=usrp1_fpga_4rx.rbf",
 stream_args=uhd.stream_args(
 cpu_format="fc32",
 channels=range(1),
 ),
 )


  You should probably start with a GRC flow-graph with a single UHD USRP
>>> source, with two channels being what you want, and look at the generated
>>>   Python code.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Artem Pisarenko]

> Yes. GNU Radio is a buffered streaming architecture, so as long as the 
> production / consumption rates are equal on average, it should work. 
> If they vary over time or really differ, then you'll end up with 
> over/underruns 

 This is exactly the problem. Rates are equal, but there are over/underruns,
even in simple "audio source -> audio sink" graph.


> Remember: there is no real realtime in general purpose signal 
> processing with GR.

 Does it mean that I will not able to run in realtime simple graph with
48kHz signal source, Qt GUI Sink and audio sink on modern computer ?


> ah ok. But: stop() stops the flowgraph.

 No. Read my first post.


> Greetings, and happy hacking!

 Thanks. :) While hacking seems to be interesting, I prefer professional,
official supported and documented approaches.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45153.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] FFT Playback

[Paul B. Huter]

There must be something with my record, because my 20 seconds of running
only produces about a 180MB file. I am not seeing any indications of
dropped data, though. I am recording to a RAMDisk, but I get the same
results recording to my HDD.

Does anyone have recommendations for how to ensure I get my data recorded?
I really think that if I cam record the data, playback will be more what I
am looking for.

Paul B. Huter
On Dec 4, 2013 1:20 AM, "Marcus Müller"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Paul!
>
> I'm gonna go ahead and rearrange parts of your message for the ease of
> reply:
> > My datafile was recorded for about 20 seconds at a sample rate of
> > 50Msps through a low-pass filter to only capture 0-30MHz.
> 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?) should be
> plenty enough, so my guess was totally astray.
>
> > Looking at the configuration for my FFT, and changing 'Refresh
> > Rate' from the default '15' to '1M' gives me some extra playback.
> what gui toolkit are you using? wx or qt?
> However, a refresh rate of one million frames per second... doesn't
> even remotely make sense. Since there is no way that your file source
> can supply 1024Msps for the GUI sink, even without throttling, I don't
> know what the (wx or qt or whatever) FFT sink does in that case. I'd
> have to read the source code...
>
> > I like the way the waterfall looks, but I'm having the same issue
> > as the FFT.
>
> Ok, this is confusing. The waterfall sink should basically be able to
> have one pixel of display per sample going in. And with 1 billion
> samples going in, there shouldn't really be repitions visible, unless
> your data is repetitive.
>
> > Is there some correlation between data rate on the record and FFT
> > refresh rate?
> No. Refresh rate is just the display refresh rate, i.e. the speed at
> which the GUI updates its visualization.
>
> > How is 'FFT Size' used (right now I have that at '1024')?
> Um this is kinda awkward - it's the size of the FFT; how the samples
> are internally processed prior to being transformed depends on the
> actual FFT sink implementation.
>
> > On a related note - is there a way to get the FFT to start out in
> > 'Autoscale', or do I need to hit the button every time?
>
> No. "Autoscale" is (as far as I know and can remember right now) not a
> /mode/ for the qt nor the wx gui fft sink, but scales the display to
> fit the data that is display /the moment the button is clicked/. So,
> since data can only be available at run time, you can't do that before
> running the flow graph. However, at least for the qt implementation,
> you can set y max/y min, if you know it beforehand.
>
> So: Verify your data is really about 1 billion samples long and not
> only a few thousand; if your waterfall looks periodic, your recorded
> signal is periodic.
>
> Greetings,
> Marcus
>
> On 03.12.2013 22:45, Paul B. Huter wrote:
> >
> > Is there some correlation between data rate on the record and FFT
> > refresh rate? How is 'FFT Size' used (right now I have that at
> > '1024')? On a related note - is there a way to get the FFT to start
> > out in 'Autoscale', or do I need to hit the button every time?
> >
> > Thanks!
> >
> >
> > On Tue, Dec 3, 2013 at 3:01 PM, Marcus Müller 
> > wrote:
> >
> > Most probably your data is simply to short in relation to the fft
> > length and the amount of samples your specific graphical FFT
> > amplitude sink drops for display. Please review you fft length,
> > update rate, and try out different fft GUIs (qt/wx).
> >
> > You could zeropad your data generously to notice the repitition.
> > However, I think with what you're describing you might be better
> > off with a waterfall graph; try them, they're fun :)
> >
> > Greetings, Marcus
> >
> > On 03.12.2013 21:45, Paul B. Huter wrote:
>  When I play my data file back through a throttle and
>  frequency translating FIR filter to an FFT sink with repeat
>  OFF, it seems to just show a static plot. However, with
>  repeat ON, I get playback, but I can't tell when data ends
>  and starts back over. Is there a way for me to know when it
>  repeats? Or, is there a way to get playback with repeat
>  turned off?
> 
>  Thanks.
> 
>  Paul B. Huter
> 
> 
> 
>  ___
>  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
> >>
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSntfEAAoJEAFxB7BbsDrL+3YIAKiTgWXVabYuQas6MeKTm7U0
> QSMRLevun7u5tx8o9Th7321BJcrm1WQ+lFCeaFrx3ug58q9gXmCU76KBB3IbYpoc
> FdNwBq7ZtzHaQIVaPYBnC3GB4UdIxDpzFuvkFcUP0V

Re: [Discuss-gnuradio] two RX paths

[Nemanja Savic]

Everything is OK, I have just put "B:A A:0" in the subdevice field.


On Wed, Dec 4, 2013 at 10:47 AM, Nemanja Savic  wrote:

> I did following: I made simple flow graph and used USRP source first with
> two channels and LFTX mboard. But the follwong error occurs:
>
>   File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 105, in
> __init__
> self.uhd_usrp_source_0_0_1.set_center_freq(43390, 1)
>   File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
> 1872, in set_center_freq
> return _uhd_swig.uhd_usrp_source_sptr_set_center_freq(self, *args)
> RuntimeError: vector::_M_range_check
>
>
> When I tried with setting two mboards, with LFTX A channel subdevice in
> the first channel (B:A option_ and WBX on the second channel I get
> following error:
>
>   File "./top_block.py", line 101, in __init__
> self.uhd_usrp_source_0_0_1.set_subdev_spec("A:0", 1)
>   File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
> 1831, in set_subdev_spec
> return _uhd_swig.uhd_usrp_source_sptr_set_subdev_spec(self, *args,
> **kwargs)
> RuntimeError: vector::_M_range_check
>
> And as far as I have seen GRC doesn't put anything in the field
> device_addr for changing FPGA image.
>
>
> On Tue, Dec 3, 2013 at 6:03 PM, Marcus D. Leech  wrote:
>
>> On 12/03/2013 12:00 PM, Nemanja Savic wrote:
>>
>>> Thank you Marcus again,
>>>
>>> I changed device address, in both places, but the same problem appears.
>>> I see that it loads now 4rx image, but the problem remains.
>>>
>>> self.uhd_usrp_source_1 = uhd.usrp_source(
>>> device_addr="fpga=usrp1_fpga_4rx.rbf",
>>> stream_args=uhd.stream_args(
>>> cpu_format="fc32",
>>> channels=range(1),
>>> ),
>>> )
>>>
>>>
>>>  You should probably start with a GRC flow-graph with a single UHD USRP
>> source, with two channels being what you want, and look at the generated
>>   Python code.
>>
>>
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] QT GUI Sink: Waterfall much faster than standalone waterfall and time domain display crashes

[Stefan Gofferje]

Hi,

so I got gnuradio basically running and started to experiment. 2 things,
I noticed:

1.) The waterfall display in the QT GUI sink seems to be about twice as
fast as the standalone QT GUI Waterfall sink. That's nothing bad but I'd
be curious where this come from.

2.) When I choose the Time Domain Display tab in the QT GUI sink, the
window just closes. Nothing on the console, like error messages, etc...
Just *puff* gone... Is there a know bug with that?

-S

-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again!

On 04.12.2013 11:36, Artem Pisarenko wrote:
> 
>> In GNU Radio terminology, since we're more of a library than an 
>> application, users are people who use GNU Radio to develop their
>> own applications. Developers are people who actively work on GNU
>> Radio and improve it.
>> 
> I meant user/developer from toolkit use point of view: user -
> developer who uses GNU Radio API in its applications and have no
> time/budget to delve into innards of huge ready-to-use code only to
> know few key concepts, developer - developer of GNU Radio toolkit.
Well, unfortunately, this is open source :) some things are easier to
do while others take a lot of time. Explaining how something works
internally for someone who is actually interested in that but doesn't
have the time to read the source itself is among the things that are
hard to do well, become obsolete fast, take a lot of time -- so nobody
does it.
>> You still have two clocks in one flow graph. Underruns can still
>> happen.
> 
> Why ??? These clocks are actualy same clock. They are synchronous.
No. Well, yes. But no.
Again, there is no continous stream in GNU Radio. Samples and
especially blocks of samples, as used in GR, are not like water: They
flow in chunks, there are buffers to accumulate them.
Usually, these buffers should be automatically sized so that two
sources with the same, constant sample production rate never run out
of buffer. I don't know what's going wrong in your case, but that
could happen if the sample delay for one of the sources differs from
the others -- all (let's call them s0 and s1) start with sample 0, but
at the point in time as s0's sample 0 "propagates" to the block where
the two sample flows are mixed together, due to delay there is no
sample from s1; so the scheduler has to wait until there is enough
input on both input ports of the mixing block. Depending on buffer
size and production rate, this might lead to overruns on s0, or
underruns on a potential hardware sink behind that block.

> Moreover, I'm sure throttle block and audio hardware clock are
> synchronous, because throttle block timing and audio driver
> scheduling both derive from same hardware generator, doesn't they
> ?
Moreover, I'm sure you still didn't understand what throttle does:
exactly nothing useful.
It's an artificial software hack to slow down the average sample
processing rate by blocking in work(). YOU NEVER EVER EVER DO IT in a
flowgraph with hardware. It can only lead to overflows, underflows.

>> Note that not consuming CPU is not necessarily due to blocking.
>> An audio sink is quite a simple matter, from a signal processing
>> point of view: Incoming samples are passed on to the sound
>> driver, then the work function can immediately return (there's
>> lots of status checking in there too).
> 
> That's why I already asked what other methods exists besides
> blocking. If it doesn't stimulate OS to switch context (by means of
> blocking calls), then it consume all available CPU time (it doesn't
> matter what kind of activity: signal processing, checking status,
> polling hardware flags, or whatever). So, it still seems to be that
> audio sink uses blocking.
The audio sink has to communicate with audio hardware. However your
system does that, the audio driver interface can only consume a
defined amount of samples per second and only has a limited buffer size.
Therefore, the call that writes samples into the device usually is a
blocking one. You see-- this is hardware with a fixed sampling rate,
so blocking is an effect, not a method.


Greetings,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnwmGAAoJEAFxB7BbsDrLrRUH/0uFi17FJjvQWx22wwpiHgQz
g+UHppH12GOZddfCnGvHXbm3JBOILYDJ2cScdgLFFNshWZFV1r2z2ko6knvi5FBl
MHtjRBTFheyMuONNEetPDNRQZL6KuKrB7EAUuflmJ+D/roZjR6N9aC81mI0qsOVL
mSZzmJbXM35mY0OvRDGx82MxpNzM94z7aLRqhiwXKRvMy8VwEwPBLrLgTYXy1MJe
A7K++4S8LNROoFAFHY+QQ85EJ2oVb3b1O/r/j4f80YTJ+l9LYDwVqu2yy72XVgpH
9lHvgcTFR59ISUcQRPZDUkVtffPhF6ON+Nz/Dm4jWj22ZbttaHH8U24wTtPJZvk=
=FBY0
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] QAM Modulation-Demodulation in Loopback

[Kartik Seth]

I had already done simulation for PSK as well as QAM in GNURadio and
everything worked fine, even after using Channel Model block in between.

When using with bladeRF in loopback the issues with 8PSK and QAM are
coming. I can see the constellation in scope sink(if that gives any
insight) but nothing is demodulated correctly. Moreover, once in a while
data is demodulated(after many executions of same flowgraph).

So  either there are some issues with Demod blocks or with the hardware
(assuming flowgraph is correct).

Has anyone tried this before and can confirm that this works?
It would be helpful if someone can try this on their end and provide
feedback.

Please correct me if I am wrong or anybody has some better explanation.

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

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Artem Pisarenko]

>> No, it's just ambiguous terminology. How should we call blocks producing 
>> output synchronously with some reference source ? 
> We call them 'source block'.

OK.


>> If I'm not user, but also I'm not developer, who am I then ? ;) 
>> I reviewed this "developers-internal" document already and that's why I 
>> intentionally mentioned user point of view. 
> 
> In GNU Radio terminology, since we're more of a library than an 
> application, users are people who use GNU Radio to develop their own 
> applications. Developers are people who actively work on GNU Radio and 
> improve it. 
> 
> It's the same with other libraries. Do you use Boost or are you 
> developing Boost? Obviously, I don't know what you do outside this list, 
> but chances are you use it. Still, the only thing you'll be using it for 
> is developing.

I meant user/developer from toolkit use point of view: user - developer who
uses GNU Radio API in its applications and have no time/budget to delve into
innards of huge ready-to-use code only to know few key concepts, developer -
developer of GNU Radio toolkit.


> You still have two clocks in one flow graph. Underruns can still happen.

Why ??? These clocks are actualy same clock. They are synchronous. Moreover,
I'm sure throttle block and audio hardware clock are synchronous, because
throttle block timing and audio driver scheduling both derive from same
hardware generator, doesn't they ?


> Note that not consuming CPU is not necessarily due to blocking. An audio 
> sink is quite a simple matter, from a signal processing point of view: 
> Incoming samples are passed on to the sound driver, then the work 
> function can immediately return (there's lots of status checking in 
> there too). 

That's why I already asked what other methods exists besides blocking. If it
doesn't stimulate OS to switch context (by means of blocking calls), then it
consume all available CPU time (it doesn't matter what kind of activity:
signal processing, checking status, polling hardware flags, or whatever).
So, it still seems to be that audio sink uses blocking.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45147.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] Prevented in-tree build. This is bad practice. ???

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm totally unable to reproduce that behaviour; my wisdom ends here.


On 04.12.2013 11:23, Stefan Gofferje wrote:
> On 12/04/2013 12:03 PM, Martin Braun (CEL) wrote:
>> Also remember, this thread isn't only for your benefit, but for
>> others with similar problems who might read this now or find it
>> in the archives later.
> 
> Point taken. However, I was not in-tree in that case unless I
> understand the expression "in-tree" wrong. It does mean "inside the
> directory where all the source files are", doesn't it?
> 
>> Now, the most common cause for your problem is leftover cmake
>> files. As I said, clean out the source dir before continuing.
> 
>> I'm assuming you're able to ignore my suggestion in that case and
>> clean the directory using other methods.
> 
> rm -rf gnuradio-3.7.2 rm -rf gr-build tar xzf
> gnuradio-3.7.2.tar.gz md gr-build cd gr-build cmake
> ../gnuradio-3.7.2
> 
> => same result
> 
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnwSjAAoJEAFxB7BbsDrL0FEH/367GlzjOUKxYI3QBjkANWSs
9F8YZD8l16U1HCKrJXH56OTm3tJPiAcsL+r8Ge4mz4kBQkD+wQFNwSk130AMZo+S
X27mdudfaHMQ9ZM9p1cR4Al0HSk7HfKyT2wMnXmUtUvVou940oyCSMbZP1Zoxj7U
zhu7utUfPdEtyqxgYPfuNqPEFp1E+HsVi+2jS3mURfXNejNOktQdiCGwqVW7EMYT
jwIru2bVx2zngplXCaV9CJMbgEa8olt0Z93MaTAbO9wgkIcpuUY1D5oava08DoRT
dtn0FL6pAkmoqNql9RbRMaCXtucJtSOKxjCoomx+SX9dNYISX1rhEU/tndSnk7g=
=GuVz
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Issue with the GNU radio installation

[Sandhya G]

Hi Marcus,

  I tried installing using pybombs but i'm failing to install uhd
itself .Here is the error i get when I run make

http://pastebin.com/eNr6CQ2f.

I manually installed pybombs and uhd from git.


Thanks and regards
Sandhya


On Wed, Dec 4, 2013 at 1:07 PM, Sandhya G  wrote:

> Hi Marcus,
>   Thanks for the reply
>  Well I installed manually from git. Ok never tried with pybombs.
> Even when I tried installing previous version I faced the same errors
> along with the volk also failed.
>
>
> Thanks
> Sandhya
>
>
> On Wed, Dec 4, 2013 at 12:57 PM, Marcus Müller  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Looks like parts of Boost are missing (boost::filesystem).
>> How did you try to install GNU Radio? PyBOMBS? manually from git?
>> build gnuradio script?
>> Did building previous versions work out?
>> PyBOMBS is the "official" way to do it and usually installs all the
>> dependencies correctly.
>>
>> Greetings,
>> Marcus
>>
>>
>> PS:Make test is irrelevant as long make fails unless you're debugging
>> something special.
>> PS2: What you're trying to do is install GNU Radio (commonly
>> abbreviated GR); GRC is short for the GNU Radio companion, which is
>> shipped with GNU Radio, but not the main software; just a "small" tool
>> to enable you to do stuff graphically.
>>
>> On 04.12.2013 06:59, Sandhya G wrote:
>> > Hi, I started installing GRC 3.7.2 but make and make test are
>> > failing with several error .
>> >
>> > i'm using using ubuntu 12.04 (32 bit) amd processor(64 bit)
>> >
>> > I even disabled the orc.
>> >
>> > Boost 1.48 is installed
>> >
>> > I'am attaching the snap shots of the errors.
>> >
>> > Could some tell me what is the cause of the errors and how can i
>> > correct them.
>> >
>> > Thanks in advance Sandhya
>> >
>> >
>> >
>> > ___ Discuss-gnuradio
>> > mailing list Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.15 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJSntlgAAoJEAFxB7BbsDrLs1gH/0QKEJMecqfnpuWG0La5bCO5
>> c7FJ4bdIM37v2DVdziCN4AZMHGNqjJT1kleTb84TwFltiWhyFaY2ENKErY2Ns8d6
>> BMj0C/WoI84PVjXr00yebmVLcD5CqozuPkIe8I6B5wA/lxmFQB4rEovXIW5ILVrr
>> 1UIddHjeuC4j15O8oVh3ECbgFAV+9OAhIJzmUJ/ryEJPUb4Gp6aRELUAqM5ue98n
>> YgPZmCnz05+5tEEKQG9DHnIOlRVVYFjminqrE6YnCVEFj7dhoikpXk9wlOjmya1/
>> 4fAAcOsVzwtLR0YOnaQRbCQ9RE/pC2P/b0I6WL2CiAcA1kJ0zifT9RPOgMbfflo=
>> =I9tX
>> -END PGP SIGNATURE-
>>
>> ___
>> 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] Prevented in-tree build. This is bad practice. ???

[Stefan Gofferje]

On 12/04/2013 12:03 PM, Martin Braun (CEL) wrote:
> Also remember, this thread isn't only for your benefit, but for others
> with similar problems who might read this now or find it in the archives
> later.

Point taken. However, I was not in-tree in that case unless I understand
the expression "in-tree" wrong. It does mean "inside the directory where
all the source files are", doesn't it?

> Now, the most common cause for your problem is leftover cmake files.
> As I said, clean out the source dir before continuing.

> I'm assuming you're able to ignore my suggestion in that case and clean
> the directory using other methods.

rm -rf gnuradio-3.7.2
rm -rf gr-build
tar xzf gnuradio-3.7.2.tar.gz
md gr-build
cd gr-build
cmake ../gnuradio-3.7.2

=> same result


-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Martin Braun (CEL)]

On Wed, Dec 04, 2013 at 11:12:01AM +0200, Stefan Gofferje wrote:
> On 12/04/2013 10:53 AM, Martin Braun (CEL) wrote:
> > On Wed, Dec 04, 2013 at 10:37:58AM +0200, Stefan Gofferje wrote:
> >> what is THAT??? Occurred with the 3.7.2 download package...
> >>
> >> enterprise:/usr/src/gr-build # cmake ../gnuradio-3.7.2
> >> CMake Error at CMakeLists.txt:22 (message):
> >>   Prevented in-tree build.  This is bad practice.
> > 
> > It looks like you tried an in-tree build, which cmake prevented you from
> > doing, because it's bad practice :)
> > 
> > You'll need to clean the repo (if nothing's changed, git clean -xdf will
> > do) and then rebuild *outside* your tree. Follow the build instructions,
> > and make sure you call cmake in a separate build folder.
> 
> Did you actually read what I posted?
> I was calling "cmake ../gnuradio-3.7.2" while being in the directory
> "/usr/src/gr-build".

Yes, Stefan, I read what you posted. Did you read what I just posted?
About making sure you're helping people help you solve your problems?
Also remember, this thread isn't only for your benefit, but for others
with similar problems who might read this now or find it in the archives
later.

Now, the most common cause for your problem is leftover cmake files.
As I said, clean out the source dir before continuing.

> And I didn't use git but the download package from the gnuradio website.

I'm assuming you're able to ignore my suggestion in that case and clean
the directory using other methods.

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


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

Re: [Discuss-gnuradio] Python chaos

[Stefan Gofferje]

Well, joy was short... I added a QT GUI range item and...

Traceback (most recent call last):
  File "/home/sgofferj/top_block.py", line 16, in 
import PyQt4.Qwt5 as Qwt
ImportError: No module named Qwt5

libqwt5 *is* installed and there's no "qwt5" package in any repo I know
off...

-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] two RX paths

[Nemanja Savic]

I did following: I made simple flow graph and used USRP source first with
two channels and LFTX mboard. But the follwong error occurs:

  File "/home/savi_ne/work/gnuradio/GRC/top_block.py", line 105, in __init__
self.uhd_usrp_source_0_0_1.set_center_freq(43390, 1)
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py",
line 1872, in set_center_freq
return _uhd_swig.uhd_usrp_source_sptr_set_center_freq(self, *args)
RuntimeError: vector::_M_range_check


When I tried with setting two mboards, with LFTX A channel subdevice in the
first channel (B:A option_ and WBX on the second channel I get following
error:

  File "./top_block.py", line 101, in __init__
self.uhd_usrp_source_0_0_1.set_subdev_spec("A:0", 1)
  File "/usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py",
line 1831, in set_subdev_spec
return _uhd_swig.uhd_usrp_source_sptr_set_subdev_spec(self, *args,
**kwargs)
RuntimeError: vector::_M_range_check

And as far as I have seen GRC doesn't put anything in the field device_addr
for changing FPGA image.


On Tue, Dec 3, 2013 at 6:03 PM, Marcus D. Leech  wrote:

> On 12/03/2013 12:00 PM, Nemanja Savic wrote:
>
>> Thank you Marcus again,
>>
>> I changed device address, in both places, but the same problem appears. I
>> see that it loads now 4rx image, but the problem remains.
>>
>> self.uhd_usrp_source_1 = uhd.usrp_source(
>> device_addr="fpga=usrp1_fpga_4rx.rbf",
>> stream_args=uhd.stream_args(
>> cpu_format="fc32",
>> channels=range(1),
>> ),
>> )
>>
>>
>>  You should probably start with a GRC flow-graph with a single UHD USRP
> source, with two channels being what you want, and look at the generated
>   Python code.
>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>


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

Re: [Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Stefan Gofferje]

On 12/04/2013 10:53 AM, Martin Braun (CEL) wrote:
> On Wed, Dec 04, 2013 at 10:37:58AM +0200, Stefan Gofferje wrote:
>> what is THAT??? Occurred with the 3.7.2 download package...
>>
>> enterprise:/usr/src/gr-build # cmake ../gnuradio-3.7.2
>> CMake Error at CMakeLists.txt:22 (message):
>>   Prevented in-tree build.  This is bad practice.
> 
> It looks like you tried an in-tree build, which cmake prevented you from
> doing, because it's bad practice :)
> 
> You'll need to clean the repo (if nothing's changed, git clean -xdf will
> do) and then rebuild *outside* your tree. Follow the build instructions,
> and make sure you call cmake in a separate build folder.

Did you actually read what I posted?
I was calling "cmake ../gnuradio-3.7.2" while being in the directory
"/usr/src/gr-build".

And I didn't use git but the download package from the gnuradio website.

-S


-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Artem,

On 04.12.2013 08:50, Artem Pisarenko wrote:
> 
> Martin Braun (CEL) wrote
>> You never use a throttle and a hardware clock in one flow graph
>> (e.g. throttle + audio)
> 
> Does it means that I can use multiple synchronous blocks of same
> type ?
Yes. GNU Radio is a buffered streaming architecture, so as long as the
production / consumption rates are equal on average, it should work.
If they vary over time or really differ, then you'll end up with
over/underruns

> Martin Braun (CEL) wrote
>> work() should never block. Sources are a bit of an exception,
>> though...
> 
> I see audio sink doesn't consume CPU, so it blocks too ? Another
> exception ?..
The GNU Radio Block idea (tm) is to have the scheduler call your work
as soon as there are samples available for processing and the blocks
downstream can take your block's output. Therefore, work()s should be
as fast as possible.

Obviously, sources don't have input, so the correct way to produce
limited samples over time is to take your time when producing samples.
So, for software sources (e.g. sine wave signal source), they just
produce as many samples as fast as they can, as the scheduler requests.

As for the audio source, the rate at which samples can be produced is
defined by hardware. So to produce e.g. 441 samples you need 10ms;
there's no way around that. So it *must* block for as long as it takes
to produce a reasonable / requested amount of samples for the output
buffer.

Throttle just throttles :) so you end up with backpressure that must
eventually lead to congestion which manifests in dropped samples,
stalled flowgraphs.
> 
> 
> Martin Braun (CEL) wrote
>> - I'm pretty sure you've misunderstood the concept of a "sync
>> block". Refer to [1] for an introduction. It merely describes the
>> ratio of input and output rates. The opposite of a sync block is
>> *not* an 'async' block.
> 
> No, it's just ambiguous terminology. How should we call blocks
> producing output synchronously with some reference source ?
I'd like to disagree. GR talks about "sync" blocks, and since it's a
pure software framework, it's obvious that the synchronous aspect is
in respect to sample flow, not to time.
Remember: there is no real realtime in general purpose signal
processing with GR.

you could say, your block is time-synchronous, but seriously, since
you always fill a buffer, this is not really true; I'd call it "rate
limited by hardware".

> Martin Braun (CEL) wrote
>> - The scheduler does all the work for you regarding calling of
>> work(). You don't need to interrupt work(). Not sure what you're
>> intentions were with using stop().
> 
> My intention was to use non-timeout blocking calls (as supposed to
> be correct) in work() with wait condition on some "stop" signal.
ah ok. But: stop() stops the flowgraph.

Greetings, and happy hacking!

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnu2kAAoJEAFxB7BbsDrLCvAH/ju+5l2oGU8KfB3zO+Neb8Od
nLmcb8CC0elmIF25OaB6xvWayZZp7MkQk7ulfvbIZlkE0sG6/Fdra/bPqzL519Nu
3wj6gyLA2Lrg0YpInO+zP3PIT25QPjORLvOSO4APFKFfdZMTCNbltdV5SNWiue/4
0e6Kjo7+6VZDYPkeZn2NzpKf/AcUzpnHFaM4Viz/UIjBGfDBpFCTCGFiMyC9QRgd
QxCRIm0a20Wk2O0PlyJ+e7OE1JCiFsjUjQp9QhoMcyfIxESI5sNvBamSB14+tNri
eitR2s+ExzgDRNrf7datCue2rEZ6ISQounsujjqVbVw5gPluQ+n17rXliddmGTc=
=wfRp
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Martin Braun (CEL)]

On Wed, Dec 04, 2013 at 10:37:58AM +0200, Stefan Gofferje wrote:
> what is THAT??? Occurred with the 3.7.2 download package...
> 
> enterprise:/usr/src/gr-build # cmake ../gnuradio-3.7.2
> CMake Error at CMakeLists.txt:22 (message):
>   Prevented in-tree build.  This is bad practice.

It looks like you tried an in-tree build, which cmake prevented you from
doing, because it's bad practice :)

You'll need to clean the repo (if nothing's changed, git clean -xdf will
do) and then rebuild *outside* your tree. Follow the build instructions,
and make sure you call cmake in a separate build folder.

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


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

Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Martin Braun (CEL)]

On Tue, Dec 03, 2013 at 11:50:44PM -0800, Artem Pisarenko wrote:
> Martin Braun (CEL) wrote
> > There's an overview of the scheduler:
> > http://gnuradio.squarespace.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html
> > "Users", as you say, usually don't need more than this to write GNU
> > Radio code, and most often don't need to know anything at all about it.
> 
> If I'm not user, but also I'm not developer, who am I then ? ;)
> I reviewed this "developers-internal" document already and that's why I
> intentionally mentioned user point of view.

In GNU Radio terminology, since we're more of a library than an
application, users are people who use GNU Radio to develop their own
applications. Developers are people who actively work on GNU Radio and
improve it.

It's the same with other libraries. Do you use Boost or are you
developing Boost? Obviously, I don't know what you do outside this list,
but chances are you use it. Still, the only thing you'll be using it for
is developing.

> Martin Braun (CEL) wrote
> > You never use a throttle and a hardware clock in one flow graph (e.g.
> > throttle + audio)
> 
> Does it means that I can use multiple synchronous blocks of same type ? I've
> checked "audio source -> audio sink" and I get same underruns.

You still have two clocks in one flow graph. Underruns can still happen.
You may use as many gr::sync_blocks in one flow graph as you wish. They
have nothing to do with clocks.

> Martin Braun (CEL) wrote
> > work() should never block. Sources are a bit of an exception, though...
> 
> I see audio sink doesn't consume CPU, so it blocks too ? Another exception
> ?..

It *can* block, depending on the backend, but doesn't have to.
Note that not consuming CPU is not necessarily due to blocking. An audio
sink is quite a simple matter, from a signal processing point of view:
Incoming samples are passed on to the sound driver, then the work
function can immediately return (there's lots of status checking in
there too).

> Martin Braun (CEL) wrote
> > - I'm pretty sure you've misunderstood the concept of a "sync block".
> >   Refer to [1] for an introduction. It merely describes the ratio of
> >   input and output rates. The opposite of a sync block is *not* an
> >   'async' block.
> 
> No, it's just ambiguous terminology. How should we call blocks producing
> output synchronously with some reference source ?

We call them 'source block'. The fact that some hardware clock is
somewhere in that block is irrelevant, all GNU Radio blocks are driven
by the states of their buffers.

MB


> Martin Braun (CEL) wrote
> > - The scheduler does all the work for you regarding calling of work().
> >   You don't need to interrupt work(). Not sure what you're intentions
> >   were with using stop().
> 
> My intention was to use non-timeout blocking calls (as supposed to be
> correct) in work() with wait condition on some "stop" signal.
> 
> 
> Martin Braun (CEL) wrote
> > Writing blocks is one of the things we try and document as good as
> > possible. The corresponding tutorial [1] has received a lot of feedback
> > and has been continuously updated. It also discusses most of the
> > questions you had earlier.
> 
> Due to lack of documentation, this tutorial was the only source and I
> learned it from cover to cover. I mentioned only non-trivial issues which is
> not discussed in it. So it's new feedback ;)

-- 
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


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

Re: [Discuss-gnuradio] Python chaos

[Stefan Gofferje]

On 12/04/2013 10:33 AM, Johannes Demel wrote:
> it might be trivial, but did you adjust the Generate Options? It should
> be set to "QT GUI" instead of the default "WX GUI".

You are my hero! :D
Of course, I forgot that after hours of going through the installed
packages on my system and trying to figure out which ones might conflict
with GR :).

Thanks a lot.

-S


-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Prevented in-tree build. This is bad practice. ???

[Stefan Gofferje]

Hi,

what is THAT??? Occurred with the 3.7.2 download package...

enterprise:/usr/src/gr-build # cmake ../gnuradio-3.7.2
CMake Error at CMakeLists.txt:22 (message):
  Prevented in-tree build.  This is bad practice.


-- Configuring incomplete, errors occurred!



-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to turn-off TX of UHD sink in gnuradio companion?

[mlustig]

Hi --

I just got my USRP B200. I'm able to receive and transmit with it. It is
very nice!
I have one issue. In gnuradio-companion I pipe an FM modulated signal into
UHD sink with the TX/RX output. 
I would like to have a button that turns the TX off to allow RX on the same
port. I can not find a way to do that within gnuradio-companion. Anybody has
an idea? 

My workaround right now is to turn the transmit gain down, and change the
center frequency of the transmit away while receiving in RX2 port. This is a
"full duplex" mode, but I would really like a half-duplex on the RX/TX. 

Thanks!

-- Miki




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-to-turn-off-TX-of-UHD-sink-in-gnuradio-companion-tp45134.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] Python chaos

[Johannes Demel]

Hi Gofferje,

it might be trivial, but did you adjust the Generate Options? It should
be set to "QT GUI" instead of the default "WX GUI".

Johannes

On 04.12.2013 00:18, Stefan Gofferje wrote:
> After some tinkering I am at this error message...:
> Traceback (most recent call last):
>   File "/home/sgofferj/top_block.py", line 75, in 
> tb = top_block()
>   File "/home/sgofferj/top_block.py", line 46, in __init__
> self.top_layout.addWidget(self._qtgui_freq_sink_x_0_win)
>   File "/usr/lib64/python2.7/site-packages/gnuradio/gr/top_block.py",
> line 100, in __getattr__
> return getattr(self._tb, name)
> AttributeError: 'top_block_sptr' object has no attribute 'top_layout'
> 
> 
> 

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

Re: [Discuss-gnuradio] LTE framework receiver gr-lte

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Johannes,
for me, this was quite trivial: Just use the original GNU Radio
cmake/Modules/FindFFTW3f.cmake, and include it in your toplevel and
lib/CMakeLists.txt
For reference, see my gist for example CMakeListses; watch out,
however, this is modified to use the double precision fftw methods;
replace FFTW by FFTWf unless you need double precision. Use the
original FindFFTWf.cmake if you want single precision float!

https://gist.github.com/marcusmueller/7783656

Greetings from the frosty banks of Bavaria,
Marcus


On 04.12.2013 08:27, Johannes Demel wrote:
> Hi Ralph,
> 
> If you come up with a sane solution for this, let me know. This
> hack is a result of getting stuck in CMake hell while being in a
> hurry.
> 
> Johannes
> 
> On 03.12.2013 20:25, Ralph A. Schmid, dk5ras wrote:
>> Hi,
>> 
>>> the library path to libfftw3f is actually hardcoded in the
>>> makefile. search for SET(FFTW3f
>>> /usr/lib/x86_64-linux-gnu/libfftw3f.so) in
>>> gr37-lte/lib/CMakeLists.txt and replace it with the the proper
>>> library location for your system. for example: SET(FFTW3f
>>> /usr/lib64/libfftw3f.so)
>> 
>> Ah, I see, the comment for this tells something about an ugly
>> hack, and it seems I fell for it :)
>> 
>>> best regards, Martin
>> 
>> Thanks!
>> 
>> 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnuZgAAoJEAFxB7BbsDrLxogH/RnW2f6k782dWyNbkYi3arpt
rHX6yUAjUceidmFPFtkTALxw/TY9xYRJBQKPkAog3V1uixoMRCtCA8Ps6F3VhSmN
/+t9e9F5e9k1rFrg4zNg2b+sK6msGxGxfPpKJclfCu2Vb3ARdBvfSstxPgt1jdtz
senFNV+PldH3FxoHmYIjMz57M3y3A5JmH4mCZlBKvEENM4u54B84XkIuX9Ihbh5c
n+nUyI/fUqFTjOKO/hYsiQDzIY6eegiTNsLHpzx/iOE86F3R/njFn6r1CU627DA/
jjYO10FSdqa5hXQPLVbUGFC4cGMllHljqKTSUgfpTeLrYZLjcSg9W3+nku/HDVI=
=arbd
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Python chaos

[Stefan Gofferje]

After some tinkering I am at this error message...:
Traceback (most recent call last):
  File "/home/sgofferj/top_block.py", line 75, in 
tb = top_block()
  File "/home/sgofferj/top_block.py", line 46, in __init__
self.top_layout.addWidget(self._qtgui_freq_sink_x_0_win)
  File "/usr/lib64/python2.7/site-packages/gnuradio/gr/top_block.py",
line 100, in __getattr__
return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'top_layout'



-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler & Koch - the original point and click interface




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio