Re: [Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error

[bob wole]

On Thu, Aug 6, 2015 at 12:44 AM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 2:07 AM, bob wole  wrote:
>
>> Ubuntu 14.04 64-bit
>> Gnuradio 3.7.8rc1
>>
>>
>> I am running this flowgraph "fecapi_async_to_stream.grc" that comes with
>> gr-fec. After running for a while following error always show up
>>
>> 
>> 
>> DEBUG: 16384, 560, 272
>> DEBUG: 16384, 560, 272
>> FATAL: Missing a required length tag on port 0 at item #14965440
>> thread[thread-per-block[7]: ]: Missing
>> length tag.
>>
>> The only thing that changes is the item#.
>> Testing further 
>>
>>
>> --
>> Bob
>>
>
> Bob,
>
> You led us down a buggy path on that one. This, I'm pretty sure, is
> related to Richard Bell's problem for a few weeks ago where adding a time
> sink caused problems in his data stream. I have to say, I kind of dismissed
> that as impossible, but nope, it's a real problem.
>
> The problem isn't with the GUI sinks; you can replace them with null sinks
> and you get the same problem. It's a race condition in our tag pruning
> method that was changed in 3.7.6. We have a patch that we're putting in now
> that will be part of 3.7.8.
>
> The patch goes backwards a bit to how tag pruning was originally done.
> However, with the map, we no longer have to restart the iterator at begin()
> like we used to, and we can terminate early, so this should still be much
> faster than the original.
>
> Tom
>
>
>
Tom,

Thanks for the update. Which block exactly is causing this? Should I wait
for version 3.7.8 then?


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

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>
>>
>> > There is a directory
>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>> >
>>> >
>>> > where you in controlport related stuff.
>>> >
>>> > - - Volker
>>> >
>>> >
>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>> >
>>> > Dear Bob,
>>> >
>>> > A few months ago, I've asked a similar question (
>>> > <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> >
>>> >
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> )
>>> >
>>> > and Tom gave me his paper in SIGCOMM.
>>> >
>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>> Counters
>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>> >
>>> > You can get one in
>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>> >
>>> > It does not fully describe how it can be used, though, through this you
>>> > can get a hint.
>>> >
>>> > Regards,
>>> > Jeon.
>>> >
>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>> >
>>> >> Ubuntu 14.04 64-bit
>>> >>
>>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
>>> >> fetched gnuradio using
>>> >>
>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>> >>
>>> >>
>>> >>  Gnuradio enabled component shows
>>> >>
>>> >> * gr-ctrlport
>>> >> * * thrift
>>> >>
>>> >> However, I do not see any *gr-ctrlport directory *inside the gnuradio
>>> >> directory. Where is the source code for control port? Also there are
>>> no
>>> >> examples for using control port.
>>> >>
>>> >> --
>>> >> Bob
>>> >>
>>> >
>>> You can find more information on these two pages:
>>>
>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>
>>>
>>> ControlPort was reintroduced just after the 3.7.7 release so we had time
>>> to
>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>> manual
>>> page linked above is from our weekly development builds.
>>>
>>> This points you to two apps that are installed with ControlPort:
>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for
>>> usage is in our QA code. Look in gr-blocks
>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>>> and qa_ctrlport_probes.py.
>>>
>>> Tom
>>>
>>>
>>>
>> ControlPort is written in python ?
>>
>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first time.
>> Then I ran the other two qa codes they passed successfully without any core
>> dump. When I ran qa_ctrlport_probes.py again it passed successfully.
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 57403
>> .
>> --
>> Ran 5 tests in 0.509s
>>
>> OK
>> *Segmentation fault (core dumped)*
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py
>> INFO: Apache Thrift: -h sdr-dev -p 35595
>> ..
>> --
>> Ran 2 tests in 0.105s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py
>> INFO: Apache Thrift: -h sdr-dev -p 38301
>> ..
>> --
>> Ran 2 tests in 0.134s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 38644
>> .
>> --
>> Ran 5 tests in 0.511s
>>
>> OK
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 48394
>> .
>> --
>> Ran 5 tests in 0.510s
>>
>> OK
>>
>>
>> What could be the cause?  I thought I should share because it is a new
>> release and is in testing stage.
>>
>>
>> --
>> Bob
>>
>
> There is a bug in Thrift 0.9.2 that I'm going to guess is the cause of
> that seg fault. See our notes on building Thrift and the patch that we have
> for it:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>
> I believe that patch has been accepted, but after the 0.9.2 release.
>
> Tom
>
>

I am going to apply the patch to thrift. Should I remove and reinstall
gnruadio too after applying patch.


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

Re: [Discuss-gnuradio] gr-perf-monitorx Error

[bob wole]

On Wed, Aug 5, 2015 at 6:44 PM, Tom Rondeau  wrote:

> On Wed, Aug 5, 2015 at 4:47 AM, bob wole  wrote:
>
>>
>> I am here again.  I ran "fecapi_async_decoders.grc" with controlport
>> performance moniter on. I made a new config.conf file in ~/.gnuradio and
>> added following lines to it
>>
>> [ControlPort]
>> on = True
>> edges_list = True
>> [PerfCounters]
>> on = True
>> export = True
>>
>>
>>
>> When I ran the flowgraph I got the following error
>>
>> Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"
>>
>> Using Volk machine: avx_64_mmx_orc
>> ControlPort Monitor running.
>> INFO: Apache Thrift: -h sdr-dev -p 50883
>> monitor::endpoints() = -h sdr-dev -p 50883
>> running: ['gr-perf-monitorx', 'sdr-dev', '50883']
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gr-perf-monitorx", line 902, in 
>> MyApp(sys.argv)
>>   File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
>> GNURadioControlPortClient(args, 'thrift', self.run,
>> QtGui.QApplication(sys.argv).exec_)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
>> line 125, in __init__
>> callback(self.client)
>>   File "/usr/local/bin/gr-perf-monitorx", line 900, in run
>> MAINWindow(client).show()
>>   File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
>> self.newCon(radioclient)
>>   File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
>> child = MForm(self.radioclient, len(self.conns), self, dialogprompt =
>> not csomeBool)
>>   File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
>> self.pos = nx.graphviz_layout(self.G);
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 257, in graphviz_layout
>> return pydot_layout(G=G,prog=prog,root=root,**kwds)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 271, in pydot_layout
>> pydot = load_pydot()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
>> line 47, in load_pydot
>> raise ImportError(msg)
>> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/
>>
>> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
>> ubuntu 14.04.
>>
>>
>> --
>> Bob
>>
>
> Did you try to install pydot?
>
> sudo apt-get install python-pydot
>
> Tom
>
>

Hi,

Thanks, after installing pydot, the flowgraph is working fine. A warning
though, but I think that can be ignored?

 WARN: asynchronous message buffer overflowing, dropping message

There is one thing more. I clicked somewhere in the graph view of
performance monitor and following error came, I tried to replicate it but I
was not successful.

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4.py",
line 299, in resizeEvent
self.draw()
  File
"/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4agg.py", line
155, in draw
self.update()
RuntimeError: wrapped C/C++ object of type FigureCanvasQTAgg has been
deleted
ctrlport.monitor received shutdown signal
calling stop on shutdown
calling stop on shutdown
pure virtual method called
terminate called without an active exception

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

Re: [Discuss-gnuradio] Channel Model

[monika bansal]

Hii
Thanks for your responses.

The problem is this channel model is eating some initial 6 bits(3 qpsk
symbols) and last 10 bits(5 qpsk symbols).
 Because of this index of output symbol is different fron input which is
resulting in error for all snr ranges.
 You can see the output for noise_volage =0.0

Input =  (0L, 0L, 2L, 3L, 1L, 2L, 1L, 1L, 2L, 3L, 0L, 1L, 0L, 1L, 1L, 3L,
2L, 3L, 1L, 0L, 2L, 0L, 3L, 2L, 2L, 1L, 3L, 2L, 3L, 0L, 2L, 2L, 0L, 1L, 2L,
3L, 3L, 0L, 2L, 2L, 0L, 2L, 3L, 3L, 2L, 2L, 3L, 0L, 0L, 0L, 1L, 0L, 2L, 2L,
2L, 0L, 3L, 0L, 1L, 1L, 3L, 0L, 1L, 3L, 3L, 3L, 0L, 0L, 2L, 0L, 1L, 1L, 0L,
2L, 3L, 2L, 2L, 3L, 2L, 3L)

Output = (3L, 1L, 2L, 1L, 1L, 2L, 3L, 0L, 1L, 0L, 1L, 1L, 3L, 2L, 3L, 1L,
0L, 2L, 0L, 3L, 2L, 2L, 1L, 3L, 2L, 3L, 0L, 2L, 2L, 0L, 1L, 2L, 3L, 3L, 0L,
2L, 2L, 0L, 2L, 3L, 3L, 2L, 2L, 3L, 0L, 0L, 0L, 1L, 0L, 2L, 2L, 2L, 0L, 3L,
0L, 1L, 1L, 3L, 0L, 1L, 3L, 3L, 3L, 0L, 0L, 2L, 0L, 1L, 1L, 0L, 2L, 3L)


Input = (0L, 1L, 0L, 2L, 0L, 1L, 1L, 3L, 2L, 3L, 3L, 1L, 0L, 2L, 2L, 0L,
0L, 1L, 1L, 1L, 0L, 0L, 3L, 2L, 3L, 1L, 1L, 2L, 1L, 0L, 3L, 0L, 0L, 0L, 3L,
0L, 3L, 2L, 1L, 0L, 3L, 1L, 3L, 1L, 1L, 3L, 1L, 2L, 0L, 1L, 0L, 3L, 1L, 0L,
3L, 2L, 1L, 2L, 3L, 3L, 2L, 1L, 3L, 0L, 1L, 2L, 3L, 3L, 0L, 0L, 0L, 2L, 3L,
3L, 1L, 3L, 3L, 1L, 0L, 3L)

Output = (2L, 0L, 1L, 1L, 3L, 2L, 3L, 3L, 1L, 0L, 2L, 2L, 0L, 0L, 1L, 1L,
1L, 0L, 0L, 3L, 2L, 3L, 1L, 1L, 2L, 1L, 0L, 3L, 0L, 0L, 0L, 3L, 0L, 3L, 2L,
1L, 0L, 3L, 1L, 3L, 1L, 1L, 3L, 1L, 2L, 0L, 1L, 0L, 3L, 1L, 0L, 3L, 2L, 1L,
2L, 3L, 3L, 2L, 1L, 3L, 0L, 1L, 2L, 3L, 3L, 0L, 0L, 0L, 2L, 3L, 3L, 1L)

How should i calculate the error now?
Should i use Delay block?

On Thu, Aug 6, 2015 at 2:34 AM, Johnathan Corgan 
wrote:

> On Wed, Aug 5, 2015 at 12:51 PM, Martin Braun 
> wrote:
>
>
>> Try
>>
>> noise_voltage = self.EbN0_to_noise_voltage(EbN0)/sqrt(2)
>>
>> the original berawgn.py was already buggy, because it didn't follow a
>> recent change in the noise power. I've submitted a patch, but it
>> probably won't be merged before the release cycle is reset (cf
>>
>> https://github.com/gnuradio/gnuradio/compare/master...mbr0wn:digital/berawgn_fix_noisepower?expand=1
>> ).
>
>
> ​This did get merged for 3.7.8 release.​
>
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
> Intro to SDR Class - Sep. 3-4, Santa Clara, CA
> http://corganlabs.com
>
> ___
> 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] pybombs difficulty

[Washbourne, Logan]

Thanks Iluta and Nathan,

My problem was not being able to use the gr-tutorials examples if I didn't
have Gnuradio installed in /usr/local, but then I realized that the
gr-tutorials was also a pybombs recipe so I used pybombs to install it and
everything worked out great! Thank you both for helping me learn how to
move my install prefix around and about proper folder locations.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Tue, Aug 4, 2015 at 11:13 AM, Iluta V  wrote:

> Hi Logan,
>
> Here is a full set of commands for installing in your own home directory
> via pybombs:
>
> git clone https://github.com/gnuradio/pybombs
> cd pybombs
> ./pybombs config
>
> sudo rm -rf /home/gnuradio
> sudo mkdir /home/gnuradio
> sudo chown -R linux /home/gnuradio /home/linux/pybombs
> rm -rf inventory.dat src
> linux@Linux:~/pybombs$ ./pybombs install -v -v gnuradio
>
> add gnuradio and all apps you want, then change path to:
>
> source /home/gnuradio/setup_env.sh
> linux@Linux:~$ sudo gedit .bashrc
> linux@Linux:~$ source ~/.bashrc
>
> Good luck! :)
>
> BR,
>
> Iluta
>
>
> On Tue, Aug 4, 2015 at 5:25 PM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> So I changed the install prefix to /home/username/thesis/target and then
>> deleted the inventory.dat file and removed the previous install prefix
>> folder(this was usr/local, but it actually ended up in usr/local/share, I'm
>> thinking this was a problem because I think there are lingering files). I'm
>> having problems now, I can't remove or update any packages, it states that
>> there is not an inventory file so it creates an empty one and then states
>> there is nothing to do. Is there a way to have it generate a new inventory
>> file? I can't install any packages because they seem to still be in the
>> pybombs folder. Do you have any advice Nathan?
>>
>> My initial reasoning for changing the install prefix to usr/local/ was to
>> enable me to create my own OOT modules and build the tutorial examples.
>> When pybomb's install prefix was in my home directory it kept throwing an
>> error about the CMake files. I tried to change the install prefix locations
>> within those CMake files but that didn't seem to fix my problems.
>>
>> I'm really starting to learn that a little knowledge can be a pretty
>> dangerous thing haha.
>>
>> I appreciate your time and help,
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Mon, Aug 3, 2015 at 10:06 PM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> Password Alert! This message may contain a request for your password.
>>> NEVER SEND OR RESPOND TO E-MAIL REQUESTS FOR YOUR PASSWORD. For questions
>>> about this alert, please contact the IT HelpDesk at 405-744-4357 or
>>> email helpd...@okstate.edu.
>>> --
>>> You only have to use sudo with pybombs if you don't have write
>>> permission to your prefix. In general it's best to avoid using sudo and
>>> pybombs together if possible (with the exception of when pybombs asks you
>>> for sudo password when using apt-get install).  You can either set the
>>> prefix to somewhere your user normally has write access to (typically your
>>> home directory), or alter permissions of your prefix. As an example, if you
>>> were setting your prefix to /opt/gnuradio/pybombs-v3.7.8  the least
>>> obtrusive way to do this is
>>> sudo mkdir -p /opt/gnuradio/pybombs-v3.7.8 # assuming your user
>>> doesn't have write access to /opt/gnuradio you need sudo to mkdir
>>> sudo chown myusername:mygroupname /opt/gnuradio/pybombs-v3.7.8
>>> ./pybombs install gnuradio
>>>
>>> In practice I usually make a group on my machines called 'developer' and
>>> add my user to it, then give the developer group ownership or write access
>>> (depends on what I feel like when I set up a new machine) to /opt. That
>>> lets me write whatever to /opt without sudo (don't forget you need to login
>>> after adding your user to group for it to take effect). The same principle
>>> can be used with /usr/local or any other directory, but IMHO you should at
>>> least make your work an extra layer deep so you can just rm -rf the whole
>>> prefix (without root!) and not have much to worry about damaging.
>>>
>>> Cheers,
>>> Nathan
>>>
>>> On Mon, Aug 3, 2015 at 9:15 PM, Washbourne, Logan <
>>> lwas...@ostatemail.okstate.edu> wrote:
>>>
 Thanks Nathan. Should I have to use sudo when using pybomb commands,
 now that the installation prefix is outside of my home directory(because I
 now I have to use sudo when using pybomb commands)?


 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 On Mon, Aug 3, 2015 at 7:38 PM, West, Nathan <
 n...@ostatemail.okstate.edu> wrote:

> Logan,
>
> For your case deleting inventory.dat would do the trick of effectively
> resetting pybombs state (and if your done wit

Re: [Discuss-gnuradio] how to choose tune_delay?

[fquitin]

Hi all,

I've implemented Marcus' solutions, and it works fine. I thought I would 
just mention some detail that threw me off at first so that other people 
do not stumble on the same problems I did:
- when you issue a set_command_time/tune_freq/clear_command_time 
(scheduled for 2 sec in the future for example), the UHD prints out the 
message that it has re-tuned the USRP right away (not after 2 seconds). 
Additionally, the USRP will generate a time-tag right away when 
receiving the command, not after 2 seconds. But the effective change of 
frequency will indeed only happen after 2 seconds. So you need to 
implement a time-counter/sample-counter that will be able to detect when 
2 seconds have passed.
- when the command_time arrives too late at the USRP (after the 
scheduled time), the USRP will retune asap. But no alert is given to the 
UHD, and it is hard to detect from the software side when this happens. 
This might happen in particular when you get a lot of overflows, and 
your tuning commands are scheduled for a short time in the future. To 
get over this, it is recommended to send several tuning commands in 
advance (if you know the successive tuning times) so that the USRP 
always has several commands in its pipeline (I read somewhere you can go 
up to 16 timed commands). In that case, if the host processor lags a bit 
to send the latest tuning command, it will be OK since the USRP will 
have some instructions in its command buffer.


Cheers (and thanks again to Marcus)
Francois




On 04.08.2015 11:38, Marcus Müller wrote:

Hi Francois,

yes, N210 and later have timed commands abilities, which comes with the
feature of metadata containing time stamps; the GNU Radio USRP source 
is

able to evaluate that metadata coming from UHD, and adds stream tags at
the right position[1].

Greetings,
Marcus

[1]
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#a8ba918061af928ee7c01e7124580eb82

On 04.08.2015 03:21, fquitin wrote:

Hi Marcus,

Thanks for your comments, as usual, you're being a life-saver (I
wasn't aware of the existence of set_command_time/clear_command_time
functions, these will be immensely helpfull). From your suggestions, I
understand that the USRP will always re-attach a rx_time tag after
being re-tuned?

Thanks,
Francois


On 03.08.2015 11:26, Marcus Müller wrote:

Hi Francois,

 yes, that seems rather high; but maybe you're seeing the effects of
the DC offset removal filter. You can try to use use
set_auto_dc_offset(False) to make that faster [1].

 However, usrp_spectrum_sense is pretty old, and hence can't even 
make

use of stream tags on the GNU Radio side and timed commands on the
USRP side, so the lower boundary for delay is the two-way latency
between host and device -- which can easily be in the order of tens 
of

milliseconds.

 I'd personally recommend just going ahead and reimplementing this:
 * Use the USRP source as usual
   * use set_time_now (if you don't have a time/PPS source),
set_start_time
   * issue two or three timed tuning commands right at the start
(set_command_time, set_rx_freq, clear_command_time)
 * write a python block that waits for rx_time tags (which
automatically get added by the USRP source nowadays)
  * that block would, upon detection of such a tag, issue "the next
tune request in line" (set_command_time(rx_time+delay), set_rx_freq,
clear_command_time)
  * that block would, after detection of such a tag, first discard a
few samples and then calculate your metrics based on the following N
samples

 Best regards,
 Marcus

 [1]
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0

[2]

On 03.08.2015 11:11, Francois Quitin wrote:


Hi all,



I want to retune the frequency of my USRP in Python during runtime.
I understand from usrp_spectrum_sense.py that I can just retune the
USRP during runtime, and that I need to allow for some tune_delay to
make sure that the samples corresponding to the old center frequency
are discarded.



Is there any way to get a good estimate of tune_delay value? I want
to keep this as short as possible… (btw I’m using a USRP-N210
with WBX daughterboard) Some trial and error gave me values around
50ms, but this seems rather high compared to what I’ve read
online.



Any hints are welcome!

Thanks,

Francois



--



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




Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0


___
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/di

Re: [Discuss-gnuradio] UHD build apparently failed - build-gnuradio script

[Marcus D. Leech]

On 08/05/2015 06:47 PM, Yoda Master wrote:

Hi,
i try to install gnuradio with your script on Debian 8.4 64bit.
I change in script version and he download pretty much of files, when he
come to UHD, he breaks:

Skipping git fetch, since 'uhd' and 'gnuradio' are new enough
Starting function uhd_build at: Wed Aug 5 17:38:44 CDT 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=
UHD build apparently failed
Exiting UHD build


from files he get:
airspy   build-gnuradio  gr-iqbalhackrf   touch19347
bladeRF  gnuradiogr-osmosdr  rtl-sdr  uhd


i try with manual install UHD via apt-get, but seems that he don`t
recognize it...

Can i get some help please?


thank you.


Run it with the -v flag to get more information about why it failed.

But since the script isn't advertised to work with Debian 8.4, I'm not 
likely to be much help debugging it.




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

[Discuss-gnuradio] UHD build apparently failed - build-gnuradio script

[Yoda Master]

Hi,
i try to install gnuradio with your script on Debian 8.4 64bit.
I change in script version and he download pretty much of files, when he
come to UHD, he breaks:

Skipping git fetch, since 'uhd' and 'gnuradio' are new enough
Starting function uhd_build at: Wed Aug 5 17:38:44 CDT 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=
UHD build apparently failed
Exiting UHD build


from files he get:
airspy   build-gnuradio  gr-iqbalhackrf   touch19347
bladeRF  gnuradiogr-osmosdr  rtl-sdr  uhd


i try with manual install UHD via apt-get, but seems that he don`t
recognize it...

Can i get some help please?


thank you.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] GLError 1285

[Marcus D. Leech]

On 08/04/2015 03:31 AM, Sylvain Munaut wrote:

Hi,


Traceback (most recent call last):
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 209, in _on_paint
 for fcn in self._draw_fcns: fcn[1]()
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 65, in draw
 GL.glCallList(self._grid_compiled_list_id)
   File "errorchecker.pyx", line 53, in
OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError
(src/errorchecker.c:1218)
OpenGL.error.GLError: GLError(
 err = 1285,
 baseOperation = glCallList,
 cArguments = (1L,)
)

After running for an hour or two.

This is on F22, but on F20, there's no such issue.  So, it appears that
there's a memory leak somewhere, but not sure where.

I'd suspect the driver ...

What hardware are they running this on ? (which GL driver)

Cheers,

Sylvain

And from another:

OpenGL vendor string: Intel Open Source Technology Center

OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile

OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.3 (git-ccef890)

OpenGL core profile shading language version string: 3.30

OpenGL core profile context flags: (none)

OpenGL core profile profile mask: core profile

OpenGL core profile extensions:

OpenGL version string: 3.0 Mesa 10.6.3 (git-ccef890)

OpenGL shading language version string: 1.30

OpenGL context flags: (none)

OpenGL extensions:

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.3 (git-ccef890)

OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

OpenGL ES profile extensions:





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

Re: [Discuss-gnuradio] GLError 1285

[Marcus D. Leech]

On 08/04/2015 03:31 AM, Sylvain Munaut wrote:

Hi,


Traceback (most recent call last):
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 209, in _on_paint
 for fcn in self._draw_fcns: fcn[1]()
   File
"/usr/local/lib64/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 65, in draw
 GL.glCallList(self._grid_compiled_list_id)
   File "errorchecker.pyx", line 53, in
OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError
(src/errorchecker.c:1218)
OpenGL.error.GLError: GLError(
 err = 1285,
 baseOperation = glCallList,
 cArguments = (1L,)
)

After running for an hour or two.

This is on F22, but on F20, there's no such issue.  So, it appears that
there's a memory leak somewhere, but not sure where.

I'd suspect the driver ...

What hardware are they running this on ? (which GL driver)

Cheers,

Sylvain

Here's info from one of the users:

Thanks for reporting the error on the mailing list.
To answer Sylvain, here's the chipset and Mesa driver I'm using. I 
suspect Dave also uses an Intel chipset.


$ glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.1 
(git-6ff3ae8)

OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.6.1 (git-6ff3ae8)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.1 (git-6ff3ae8)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

$ dnf list installed | grep -i mesa-dri-drivers
mesa-dri-drivers.x86_64 10.6.1-1.20150629.fc22   @System

I'm not a subscriber on the mailing list and I'm unknown there, maybe 
you could forward them this.
If some debug info is required such as an strace, I'll subscribe to 
their list and deal with them directly.


Regards,
Damien


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

Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

[Moritz Fischer]

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli
 wrote:
> Hi Martin or others who can support me,
> I have a problem which is similar as Frank's: I have an E310 and I want to
> receive a and external trigger on a pin which starts an acquisition process
> of a burst of samples from the radio source.

In the default FPGA image the GPIO pins are wired up to ATR pins that
are connected
to the radio0.

https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304

would be your places to start.

If you want to use our GPIO API take a look at:

http://files.ettus.com/manual/page_gpio_api.html

>
> Stated that I have to remove the box around the E310 to have access to the
> GPIO ports (not a problem!), according to what I have read so far in this
> thread, no way to reach my goal but using C++ (no GRC!). Not an easy task
> for me but I do hope I can do it.
>
> What I need you support about is related to the right approach I should
> follow. I would think that I should write a "while" loop which runs in ARM
> processors where one on the available GPIO port is constantly monitored:
> when the trigger is detected the acquisition process of a burst of samples
> from the radio source is started and, once it has been completed, the flow
> goes back to the GPIO port monitoring.

You could either fork of a thread to monitor the ports through the UHD API,
or rewire stuff in the FPGA (as pointed out above) to use the Zynq's
GPIO_I signals in the FPGA.
You could then use the default kernel sysfs GPIO API to use GPIO interrupts.

places to start investigating are:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
http://elinux.org/GPIO#GPIO_interrupts_from_user_space

maybe there are python bindings available?

>
> Is there any example code I be inspired from? OF course I have to study what
> can be found in the manual page "The E3x0/X3x0 Front Panel GPIO", but,
> together with the suggested gpio.cpp example under UHD, it looks like there
> is more emphasis on the ATR mechanism, which - I think - has nothing to do
> with the problem I have to solve.

That is true, see the above links. Depending on latency requirements,
and your input signal,
the ATR API might not be what you need.
>
> Martin or others, could you please comment on my problem?
>
> TIA!
>
> BR,
> Maurizio.
>
> PS If you think that, according to what I have understood so far, I will
> need to use RFNoC in order to cope with the sampling speed constraints of
> the acquisition process of a burst of samples from the radio source, you
> might well understand how much I need your help, and not just for this
> post...

Just for the GPIO part no requirement of using RFNOC.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.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

Happy hacking,

Moritz

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

Re: [Discuss-gnuradio] [UHD] Request for Feedback: C-API

[Martin Braun]

Just a quick follow-up,

we've gotten some feedback, and made some small changes, but it seems
overall this C-wrapper API will get merged soon. I'm taking down the
public branch for now, but you will get the codes back in master within
the next week.

Thanks, everyone!

Martin

On 20.07.2015 19:07, Martin Braun wrote:
> Hi friends,
> 
> we will soon be amending UHD with a C API, and we've just pushed it
> public for feedback: https://github.com/EttusResearch/uhd/tree/uhd/c-api
> 
> Quick disclaimer: It's not 100% feature-complete (i.e., not every single
> item from the C++ API has made it to the C API), but we will fix those
> holes over time. Also, the documentation is 'implicit' right now,
> meaning the C API itself isn't documented itself, but follows the C++
> API closely.
> 
> I'm very interested to hear if there's any feedback from anyone on this.
> I recommend starting with the C-examples (in host/examples/*.c) if you
> want to learn more.
> 
> Cheers,
> Martin
> 


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

Re: [Discuss-gnuradio] Channel Model

[Johnathan Corgan]

On Wed, Aug 5, 2015 at 12:51 PM, Martin Braun 
wrote:


> Try
>
> noise_voltage = self.EbN0_to_noise_voltage(EbN0)/sqrt(2)
>
> the original berawgn.py was already buggy, because it didn't follow a
> recent change in the noise power. I've submitted a patch, but it
> probably won't be merged before the release cycle is reset (cf
>
> https://github.com/gnuradio/gnuradio/compare/master...mbr0wn:digital/berawgn_fix_noisepower?expand=1
> ).


​This did get merged for 3.7.8 release.​


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with streamed tags

[Martin Braun]

On 05.08.2015 01:42, Mat Mat wrote:
> My question is this: I don't get this item enumeration thing in
> gnuradio. between the first 2 blocks it was easy enough, as I had to
> simply include tags in every 28th byte, and it is easy to picture item
> enumeration there (the first byte of the file has offset 0, the second
> one 1 etc). but how are the items enumerated between the PACKET_CREATOR
> and the PACKET_VERIFIER block?? which item index should I use to add the
> length tag to the first header byte??

Item 0 will have the first byte of the first packet, regardless of what
you're actually doing. There's a couple of blocks that do something like
this, and they all set the tag propagation policy to 'NONE' (which
requires manual propagation), and then get/set tags accordingly.

So, if you read the tag from input item 0, and then write one to output
item 0, I believe it'll do what you wanted.

M


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

Re: [Discuss-gnuradio] Channel Model

[Martin Braun]

On 05.08.2015 04:25, monika bansal wrote:
> Hii
> 
> I am using channels.channel_model as
> 
> channels_channel_model_0 = channels.channel_model(
> noise_voltage = self.EbN0_to_noise_voltage(EbN0),
> frequency_offset=0.0,
> epsilon=1.0,
> taps=(1.0 + 0j, ),
> noise_seed=RAND_SEED,
> block_tags=True
> )  

Try

noise_voltage = self.EbN0_to_noise_voltage(EbN0)/sqrt(2)

the original berawgn.py was already buggy, because it didn't follow a
recent change in the noise power. I've submitted a patch, but it
probably won't be merged before the release cycle is reset (cf
https://github.com/gnuradio/gnuradio/compare/master...mbr0wn:digital/berawgn_fix_noisepower?expand=1).

M

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

Re: [Discuss-gnuradio] QT Blocks causing BER errors?

[Tom Rondeau]

On Thu, Jul 23, 2015 at 10:54 AM, Nick Foster  wrote:

> My guess, educated only in that I've seen it happen before, is that one of
> the blocks in your flowgraph exhibits behavior which is dependent on the
> number of samples per work call. Loading the machine down with GUI blocks
> will change the number of samples GR doles out during each work call.
>
> Timing synchronizers would be the first place I'd look.
>
> --n
>


Hey guys,

I just replied to bob wole on another thread with a bug that I think is
related to this issue, too. To quote myself:

"The problem isn't with the GUI sinks; you can replace them with null sinks
and you get the same problem. It's a race condition in our tag pruning
method that was changed in 3.7.6. We have a patch that we're putting in now
that will be part of 3.7.8.

The patch goes backwards a bit to how tag pruning was originally done.
However, with the map, we no longer have to restart the iterator at begin()
like we used to, and we can terminate early, so this should still be much
faster than the original."

Hope this solves others' problems as well!

Tom




>
>
On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller 
> wrote:
>
>> Hi Rich,
>>
>> being really surprised:
>> I think it would be nice if we knew a bit more about the signal
>> processing part of your flow graph.
>> What does it rely on? Pure Sample Streams? Stream Tags? Message Passing?
>> Old-Style Message queues?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 22.07.2015 20:11, Richard Bell wrote:
>>
>> I've come across a really unexpected correlation this morning that I'm
>> hoping someone has an explanation for. I have a large flow graph with many
>> QT GUI blocks because I'm debugging a design. Mostly Time Sinks and
>> Constellations plots with a couple of Frequency Sinks thrown in. The number
>> of points in some of the time sinks is rather large, on the order of 30k,
>> which allows me to see several packets of data at once.
>>
>> What I noticed this morning, while debugging a BPSK loopback BER tester,
>> is by disabling a number of Constellation plots which were fed by RRC
>> filters to make the plot pretty, errors went away. The system works as you
>> would expect a simulation with no noise or channel effects to work,
>> perfectly. When I enable those GUI blocks, the system looses packet
>> synchronization within the first minute consistently. Nothing is changed in
>> the data stream between these tests.
>>
>> So the question is, is there a known cap on GUI plots? Like I said, I
>> have a lot of them and some of them are plotting a large number of points.
>> Could this be causing buffers overruns into data spaces or something scary
>> like that?
>>
>> Another thought I had, could there be an identity problem in which GNU
>> Radio at some point can't uniquely identify blocks with the same name apart
>> from each other and thus chooses one in some default manner? I'm imagining
>> a plotting stream getting crossed with a data stream in some way.
>>
>> The bottom line is all I need to do to make this system work is disable
>> some plotting only related blocks. Is there a known plotting cap issue that
>> I should be aware of?
>>
>> Thanks,
>> Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error

[Tom Rondeau]

On Wed, Aug 5, 2015 at 2:07 AM, bob wole  wrote:

> Ubuntu 14.04 64-bit
> Gnuradio 3.7.8rc1
>
>
> I am running this flowgraph "fecapi_async_to_stream.grc" that comes with
> gr-fec. After running for a while following error always show up
>
> 
> 
> DEBUG: 16384, 560, 272
> DEBUG: 16384, 560, 272
> FATAL: Missing a required length tag on port 0 at item #14965440
> thread[thread-per-block[7]: ]: Missing
> length tag.
>
> The only thing that changes is the item#.
> Testing further 
>
>
> --
> Bob
>

Bob,

You led us down a buggy path on that one. This, I'm pretty sure, is related
to Richard Bell's problem for a few weeks ago where adding a time sink
caused problems in his data stream. I have to say, I kind of dismissed that
as impossible, but nope, it's a real problem.

The problem isn't with the GUI sinks; you can replace them with null sinks
and you get the same problem. It's a race condition in our tag pruning
method that was changed in 3.7.6. We have a patch that we're putting in now
that will be part of 3.7.8.

The patch goes backwards a bit to how tag pruning was originally done.
However, with the map, we no longer have to restart the iterator at begin()
like we used to, and we can terminate early, so this should still be much
faster than the original.

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

Re: [Discuss-gnuradio] USRP B210 GPIO

[Martin Braun]

On 05.08.2015 10:32, mle...@ripnet.com wrote:
> The B2xx GPIO J504 GPIO has the same API as X3xx. 

...and the example is also the same (gpio.cpp).

Cheers,
Martin
> 
>  
> 
>  
> 
>  
> 
> On 2015-08-05 13:26, Samith Abeywickrama wrote:
> 
>> Hi, I want to control an antenna multiplxer via J504 gpio port.
>> Actually I want to have logic 1 and logic 0 in order to switch the
>> multiplxer. But it is difficult to find gpio example for B210. I have
>> new version of b210 (green board) and 3.8.005 uhd version. I m very
>> much thankful to if you can help me with gpio example. Ettus research
>> says that B210 is supported for gpio in j504 port but in UHD there is
>> only one example for x300.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] USRP B210 GPIO

[mleech]

 

The B2xx GPIO J504 GPIO has the same API as X3xx. 

On 2015-08-05 13:26, Samith Abeywickrama wrote: 

> Hi, I want to control an antenna multiplxer via J504 gpio port. Actually I 
> want to have logic 1 and logic 0 in order to switch the multiplxer. But it is 
> difficult to find gpio example for B210. I have new version of b210 (green 
> board) and 3.8.005 uhd version. I m very much thankful to if you can help me 
> with gpio example. Ettus research says that B210 is supported for gpio in 
> j504 port but in UHD there is only one example for x300. 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] USRP B210 GPIO

[Samith Abeywickrama]

Hi, I want to control an antenna multiplxer via J504 gpio port. Actually I
want to have logic 1 and logic 0 in order to switch the multiplxer. But it
is difficult to find gpio example for B210. I have new version of b210
(green board) and 3.8.005 uhd version. I m very much thankful to if you can
help me with gpio example. Ettus research says that B210 is supported for
gpio in j504 port but in UHD there is only one example for x300.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

[Maurizio Crozzoli]

Hi Martin or others who can support me,
I have a problem which is similar as Frank's: I have an E310 and I want to
receive a and external trigger on a pin which starts an acquisition process
of a burst of samples from the radio source.

Stated that I have to remove the box around the E310 to have access to the
GPIO ports (not a problem!), according to what I have read so far in this
thread, no way to reach my goal but using C++ (no GRC!). Not an easy task
for me but I do hope I can do it.

What I need you support about is related to the right approach I should
follow. I would think that I should write a "while" loop which runs in ARM
processors where one on the available GPIO port is constantly monitored:
when the trigger is detected the acquisition process of a burst of samples
from the radio source is started and, once it has been completed, the flow
goes back to the GPIO port monitoring.

Is there any example code I be inspired from? OF course I have to study what
can be found in the manual page "The E3x0/X3x0 Front Panel GPIO", but,
together with the suggested gpio.cpp example under UHD, it looks like there
is more emphasis on the ATR mechanism, which - I think - has nothing to do
with the problem I have to solve.

Martin or others, could you please comment on my problem?

TIA!

BR,
Maurizio.

PS If you think that, according to what I have understood so far, I will
need to use RFNoC in order to cope with the sampling speed constraints of
the acquisition process of a burst of samples from the radio source, you
might well understand how much I need your help, and not just for this
post...



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.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] GRCon15> Registration Updates

[Michael Dickens]

We're heading into the final weeks before GRCon15, and registration has
thus far been strong. The new developers day and the main conference are
about 2/3 sold, which still leaves plenty of tickets. The RFNoC tutorial
is sold out, and we still have 8 student tickets (+ 8 tickets still
waiting for proof of enrollment). We are currently on track to sell out
the whole conference so don't delay in getting your tickets!

In related and exciting news, we have coordinate with Dr Joe Mitola to
be our conference keynote speaker. Dr Mitola is globally recognized as
the 'Godfather' of software defined and cognitive radios' having coined
both terms, written seminal peer reviewed IEEE papers, and published the
first graduate text books on both topics in English and Chinese. He is a
widely sought after consultant, subject matter expert, and expert
witness currently a Member, US Defense Science Board task force on
MILSATCOM and Tactical Networking, supporting DARPA, Army and the Office
of Naval Research on collaboration with the Naval Postgraduate School
and Naval Research Laboratory.  Previously Dr Mitola held positions of
technology leadership with DoD, ITT, E-Systems, Harris, ADS, MITRE and
Stevens Institute of Technology. BS EE Northeastern U, MSE Johns Hopkins
U, Licentiate and Doctorate KTH, Fellow of the IEEE'. His current
research centers on "hackproof technologies", of which he will be
speaking in his keynote at GRCon15 on Tuesday morning.

We've got a great conference coming up, with a wide diversity of
presentations, posters, demos, and vendors; we look forward to seeing
many of you in Washington, DC in a few weeks! - MLD

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

Re: [Discuss-gnuradio] python keep running

[Tom Rondeau]

On Tue, Aug 4, 2015 at 10:27 AM,  wrote:

> I have a GRC file that brings up a QT spectrum. I run grcc to create
> top_block.py and then run python on the top_block.py. When I click the
> close icon in the upper right corner of the spectrum window, the window
> goes away but the python is still running. Do you know why that might
> happen?
>
> Mark.
>


Nope. It'd be easier to help out if we knew what your flowgraph was doing
and what blocks are in it.

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

Re: [Discuss-gnuradio] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor

[Tom Rondeau]

On Wed, Aug 5, 2015 at 2:15 AM, Jeon  wrote:

> Dear Tom,
>
> Thanks for your advice.
>
> Actually, I've got a trouble for days installing Thrift and enabling it
> from GNU Radio.
>
> This is just a simple wrap-up for readers who are not familiar with
> compiling and building things.)
>
> Installing thrift:
>
> 1. Get Thrift 0.9.2
>
> 0.9.2 release tag of git repository have some buggy  stuff.
> So get the stable release from https://thrift.apache.org/download
>
> 2. Extract it and build. Make sure that you have all of pre-requisites.
>
> $ tar xf thrift-0.9.2.tar.bz2
> $ cd thrift-0.9.2
> $ ./configure
> $ make
> $ sudo make install
> $ sudo ldconfig # just in case
>
> 3. Check python can import Thrift
>
> $ python
> >>> import thrift
>
> 3-1. If python can't, do the followings:
>
> $ cd thrift-0.9.2/lib/py
> $ sudo python setup.py install
>
> Go back step 3. And check again.
>
> 4. Build GNU Radio.
>
> $ cd gnuradio
> $ mkdir build
> $ cd build
> $ cmake ..
> $ make
> $ sudo make isntall
>
> 4-1. One important thing is, I recommend you to delete everythink inside
> build directory.
>
> At least, I recommend you to remove CMakeCache.txt:
>
> $ cd build
> $ rm -rf ./
> # or
> $ rm CMakeCache.txt
>
> This file can help executing cmake, but sometimes it makes cmake get
> wrong variables.
>
> I've spent days to figure out this. cmakek gives me a wrong thrift
> binary path /usr/bin/thrift.
> Actually, I have thrift under /usr/local/bin.
>
> I think it's a quite unusual case since I have been messing around my PC.
> If you have a system with some fresh installation and configuration, it
> won't be a problem.
>
> Regards,
> Jeon.
>


We write this page to help people build Thrift:
http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort

But there are some good hints here about resetting cmake in GNU Radio to
get it to recognize Thrift after installation.

Thanks,
Tom





> 2015-08-04 0:05 GMT+09:00 Tom Rondeau :
>
>> On Sat, Aug 1, 2015 at 1:41 AM, Volker Schroer  wrote:
>>
>>> The same error happens in the 3.7.8 release candidate.
>>>
>>> -- Volker
>>>
>>>
>>>
>>> I am trying to measure performance of my OOT module with performance
>>> counter and control port.
>>>
>>> When I execute a command line `gr-perf-monitorx` or
>>> `gr-ctrlport-monitor`, an error below occurred:
>>>
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py",
>>> line 26, in 
>>> from gnuradio.ctrlport import GNURadio
>>> ImportError: cannot import name GNURadio
>>>
>>> Could anyone give me a hint for this?
>>>
>>> For detail information, I've installed GNU Radio with `build-gnuradio`
>>> script. The last commit of cloned git repository in my PC is `d5cea6e4(
>>> https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)`
>>> in Jun 22 2015. I can't remember exactly, but I think this commit was used
>>> to install the GNU Radio.
>>>
>>> Regards,
>>> Jeon.
>>>
>>>
>> This sounds as if Thrift wasn't found when running cmake. Our cmake
>> scripts use thrift to compile our gnuradio.thrift file into C++ and Python
>> code that is installed with GNU Radio.
>>
>> The output of cmake will tell you if it found Thrift or not. Look under
>> the list of enabled components for:
>>
>> --   * gr-ctrlport
>> --   * * thrift
>>
>> Tom
>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[Tom Rondeau]

On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:

>
> > There is a directory
>> > gnuradio-runtime/python/gnuradio/ctrlport
>> >
>> >
>> > where you in controlport related stuff.
>> >
>> > - - Volker
>> >
>> >
>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>> >
>> > Dear Bob,
>> >
>> > A few months ago, I've asked a similar question (
>> > <
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html>
>> >
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html)
>> >
>> > and Tom gave me his paper in SIGCOMM.
>> >
>> > Inspecting GNU Radio Applications with ControlPort and Performance
>> Counters
>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>> >
>> > You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php
>> >
>> > It does not fully describe how it can be used, though, through this you
>> > can get a hint.
>> >
>> > Regards,
>> > Jeon.
>> >
>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>> >
>> >> Ubuntu 14.04 64-bit
>> >>
>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I
>> >> fetched gnuradio using
>> >>
>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>> >>
>> >>
>> >>  Gnuradio enabled component shows
>> >>
>> >> * gr-ctrlport
>> >> * * thrift
>> >>
>> >> However, I do not see any *gr-ctrlport directory *inside the gnuradio
>> >> directory. Where is the source code for control port? Also there are no
>> >> examples for using control port.
>> >>
>> >> --
>> >> Bob
>> >>
>> >
>> You can find more information on these two pages:
>>
>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>
>>
>> ControlPort was reintroduced just after the 3.7.7 release so we had time
>> to
>> test it, but it will be available in the upcoming 3.7.8 release. The
>> manual
>> page linked above is from our weekly development builds.
>>
>> This points you to two apps that are installed with ControlPort:
>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for
>> usage is in our QA code. Look in gr-blocks
>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>> and qa_ctrlport_probes.py.
>>
>> Tom
>>
>>
>>
> ControlPort is written in python ?
>
> When I ran qa_ctrlport_probes.py. I got a segmentation fault first time.
> Then I ran the other two qa codes they passed successfully without any core
> dump. When I ran qa_ctrlport_probes.py again it passed successfully.
>
> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
> INFO: Apache Thrift: -h sdr-dev -p 57403
> .
> --
> Ran 5 tests in 0.509s
>
> OK
> *Segmentation fault (core dumped)*
>
> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py
> INFO: Apache Thrift: -h sdr-dev -p 35595
> ..
> --
> Ran 2 tests in 0.105s
>
> OK
>
> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py
> INFO: Apache Thrift: -h sdr-dev -p 38301
> ..
> --
> Ran 2 tests in 0.134s
>
> OK
>
> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
> INFO: Apache Thrift: -h sdr-dev -p 38644
> .
> --
> Ran 5 tests in 0.511s
>
> OK
> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
> INFO: Apache Thrift: -h sdr-dev -p 48394
> .
> --
> Ran 5 tests in 0.510s
>
> OK
>
>
> What could be the cause?  I thought I should share because it is a new
> release and is in testing stage.
>
>
> --
> Bob
>

There is a bug in Thrift 0.9.2 that I'm going to guess is the cause of that
seg fault. See our notes on building Thrift and the patch that we have for
it:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort

I believe that patch has been accepted, but after the 0.9.2 release.

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

Re: [Discuss-gnuradio] gr-perf-monitorx Error

[Tom Rondeau]

On Wed, Aug 5, 2015 at 4:47 AM, bob wole  wrote:

>
> I am here again.  I ran "fecapi_async_decoders.grc" with controlport
> performance moniter on. I made a new config.conf file in ~/.gnuradio and
> added following lines to it
>
> [ControlPort]
> on = True
> edges_list = True
> [PerfCounters]
> on = True
> export = True
>
>
>
> When I ran the flowgraph I got the following error
>
> Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"
>
> Using Volk machine: avx_64_mmx_orc
> ControlPort Monitor running.
> INFO: Apache Thrift: -h sdr-dev -p 50883
> monitor::endpoints() = -h sdr-dev -p 50883
> running: ['gr-perf-monitorx', 'sdr-dev', '50883']
> Traceback (most recent call last):
>   File "/usr/local/bin/gr-perf-monitorx", line 902, in 
> MyApp(sys.argv)
>   File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
> GNURadioControlPortClient(args, 'thrift', self.run,
> QtGui.QApplication(sys.argv).exec_)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
> line 125, in __init__
> callback(self.client)
>   File "/usr/local/bin/gr-perf-monitorx", line 900, in run
> MAINWindow(client).show()
>   File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
> self.newCon(radioclient)
>   File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
> child = MForm(self.radioclient, len(self.conns), self, dialogprompt =
> not csomeBool)
>   File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
> self.pos = nx.graphviz_layout(self.G);
>   File
> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
> line 257, in graphviz_layout
> return pydot_layout(G=G,prog=prog,root=root,**kwds)
>   File
> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
> line 271, in pydot_layout
> pydot = load_pydot()
>   File
> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
> line 47, in load_pydot
> raise ImportError(msg)
> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/
>
> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
> ubuntu 14.04.
>
>
> --
> Bob
>

Did you try to install pydot?

sudo apt-get install python-pydot

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

Re: [Discuss-gnuradio] Channel Model

[Tom Rondeau]

On Wed, Aug 5, 2015 at 7:25 AM, monika bansal  wrote:

> Hii
>
> I am using channels.channel_model as
>
> channels_channel_model_0 = channels.channel_model(
> noise_voltage = self.EbN0_to_noise_voltage(EbN0),
> frequency_offset=0.0,
> epsilon=1.0,
> taps=(1.0 + 0j, ),
> noise_seed=RAND_SEED,
> block_tags=True
> )
>
> in the place of Add and Noise_Source in berawgn.py file.. But the BER is
> not following the theory curve. I am attaching the curve i got.
>
> What does this channel model do ? Can someone please explain it.
>


The channel_model is a hierarchical block to add noise, frequency offset,
timing offset, and a constant channel. In your case, you've turned off
everything but the noise source, which is generated using a
gr::analog::noise_source_c.

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

My guess is that you're setting the noise voltage level incorrectly.

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

[Discuss-gnuradio] Channel Model

[monika bansal]

Hii

I am using channels.channel_model as

channels_channel_model_0 = channels.channel_model(
noise_voltage = self.EbN0_to_noise_voltage(EbN0),
frequency_offset=0.0,
epsilon=1.0,
taps=(1.0 + 0j, ),
noise_seed=RAND_SEED,
block_tags=True
)

in the place of Add and Noise_Source in berawgn.py file.. But the BER is
not following the theory curve. I am attaching the curve i got.

What does this channel model do ? Can someone please explain it.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-perf-monitorx Error

[bob wole]

I am here again.  I ran "fecapi_async_decoders.grc" with controlport
performance moniter on. I made a new config.conf file in ~/.gnuradio and
added following lines to it

[ControlPort]
on = True
edges_list = True
[PerfCounters]
on = True
export = True



When I ran the flowgraph I got the following error

Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py"

Using Volk machine: avx_64_mmx_orc
ControlPort Monitor running.
INFO: Apache Thrift: -h sdr-dev -p 50883
monitor::endpoints() = -h sdr-dev -p 50883
running: ['gr-perf-monitorx', 'sdr-dev', '50883']
Traceback (most recent call last):
  File "/usr/local/bin/gr-perf-monitorx", line 902, in 
MyApp(sys.argv)
  File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__
GNURadioControlPortClient(args, 'thrift', self.run,
QtGui.QApplication(sys.argv).exec_)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py",
line 125, in __init__
callback(self.client)
  File "/usr/local/bin/gr-perf-monitorx", line 900, in run
MAINWindow(client).show()
  File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__
self.newCon(radioclient)
  File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon
child = MForm(self.radioclient, len(self.conns), self, dialogprompt =
not csomeBool)
  File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__
self.pos = nx.graphviz_layout(self.G);
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 257, in graphviz_layout
return pydot_layout(G=G,prog=prog,root=root,**kwds)
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 271, in pydot_layout
pydot = load_pydot()
  File
"/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py",
line 47, in load_pydot
raise ImportError(msg)
ImportError: pydot could not be loaded: http://code.google.com/p/pydot/

I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on
ubuntu 14.04.


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

[Discuss-gnuradio] problem with streamed tags

[Mat Mat]

hi all,

I have three blocks:

1. MESSAGE_LOADER
reads a binary file and outputs it byte by byte to the next block
(PACKET_CREATOR). On every 28th byte (and on the 0th byte) it adds tags
denoting the start of a PDU

2. PACKET_CREATOR (tagged_stream_block)
waits for 28 bytes to arrive. once this is accomplished, it reads the
first of those 28 bytes and uses it for internal logic. the other 27
bytes are the payload of a packet, to which it prepends a header and
appends a crc (2 bytes). NOTE: the length of the header in bits is not
divisible by 8. because of this, in order to have the whole packet in
one single chunk of memory, I have to do tedious bit shifting of the 27
payload bytes that come after the header.. once the packet is created, I
want to pass it to the next block, containing tags in the first header
byte. So, now I've changed things: before, the tags were 'connected' to
the first payload byte. now, I want them to be 'connected' to the first
header byte, which was created in this very block.

3. PACKET_VERIFIER (tagged_stream_block)
for testing purposes, I want this block to receive the whole packet that
was created in PACKET_CREATOR and write it to the screen. In order for
the block to know when a packet starts, every first byte of a packet
must contain the length of it.

My question is this: I don't get this item enumeration thing in
gnuradio. between the first 2 blocks it was easy enough, as I had to
simply include tags in every 28th byte, and it is easy to picture item
enumeration there (the first byte of the file has offset 0, the second
one 1 etc). but how are the items enumerated between the PACKET_CREATOR
and the PACKET_VERIFIER block?? which item index should I use to add the
length tag to the first header byte??

I hope I have made myself sufficiently clear..if not, feel free to ask
for more details. any help is immensely appreciated!

thanks in advance!

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] gnuradio-core missing / UCLA Zigbee PHY in gnuradio version 3.6.5.1

[Bastian Bloessl]

Hi,

looks like GRC cannot find your blocks, so I guess you should adapt your 
local_blocks_path


https://github.com/bastibl/gr-ieee802-11#troubleshooting


On 08/05/2015 02:15 AM, Jaeho wrote:

the figure that i insert as below, some files has comment that "compile on
mac"

is this comments mean that those file works on only Apple Mac? or mean MAC
layer?


No, it just means that it also compiles on OS X.

Best,
Bastian

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