Re: [Discuss-gnuradio] Unexpected wifi_loopback.grc output

[Bastian Bloessl]

Hi,

On 04/26/2016 03:44 AM, Gupta, Arjan wrote:

Here is the output the output for the flow graph:

http://pastebin.com/JrfKwEB7


Looks fine.




When I generate the flow graph for wifi_loopback.grc, it gives me the
output:

-

Generating: '/home/student/bastibl/gr-ieee802-11/examples/wifi_loopback.py'
 >>> Warning: This flow graph may not have flow control: no audio or RF
hardware blocks found. Add a Misc->Throttle block to your flow graph to
avoid CPU congestion.

-


Is it supposed to be this way or am I doing something wrong? Any help
would be really appreciated.



That's OK. It just tells you that if you had only streams in your flow 
graph and no clock that throttles it down then the flow graph would run 
at maximum speed occupying all CPU cores.


In the loopback example there is, however, a message strobe that inputs 
frames only from time to time and, therefore, takes care not to burn 
your CPU.


Best,
Bastian

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

[Discuss-gnuradio] Unexpected wifi_loopback.grc output

[Gupta, Arjan]

Dear list,


I am trying to set up a transceiver in GNU Radio. I have downloaded and 
installed Bastian Bloessl's repos by following his instructions on

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


Here are my system details:

  *   OS: Ubuntu 14.04.1
  *   GNU Radio version: 3.7.9.2

Since I just installed this, I am just trying to get wifi_loopback.grc to 
execute properly, but I have strange output. I have tried to fiddle around with 
the snr, pdu length, pdu interval, but my output does not have the decoded 
"Hello World" packets that it should.


Here is the output the output for the flow graph:

http://pastebin.com/JrfKwEB7


When I generate the flow graph for wifi_loopback.grc, it gives me the output:

-

Generating: '/home/student/bastibl/gr-ieee802-11/examples/wifi_loopback.py'
>>> Warning: This flow graph may not have flow control: no audio or RF hardware 
>>> blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU 
>>> congestion.

-


Is it supposed to be this way or am I doing something wrong? Any help would be 
really appreciated.



Best regards,


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

Re: [Discuss-gnuradio] Pybomb installation error

[Martin Braun]

On 04/25/2016 05:39 AM, Jason Matusiak wrote:
>> My apologies, just double-checked and I was looking at an older version.
>> Try updating, it should be fixed now.
> 
> I just pulled down the latest and still get the same UHD CMakeList error.  
> Nathan W
> sat down at my laptop last THUR and poked around and seemed to be stumped as 
> well (though 
> he couldn't recreate it on his laptop).

This was a different issue though, right? Are you referring to the
builddir thing?

M


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

Re: [Discuss-gnuradio] GRC Developers Call April 2016

[Koslowski, Sebastian (CEL)]

April 28, 2016, of course.

On 04/25/2016 04:52 PM, Sebastian Koslowski wrote:
> Hey,
>
> we plan to have a GRC Development Meeting on Thursday April 25, 2016 at
> 7pm CEST.
> Anyone, how whats to work on GRC is welcome to join. We'll review the
> latest changes briefly and then move on to future developments. An
> agenda draft can be found here:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20160428
>
> This will be on the GNU Radio calendar shortly. We will use the Hangout
> attached to the event.
>
> Sebastian
>
>
>
> ___
> 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] GRC Developers Call April 2016

[Sebastian Koslowski]

Hey,

we plan to have a GRC Development Meeting on Thursday April 25, 2016 at
7pm CEST.
Anyone, how whats to work on GRC is welcome to join. We'll review the
latest changes briefly and then move on to future developments. An
agenda draft can be found here:

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

This will be on the GNU Radio calendar shortly. We will use the Hangout
attached to the event.

Sebastian



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

Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?

[Marcus Müller]

Hi Michael,
I think I see a bug in gr-uhd there!

So point is that the python code generated by this is (example):

[...]
##
# Blocks
##
self.uhd_usrp_sink_0 = uhd.usrp_sink(
",".join(("", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_sink_0.set_time_source("external", 0)
self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_sink_0.set_samp_rate(4e6)
self.uhd_usrp_sink_0.set_center_freq(1.5e9, 0)
[...]

Now, what GRC generates here means that you first set your time, then
you set your sampling rate – and on B2xx, that might have the side
effect of changing your master clock rate. The MCR is the speed at which
the internal time counter is incremented.

You can avoid that auto-MCR behaviour by explicitely setting the master
clock rate first – could you add "master_clock_rate=30e3" to your device
Address or device Arguments?

Best regards,
Marcus

On 04/25/2016 04:09 PM, Michael Skaggs wrote:
> Hey Marcus,
>
> In GRC, I have a USRP Source block with "Sync" set to "Unknown PPS"
> and "Timing Source" set to "External". I assumed the device would be
> setting time based on the external PPS using these parameters. The
> synchronize(S0) LED goes solid (after about half a second of
> recording, maybe less) and the other LED (S1) is blinking with the PPS.
>
> Thanks,
> Michael
>
> On Fri, Apr 22, 2016 at 11:56 AM, Marcus Müller
> > wrote:
>
> Are you sure you're setting the device time correctly? 2.5ms
> offset is definitely much much worse than what to devices that
> should have the same device time should exhibit. So:
> How are you setting the device time?
>
> Best regards,
> Marcus
>
>
> On 04/21/2016 08:59 PM, Michael Skaggs wrote:
>> Aha! You were correct. I was parsing the header incorrectly.
>> However, even after parsing, and the more accurate values (now
>> accurate to 10e-6), it appears the recorded RF data sets are
>> still are offset from each other by an amount of nearly 2.5e-3
>> seconds. Any idea why this would be? It's strange, especially
>> considering that the are synchronized to the same PPS, and I
>> think the time is with reference to the pulse.
>>
>> Michael
>>
>> On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech
>> > wrote:
>>
>> On 04/21/2016 11:41 AM, Michael Skaggs wrote:
>>
>> I'm trying to time/sample synchronize RF recordings with
>> two B200minis. I am using the detached Metadata File Sink
>> in GRC. Both recordings are at 30MSps and both B200mini
>> boards are synchronized to the same 1PPS signal.
>>
>> My issue is this, when I extract the data from the
>> Metadata header file, the "rx_time" value is only
>> accurate to 10e-4 seconds (0.0001s). Which, with a
>> recording at 30MSps, this will only give me a sample
>> alignment accuracy to 10e-4(s)*30(MS/s) = 30,000 samples.
>>
>> If I'm attempting to align the two recordings by samples
>> or time, this is not nearly accurate enough. Is there a
>> way that I can get more accuracy out of my metadata
>> header or a way that I can synchronize the recordings of
>> these B200minis?
>>
>> Thanks,
>> Michael
>>
>> The precision of the timestamps from UHD should have a
>> precision of whatever the master-clock is on the device--how
>> are you interpreting
>>   the rx_time tag?  It's two parts--a uint64 with the
>> full-seconds portion, and a double-precision float for the
>> fractional part.
>>
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?

[Michael Skaggs]

Hey Marcus,

In GRC, I have a USRP Source block with "Sync" set to "Unknown PPS" and
"Timing Source" set to "External". I assumed the device would be setting
time based on the external PPS using these parameters. The synchronize(S0)
LED goes solid (after about half a second of recording, maybe less) and the
other LED (S1) is blinking with the PPS.

Thanks,
Michael

On Fri, Apr 22, 2016 at 11:56 AM, Marcus Müller 
wrote:

> Are you sure you're setting the device time correctly? 2.5ms offset is
> definitely much much worse than what to devices that should have the same
> device time should exhibit. So:
> How are you setting the device time?
>
> Best regards,
> Marcus
>
>
> On 04/21/2016 08:59 PM, Michael Skaggs wrote:
>
> Aha! You were correct. I was parsing the header incorrectly. However, even
> after parsing, and the more accurate values (now accurate to 10e-6), it
> appears the recorded RF data sets are still are offset from each other by
> an amount of nearly 2.5e-3 seconds. Any idea why this would be? It's
> strange, especially considering that the are synchronized to the same PPS,
> and I think the time is with reference to the pulse.
>
> Michael
>
> On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech 
> wrote:
>
>> On 04/21/2016 11:41 AM, Michael Skaggs wrote:
>>
>>> I'm trying to time/sample synchronize RF recordings with two B200minis.
>>> I am using the detached Metadata File Sink in GRC. Both recordings are at
>>> 30MSps and both B200mini boards are synchronized to the same 1PPS signal.
>>>
>>> My issue is this, when I extract the data from the Metadata header file,
>>> the "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which,
>>> with a recording at 30MSps, this will only give me a sample alignment
>>> accuracy to 10e-4(s)*30(MS/s) = 30,000 samples.
>>>
>>> If I'm attempting to align the two recordings by samples or time, this
>>> is not nearly accurate enough. Is there a way that I can get more accuracy
>>> out of my metadata header or a way that I can synchronize the recordings of
>>> these B200minis?
>>>
>>> Thanks,
>>> Michael
>>>
>>> The precision of the timestamps from UHD should have a precision of
>> whatever the master-clock is on the device--how are you interpreting
>>   the rx_time tag?  It's two parts--a uint64 with the full-seconds
>> portion, and a double-precision float for the fractional part.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> 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

Re: [Discuss-gnuradio] stream_mux tag propagation

[Andrej Rode]

Hey Merlin,

> The tagged_stream_mux uses the packet_len tags to determine the input
> lengths. It outputs a new packet_len that is the sum of the input
> packet_lens. So here you also loose information about the streams that were
> muxed.
>
> What sense would the standard tag propagation make in this case?

I have adjusted the tag propagation policy to at match least your example. But
it should be able to handle tag propagation in general preserving tag position
relative to its original stream.

If you have installed GNU Radio from git-master you should be able to apply
this patch and compile GNU Radio with it. I will submit a pull request, maybe
this patch will be in master soon.

Best Regards,
Andrej


From 512bd5d2b082807c6687a546d5fe096c9c9b7af6 Mon Sep 17 00:00:00 2001
From: Andrej Rode 
Date: Mon, 25 Apr 2016 14:33:17 +0200
Subject: [PATCH] gr-blocks: fix tag propagation policy for stream mux block

---
 gr-blocks/lib/stream_mux_impl.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/gr-blocks/lib/stream_mux_impl.cc b/gr-blocks/lib/stream_mux_impl.cc
index 698cf89..4d5e71b 100644
--- a/gr-blocks/lib/stream_mux_impl.cc
+++ b/gr-blocks/lib/stream_mux_impl.cc
@@ -53,6 +53,7 @@ namespace gr {
 }
   }
   d_residual = d_lengths[d_stream];
+  set_tag_propagation_policy(TPP_DONT);
 }

 void
@@ -76,6 +77,7 @@ namespace gr {
   const char *in;
   int out_index = 0; // Items written
   gr_vector_int input_index(d_lengths.size(), 0); // Items read
+  std::vector stream_t;

   while (out_index < noutput_items) {
 if (ninput_items[d_stream] <= input_index[d_stream]) {
@@ -91,6 +93,12 @@ namespace gr {
 );
 in = (const char *) input_items[d_stream] + input_index[d_stream]*d_itemsize;
 memcpy([out_index*d_itemsize], in, items_to_copy*d_itemsize);
+get_tags_in_window(stream_t, d_stream,input_index[d_stream],input_index[d_stream] + items_to_copy);
+BOOST_FOREACH(gr::tag_t t, stream_t){
+  t.offset = t.offset - nitems_read(d_stream) - input_index[d_stream] + nitems_written(0) + out_index;
+  add_item_tag(0, t);
+}
+
 out_index += items_to_copy;
 input_index[d_stream] += items_to_copy;
 d_residual -= items_to_copy;
--
2.7.3



signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Jason Matusiak]

My apologies, just double-checked and I was looking at an older version.
Try updating, it should be fixed now.


I just pulled down the latest and still get the same UHD CMakeList error.  
Nathan W
sat down at my laptop last THUR and poked around and seemed to be stumped as 
well (though
he couldn't recreate it on his laptop).

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

Re: [Discuss-gnuradio] OS X GnuRadio Tutorial question

[Michael Dickens]

Hi Jim - Great to hear from another OS X GNU Radio user!
 
The issue is likely that MacPorts' 'python' expects its packages to be
installed into /opt/local somewhere, not /usr/local . I sure there's a
way to set various environment variables to find the installed files,
but it's easier to just install them where MacPorts' Python and Apple's
library loader (DYLD) will look for them.
 
Here's what I would recommend *** all from your OOT's build
directory ***:
 
1) "make uninstall" (sudo or not as needed); hopefully this step will
   remove everything from /usr/local that it installed. If not, I'd
   highly recommend removing it by hand.
 
2) if the build directory is separate from the source directory (as we
   recommend), then "rm -rf *". If they are the same, then do "make
   clean" or "make distclean" to remove the build cruft. You do,
   unfortunately, need to start with a clean CMake build.
 
3) Follow the instructions from <
   
http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall#Compiling-GNU-Radio-from-Source
   >, but add in to the CMake command line "-
   DCMAKE_INSTALL_PREFIX=/opt/local" (as described towards the end of
   that section in the paragraph starting "By default ..."). You can
   choose some other compiler via changing the "CC=... CXX=..." parts;
   or, just omit them entirely to use the defaults provided by Xcode.
 
3.1) "make"
3.2) "make test"
 
4) "sudo make install" to get your OOT installed into /opt/local ...
   you'll need the "sudo" because you're installing into the normal
   MacPorts area, which by default is owned by "root". If you look
   through where files are installed, they should be into:
 
/opt/local/bin/
/opt/local/lib/
/opt/local/share/gnuradio/
/opt/local/share/cmake/
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2-
.7/site-packages/
 
... and, if not, then I/we need to work on fixing  options to work more
robustly (at least for OS X).
 
Hope this helps! - MLD
 
On Mon, Apr 25, 2016, at 06:22 AM, jim Schimpf wrote:
> I have installed GnuRadio via “port” on OS X 10.11.4 and it runs with
> my RTL dongle.  I am working through the GnuRadio Tutorials and am on
> this one
> (http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python)
> building new blocks. I have followed the tutorial, building the
> multiply_py_ff block and run it directly in Python which works.  When
> I try to build it so gnuradio-companion can use it all the steps work
> except for the last “sudo ldconfig” as ”ldconfig” is not present. in
> OS X  The block does not appear in the list of available blocks when I
> run gnuradio-companion.
>
> The "make install" ran OK and put things in the right places. How do I
> fix this so the new block appears in gnuradio-companion ?  I searched
> the group and didn’t find a reference to this particular problem.
>
> The make install did write the XML to the block directory that gnuradio-
> companion uses:
>
> ---
> -- Installing:
> /usr/local/share/gnuradio/grc/blocks/tutorial_multiply_py_ff.xml
>
> Startup of gnuradio-companion
>
> Preferences file: /Users/jim/.gnuradio/grc.conf
> Block paths:
>  /opt/local/share/gnuradio/grc/blocks
>  /Users/jim/.grc_gnuradio
> ---
>
> Thank you for the help.
>
> Also I am using PyCharm as my Python IDE and found to use it on my
> install of GnuRadio I created a new project and set the Python
> interpreter to /opt/local/bin/python2.7. it then works just fine with
> the GnuRadio python code.
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OS X GnuRadio Tutorial question

[jim Schimpf]

Hi,
 I have installed GnuRadio via “port” on OS X 10.11.4 and it runs with 
my RTL dongle.  I am working through the GnuRadio Tutorials and am on this one 
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python
 
)
 building new blocks. I have followed the tutorial, building the multiply_py_ff 
block and run it directly in Python which works.  When I try to build it so 
gnuradio-companion can use it all the steps work except for the last “sudo 
ldconfig” as ”ldconfig” is not present. in OS X  The block does not appear in 
the list of available blocks when I run gnuradio-companion.  

The "make install" ran OK and put things in the right places. How do I 
fix this so the new block appears in gnuradio-companion ?  I searched the group 
and didn’t find a reference to this particular problem.

The make install did write the XML to the block directory that 
gnuradio-companion uses:

---
-- Installing: /usr/local/share/gnuradio/grc/blocks/tutorial_multiply_py_ff.xml

Startup of gnuradio-companion

Preferences file: /Users/jim/.gnuradio/grc.conf
Block paths:
/opt/local/share/gnuradio/grc/blocks
/Users/jim/.grc_gnuradio
---

Thank you for the help.

Also I am using PyCharm as my Python IDE and found to use it on my 
install of GnuRadio I created a new project and set the Python interpreter to 
/opt/local/bin/python2.7. it then works just fine with the GnuRadio python code.


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