Re: [Discuss-gnuradio] Gnuradio locking up

[Matt Mills]

It appears UHD does not like to be watched; reproducibly if I run with GDB
attached, UHD eventually stops sending data to the upstream blocks and my
screen fills up with:

thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError: Control channel send error

if I run it without GDB attached, it segfaults.

On Wed, Nov 23, 2011 at 9:44 AM, Tom Rondeau  wrote:

> Since it's a segfault, I just added this to the FAQ on the wiki to explain
> how to get more information:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python
>
> Post the output of the backtrace to help us find out what's going wrong.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] the missing of /usr/local/lib/python2.7/dist-packages/usrpm ?

[Alex Zhang]

I installed the Gnuradio+UHD+GRC on my ubuntu this Oct, and it is noticed
that there is a directory usrpm in
the  /usr/local/lib/python2.7/dist-packages/.
Today, I install all the Gnuradio+UHD on a new ubuntu (11.10) PC, just
using the script from http://www.sbrac.org/files/build-gnuradio and then
installed the gnuradio-companion.
Seems everything is ok, such as uhd_find_device can find the connected USRP
N210, the gnuradio-companion can be initiated without any errors.
However, I can not find the /usr/local/lib/python2.7/dist-packages/usrpm
any longer. I am wondering what is this usrpm for and did I miss something
necessary during my installation?

-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio Pseudo Noise sequence

[Phone Naing MYINT]

Hi,

In gnuradio, they use Pseudo noise sequence generated from 15 bits LFSR 
(sequence in packet_utils.py). Now I'm implementing the whitening in hardware. 
I like to know the configuration of that 15 bits LFSR?

PN

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

[Discuss-gnuradio] The values written into AD9862 registers

[signalswdm]

Hello everyone：
  You see there are 63 registers in AD9862, which are configured by SPI. It 
seems in usrp_stand.cc and usrp_basic.cc there are codes about how to write and 
read AD9862 registers, but I still have not yet found the exact values written 
into all the 63 AD9862 registers.
 Can you point to me where the codes about the exact value written into 
AD9862 registers are?? Thank you!!
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Messages, queues, and tags

[Josh Blum]

On 11/23/2011 06:11 PM, Eugene Grayver wrote:
> Hello,
> 
> I've been following the changes Josh is making to the GR messaging system. 
>  I am not sure that a gr_tag is a good fit for a generic message.  For 
> example, the 'offset' may not be relevant to many messages.
> 

Well, so basically I wanted a object with key, value, and srcid. All of
those concepts from tags fit really well with the pmt-based message passing.

So I decided to use gr_tag which has all of that good stuff. However,
there is an offset member, which only applies to streams. Yes, it is
laziness on my part (or is it efficiency?)

Did you have an issue other than the unused "offset" member?

> We've been using tags very extensively in our designs and they are great 
> but serve a very different purpose than messages should.  Perhaps a better 
> idea is to define a standard message header? 
> 
> How about something like this:
> 
> A pmt_t tuple with 
> 
> 1. First entry is a string indicating the packet type

In this current design above, this is the purpose of tag.key

> 2. A sequence of zero or more pairs with (key, value), where key is a 
> string, and value is any pmt_t
> 

I suppose if you wanted to aggregate several messages (several key/value
pairs), you could set tag.key to "my super message aggregate" and then
tag.value would be this combined tuple format of keys and values.

I would like to keep the pmt-based message passing parallel with the
tags API, so if one deserves changing, than I think changes are merited
for both.

keep the feedback coming! Thanks,
-Josh

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

[Discuss-gnuradio] Messages, queues, and tags

[Eugene Grayver]

Hello,

I've been following the changes Josh is making to the GR messaging system. 
 I am not sure that a gr_tag is a good fit for a generic message.  For 
example, the 'offset' may not be relevant to many messages.

We've been using tags very extensively in our designs and they are great 
but serve a very different purpose than messages should.  Perhaps a better 
idea is to define a standard message header? 

How about something like this:

A pmt_t tuple with 

1. First entry is a string indicating the packet type
2. A sequence of zero or more pairs with (key, value), where key is a 
string, and value is any pmt_t


Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Messages, queues, and tags

[Eugene Grayver]

Hello,

I've been following the changes Josh is making to the GR messaging system. 
 I am not sure that a gr_tag is a good fit for a generic message.  For 
example, the 'offset' may not be relevant to many messages.

We've been using tags very extensively in our designs and they are great 
but serve a very different purpose than messages should.  Perhaps a better 
idea is to define a standard message header? 

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using PPS to trigger received data storage in Python

[Josh Blum]

When you say PPS, do you mean "pulse per second" or are you trying to
use the PPS input as a generic triggering system? If the second case,
you can do this, but my advice will be different.

> 1. I am wondering how to fill meta-data in Python if device.recv() is
> not swigged? I need to use the PPS signal to trigger the received
> data storage for 1ms every second after detecting the edge of PPS

It seems like you do not need the PPS to trigger anything. Your
downstream block can use the timestamp tag and sample count to determine
which samples should be stored.

> signal every second. I am using the follow setting method to detect
> the PPS signal:
> 
> self.clk_cfg = uhd.clock_config() self.clk_cfg.pps_source =
> uhd.clock_config.PPS_SMA self.clk_cfg.pps_polarity =
> uhd.clock_config.PPS_NEG self._usrp2.set_clock_config(self.clk_cfg,
> uhd.ALL_MBOARDS) 
> self._usrp2.set_time_unknown_pps(uhd.time_spec(0.0))
> 

That will work

> 2. This PPS setting is done just after the usrp device is created.
> The PPS signal could be detected while usrp device is setup. I am
> also wondering if this approach could make usrp detect PPS signal
> every second or only once when the usrp device is setup?
> 

You need to understand that the PPS is only used to trigger the latching
of the time registers. Once you set the time registers, thats it, your
are done. You know what time the next pps will occur because it is one
second plus the time you set.

-Josh

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

Re: [Discuss-gnuradio] using PPS signal to trigger the received data storage in Pyton

[Josh Blum]

On 11/23/2011 01:52 PM, Yan Nie wrote:
> Dear all,
> 
> I am using USRP N200 with LFRX +UHD to design a receiver, which works
> fine to continuously receive data. I need to use PPS signal to
> trigger the received data storing only for 1ms every second after
> detecting the edge of PPS signal every second.
> 
> I tried the approach introduced in the gnuradio example,
> rx_timed_samples, detecting the PPS signal, then setup streaming,
> then fill out rx-meta-data by recv(). Eventually, I got to know the
> stream_cmd and recv are not swigged, which means I could use this
> method in Python.
> 

You may be interested, on my uhd_work branch, I added a set_start_time
call: http://gnuradio.org/cgit/jblum.git/log/?h=uhd_work

You can use this call to control when streaming will begin. So you
should use PPS to synchronize the usrp time registers, then set the
start time to be one second later, then start the flow graph.

-Josh

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

[Discuss-gnuradio] using PPS signal to trigger the received data storage in Pyton

[Yan Nie]

Dear all,

I am using USRP N200 with LFRX +UHD to design a receiver, which works fine to 
continuously receive data. I need to use PPS signal to trigger the received 
data storing only for 1ms every second after detecting the edge of PPS signal 
every second. 

I tried the approach introduced in the gnuradio example, rx_timed_samples, 
detecting the PPS signal, then setup streaming, then fill out rx-meta-data by 
recv(). Eventually, I got to know the stream_cmd and recv are not swigged, 
which means I could use this method in Python.

>From previous email reply, the USRP source already tags the samples with a 
>timestamp, I do not need to control when streaming begins, because the 
>downstream block can determine the time of any samples using metadata. 

1. I am wondering how can I fill out meta-data by the received data if recv() 
cannot be used in Python,as I wish to set the time of samples as the time when 
PPS signal is detected every second and use the total_num_samps to control the 
number of data USRP received every second after triggering be PPS signal.

I am using the following method to detect PPS signal:

    self.clk_cfg = uhd.clock_config()
    self.clk_cfg.pps_source = uhd.clock_config.PPS_SMA
    self.clk_cfg.pps_polarity = uhd.clock_config.PPS_NEG
    self._usrp2.set_clock_config(self.clk_cfg, uhd.ALL_MBOARDS)
    self._usrp2.set_time_unknown_pps(uhd.time_spec(0.0))

2. The PPS setting is done right after the USRP device is created, hence the 
PPS signal could be detected when USRP device is setup. I am also wondering 
this PPS setting could let the USRP detect PPS signal every second, or only 
once when this setting is called? 

Any suggestion or idea will be really appreciated! 

Thanks,
Yan

I am really sorry for the last uncompleted email, as I got some problems with 
our server here. Sorry.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using PPS to trigger received data storage in Python

[Yan Nie]

 Dear all,

I used USRP N200 with LFRX +UHD to design a receiver, which works well to 
continuously receive data. I am trying to control the received data streaming 
using PPS to trigger received data storing, which is storing the received data 
into a data file for 1ms after receiver detecting the edge of the PPS signal 
every second. 

I tried the approach introduced in gnuradio apps, rx_timed_samples, detecting 
the PPS signal, then setup streaming, then filled meta-data by recv(). 
Eventually, I got to know stream_cmd and recv() are not swigged in gnuradio, 
which means it cannot be implemented in Python.

I got to know the USRP source already tags the samples with a timestamp and I 
do not need to control when streaming begins, because the downstream block 
determine the time of any sample using "metadata". 

1. I am wondering how to fill meta-data in Python if device.recv() is not 
swigged? I need to use the PPS signal to trigger the received data storage for 
1ms every second after detecting the edge of PPS signal every second.
I am using the follow setting method to detect the PPS signal:

    self.clk_cfg = uhd.clock_config()
    self.clk_cfg.pps_source = uhd.clock_config.PPS_SMA
    self.clk_cfg.pps_polarity = uhd.clock_config.PPS_NEG
    self._usrp2.set_clock_config(self.clk_cfg, uhd.ALL_MBOARDS)
    self._usrp2.set_time_unknown_pps(uhd.time_spec(0.0))

2. This PPS setting is done just after the usrp device is created. The PPS 
signal could be detected while usrp device is setup. I am also wondering if 
this approach could make usrp detect PPS signal every second or only once when 
the usrp device is setup?

Any suggestion will be really appreciated!! I am dying to know how this 
scheduling issue could work in Python.

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

Re: [Discuss-gnuradio] Maximum Ratio Combining

[Vanessa Gardellin]

Well, I am counting the number of received, lost and wrong packets.
Each packet is 1500 Bytes + header.

I will investigate better the problem. I sent this message to know if
there was any particular parameter that could affect the performance.

How did you compute the BER? So that I can do the same and see the results.

Thank you for your replay

BR,
Vanessa

On Wed, Nov 23, 2011 at 5:12 PM, Tom Rondeau  wrote:
> On Wed, Nov 23, 2011 at 11:08 AM, Vanessa Gardellin
>  wrote:
>>
>> Dear all,
>>
>> I am using the mrc implemented in gnuradio but my performance does not
>> improve compared with the case 1TX-1RX.
>> The parameters and devices are the same in both cases.
>>
>> Do you have any hint?
>>
>> Regards,
>> Vanessa
>
> Really? What's your performance metric?
> Matt and I didn't do a BER test or anything, but we looked at the
> constellations with 1x1 and 1x2 MRC and saw much less variance in noise with
> the MRC methods. We had to assume that meant better performance.
> Tom
>



-- 
Vanessa GARDELLIN, Ph.D.
Researcher
Institute for Informatics and Telematics (IIT),
Italian National Research Council (CNR)
Via G. Moruzzi 1
56124 Pisa - ITALY
Phone: +390503153267
Room: B65/c
E-mail: vanessa.gardel...@iit.cnr.it
WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
Skype: gardellin.vanessa

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

[Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes

[Nazmul Islam]

Hello All,

I am trying to measure packet error rates for different modulation schemes
using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2
dughterboard and I am using the UHD_003_002_001 image (That image was
downloaded on June, 2011 from the website, I believe). Now, I am getting
strange results in terms of packet error rate. The benchmark_rx codes don't
receive anything for d8psk modulation. It receives packets for dqpsk and
qbpsk,  but the work-ability depends on the inputs in a weird way. I am
listing down some of the results that I have observed for different
commands:

Scenario 1:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05
--gain-mu 0.01

Results: All packets receiverd.


Scenario 2:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05
--gain-mu 0.01

Results: All packets are received as false.( The only difference between
scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to
25).)


Scenario 3:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dqpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05
--gain-mu 0.01

Result: All packets are received as OK. (The difference between scenario 2
and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).)


Scenario 4:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m d8psk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05
--gain-mu 0.01

Result: No packet gets received. The receiver sits idle waiting for the
packets.


I observed my transmitted signal in the spectrum analyzer and I did not see
any carrier offset, i.e., the received signal was centered at 2.4 GHz. I
think that the error is coming from either over-saturation of transmission
signal or the costas-loop at the receiver. At present, I am simply walking
in the dark and trying random input values to make the schemes work. Is
there any suitable range for these options? (--tx-ampl, --tx-gain,
--costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know if any of
you have found a suitable range for these options. Your suggestions will be
valuable.

Thanks for reading the long email.

Nazmul



-- 
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Importing Grblock or not?

[Alex Zhang]

For the boost issue, unitl now, I think the most likely cause is due to
incorrect installation of my boost. I manually compiled a boost 1.47 and
copy the related lib files to the /usr/local/lib and /usr/lib. But the
ubunut 11.10 could have already built-in boost of the other older version.
If so, the confilict could happen. I need to verify if this is my problem.

I can successfully cmake/make/make install in anthother PC with a fresh
ubuntu 11.10, from the code of your next branch.


On Wed, Nov 23, 2011 at 9:44 AM, Josh Blum  wrote:

>
>
> > If I build and install the gnuradio based on your next branch, do we
> still
> > need use "import grblock" in the application code?
> >
>
> No, the old module "grblock" is gone, the work is now integrated into
> "gnuradio.gr". Did you see the examples here:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython#Some-quick-examples
>
> If you solve your build issue with boost, please let me know. I am
> interested to understand the cause.
>
> -Josh
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in gr_pll_carriertracking.cc

[Ben Hilburn]

Heh, sometimes you have to e-mail a public list before any of it makes
sense.  Happens to me all the time =)

Cheers,
Ben


On Wed, Nov 23, 2011 at 8:53 AM, Marcus M  wrote:

>
>
> On Wed, Nov 23, 2011 at 10:12 AM, Marcus M  wrote:
>
>> Hi,
>> I have the latest gnuradio release and I think the phase error
>> calculation in gr_pll_carriertracking.cc might be wrong.
>>
>> In Line 107 the phase error is calculated as,
>> error = phase_detector(iptr[i],d_phase);
>>
>> whereas, I think it should be as shown below as the phase error is
>> calculated from the signal that has been corrected in phase.
>> error = phase_detector(optr[i],d_phase);
>>
>> Am I right?
>>
>> My bad. The phase_detector() function returns the difference. Ignore this
> message.
>
> Thanks
>
> ___
> 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] Bug in gr_pll_carriertracking.cc

[Marcus M]

On Wed, Nov 23, 2011 at 10:12 AM, Marcus M  wrote:

> Hi,
> I have the latest gnuradio release and I think the phase error calculation
> in gr_pll_carriertracking.cc might be wrong.
>
> In Line 107 the phase error is calculated as,
> error = phase_detector(iptr[i],d_phase);
>
> whereas, I think it should be as shown below as the phase error is
> calculated from the signal that has been corrected in phase.
> error = phase_detector(optr[i],d_phase);
>
> Am I right?
>
> My bad. The phase_detector() function returns the difference. Ignore this
message.

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

Re: [Discuss-gnuradio] Gnuradio locking up

[Tom Rondeau]

On Tue, Nov 22, 2011 at 10:21 PM, Matt Mills  wrote:

>
>
> On Tue, Nov 22, 2011 at 11:28 AM, Philip Balister wrote:
>
>> You can use the single threaded scheduler by setting an environment
>> variable:
>>
>> export GR_SCHEDULER=STS
>>
>
>
> Gave this a shot; app runs for a while (at 100% CPU with quite a few
> overruns) then segfaults...
> [20077.594080] python[16760]: segfault at 8 ip b7478dc4 sp a862c09c error
> 6 in libc-2.11.1.so[b741c000+153000]
> and
> [21548.361453] python[15672]: segfault at 0 ip b74b9330 sp a9b6f0e0 error
> 4 in libc-2.11.1.so[b745a000+153000]
>

Since it's a segfault, I just added this to the FAQ on the wiki to explain
how to get more information:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python

Post the output of the backtrace to help us find out what's going wrong.

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

Re: [Discuss-gnuradio] DC offset removal

[Josh Blum]

On 11/23/2011 03:00 AM, Michael Höin wrote:
> Hi all
> 
> Is it possible to disable the automatic DC offset removal control loop in
> the FPGA to measure DC? In old posts I found the function
> "set_dc_offset_cl_enable". But if I try that, this function can not be
> found.
> 
> I use a USRP N210 with a LFRX board.
> 
> my code:
> .
> self.uhd_usrp_source_0 = uhd.usrp_source(
>  device_addr="",
>  stream_args=uhd.stream_args(
>  cpu_format="fc32",
>  channels=range(1),
>  ),
> )
> .
> self.uhd_usrp_source_0.set_dc_offset_cl_enable(0x0,0xF)
> .
> 


Can you give this a try?
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n254

Let me know if it works for you.

-josh

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

Re: [Discuss-gnuradio] Maximum Ratio Combining

[Tom Rondeau]

On Wed, Nov 23, 2011 at 11:08 AM, Vanessa Gardellin <
vanessa.gardel...@iit.cnr.it> wrote:

> Dear all,
>
> I am using the mrc implemented in gnuradio but my performance does not
> improve compared with the case 1TX-1RX.
> The parameters and devices are the same in both cases.
>
> Do you have any hint?
>
> Regards,
> Vanessa
>

Really? What's your performance metric?

Matt and I didn't do a BER test or anything, but we looked at the
constellations with 1x1 and 1x2 MRC and saw much less variance in noise
with the MRC methods. We had to assume that meant better performance.

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

[Discuss-gnuradio] Bug in gr_pll_carriertracking.cc

[Marcus M]

Hi,
I have the latest gnuradio release and I think the phase error calculation
in gr_pll_carriertracking.cc might be wrong.

In Line 107 the phase error is calculated as,
error = phase_detector(iptr[i],d_phase);

whereas, I think it should be as shown below as the phase error is
calculated from the signal that has been corrected in phase.
error = phase_detector(optr[i],d_phase);

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

[Discuss-gnuradio] Maximum Ratio Combining

[Vanessa Gardellin]

Dear all,

I am using the mrc implemented in gnuradio but my performance does not
improve compared with the case 1TX-1RX.
The parameters and devices are the same in both cases.

Do you have any hint?

Regards,
Vanessa

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

Re: [Discuss-gnuradio] Video of talk from Ruxcon 2011: Hacking the wireless world with Software Defined/GNU Radio

[Tom Rondeau]

On Wed, Nov 23, 2011 at 8:16 AM, Balint Seeber  wrote:

> Hi folks,
>
> ** **
>
> For Ruxcon 2011  I gave a 
> presentationat
>  the weekend covering some of the neat things you can do with SDR. In
> particular, I spoke about some of my recent projects that employ GNU Radio: 
> tracking
> aircraft using Mode S/ADS-B  in
> order to visualise your local airspace in web-streaming 3D, and creating a
> satellite communications demodulator using blind signal analysis.
>
> ** **
>
> I’ve uploaded a video of the talk and would like to share it with you:
>
> ** **
>
> http://www.youtube.com/watch?v=Vn-dpUegUDQ
>
> ** **
>
> If you wish to skip to a specific section, just open the description pane
> on the video’s page and jump to a time in the topic list.
>
> ** **
>
> During the course of these projects, I added and modified a number of
> GR/GRC blocks. In the coming days, I will consolidate the modifications to
> the GR source tree into a patch, and put ‘gr-baz’ on GitHub. The gr-baz
> package contains several new blocks, GRC block defs and Python scripts,
> e.g. for sat comms (automatic FEC parameter search, convolutional code
> (de-)puncturing, symbol swapping, raise-to-power, variable delay,
> text-file-dumper) and a seamless BorIP 
> sample source drop-in for the USRP 1 and 
> FUNcube Dongle to allow remote
> streaming and control over one’s LAN. I shall post the relevant info when
> it’s all up.
>
> ** **
>
> All comments are welcome!
>
> Balint
>
> http://wiki.spench.net/wiki/RF
>
> http://spench.net/
>
> @spenchdotnet 
>


Balint,
Great work, thanks! I'm looking forward to seeing your branch, and we'll
work to move your innovations into GNU Radio.

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

Re: [Discuss-gnuradio] Importing Grblock or not?

[Josh Blum]

> If I build and install the gnuradio based on your next branch, do we still
> need use "import grblock" in the application code?
> 

No, the old module "grblock" is gone, the work is now integrated into
"gnuradio.gr". Did you see the examples here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython#Some-quick-examples

If you solve your build issue with boost, please let me know. I am
interested to understand the cause.

-Josh

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

[Discuss-gnuradio] Video of talk from Ruxcon 2011: Hacking the wireless world with Software Defined/GNU Radio

[Balint Seeber]

Hi folks,

 

For Ruxcon 2011   I gave a presentation
  at the weekend covering some of the neat things you can do with SDR. In
particular, I spoke about some of my recent projects that employ GNU Radio:
tracking aircraft using Mode S/ADS-B
  in order to visualise your local
airspace in web-streaming 3D, and creating a satellite communications
demodulator using blind signal analysis.

 

I've uploaded a video of the talk and would like to share it with you:

 

http://www.youtube.com/watch?v=Vn-dpUegUDQ

 

If you wish to skip to a specific section, just open the description pane on
the video's page and jump to a time in the topic list.

 

During the course of these projects, I added and modified a number of GR/GRC
blocks. In the coming days, I will consolidate the modifications to the GR
source tree into a patch, and put 'gr-baz' on GitHub. The gr-baz package
contains several new blocks, GRC block defs and Python scripts, e.g. for sat
comms (automatic FEC parameter search, convolutional code (de-)puncturing,
symbol swapping, raise-to-power, variable delay, text-file-dumper) and a
seamless BorIP   sample source drop-in
for the USRP 1 and FUNcube Dongle to allow remote streaming and control over
one's LAN. I shall post the relevant info when it's all up.

 

All comments are welcome!

Balint

http://wiki.spench.net/wiki/RF

http://spench.net/

@spenchdotnet  

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

[Discuss-gnuradio] DC offset removal

[Michael Höin]

Hi all

Is it possible to disable the automatic DC offset removal control loop in
the FPGA to measure DC? In old posts I found the function
"set_dc_offset_cl_enable". But if I try that, this function can not be
found.

I use a USRP N210 with a LFRX board.

my code:
.
self.uhd_usrp_source_0 = uhd.usrp_source(
 device_addr="",
 stream_args=uhd.stream_args(
 cpu_format="fc32",
 channels=range(1),
 ),
)
.
self.uhd_usrp_source_0.set_dc_offset_cl_enable(0x0,0xF)
.

Any help will be appreciated.

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