Re: [Discuss-gnuradio] gr-modtool patch
Hi, I've been getting some comments about gr_modtool not working with Python 2.6. Nick McCarthy sent in a patch to fix this, so if lack of Python 2.7 was what stopped you from using gr_modtool, you might want to try again. Thanks to Nick! 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 pgpfX9MnTH39c.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems of GPSDO with GPS antenna
Hi,
I want to use GPSDO in my application. Since there is no GPS antenna with
GPSDO-kit, I bought a 'SMA male straight GPS antenna'. Everything went well
before I connect the GPS antenna to the GPSDO. For example, I can receive
GPS time using usrp->get_mboard_sensor("gps_time"). Other uhd applications
also work well.
To lock to the satellite and update the GPS time, I connected the GPS
antenna to GPSDO. However, I got some weird errors. I even got the same
errors when I run 'uhd_usrp_probe'.
~$ uhd_usrp_probe
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.003.000-d5d448e
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Found a Jackson Labs GPS
..
UHD Warning:
get_time: bad lexical cast: source type value could not be interpreted
as target
UHD Warning:
get_time: bad lexical cast: source type value could not be interpreted
as target
UHD Warning:
get_time: bad lexical cast: source type value could not be interpreted
as target
Error: ValueError: Timeout after no valid message found
Does anyone know how to fix it? I am using GPSDO+USRPN210+WBX on Ubuntu
10.04.
Thanks in advance.
Regards,
Jamie
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD+ USRP1 - transmitting on 2 WBX DBs
Hi! I am trying to make the following configuration work: 1 X USRP1 2 X WBX db's UHD driver gnuradio 3.5.2.1 I can transmit on each separately, and get 10-12dBm, but when trying both at once (using the UHD sing in GRC), I get much less power, if at all. What can I be doing wrong? Thanks for any suggestions, Uri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems of GPSDO with GPS antenna
Update to the latest version of UHD and corresponding firmware.
On Mon, 2 Apr 2012 22:37:40 +1000, 魏俊明 wrote:
> Hi,
>
> I want to
use GPSDO in my application. Since there is no GPS antenna with
GPSDO-kit, I bought a 'SMA male straight GPS antenna'. Everything went
well before I connect the GPS antenna to the GPSDO. For example, I can
receive GPS time using usrp->get_mboard_sensor("gps_time"). Other uhd
applications also work well.
>
> To lock to the satellite and update
the GPS time, I connected the GPS antenna to GPSDO. However, I got some
weird errors. I even got the same errors when I run 'uhd_usrp_probe'.
>
> ~$ uhd_usrp_probe
> linux; GNU C++ version 4.4.5; Boost_104200;
UHD_003.003.000-d5d448e
>
> -- Opening a USRP2/N-Series device...
>
-- Current recv frame size: 1472 bytes
> -- Current send frame size:
1472 bytes
> -- Found a Jackson Labs GPS
> ..
> UHD Warning:
>
get_time: bad lexical cast: source type value could not be interpreted
as target
>
> UHD Warning:
> get_time: bad lexical cast: source type
value could not be interpreted as target
>
> UHD Warning:
> get_time:
bad lexical cast: source type value could not be interpreted as target
>
> Error: ValueError: Timeout after no valid message found
>
> Does
anyone know how to fix it? I am using GPSDO+USRPN210+WBX on Ubuntu
10.04.
>
> Thanks in advance.
>
> Regards,
>
> Jamie
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_sync_block question
Thanks for clearing that up. That's what I surmised after poking around gr_block_executor; the problem turned out to be a mistake in the work function of a data source I put together. -Original Message- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf Of Johnathan Corgan Sent: Saturday, March 31, 2012 1:28 PM To: Tom Rondeau Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gr_sync_block question On Sat, Mar 31, 2012 at 07:52, Tom Rondeau wrote: > On Fri, Mar 30, 2012 at 2:58 PM, Josh Blum wrote: >> On 03/30/2012 11:23 AM, Nowlan, Sean wrote: >>> Do objects that extend gr_sync_block *require* that their work >>> function *always* returns as many items as the scheduler asked in >>> noutput_items, except for the case when a block may be completely >>> finished producing items? >> >> Returning 0 or -1 will tell the block executor code to stop. >> >> -Josh > > Just to clarify, a block can legitimately return 0; it just means that > it didn't produce any output, but it will try again. To clarify even further--a *source* block that returns 0 samples will be treated as done, for other blocks it is ok. Johnathan ___ 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] A question on the order of the processing stages for the psk receiver
Dear all, I have a question on the order of the processing stages for the psk receiver. As I have seen from some source code (e.g., dqpsk.py in earlier version of GnuRadio 3.4.2 backwards), the sequence of blocks for a psk receiver is: AGC -> RRC filter -> mpsk receiver (mpsk_receiver_cc) -> differential decoding -> symbol demapping (find closest constellation point) -> gray code decoding (optional) -> and so on. My confusion here is why the differential decoding is placed before the symbol demapping block, while as my usual thought the demapping should goes ahead of the differential decoding stage. Can anyone explain that to me or just show me the related documents, i would be greatly grateful for it, With best regards, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A question on the order of the processing stages for the psk receiver
On Mon, Apr 2, 2012 at 11:45 AM, Anh Duc Nguyen wrote: > Dear all, > > I have a question on the order of the processing stages for the psk > receiver. > As I have seen from some source code (e.g., dqpsk.py in earlier version of > GnuRadio 3.4.2 backwards), the sequence of blocks for a psk receiver is: > > AGC -> RRC filter -> mpsk receiver (mpsk_receiver_cc) -> differential > decoding -> symbol demapping (find closest constellation point) -> gray code > decoding (optional) -> and so on. > > My confusion here is why the differential decoding is placed before the > symbol demapping block, while as my usual thought the demapping should goes > ahead of the differential decoding stage. > > Can anyone explain that to me or just show me the related documents, i would > be greatly grateful for it, > > With best regards, We use the phasor of the symbol to do the differential decoding. Instead of looking at the bits, the phasor looks at the phase change between symbols. The major benefit of this is you don't have to care at all about the starting point or any rotation in the constellation; you just see a phase change. It's a much easier method to implement and is equivalent to looking at the bits, which is what's always taught in the text books. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD+ USRP1 - transmitting on 2 WBX DBs
On 04/02/2012 05:40 AM, Uri Savoray wrote: > Hi! > I am trying to make the following configuration work: > 1 X USRP1 > 2 X WBX db's > UHD driver > gnuradio 3.5.2.1 > > I can transmit on each separately, and get 10-12dBm, but when trying both at > once (using the UHD sing in GRC), I get much less power, if at all. > What can I be doing wrong? > Thanks for any suggestions, > Uri > > Please attach the GRC flowgraph. Perhaps we can guide you. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-companion: set value to None
For example, when there isif tau is not None: in fm_demod.py, and you want to put None for tau in gnuradio-companion "FM Demod" block, what do you put into the properties dialog for FM demod block? If I want no filtering of any kind.. I also wonder about another block for FM demod, perhaps Quadrature demod block? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-Trellis FSM
Yep, this fixed the problem. Successfully ran the FSM for 20,000+ times without an error. Thanks for the fix! -Chris --- On Sat, 3/31/12, Achilleas Anastasopoulos wrote: From: Achilleas Anastasopoulos Subject: Re: [Discuss-gnuradio] gr-Trellis FSM To: "Discuss-gnuradio@gnu.org" Cc: valen...@sbcglobal.net Date: Saturday, March 31, 2012, 12:20 PM great catch! It appears that in the constructor we (ie, I) forgot to close the file... I will submit a patch ASAP, but in the meantime, please add fclose(fsmfile); just before generate_PS_PI(); generate_TM(); in the fsm constructor fsm::fsm(const char *name) in gr-trellis/src/lib/fsm.cc remake reinstall and test. Please let us know if this fixes your problem. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Segfault
Hey Just curious, have you had a chance to look at this? Also, in the meantime I tried using your kernel tree (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version of the usrp_e driver, built with the kernel configuration that I took from a working USRP image. However, when trying to modprobe the usrp-e module, I get: usrp_e entering driver initialization Unable to handle kernel NULL pointer dereference at virtual address 003c pgd = c9554000 [003c] *pgd=9f843831, *pte=, *ppte= Internal error: Oops: 817 [#1] Modules linked in: usrp_e(+) CPU: 0Not tainted (3.0.0 #1) PC is at usrp_e_init+0x84/0x1c4 [usrp_e] LR is at usrp_e_init+0x84/0x1c4 [usrp_e] pc : []lr : []psr: 6013 sp : c954deb0 ip : fp : r10: 001c r9 : 0024 r8 : 0001 r7 : bf001a38 r6 : bf001b70 r5 : r4 : r3 : r2 : c954dea4 r1 : bf001914 r0 : 000b Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 89554019 DAC: 0015 Process modprobe (pid: 57, stack limit = 0xc954c2f0) Stack: (0xc954deb0 to 0xc954e000) dea0: bf004000 bf001a38 dec0: bf004000 c94e6680 c003737c c0569858 0001 bf001a38 bf001a38 dee0: 0001 bf001a38 0001 bf001a80 c94e6680 0001 0024 c0088550 df00: bf001a44 000203c0 0065f11c 0124 c0086288 c03c70bc bf001b5c 0065b018 df20: c943bc28 e08ae000 000246d5 e08c7aac e08c7891 e08d20cc c94950c0 1b84 df40: 20e4 0032 0033 001c 0019 0017 df60: c0511494 df80: 401955b0 0080 c003c484 c954c000 dfa0: 0065b018 c003c300 401955b0 401bc008 000246d5 0065b018 bebf89e4 dfc0: 401955b0 0080 00016f50 000203c0 0065f11c 0065b018 dfe0: 40143cd8 bebf89e4 c25c 40143ce8 2010 401bc008 e1a06007 1af7 [] (usrp_e_init+0x84/0x1c4 [usrp_e]) from [] (do_one_initca) [] (do_one_initcall+0x90/0x160) from [] (sys_init_module+0x) [] (sys_init_module+0x1628/0x181c) from [] (ret_fast_syscal) Code: eb48b539 e5860010 e59f011c eb4ee213 (e584503c) ---[ end trace 784c802e29369acf ]--- Segmentation fault This seems to happen in usrp_e.c on line 854: atomic_set(&p->mapped, 0); - I assume that, for some reason, "p" isn't properly initialized. You wouldn't by any chance have some idea about what might be wrong there? Furthermore, sorry for the nagging :) cheers -- Stefan Ott Communication and Distributed Systems Institute of Computer Science and Applied Mathematics University of Bern ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-companion: set value to None
On 04/02/2012 09:16 AM, wayne roberts wrote: > For example, when there isif tau is not None: in fm_demod.py, and you > want to put None for tau in gnuradio-companion "FM Demod" block, what do > you put into the properties dialog for FM demod block? > > If I want no filtering of any kind.. > I also wonder about another block for FM demod, perhaps Quadrature demod > block? > > 2 thoughts on this Maybe it would be a good idea in general for grc param entries to simply accept None. That is, bypass the whole type checking when "x is None". Also, perhaps a simple patch is in order, then set tau to zero. I assume thats out of the acceptable range: diff --git a/grc/blocks/blks2_fm_demod_cf.xml b/grc/blocks/blks2_fm_demod_cf.xml index 2ce1fb9..89b5d23 100644 --- a/grc/blocks/blks2_fm_demod_cf.xml +++ b/grc/blocks/blks2_fm_demod_cf.xml @@ -15,7 +15,9 @@ audio_pass=$audio_pass, audio_stop=$audio_stop, gain=$gain, +#if $tau() tau=$tau, +#end if ) Channel Rate -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Segfault
On 04/02/2012 09:27 AM, Stefan Ott wrote: > Hey > > Just curious, have you had a chance to look at this? > > Also, in the meantime I tried using your kernel tree > (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version > of the usrp_e driver, built with the kernel configuration that I took > from a working USRP image. However, when trying to modprobe the usrp-e > module, I get: That branch is not done yet :) I just updated github to match the current shipping kernel (from last week) See the e100-3.0-pm-2-bugfixes branch. In particular, I added some code to do some range checking on the values passed to the ioctl in: https://github.com/balister/linux-omap-philip/commit/057c170c1bae5f036c9b37838405b9d1d773ab84 Philip > > usrp_e entering driver initialization > Unable to handle kernel NULL pointer dereference at virtual address 003c > pgd = c9554000 > [003c] *pgd=9f843831, *pte=, *ppte= > Internal error: Oops: 817 [#1] > Modules linked in: usrp_e(+) > CPU: 0Not tainted (3.0.0 #1) > PC is at usrp_e_init+0x84/0x1c4 [usrp_e] > LR is at usrp_e_init+0x84/0x1c4 [usrp_e] > pc : []lr : []psr: 6013 > sp : c954deb0 ip : fp : > r10: 001c r9 : 0024 r8 : 0001 > r7 : bf001a38 r6 : bf001b70 r5 : r4 : > r3 : r2 : c954dea4 r1 : bf001914 r0 : 000b > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 10c5387d Table: 89554019 DAC: 0015 > Process modprobe (pid: 57, stack limit = 0xc954c2f0) > Stack: (0xc954deb0 to 0xc954e000) > dea0: bf004000 bf001a38 > dec0: bf004000 c94e6680 c003737c c0569858 0001 bf001a38 bf001a38 > dee0: 0001 bf001a38 0001 bf001a80 c94e6680 0001 0024 c0088550 > df00: bf001a44 000203c0 0065f11c 0124 c0086288 c03c70bc bf001b5c 0065b018 > df20: c943bc28 e08ae000 000246d5 e08c7aac e08c7891 e08d20cc c94950c0 1b84 > df40: 20e4 0032 0033 001c 0019 0017 > df60: c0511494 > df80: 401955b0 0080 c003c484 c954c000 > dfa0: 0065b018 c003c300 401955b0 401bc008 000246d5 0065b018 bebf89e4 > dfc0: 401955b0 0080 00016f50 000203c0 0065f11c 0065b018 > dfe0: 40143cd8 bebf89e4 c25c 40143ce8 2010 401bc008 e1a06007 1af7 > [] (usrp_e_init+0x84/0x1c4 [usrp_e]) from [] > (do_one_initca) > [] (do_one_initcall+0x90/0x160) from [] > (sys_init_module+0x) > [] (sys_init_module+0x1628/0x181c) from [] > (ret_fast_syscal) > Code: eb48b539 e5860010 e59f011c eb4ee213 (e584503c) > ---[ end trace 784c802e29369acf ]--- > Segmentation fault > > This seems to happen in usrp_e.c on line 854: atomic_set(&p->mapped, > 0); - I assume that, for some reason, "p" isn't properly initialized. > You wouldn't by any chance have some idea about what might be wrong > there? > > Furthermore, sorry for the nagging :) > > cheers ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A question on the order of the processing stages for the psk receiver
Dear Tom, Thank you very much for your prompt reply. It is pretty new and makes sense to me. But I still have a little doubt, let me present it briefly as follows: Denote omega(n) and d_omega(n) the phases of psk and dpsk modulated signals, we have omega(n) = d_omega(n) - d_omega(n-1) Then exp(j* omega(n) ) = exp( j*d_omega(n) - j*d_omega(n-1) ) = exp( j*d_omega(n) ) * exp( -j*d_omega(n-1)) In the case of (I^2+Q^2) is constant over time, we have the psk modulated signal is determined through the dpsk modulated signal: y(n) = d_y(n) * d_y**(n-1);y(n), d_y(n) are complex numbers, d_y**(n) is the complex-conjugate of d_y(n) And here is the point to do the differential decoding before symbol demapping, right? But the question is what happens if the amplitude (I^2+Q^2) changes over time due to some transmission conditions, and in that case, do we have to normalize signal amplitudes, just consider the phases? I am sorry if I disturb you with my lack of digital communications background , Thank you in advance, On Mon, Apr 2, 2012 at 10:59 PM, Tom Rondeau wrote: > On Mon, Apr 2, 2012 at 11:45 AM, Anh Duc Nguyen wrote: > > Dear all, > > > > I have a question on the order of the processing stages for the psk > > receiver. > > As I have seen from some source code (e.g., dqpsk.py in earlier version > of > > GnuRadio 3.4.2 backwards), the sequence of blocks for a psk receiver is: > > > > AGC -> RRC filter -> mpsk receiver (mpsk_receiver_cc) -> differential > > decoding -> symbol demapping (find closest constellation point) -> gray > code > > decoding (optional) -> and so on. > > > > My confusion here is why the differential decoding is placed before the > > symbol demapping block, while as my usual thought the demapping should > goes > > ahead of the differential decoding stage. > > > > Can anyone explain that to me or just show me the related documents, i > would > > be greatly grateful for it, > > > > With best regards, > > We use the phasor of the symbol to do the differential decoding. > Instead of looking at the bits, the phasor looks at the phase change > between symbols. The major benefit of this is you don't have to care > at all about the starting point or any rotation in the constellation; > you just see a phase change. It's a much easier method to implement > and is equivalent to looking at the bits, which is what's always > taught in the text books. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pack k bits?
On Wed, Mar 28, 2012 at 8:48 AM, Nowlan, Sean wrote: > I want to take an input stream of bytes in which only one LSB is relevant > (e.g., the output of the GR GLFSR block) and pack these bits into bytes with > k relevant bits. For example, I’d like to take a stream of raw bits > generated by the GLFSR and feed them to an M-PSK modulator, which requires > chunks with k=log2(M) bits. Unfortunately I haven’t found this to be > straightforward. There is no “pack_k_bits” module that I could find, so I > tried using unpacked_to_packed_bb and packed_to_unpacked_bb. They are not > working like I would expect. For instance, here’s an example in Python: > > … > > data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0] Ok, finally got some time to work through this. What's happening here is that first you are packing these into bytes, but in reverse order since you're taking the LSB first. So the output of self.pack is: [01000101, 01100111] --> 0x45, 0x67 Then you are telling the upacked_to_packed to read the LSB first and unpack from there where the output stream has 2-bits per byte: [01, 00, 01, 01 | 01, 10, 01, 11] --> unpack 2, LSB, read left to right That means that you are reading each byte out from left to right and putting them into bytes two at a time. In other words: Byte 1: [01, 00, 01, 01] 01 --> 10 (2) 01 --> 10 (2) 00 --> 00 (0) 01 --> 10 (2) Byte 2: [01, 10, 01, 11] 11 --> 11 (3) 01 --> 10 (2) 10 --> 01 (1) 01 --> 10 (2) If you want it your way, use gr.GR_MSB_FIRST for the gr.unpacked_to_packed_bb. Working through it this way, I'm pretty sure what's happening is correct. There might be a confusion about byte order and how the unpacked_to_packed with LSB first swaps things around on you. For instance, you said that "data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0] # 45 67", but they are just bits in a string of bytes at that point, so you're trying to read it backwards. That vector is actually [0xA2, 0xE6]. Of course, now I'm confused... but I'm pretty sure the way that it's working is correct. Tom > self.source = gr.vector_source_b(data, False, 1) > > self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST) > > self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST) # stuff 2 > bits into LSB of each output byte > > self.head = gr.head(gr.sizeof_char, 8) # should > have 16/2 = 8 output bytes > > self.sink = gr.file_sink(gr.sizeof_char, “out.bin”) > > self.connect(self.source, self.pack, self.unpack, self.head, self.sink) > > … > > > > This gives the following: > > $ hexdump -C out.bin > > 000 02 02 00 02 03 02 01 02 |……..| > > 008 > > > > But I would expect the following: > > 000 01 01 00 01 03 01 02 01 |……..| > > 008 > > > > Notice that the two least significant bits are in reverse order. Any clue > what’s going on here? > > > > Thanks, > > Sean > > > ___ > 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] UHD+ USRP1 - transmitting on 2 WBX DBs
Here goes... I think this is as simple as it gets :-) Thanks, Uri -Original Message- From: discuss-gnuradio-bounces+uris=septier@gnu.org [mailto:discuss-gnuradio-bounces+uris=septier@gnu.org] On Behalf Of Josh Blum Sent: 02 April 2012 19:04 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] UHD+ USRP1 - transmitting on 2 WBX DBs On 04/02/2012 05:40 AM, Uri Savoray wrote: > Hi! > I am trying to make the following configuration work: > 1 X USRP1 > 2 X WBX db's > UHD driver > gnuradio 3.5.2.1 > > I can transmit on each separately, and get 10-12dBm, but when trying both at > once (using the UHD sing in GRC), I get much less power, if at all. > What can I be doing wrong? > Thanks for any suggestions, > Uri > > Please attach the GRC flowgraph. Perhaps we can guide you. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio t.grc Description: t.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Job openings that might interest list members
We have two job openings here at Horizon Analog. We're a small outfit in downtown Lawrence, Kansas, a great college town. One position is more RF hardware oriented and one is more software and DSP related. We're developing non-linear technology and use Ettus radios for a lot of our work, partially with GNU Radio, partially with MATLAB, with a some C++ and Verilog HDL for fun. http://www.horizonanalog.com/Career_Opportunities.htm -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent development activity, upcoming plans
On Mon, Apr 2, 2012 at 2:17 AM, Josh Blum wrote: > >> - Removal of dependency on gsl for gnuradio-core. The wavelet blocks >> that were in gnuradio-core, which depend on the GNU Scientific Library > > I would make a similar argument for the FFTW dependency on > gnuradio-core. I'm not volunteering, but that would bring gnuradio-core > down to gruel, boost, and cppunit as dependencies. Even cppunit could be > replaced with boost unit test. FFTs are pretty vital to signal processing and are used in multiple places. Many of these are in the filters, and we have a plan (for 3.7) to create a gr-filter category. You aren't going to get a whole lot accomplished in signal processing if you don't have filters and the components that use FFTW. So even if we made a separate component for FFTs, it's still and _effective_ requirement to install it even if it's not a _required_ requirement. When we get gr-filter, then we could have a discussion of whether its appropriate to have a gr-fft component. I feel that's a bit too much granularity, but we can discuss it at that point. I think as we are moving towards more top-level components and less in gnuradio-core (mainly just runtime), we will be working on these issues in general. We don't want too much granularity, and I still see gr_fft_vcc being a part of a larger component structure and not just on its own. Wavelets are their own class of algorithms that are really useful for lots of things, but aren't fundamental to most processing we do. So on one level, separating it out means most people won't notice that it's missing, and on another, there are lots of new things that can be added that fall under the gr-wavelet component in the future. That's not really true for FFTs. I had suggested we have a gr-scientific or maybe a gr-transforms, but I don't think that plays too well, really, even if it is technically appropriate (and if we did FFTs and wavelets in one component, we'd force people to install GSL just to get FFTs; not where we want to be going with this). Basically, I'm saying this is a discussion for a little while in the future. Definitely at least after we've move gr-filter out of gnuradio-core. As for the unit testing, frankly, I don't care what tool is used so long as the behavior is the same as we have now. One thing that's important is that the QA results are stored in the XML files that Jenkins reads. I'm pretty sure Jenkins can handle Boost output files, too, but we'd want to make sure that was working cleanly if we made the move. What I don't want is to have two such systems running (we already have a Python and C++ unit test, which some find confusing already). So an switch would have to be made all at once. I personally don't see that it's such a big deal to go through that effort to make the change. >> - Preparation to to merge the 'next' branch back in to 'master', after >> the 3.5.3 release. The 'next' branch is the long-running development >> branch where we implement things that are either somewhat unstable, or >> more often, make changes to the API such that user code might break. > > There was this idea of loadable modules for gr-audio. That way one could > build gr-audio for all the audio development environments, but when > deploying, you only install the modules that the OS has runtime support > for. Think deb packaging, where each module becomes a package with > specific requirements like libjack, libalsa... Would this merge event be > a good time to implement something like that? > > Also, for those of us who are interested in gnuradio's PMT library: > > 1) Would this be a good time to fix the tag/PMT mutability issue? This > would prevent multiple downstream blocks from being able to manipulate a > shared resource, but it is a slight API change for the tags: > http://gnuradio.org/redmine/issues/490 Johnathan and I have discussed this, but I don't think we've come up with a plan. The idea is that we fix the issue of being able to manipulate pmt_vectors (and any other containers) after their creation such that all PMTs are now read-only. The PMT vectors are a good idea in that you want to be able to have a vector of items, but the implementation has allowed them to be changed, which produces thread safety issues. > 2) I would love to see the concept of tag/PMT based message passing make > it into the scheduler. The basic idea is to pass tags (without samples > associated) between blocks as a form of out-of-band > communication/control-plane. Here is here squashed into a single > changeset: https://github.com/guruofquality/gnuradio/tree/msg_passing I'm of the mind that yes, this is a good thing. The squashed commit it nice, so I finally went through to look at the code. This can probably be merged in soon. Johnathan and I are going to take a closer look at it, so we might have a few requests for it soon. One request. Could you write either some documentation for how to use the message passing system or, probably better, a simple e
Re: [Discuss-gnuradio] Build problems and some possible solutions
On 01/08/2012 06:39 PM, Volker Schroer wrote: But make installmake[5]: Entering directory `/home/schroer/gnuradiocomponents/gnuradio/gr-vocoder/python' make[6]: Entering directory `/home/schroer/gnuradiocomponents/gnuradio/gr-vocoder/python' make[6]: Für das Ziel »install-exec-am« ist nichts zu tun. test -z "/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/vocoder" || /bin/mkdir -p "/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/vocoder" /usr/bin/install -c -m 644 __init__.py cvsd.py '/usr/local/gnuradio/lib64/python2.7/site-packages/gnuradio/vocoder' /bin/sh: Zeile 15: --destdir: Kommando nicht gefunden. make[6]: *** [install-vocoderPYTHON] Fehler 127 Is this one of the possible side effects ? I suppose not, but at the moment I have no solution. Any hint would be welcome. -- Volker fails with I know this is an old thread, but I've hit the --destdir problem myself, and it's due to an automake bug, see http://lists.gnu.org/archive/html/bug-automake/2012-03/msg00041.html Regards, João Silva ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent development activity, upcoming plans
On Sun, Apr 1, 2012 at 23:17, Josh Blum wrote: > There was this idea of loadable modules for gr-audio. That way one could > build gr-audio for all the audio development environments, but when > deploying, you only install the modules that the OS has runtime support > for. Think deb packaging, where each module becomes a package with > specific requirements like libjack, libalsa... When gr-audio was individual top-level directories, doing the above was trivial, and in fact, was how it was done for the old debian packages in 3.2. How do you see making this work now? > Would this merge event be > a good time to implement something like that? No, I think it would be development work that could happen after the 3.6.0 release, either on master as part of 3.6.1, or on the new 3.7 next branch, depending on the intrusiveness of the solution. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A question on the order of the processing stages for the psk receiver
Dear Tom, Thank you for your kind help, I appreciate it much. I am at the starting point of studying GnuRadio and radio communication in general, so your support is valuable to me. With best regards, On Tue, Apr 3, 2012 at 1:51 AM, Tom Rondeau wrote: > On Mon, Apr 2, 2012 at 2:00 PM, Anh Duc Nguyen wrote: > > Dear Tom, > > > > Thank you very much for your prompt reply. It is pretty new and makes > sense > > to me. But I still have a little doubt, let me present it briefly as > > follows: > > > > Denote omega(n) and d_omega(n) the phases of psk and dpsk modulated > > signals, we have > > > > omega(n) = d_omega(n) - d_omega(n-1) > > > > Then > > > > exp(j* omega(n) ) = exp( j*d_omega(n) - j*d_omega(n-1) ) = > > exp( j*d_omega(n) ) * exp( -j*d_omega(n-1)) > > > > In the case of (I^2+Q^2) is constant over time, we have the psk modulated > > signal is determined through the dpsk modulated signal: > > > > y(n) = d_y(n) * d_y**(n-1);y(n), d_y(n) are complex numbers, > d_y**(n) is > > the complex-conjugate of d_y(n) > > > > And here is the point to do the differential decoding before symbol > > demapping, right? > > > > But the question is what happens if the amplitude (I^2+Q^2) changes over > > time due to some transmission conditions, and in that case, do we have to > > normalize signal amplitudes, just consider the phases? > > > > I am sorry if I disturb you with my lack of digital > > communications background , > > > > Thank you in advance, > > The amplitude has nothing to do with the phase. A small amplitude > might make the phase harder to determine because you are closer to > zero on the unit circle, so that noise could push you over the edge of > a decision boundary, but affecting the amplitude does _not_ change the > phase at all. The only way to do that would be to change I and Q > separately, which won't happen (there will be an IQ imbalance in the > hardware, but a) it's minor and b) it will not change fast over time). > So what you're suggesting isn't really a problem for real systems. > > Tom > > > > On Mon, Apr 2, 2012 at 10:59 PM, Tom Rondeau wrote: > >> > >> On Mon, Apr 2, 2012 at 11:45 AM, Anh Duc Nguyen > wrote: > >> > Dear all, > >> > > >> > I have a question on the order of the processing stages for the psk > >> > receiver. > >> > As I have seen from some source code (e.g., dqpsk.py in earlier > version > >> > of > >> > GnuRadio 3.4.2 backwards), the sequence of blocks for a psk receiver > is: > >> > > >> > AGC -> RRC filter -> mpsk receiver (mpsk_receiver_cc) -> differential > >> > decoding -> symbol demapping (find closest constellation point) -> > gray > >> > code > >> > decoding (optional) -> and so on. > >> > > >> > My confusion here is why the differential decoding is placed before > the > >> > symbol demapping block, while as my usual thought the demapping should > >> > goes > >> > ahead of the differential decoding stage. > >> > > >> > Can anyone explain that to me or just show me the related documents, i > >> > would > >> > be greatly grateful for it, > >> > > >> > With best regards, > >> > >> We use the phasor of the symbol to do the differential decoding. > >> Instead of looking at the bits, the phasor looks at the phase change > >> between symbols. The major benefit of this is you don't have to care > >> at all about the starting point or any rotation in the constellation; > >> you just see a phase change. It's a much easier method to implement > >> and is equivalent to looking at the bits, which is what's always > >> taught in the text books. > >> > >> Tom > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent development activity, upcoming plans
On 04/02/2012 03:20 PM, Johnathan Corgan wrote: > On Sun, Apr 1, 2012 at 23:17, Josh Blum wrote: > >> There was this idea of loadable modules for gr-audio. That way one could >> build gr-audio for all the audio development environments, but when >> deploying, you only install the modules that the OS has runtime support >> for. Think deb packaging, where each module becomes a package with >> specific requirements like libjack, libalsa... > > When gr-audio was individual top-level directories, doing the above > was trivial, and in fact, was how it was done for the old debian > packages in 3.2. > > How do you see making this work now? > Well, so I would like to restore that install capability that was lost when we combined gr-audio components into one. The basic idea is, rather than all implementations of audio source/sink being built into the gnuradio-audio.so, we build the implementations into separate modules. Whatever modules are installed at runtime are loaded, and available for selection via the audio.conf settings. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent development activity, upcoming plans
> > As for the unit testing, frankly, I don't care what tool is used so > long as the behavior is the same as we have now. One thing that's > important is that the QA results are stored in the XML files that > Jenkins reads. I'm pretty sure Jenkins can handle Boost output files, > too, but we'd want to make sure that was working cleanly if we made > the move. What I don't want is to have two such systems running (we > already have a Python and C++ unit test, which some find confusing > already). So an switch would have to be made all at once. I personally > don't see that it's such a big deal to go through that effort to make > the change. > Looks like Boost unit test can output XML FWIW. Dont know if thats a format jenkins can parse: http://www.alittlemadness.com/2009/04/07/boosttest-xml-reports-for-continuous-integration/ > Johnathan and I have discussed this, but I don't think we've come up > with a plan. The idea is that we fix the issue of being able to > manipulate pmt_vectors (and any other containers) after their creation > such that all PMTs are now read-only. The PMT vectors are a good idea > in that you want to be able to have a vector of items, but the > implementation has allowed them to be changed, which produces thread > safety issues. > In the plan outlined in that ticket, gr_tag_t would be filled with pmt_const_t and not pmt_t. This would prevent the downstream dudes from violating the immutability contract with the upstream. The implementation of creating and filling a PMT would not have to change. > One request. Could you write either some documentation for how to use > the message passing system or, probably better, a simple example that > shows connecting blocks together and passing messages between them? > That would help clarify their use. I'm not saying that this is a > requirement before the merge, but it would be nice to see how it's > used. > Absolutely. Here is a QA test: https://github.com/guruofquality/grextras/blob/master/python/qa_msg_passing.py And usage is fully documented on the blocks coding guide for c++/python: http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide > that doesn't require this. But again, I'm not sure where PMT creation > is the bottleneck anywhere, and Boost intrusive pointers work really > fast already. > Boost intrusive pointers are great. But they are actually just stack-allocated objects. Its the pointer you fill them with, which is the allocation in question. So, In small quantities, when latency isnt a concern, of course its not a big deal. However, for large quantities, I learned this the hard way with UHD and oprofile. If you have a malloc on every packet, the overhead is on the same order of magnitude as converting a packet worth of samples. So, it can be serious overhead, and its a good thing to give users a way to avoid allocating heavily in the work function (should they be using PMTs that heavily). > I hope this clears up why the PMT read/write issue is a non-starter. > I'd rather see a bit of slowdown then segfaults :) > I'm not sure what segfaults you are referring to. But the thread safety issue is already a problem. Technically, tags/PMTs are one giant race condition if your downstream blocks do not follow the implicit contract. We should fix this. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
