Re: [Discuss-gnuradio] looping with work() function

[Activecat]

Dear Sumedha,

My idea is to create a custom block of type "general".
This block takes an input from a File Source. It has an output connect
to USRP (for transmitting signal).
It has another input port connected to USRP for receiving ACK.

See below inline answers for further elaboration.

On Thu, Mar 13, 2014 at 1:42 PM, Sumedha Goyal  wrote:
>> Hi Activecat,
>
> This is true that I am trying to accomplish the same task that you have
> mentioned . But the difference is:
>
> 1. I pass a threshold value to my "test_demo" block from the
> "top_block"(Example: top_block(options, 0.4)). A random number is generated
> inside the "test_demo" block and compared to this threshold.
> 2. If the random number is more than threshold, the transmission process
> starts.

We make this threshold value an argument to the constructor of the
custom block. The block will store this threshold value as its class
variable.
The random number could be generated inside the general_work() function.
Hence, before transmission of packet starts, a random number will be
generated each time the general_work() is called.
If the random number is lower than the threshold, then the
general_work() just return without performing any other action.
But make sure the returned value will make this general_work() to be
continuously called repeatedly.

> 3. The block makes transmitter USRP to send data packets in a specified
> format(source_address+destination_address+packet_sequence_no+message).
> 4. Upon receiving a packet, the receiver USRP sends an ACK.

Hence the transmitting USRP needs to have the hardware capability to
receive signal.  We feed this signal from USRP back to the custom
block.
In alternative, you could use the 3rd USRP attaching to PC#1 to
receive the ACK, but this is not likely the preferable way.

> 5. Meanwhile, the transmitter USRP counts number of data packets sent before
> receiving an ACK. As soon as the transmitter USRP receives first ACK, it
> should stop data transmission and reception of further packets from anywhere
> (from the user payload from a file source on harddisk).

Data packet counting can be done on this custom block.
When not transmitting data packets, the output of the block to USRP is
just a series of zeros.
We need to set_max_noutput_items() to a small value, so that the block
response fast enough to the ACK signal.
This block should continuously consuming input from USRP (to detect
ACK) while sending output (either data packets, or a series of zero)
to the USRP.
I think these two ports (the input and output connecting to USRP)
should have the same data rate as they are connecting to the same
USRP.

> 6. At this point, I want to be able to change the threshold value for the
> block and start the process again. The random number will be generated again
> and so on.

Without interrupting the flow graph, we can change this threshold
value using WX GUI Slider, because the threshold value is stored as a
class variable of the custom block.

> 7. I want to continue this process for several number of times and plot a
> graph between the threshold and the number of packets transmitted.

As the custom block is doing the counting of data packets, it can save
the packet counts information into a file. You could later retrieve
data from this file to plot graph, after stopping the flow graph.
If you insist to plot graph in real time, then this block could send
the packet counts information to another output port.  Be careful here
because all output ports must have same data rate. Nevertheless there
is a workaround for overcome this issue.

>
> How should I proceed?

If this confirms what you want, I could then send you a sample code.
Make sure the requirements is correct first.

Additional question to you:
When PC#1 transmit packets, PC#2 may miss the few packets before
detecting the first one.
That's why you want PC#1 to count the number of packets transmitted
before receiving ACK.
But have you ever think that, the ACK sent by PC#2 may also be missed
out by PC#1.
Then how would you handle this ..?

Regards,
Activecat

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

Re: [Discuss-gnuradio] Running Flowgraph some a certain period of time

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ruecan,

On 12.03.2014 22:52, Ruecan wrote:
> Hello GR,
> 
> * Is there a way how to run my flowgraph for a given number of 
> minutes/seconds then stop it.
Of course.
If what you really want to do is doing a certain number of samples,
the head block is what you need.

If your end condition really comes from outside, you should use
something like topblock.start(), [wait 5s, e.g. using time.sleep()],
toblock.stop(), topblock.wait()
> 
> * I'd like to know too how to reconfigure my flowgraph (after I
> stop it from runtime) and resume its run after I changed for
> example the signal source at the begin of the flowgraph.

> 
> I tried:
> 
> My_flowgraph Description
> 
> def MyRoutine(args): global tb . if (condition): tb.stop() 
> myModifiedflowgraph.myModifiedflowgraph(args) . . ..
> 
> if __name__ == '__main__': global tb . . 
> threading.Timer(10,myRoutine).start() tb.Run(True)
> 
> My point here is that I need to run myModifiedflowgraph for a
> certain period of time then stop it and resume tb. FYI
> myModifiedflowgraph is the name of the other py script which
> contain the modifiedflowgraph called also myModifiedflowgraph. Any
> hints or explanations are well appreciated
> 
This is not really reconfiguration, as far as I understand your
architecture. It is stopping and starting two different flowgraphs -
which is ok in theory, but you have to find a way to share the
hardware between the two. Which usually defeats the purpose of having
reconfigurable flowgraphs-adjusting your receiver structure to
changing environment.
In this case, it might be a good choide to disconnect() only the
blocks in tb that need to be replaced and connect() the new ones.

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

iQEcBAEBAgAGBQJTIWsRAAoJEBQ6EdjyzlHtq3gIAIfEwZNuSgL9iZxETuy1i8Wa
9eAk5I2SQ2gyFSFKXlizeYTTZ9apCC81VD3fMYt8foYfVcEY+TL4orOFTUbrbeok
VD6+T8/gLxErnYa37YiYXZBRjIX7SzFdrLt2eiUZBHMF0HDi4RJzJM594SBnDNyI
OvqtY1pTcW+B4OEVS+BZgI/pj8zj6TrP+0Mg3JiyzKMoi4Yhvf3fcFQ9PXPmk7gW
58lzl8GRFBi0Cexi9Q56pyaM1MqPJ0kflfz8rSydQjmS5b4HfuQk9VS6FT4P008e
E0Vg0H71iNYXW83a0ZvbT9K5lXPvUdIGW/pQw9yY21OdqckKtezq64MzHQ6pwfc=
=TSGr
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] RX Channel Out Of Range

[Martin Braun]

On 13.03.2014 02:00, Azza Ben Mosbah wrote:

Hi Ben,

Actually, I didn't copy them from another flowgraph.
But, I noticed there is a problem with my PYTHONPATH, which generates
this error. When I correct it, the execution goes well.


Interesting -- could you please give some details on what the problem 
was and what you did to fix it?


Martin

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

Re: [Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm

[zhenhua han]

The figure in the previous mail is incorrect.
It is too weird that the ratio is so low and with narrow transition. And
the sample count is not match the FB.

After some debugs, I found the reason. I got the sample data with GNU Radio
companion. When I execute the flow graph, it starts to write data into the
file before my RTL-SDR started. So there are lots of invalid samples at the
start.

I have fixed this bug. Here is a correct (maybe :) ) figure. The sample
rate is 1.25M sps. The FCCH burst lasts about 700 samples which equals 0.56
ms. The duration of a standard FB is 0.57 ms. It seems correct.

I have updated this part in my proposal. Sorry for my mistakes.[image: 内嵌图片
1]


Best,
Zhenhua


2014-03-13 11:27 GMT+08:00 zhenhua han :

> Oh, I forgot to say. The data is sampled by a RTL-SDR.
>
> Zhenhua
>
>
> 2014-03-13 11:25 GMT+08:00 zhenhua han :
>
> Hi,
>>
>> I have implemented the algorithm in the paper for test and uploaded my
>> code to github.
>>
>> https://github.com/hzhua/gr-fchdetection
>>
>> The result given by the algorithm seems great.
>>
>> Here is a figure generated by my program which is the ratio of average
>> error power to input power. It is very low at frequency burst and high at
>> other bursts.
>> [image: 内嵌图片 1]
>> I have also added this part in my proposal.
>>
>> Best,
>> Zhenhua
>>
>>
>>
>> 2014-03-11 21:41 GMT+08:00 Bogdan Diaconescu :
>>
>> I totally agree with Martin regarding PFB channelizer. The PFB for gsm
>>> will be also a good challenge for gnuradio in general as obtaining only a
>>> moderate number of channels(say 50) takes a lot of processing power and
>>> achieving realtime processing is not possible currently. Split per thereads
>>> and VOLK should be taken in consideration.
>>>
>>> Bogdan
>>>
>>>
>>>
>>>
>>>
>>>   On Tuesday, March 11, 2014 2:30 PM, Martin Braun <
>>> martin.br...@ettus.com> wrote:
>>>   On 03/11/2014 11:14 AM, zhenhua han wrote:
>>> > -- Forwarded message --
>>> > From: *zhenhua han* mailto:hzhua...@gmail.com>>
>>> > Date: 2014-03-11 16:00 GMT+08:00
>>> > Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
>>> > To: Bogdan Diaconescu >> > >
>>> >
>>> >
>>> > Thank you, Bogdan. Your work is a great help in developing the channel
>>> > hopping part.
>>> > As there are only 14 weeks in GSoC, the schedule is a little tight.
>>> > However, I will continue working on this project after GSoC (if I am
>>> > selected). And Channel hopping will be the first task after I finish
>>> all
>>> > the tasks planned in GSoC.
>>>
>>> You should definitely check out the PFB channelization, though. For
>>> multi-ARFCN applications, this will always be a requirement.
>>>
>>>
>>> M
>>>
>>>
>>> ___
>>> 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

[Discuss-gnuradio] GSOC 14 proposal for project "Vector Network Analyzer"

[MITUL VEKARIYA]

Hi
Here's the link for my proposal for the project "Vector Network Analyzer"
https://docs.google.com/file/d/0B5wp9A_w2B5scmVKOTlGbVFISm8/edit?pli=1

You can post comment on google doc also.
I am all ears to any suggestion.

Thanks
Mitul Vekariya
Institute of Technology
Nirma University
Ahmedabad 382350
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GSoC'14 draft proposal - MIMO Transceiver

[kunal sankhe]

Hello,

Here's the link for my proposal for the project "MIMO Transceiver"
https://github.com/kunal2904/GSoC-14

Please let me know your feedback on this.

Thanks and regards,
Kunal Sankhe
IIIT Hyderabad, India
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSOC 2014 - Automatic Filter Optimization

[Tom Rondeau]

On Wed, Mar 12, 2014 at 6:23 PM, Sujath Nair  wrote:
> Hi everyone,
>
> I'm Sujath Nair, doing my Masters from Indian Institute of Technology,Bombay
> in the field of Communication and Signal Processing.I'm interested in the
> project of Automatic Filter optimization in Gnuradio. I have experience in
> c++,python ,matlab and gnuradio.
> I'm interested in this project because my thesis is based on design of
> filter banks and their applications.So i think this project will really help
> me understand the physical implementation of DSP filters and their
> optimization in Gnuradio.I also have done courses in signal processing and
> have experience working on TMS320vc5515 DSP Processors.
>
>
> Please guide me on this matter.
>
> --
> Sujath S Nair


Hi Sujath,

Make sure you've read the GSoC material on gnuradio.org. See the
mailing list message from Michael Dickens this past week for the links
and further information. Other than that, get your proposal together
as soon as you can so we can start discussing it.

Tom

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

Re: [Discuss-gnuradio] change center freq of usrp_source block automatically in incremental way

[Tom Rondeau]

On Wed, Mar 12, 2014 at 7:26 PM, MITUL VEKARIYA <10bec...@nirmauni.ac.in> wrote:
> Hi
> I want to make block diagram in grc such that the center freq of usrp_source
> should be automatically changed in incremental way defined by min and max
> boundary. I don't want to take input from qt-qui slider.
> Just like the example of usrp_spectum_sense.py but in grc.
> How can I do that?
>
> Thanks
> Mitul Vekariya

That's a good question. You can maybe create a variable that's a
simple Python function to update it's value (the frequency) after a
timeout.

That reminds me that I wanted to implement a GRC function block so we
can define multi-line functions in a GRC graph, which would be much
more useful for something like this. Never made it from my head to an
implementation, though.

Tom

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

[Discuss-gnuradio] GRC issues with GNU Radio 3.7

[Ruecan]

Hello GR,

I just installed GR 3.7 on my Centos 6.5 machine, everything I done is ok (I
set the env. var. after accordingly). 
But when I run gnuradio-companion I got a bunch of errors appearing in the
terminal:

*Error: 'DrawingArea' object has no attribute 'set_can_focus'*
>>> Failure
Traceback (most recent call last):
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
line 188, in new_page
file_path=file_path,
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/NotebookPage.py",
line 82, in __init__
self.drawing_area = DrawingArea(self.get_flow_graph())
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/DrawingArea.py",
line 66, in __init__
self.set_can_focus(True)
*AttributeError: 'DrawingArea' object has no attribute 'set_can_focus'*
Traceback (most recent call last):
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 357, in _handle_action
self.main_window.reports_scrolled_window.set_visible(visible)
AttributeError: 'gtk.ScrolledWindow' object has no attribute 'set_visible'
Traceback (most recent call last):
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 361, in _handle_action
self.main_window.btwin.set_visible(visible)
AttributeError: 'BlockTreeWindow' object has no attribute 'set_visible'
Traceback (most recent call last):
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 489, in _handle_action
Actions.ERRORS_WINDOW_DISPLAY.set_sensitive(not
self.get_flow_graph().is_valid())
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
line 304, in get_flow_graph
return self.get_page().get_flow_graph()
*AttributeError: 'NoneType' object has no attribute 'get_flow_graph'
*^CTraceback (most recent call last):
  File "~/gnuradio-3.7_install/bin/gnuradio-companion", line 72, in 
ActionHandler(args, Platform())
  File
"~/gnuradio-3.7_install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
line 72, in __init__
gtk.main()

And the window of grc appears but empty nothing inside just gray. 
BTW the menu bar appears but the blocks, output and the main windows does
not.
Trying to click close or click on any button of the menu bar give no result.
One need to close the graph by Ctl+C in the terminal.

Any hints or help is well appreciated.

Regards,
Ruecan



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-issues-with-GNU-Radio-3-7-tp46935.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] gr-osmosdr - No RTL2832 Source Block

[spam9642]

Hi List,

I've recently been trying to get gnuradio-3.6.5 to talk to my RTL2832-based
tuner dongle.  I installed gr-osmosdr, and all of the blocks seem to load
fine in gnuradio-companion.  Except for one, the rtl2832 source block. 
Every time I run some code that uses osmosdr.source, I end up with this
traceback:

Traceback (most recent call last):
  File "./rtl_flex_noX.py", line 123, in 
tb = app_top_block(options, queue)
  File "./rtl_flex_noX.py", line 45, in __init__
self.u = osmosdr.source( args="%s"%(options.device) )
AttributeError: 'module' object has no attribute 'source'

I tried installing gr-baz (as per this post on Reddit: 
http://www.reddit.com/r/RTLSDR/comments/sn4t2/how_does_one_get_rtl_as_source_in_gnu/)

  
and I had zero luck whatsoever trying to get it to work.  I did some further
digging regarding what functions were available in osmosdr using
dir(osmosdr) in Python and got this:

['SwigPyIterator', 'SwigPyIterator_swigregister', '_RTLD_GLOBAL',
'__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__path__', '_dlopenflags', 'device', 'device_find', 'device_swigregister',
'device_t', 'device_t_swigregister', 'devices_t', 'devices_t_swigregister',
'meta_range_t', 'meta_range_t_swigregister', 'osmosdr_sink_c_sptr',
'osmosdr_sink_c_sptr_swigregister', 'osmosdr_source_c_sptr',
'osmosdr_source_c_sptr_swigregister', 'osmosdr_swig', 'range_t',
'range_t_swigregister', 'range_vector_t', 'range_vector_t_swigregister',
'sink_c', 'source_c', 'string_string_dict_t',
'string_string_dict_t_swigregister', 'string_vector_t',
'string_vector_t_swigregister', 'sys']

Oddly enough there was a function called source_c, but no function called
source.  When I make gr-osmosdr with cmake, these are the enabled and
disabled components:

-- ##
-- # gr-osmosdr enabled components 
-- ##
--   * Python support
--   * sysmocom OsmoSDR
--   * IQ File Source
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * RFSPACE Receivers
-- 
-- ##
-- # gr-osmosdr disabled components
-- ##
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * FUNcube Dongle Pro+
--   * Ettus USRP Devices
--   * Osmocom MiriSDR
--   * HackRF Jawbreaker
--   * nuand bladeRF
--   * AIRSPY Receiver

Is osmosdr.source() in one of the disabled components? If so, what
dependencies do I need to install to get that component to work?  I can't
seem to find any straightforward information as to what dependencies I need
to get all the components to work.

I've been working on this for the past week and I have had little luck, so
any help will be greatly appreciated :)



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-osmosdr-No-RTL2832-Source-Block-tp46936.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] adding meta-sdr to openembedded

[Richard Cagley]

I have a basic bblayers.conf with one layer
BBLAYERS ?= " \
  /home/rcagley/oe-zed/openembedded-core/meta \
"

I've initialized the build system
. ./oe-init-build-env ../build/ ../bitbake/
and then I've bitbaked
bitbake core-image-minimal

That all works fine. Now I want to add in the meta-sdr layer. If I just add
the meta-sdr layer to the bblayers.conf file and rerun the bitbake
core-image-minimal nothing seems to happen. Do I need to specify a
different recipe?

Here is my full bblayers.conf

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/rcagley/oe-zed/openembedded-core/meta \
  /home/rcagley/oe-zed/meta-sdr \
  "

BBLAYERS_NON_REMOVABLE ?= " \
  /home/rcagley/oe-zed/openembedded-core/meta \
  "
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] adding meta-sdr to openembedded

[Richard Cagley]

On Thu, Mar 13, 2014 at 5:24 PM, Richard Cagley  wrote:

> I have a basic bblayers.conf with one layer
> BBLAYERS ?= " \
>   /home/rcagley/oe-zed/openembedded-core/meta \
> "
>
> I've initialized the build system
> . ./oe-init-build-env ../build/ ../bitbake/
> and then I've bitbaked
> bitbake core-image-minimal
>
> That all works fine. Now I want to add in the meta-sdr layer. If I just
> add the meta-sdr layer to the bblayers.conf file and rerun the bitbake
> core-image-minimal nothing seems to happen. Do I need to specify a
> different recipe?
>
> Here is my full bblayers.conf
>
> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> LCONF_VERSION = "5"
>
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
>
> BBLAYERS ?= " \
>   /home/rcagley/oe-zed/openembedded-core/meta \
>   /home/rcagley/oe-zed/meta-sdr \
>   "
>
> BBLAYERS_NON_REMOVABLE ?= " \
>   /home/rcagley/oe-zed/openembedded-core/meta \
>   "
>
>
I should also say that I've now found this
http://gnuradio.org/redmine/projects/gnuradio/wiki/Meta-SDR

but it throw a bunch of errors when I issue the bitbake command.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Support e-mails to supp...@ettus.com

[Marcus D. Leech]

Folks:

I've been on the road for the last 8 days, and I just got back this 
evening.  Any of you who are waiting for a reply from supp...@ettus.com, 
I'll

  be working my way through the back-log tomorrow.

Not ignoring you, just was on the road.

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


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

Re: [Discuss-gnuradio] gr-osmosdr - No RTL2832 Source Block

[Sylvain Munaut]

Hi,

osmosdr.source is the name in gnuradio 3.7.x version
osmosdr.source_c is the name in gnuradio 3.6.x version

Are you sure your application is compatible with gnuradio 3.6.x ?


Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] Controlport error in GRC

[sarankumar]

Hi,

Thanks. Rebuilding Pybombs with Ice 3.5.0 helped.

Regards,
Saran



On Wed, Mar 12, 2014 at 9:13 PM, Tim  wrote:

> If you built GNU Radio under pybombs, you can also run
> ./pybombs rb gnuradio
> this alias (rebuild) will blow away the build dir and re-run
> cmake/make/install for you with the proper environment set up
> don't forget to rebuild everything that links against gnuradio afterwards
> (any OOT modules you may have)
> -Tim
>
>
> On 03/12/2014 09:05 AM, Tom Rondeau wrote:
>
>> On Wed, Mar 12, 2014 at 1:12 PM, sarankumar  wrote:
>>
>>> hi,
>>> I removed version Ice3.5.1 and built Ice 3.5.0. But now GRC cannot detect
>>> Ice:
>>>
>>> from gnuradio.ctrlport.monitor import *
>>>File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/__init__.py",
>>> line
>>> 23, in 
>>>  import Ice, IcePy
>>> ImportError: No module named Ice
>>>
>>> do I need to build PyBombs again for gnuradio to detect Ice?
>>>
>>> regards,
>>> Saran
>>>
>> Remove CMakeCache.txt from your build directory and rerun cmake with
>> the ICE_MANUAL_INSTALL_PATH set. Also make sure PYTHONPATH and
>> LD_LIBRARY_PATH are set properly to the location of the ICE 3.5.0
>> installation.
>>
>> Tom
>>
>>
>>
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoc2014 gr-trellis/turboeq proposal

[kraemer]

Hey,

an updated version of my GSoC proposal is now on available:

https://github.com/SpectreJan/GSoC2014

Regarding work that I have done in the past:
Parts of the code of my current master thesis project (Log-MAP decoder
with OpenCL) is now available on Github.

https://github.com/SpectreJan/cel_gpu_logmap
This is also included in my proposal.

I also have done some work on getting a non-proprietary linux distribution
on the Lyrtech SFF-SDR. A small compendium is available on the
Communication Engineering Lab website. But it is in German, as it was
initially meant as a CEL intern manual only. But maybe Phil might enjoy
this ;)

http://www.cel.kit.edu/lyrtech.php

best regards,
Jan


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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Sylvain Munaut]

Hi,


> I try to send square wave from one USRP to another.
> The received signal at the receiver USRP is very different from what
> was being sent.

> This is just a very simple setup. What could be wrong ..?

Apparently your understanding of how things work :)

First thing, square waves have infinite bandwidth, the DAC can't
generate them properly, the ADC can't capture them properly and
they'll be modified by the IF filters. The effect of that is to "round
off the edges". And since you sample at 32k, that's probably going to
be fairly visible.

Then the second and major thing is that I & Q aren't magically
transmitted and received perfectly aligned. Unless you use the _exact_
same totally phase aligned LO and ensure the propagation delay to have
the ADC sample exactly on your DAC transmitted symbols, the I & Q you
receive won't be the I & Q you transmit, you'll have random time and
phase alignement.


That's kind of why people use modulation rather than TX raw binary waveforms.


Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Johnathan Corgan]

On 03/13/2014 09:32 PM, Activecat wrote:

> I try to send square wave from one USRP to another.
> The received signal at the receiver USRP is very different from what
> was being sent.
> This is just a very simple setup. What could be wrong ..?

What you are seeing is a classic case of frequency/phase offset between
the transmitter and receiver, introducing a "rotation" in the I/Q domain
at baseband equal to the difference frequency.

In spite of "calibrating" things, you have only made the transmitter and
receiver local oscillator frequencies "close".  All real-world receivers
must implement a correction loop to estimate this frequency and
compensate for it, which eliminates the rotation.  This correction loop
often takes the form of a phase-locked loop, of which there are several
in GNU Radio.  For the type of waveform you are transmitting, the "PLL
Carrier Tracking" loop should work, as your baseband waveform results in
significant carrier energy when upconverted to passband.

Also, the amplitude of the data you are transmitting at baseband is
likely too high; you can see evidence of numerical overflow in the
received signal.  I suggest you limit the amplitude of the square wave
baseband waveform to +-0.7; this prevents the magnitude of the signal
exceeding 1.0 in the CORDIC stage of the DUC in the USRP.

If any of the above concepts are unfamiliar to you, there are excellent
references in the Suggested Reading page on the GNU Radio wiki.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com



<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

Dear Sylvain,

>On Fri, Mar 14, 2014 at 2:17 PM, Sylvain Munaut <246...@gmail.com> wrote:
> First thing, square waves have infinite bandwidth, the DAC can't
> generate them properly, the ADC can't capture them properly and
> they'll be modified by the IF filters. The effect of that is to "round
> off the edges".

I am using Ettus SBX daughtercard at the transmitter USRP to transmit
complex square wave (means the signal is in IQ form).
https://www.ettus.com/product/details/SBX
I understand that SBX performs quadrature up-conversion automatically,
and this feature cannot be disabled.
Hence, the signal sent to the transmitter antenna is no longer square
waves, but IQ up-converted signal.
That's why I guess the "round off the edges" effect is no longer
applicable here.

At the receiver side, another SBX daughtercard should have
automatically down-converted the signal back into IQ form.
Here I expect the signal output from SBX become (nearly) square wave.

> And since you sample at 32k, that's probably going to
> be fairly visible.

I repeat the test with sampling rate changed to 1MHz at both sides,
this gain similar undesirable result.

> Then the second and major thing is that I & Q aren't magically
> transmitted and received perfectly aligned.

Now I am focusing on the frequency and phase alignment issue.

Thank you very much.

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