[Discuss-gnuradio] How to call another blocks in custom out-of-tree module

[y...@solid.co.kr]

Hi,

Can you help me to call gnu-blocks from my own out-of-tree code written in 
python?

For example, from this code 
(http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules)
1 import numpy
2 from gnuradio import gr
3
 4 class square3_ff(gr.sync_block):
5 " Squaring block "
 6 def __init__(self):
7 gr.sync_block.__init__(
8 self,
9 name = "square3_ff",
10 in_sig = [numpy.float32], # Input signature: 1 float at a time
11 out_sig = [numpy.float32], # Output signature: 1 float at a time
12 )
   Self.my_block = (another block / or hier-block)
13
14 def work(self, input_items, output_items):
15 #output_items[0][:] = input_items[0] * input_items[0] # Only works 
because numpy.array
# I want to call self.my_block here
16 return len(output_items[0])



I want to call another gnu-blocks (or another hier-block) in work 
function.(Line 14~16)

1) How to connect input item to another block’s input

2) How to connect local array to another block’s output

Please help me.
Actually I need to make my own sub block.
But I need gnuradio blocks during processing my own block.

Bye.

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

Re: [Discuss-gnuradio] How to call another blocks in custom out-of-tree module

[Martin Braun (CEL)]

On Tue, Nov 05, 2013 at 12:56:24PM +, y...@solid.co.kr wrote:
> I want to call another gnu-blocks (or another hier-block) in work function.
> (Line 14~16)
> 
> 1) How to connect input item to another block’s input
> 
> 2) How to connect local array to another block’s output

In GNU Radio's 'block' terminology, you will *never* call another block
from within one block's work function. You always connect the output of
one block the input of the next.

What exactly are you trying to do? Are you simply trying to outsource
some signal processing code out of your block?
We do this quite a lot, but then the object we call from the work
function is not a GNU Radio block, but rather a generic object. Of
course, you can include any Python module or object into your own Python
blocks.

Or are you trying to call another, existing GNU Radio block? In this
case, you might want to think about splitting your block up such that
you can connect your block and existing blocks through the regular
mechanism (i.e. top_block.connect()).

> Please help me.
> 
> Actually I need to make my own sub block.
> 
> But I need gnuradio blocks during processing my own block.

Perhaps a hier block will solve your problem?

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


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

[Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

Or, rather, with Apple's new libc++ runtime.  I'm working on the MacPorts 
ticket: <  https://trac.macports.org/ticket/41162 >.

The high level advice right now is: If you update to 10.9, you won't be using 
GNU Radio for a while.

It looks like there is will be 2 issues encountered when compiling GNU Radio on 
OSX 10.9 using libc++ and clang:

1) As with the ticket, there will be errors caused by something to do with 
boost.  This is typical, and we're seeing it in a bunch of other ports too 
(incuding UHD, which I have patched temporarily within MacPorts to work around 
the issue).  I'm not sure what the solution is, but it does not happen to 
everyone so it's likely the way boost is installed.

2) Even if you did get past the first boost issue, you'd get to the SWIG one, 
which isn't easily fixable -- we can't patch SWIG-generated code, since it is 
created during runtime.  The issue is that SWIG works with C++04 compliant c++ 
runtime, but not with C++11 compliant runtime, and libc++ is the latter, and 
the 2 are not totally backwards compatible.  SWIG has a ticket open at < 
http://sourceforge.net/p/swig/bugs/1331/ > with this issue since August 27, 
2013; it has LOTS of tickets open right now with various issue, and, while I'm 
sure the SWIG programmers are making progress, progress does not seem to be 
very fast.

With the above in mind, I recommend that you do NOT update to 10.9 if you're 
going to be using GNU Radio; not at this time.  I think the "best" temporary 
solution right now to get GNU Radio working with 10.9
is to uninstall -everything- from MacPorts and rebuild from go using libstdc++ 
(the default in 10.9 is to use Apple's new libc++; libstdc++ is provided by 
libgcc).  I'm not sure how to do that yet; I'll experiment & post back once 
I've figured it out. - MLD



--

Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: supp...@ettus.com

Web: http://www.ettus.com


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

Re: [Discuss-gnuradio] BPSK receiver issue

[Tom Rondeau]

On Mon, Nov 4, 2013 at 10:25 AM, Vanush Vaswani  wrote:
> Hi all,
>
> I am using GR 3.6.5.1 to receive BPSK modulated data from a third
> party RF chip / microcontroller combination and am having a strange
> experience. I am implementing a very simple protocol by constantly
> transmitting 0x7E constantly and then ASCII data triggered by a serial
> connection to the microcontroller, all at 9.6kbps
>
> With the  following configuration
> FCDPP source sampling at 192KHz.
> -> AGC
>  -> Freq Xlate (bring near baseband)
>  -> Costas loop (remove carrier)
> -> RRC (48 taps, symbol rate = 9600)
> -> PSK Demod (sps = 20 as 192/20 = 9.6kbps, everything else default)
>
> I can see my 0x7E bitstream "square wave" in a scope sink.
> When I pack the bits and send it to a file sink, I can see my 0x7E's
> and also ascii data that I've typed in to the microcontroller serial
> port. However - this is rare. Most of the time, I see the bytes of
> rotated flag - 0x3F, 0xFC, 0x3F etc. I thought this was ok, I can
> simply rotate the whole file by x bits to remake all the flags as
> 0x7E. But when I do this, my ascii text input is completely garbled,
> with only a few letters showing up.
>
> Can anyone give me a hint as to what is going on? I don't think my
> transmitter is the issue, as when I get my flag bytes in the output
> file, I can see my data.
>
> vanush

The PSK demod has the FLL, Costas loop, and RRC filter in it. That's
what each of those bandwidth settings are for (frequency, phase, and
timing). But also, going in at 20 sps is really high. You should put a
channel filter in front that both removes any extra noise and
downsamples (by a factor of 5 or 10 to get to 4 or 2 sps).

Tom

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

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

[ikjtel]

Greetings

I was very interested in this project for possible application to the op25 
project, since P25 uses several FEC codes
including RS and other block codes.  I've brought up the gr-ldpc library and 
have a few questions.  Due to the hateful YAhoo mail composer, I'm hesitant to 
post lengthy emails to the general list with no opportunity for preview prior 
to hitting SEND, so I'll try breaking up the list of questions into several 
posts, one per question...

First question: I was getting lots of errors, seg faults, aborts, and other 
misbehavior from the code, which were traced to an apparent bug in alist.cc, 
all of which cleared up when I applied the following patch:

--- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061 -0400
+++ ./alist.cc  2013-11-05 11:21:03.879972116 -0500
@@ -123,7 +123,7 @@
 }
 
 // Parse indices with non zero entries in ith row
-    for (int row = 0; row < N; row++) {
+    for (int row = 0; row < M; row++) {
 std::getline(file, line);
 ss << line;
 for (int entry = 0; entry < num_mlist[row]; entry++) {

Can you confirm, is this really a bug?

Thanks and Best

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

[Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Ralph A. Schmid, dk5ras]

Hi,

gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions, built 
directly from the repo.

modes_rx works just fine, the messages come through.

modes_gui throws this error, when switching insinde the gui to osmosdr:

ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr 
[INFO] Instance: 0
[bladeRF source] Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57 
FW v1.5.3 FPGA v0.0.0
gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr 
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr 
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.



The bladerf is flashed with latest fx3 image and latest fpga file into the SPI 
flash.

All the involved packages itself work just fine.

Any ideas what there may be wrong?


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/




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

Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Nick Foster]

Does osmocom_fft work?

--n


On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras wrote:

> Hi,
>
> gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions,
> built directly from the repo.
>
> modes_rx works just fine, the messages come through.
>
> modes_gui throws this error, when switching insinde the gui to osmosdr:
>
> ras@ubuntu:~$ modes_gui
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab
>
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
> [bladeRF source] Using nuand LLC bladeRF #0 SN
> 8efd2b30699e61bec690a0b37cc5ad57 FW v1.5.3 FPGA v0.0.0
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
>
> FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to a gnuradio bug. The maintainers have been informed.
>
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
>
> FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to a gnuradio bug. The maintainers have been informed.
>
>
>
> The bladerf is flashed with latest fx3 image and latest fpga file into the
> SPI flash.
>
> All the involved packages itself work just fine.
>
> Any ideas what there may be wrong?
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 Fürth
> +49-171-3631223
> ra...@schmid.xxx
> http://www.bclog.de/
>
>
>
>
> ___
> 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] The GSoC project on LDPC codes.

[Manu T S]

Dear Max,

You are correct. It is a bug. Now I'm wondering why I didn't get any
segmentation faults.

Probably I didn't get any segmentation faults because, after i = M - 1, EOF
has reached.

Thanks for the correction.


On Tue, Nov 5, 2013 at 9:14 PM, ikjtel  wrote:

> Greetings
>
> I was very interested in this project for possible application to the op25
> project, since P25 uses several FEC codes
> including RS and other block codes.  I've brought up the gr-ldpc library
> and have a few questions.  Due to the hateful YAhoo mail composer, I'm
> hesitant to post lengthy emails to the general list with no opportunity for
> preview prior to hitting SEND, so I'll try breaking up the list of
> questions into several posts, one per question...
>
> First question: I was getting lots of errors, seg faults, aborts, and
> other misbehavior from the code, which were traced to an apparent bug in
> alist.cc, all of which cleared up when I applied the following patch:
>
> --- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061 -0400
> +++ ./alist.cc  2013-11-05 11:21:03.879972116 -0500
> @@ -123,7 +123,7 @@
>  }
>
>  // Parse indices with non zero entries in ith row
> -for (int row = 0; row < N; row++) {
> +for (int row = 0; row < M; row++) {
>  std::getline(file, line);
>  ss << line;
>  for (int entry = 0; entry < num_mlist[row]; entry++) {
>
> Can you confirm, is this really a bug?
>
> Thanks and Best
>
> Max
>



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

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

[Miklos Maroti]

Dear Manu,

Do you have any performance numbers on your LDPC decoder? I could not
find any info, even in your presentation. Do you have also a BER
figure, or even better would be some technical report. I would love to
get some sense on the performance of your implementation.

Best,
Miklos

On Tue, Nov 5, 2013 at 6:15 PM, Manu T S  wrote:
> Dear Max,
>
> You are correct. It is a bug. Now I'm wondering why I didn't get any
> segmentation faults.
>
> Probably I didn't get any segmentation faults because, after i = M - 1, EOF
> has reached.
>
> Thanks for the correction.
>
>
> On Tue, Nov 5, 2013 at 9:14 PM, ikjtel  wrote:
>>
>> Greetings
>>
>> I was very interested in this project for possible application to the op25
>> project, since P25 uses several FEC codes
>> including RS and other block codes.  I've brought up the gr-ldpc library
>> and have a few questions.  Due to the hateful YAhoo mail composer, I'm
>> hesitant to post lengthy emails to the general list with no opportunity for
>> preview prior to hitting SEND, so I'll try breaking up the list of questions
>> into several posts, one per question...
>>
>> First question: I was getting lots of errors, seg faults, aborts, and
>> other misbehavior from the code, which were traced to an apparent bug in
>> alist.cc, all of which cleared up when I applied the following patch:
>>
>> --- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061
>> -0400
>> +++ ./alist.cc  2013-11-05 11:21:03.879972116 -0500
>> @@ -123,7 +123,7 @@
>>  }
>>
>>  // Parse indices with non zero entries in ith row
>> -for (int row = 0; row < N; row++) {
>> +for (int row = 0; row < M; row++) {
>>  std::getline(file, line);
>>  ss << line;
>>  for (int entry = 0; entry < num_mlist[row]; entry++) {
>>
>> Can you confirm, is this really a bug?
>>
>> Thanks and Best
>>
>> Max
>
>
>
>
> --
> Manu T S
>
> ___
> 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] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Ralph A. Schmid, dk5ras]

Yes, works just fine, also other “toolchains” like gqrx – gr-osmosdr – bladerf 
do not show any strange effects, so osmosdr seems to be OK.

 

Ralph

 

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 18:10
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and 
bladerf...

 

Does osmocom_fft work?

 

--n

 

On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras  
wrote:

Hi,

gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions, built 
directly from the repo.

modes_rx works just fine, the messages come through.

modes_gui throws this error, when switching insinde the gui to osmosdr:

ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0
[bladeRF source] Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57 
FW v1.5.3 FPGA v0.0.0
gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.



The bladerf is flashed with latest fx3 image and latest fpga file into the SPI 
flash.

All the involved packages itself work just fine.

Any ideas what there may be wrong?


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/




___
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] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Nick Foster]

I've only tested osmocom in gr-air-modes with the HackRF. The relevant code
is in python/radio.py lines 177-189. modes_gui does reinstantiate the
source block a couple of times (to populate the options boxes) -- it's
possible that this isn't allowing gr-osmocom enough time to close/open the
USB device, or maybe gr-osmocom doesn't like reopening the device from
within the same process?

--n


On Tue, Nov 5, 2013 at 10:04 AM, Ralph A. Schmid, dk5ras
wrote:

> Yes, works just fine, also other “toolchains” like gqrx – gr-osmosdr –
> bladerf do not show any strange effects, so osmosdr seems to be OK.
>
>
>
> Ralph
>
>
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Tuesday, 5 November, 2013 18:10
> *To:* Ralph A. Schmid, dk5ras
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr
> and bladerf...
>
>
>
> Does osmocom_fft work?
>
>
>
> --n
>
>
>
> On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras 
> wrote:
>
> Hi,
>
> gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions,
> built directly from the repo.
>
> modes_rx works just fine, the messages come through.
>
> modes_gui throws this error, when switching insinde the gui to osmosdr:
>
> ras@ubuntu:~$ modes_gui
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab
>
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
> [bladeRF source] Using nuand LLC bladeRF #0 SN
> 8efd2b30699e61bec690a0b37cc5ad57 FW v1.5.3 FPGA v0.0.0
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
>
> FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to a gnuradio bug. The maintainers have been informed.
>
> gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
> [INFO] Instance: 0
>
> FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to a gnuradio bug. The maintainers have been informed.
>
>
>
> The bladerf is flashed with latest fx3 image and latest fpga file into the
> SPI flash.
>
> All the involved packages itself work just fine.
>
> Any ideas what there may be wrong?
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 Fürth
> +49-171-3631223
> ra...@schmid.xxx
> http://www.bclog.de/
>
>
>
>
> ___
> 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] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Ralph A. Schmid, dk5ras]

I’m afraid I am not a programmer, so I do not know if I can find something 
there, but I will have l look later or tomorrow J

 

Ralph.

 

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 19:14
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and 
bladerf...

 

I've only tested osmocom in gr-air-modes with the HackRF. The relevant code is 
in python/radio.py lines 177-189. modes_gui does reinstantiate the source block 
a couple of times (to populate the options boxes) -- it's possible that this 
isn't allowing gr-osmocom enough time to close/open the USB device, or maybe 
gr-osmocom doesn't like reopening the device from within the same process?

 

--n

 

On Tue, Nov 5, 2013 at 10:04 AM, Ralph A. Schmid, dk5ras  
wrote:

Yes, works just fine, also other “toolchains” like gqrx – gr-osmosdr – bladerf 
do not show any strange effects, so osmosdr seems to be OK.

 

Ralph

 

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 18:10
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and 
bladerf...

 

Does osmocom_fft work?

 

--n

 

On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras  
wrote:

Hi,

gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions, built 
directly from the repo.

modes_rx works just fine, the messages come through.

modes_gui throws this error, when switching insinde the gui to osmosdr:

ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0
[bladeRF source] Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57 
FW v1.5.3 FPGA v0.0.0
gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.



The bladerf is flashed with latest fx3 image and latest fpga file into the SPI 
flash.

All the involved packages itself work just fine.

Any ideas what there may be wrong?


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223  
ra...@schmid.xxx
http://www.bclog.de/




___
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] DC Nonexistent Peak at Transmitter

[Ben Hilburn]

Sema -

Also, please be sure you run the calibrations provided by UHD. The TX DC
Offset calibration addresses exactly what you are talking about.

http://files.ettus.com/uhd_docs/manual/html/calibration.html

Cheers,
Ben


On Fri, Nov 1, 2013 at 9:04 AM, Mike Jameson  wrote:

> Hi Sema,
>
> You are most likely seeing the local oscillator at the centre due to the
> WBX being a direct conversion daughterboard:
>
> http://en.wikipedia.org/wiki/Direct-conversion_receiver
>
> To remove this, you can put the following in the center frequency box of
> the UHD source/sink block in GRC:
>
> uhd.tune_request(uhd_center_freq,
> rf_freq=(uhd_center_freq+uhd_lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)
>
> The 'uhd_center_freq'  and 'uhd_lo_offset' need to be specified. Set
> 'uhd_lo_offset' to be something like ((samp_rate/2)*1.1).
>
> Regards,
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: http://www.ettus.com 
>
>
> On Fri, Nov 1, 2013 at 3:21 PM, s k  wrote:
>
>> Hi all,
>>
>> I am trying to create a complex cosine signal in 100kHz and transmit it
>> with USRP in 110MHz using WBX daughterboard. I have observed this signal in
>> an oscilloscope and a spectrum analyzer. It can be seen that there is a
>> nonexistent peak at transmit frequency of USRP. I also added the related
>> photos to be clear.
>>
>> Any help would be kindly appreciated.
>>
>> Sema
>>
>> ___
>> 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] Resolution of USRP N210 and N200

[Ben Hilburn]

Ting -

This question really isn't GNURadio related. If you resend it over the
USRP-Users list, though, we will help explain things quickly!

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Cheers,
Ben


On Sat, Nov 2, 2013 at 12:22 AM, Ting Wu <
wu.t...@comf5.comm.eng.osaka-u.ac.jp> wrote:

> Hi,
>
>
>
> Both of USRP N210 and N200 have 14 bit ADC, which means a range of
> +/-2e13=+/-8129.
>
> However, as I tested a N210 with LFRX, I got values from -32704 ~ 30073,
> close to +/-2e15=32768.
>
> Last year, I also tested a N200 with LFRX, I got values from -16357 ~
> 16241, close to +/-2e14=16384.
>
> The sampling rate was set to 4 MHz.
>
>
>
> So why does the ADC has a real resolution higher than 14 bit, and are N210
> and N200 the same?
>
> I’m really new to the world of ADC, so some basics would be very helpful.
>
>
>
> Thanks!
>
>
>
> Wu
>
> ___
> 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] DEBUG Logger not logging from within block

[Tommy Tracy]

*False alarm. This is not a problem.
I had accidentally installed to a different directory than I was importing
from.

Tom


On Sun, Nov 3, 2013 at 11:23 PM, Tommy Tracy  wrote:

> Dear GNU Radio,
>
> If I have a:
>  GR_LOG_DEBUG(d_debug_logger, );
>
> in my c++ application, the program will write my string to std out in the
> following format:
>DEBUG: 
> when executed, or if I step through with GDB.
> --
> If, however, I have the following line in a GR Block private constructor:
>GR_LOG_DEBUG(d_debug_logger, );
>
> Nothing is printed to std out when running or using GDB. Is GNU Radio
> catching these log outputs, or is there another method for me to get
> information from within a block constructor/work() method?
>
> --
> Sincerely,
> Tommy Tracy II
> UVA
>



-- 
Sincerely,
Tommy Tracy II
UVA
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

On Nov 5, 2013, at 8:41 AM, Michael Dickens  wrote:
> I'm not sure how to do that yet; I'll experiment & post back once I've 
> figured it out.

I'm pretty sure we can use the legacy libstdc++ provided by Apple, but it 
requires that "port" be either from the SVN trunk (as of a few days ago) or 
that you wait for the next release (probably 2.3), which I'm not sure when that 
will be.

Once you have "port" from the SVN trunk installed, you then do:
{{{
sudo port -f uninstall installed
sudo port clean all
sudo port install gnuradio +gcc48 +atlas configure.cxx_stdlib=libstdc++
}}}
and, then go off and wait for a day.  Feel free to substitute other variants 
you want everything to have, or some other +gcc4X instead of what I put there.  
I do recommend +atlas, since Apple's Accelerate framework, at least up through 
10.8, has bugs in it here and Apple is both slow to fix and push out fixes; 
atlas has regular updates and bug fixes, and generally works much better than 
Accelerate.

The "down side" to doing this method is that, from now on, you'll need to add 
configure.cxx_stdlib=libstdc++ to any port install command.  There's probably a 
way to set this variable in a configuration file, but it is so new I'm not sure 
it's there yet.

Thus, as I wrote before, my high level advice is to not update to 10.9 yet if 
you truly need GNU Radio.  We will continue to work on these bugs and fix them, 
but it will take some time, likely months, to track down enough to make GNU 
Radio and 10.9 play nicely together using libc++. - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Resolution of USRP N210 and N200

[Ben Hilburn]

Hi Ting -

Sorry, there really wasn't a good reason for me to not answer your
question, regardless =)

So the ADCs are indeed 14 bits, but those samples go through a lot of
processing on a number of different platforms, and get sent over a few
different buses. At any of these stages, depending on your system
parameters, there might be conversions and scaling factors applied to the
data, which changes the representation. Remember that since the ADC is a
14-bit ADC, you are never really getting more precision than those 14-bits;
they are just different ways of representing that data.

Does that help, at all?

Cheers,
Ben


On Tue, Nov 5, 2013 at 11:34 AM, Ben Hilburn  wrote:

> Ting -
>
> This question really isn't GNURadio related. If you resend it over the
> USRP-Users list, though, we will help explain things quickly!
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Cheers,
> Ben
>
>
> On Sat, Nov 2, 2013 at 12:22 AM, Ting Wu <
> wu.t...@comf5.comm.eng.osaka-u.ac.jp> wrote:
>
>> Hi,
>>
>>
>>
>> Both of USRP N210 and N200 have 14 bit ADC, which means a range of
>> +/-2e13=+/-8129.
>>
>> However, as I tested a N210 with LFRX, I got values from -32704 ~ 30073,
>> close to +/-2e15=32768.
>>
>> Last year, I also tested a N200 with LFRX, I got values from -16357 ~
>> 16241, close to +/-2e14=16384.
>>
>> The sampling rate was set to 4 MHz.
>>
>>
>>
>> So why does the ADC has a real resolution higher than 14 bit, and are
>> N210 and N200 the same?
>>
>> I’m really new to the world of ADC, so some basics would be very helpful.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Wu
>>
>> ___
>> 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] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[Ralph A. Schmid, dk5ras]

Just as a note, I also did not get the gui to work with my USRP1, the error 
messages are different, but at least it did not receive.

 

Ralph.

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 19:14
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and 
bladerf...

 

I've only tested osmocom in gr-air-modes with the HackRF. The relevant code is 
in python/radio.py lines 177-189. modes_gui does reinstantiate the source block 
a couple of times (to populate the options boxes) -- it's possible that this 
isn't allowing gr-osmocom enough time to close/open the USB device, or maybe 
gr-osmocom doesn't like reopening the device from within the same process?

 

--n

 

On Tue, Nov 5, 2013 at 10:04 AM, Ralph A. Schmid, dk5ras  
wrote:

Yes, works just fine, also other “toolchains” like gqrx – gr-osmosdr – bladerf 
do not show any strange effects, so osmosdr seems to be OK.

 

Ralph

 

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 18:10
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and 
bladerf...

 

Does osmocom_fft work?

 

--n

 

On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras  
wrote:

Hi,

gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions, built 
directly from the repo.

modes_rx works just fine, the messages come through.

modes_gui throws this error, when switching insinde the gui to osmosdr:

ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0
[bladeRF source] Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57 
FW v1.5.3 FPGA v0.0.0
gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.



The bladerf is flashed with latest fx3 image and latest fpga file into the SPI 
flash.

All the involved packages itself work just fine.

Any ideas what there may be wrong?


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223  
ra...@schmid.xxx
http://www.bclog.de/




___
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