[Discuss-gnuradio] how to use raw2num_f.c file

[Maheshkumar Pandit]

Hello every buddy


  can one guide me how we can use the code of
*raw2num_f.c* in gnuradio-companion.that code available on line ...just
type the word.


.guide me if you know i need it in my work

-- 
*Thanks and regard:*


*MR.Maheshkumar Pandit*

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

Re: [Discuss-gnuradio] how to use raw2num_f.c file

[Manu T S]

Mahesh,

I am not sure if it can be used as a block in gnuradio-companion.

This is how I understand it.
What this code does is to read from a binary file containing float
numbers(for example the data that gets dumped by a file sink with float
input type) and stores it in a text file so that you can read it easily.

If this is what you want, you can do it as follows.
1. Download the code.
2. Compile the code by running gcc raw2num_f.c -o raw2num_f
The above step gives you the executable raw2num_f which you can run to
convert raw floating point data to a text file.

For that you have to run

raw2num_f   [offset] [number of numbers]



On Thu, Feb 13, 2014 at 2:45 PM, Maheshkumar Pandit
wrote:

> Hello every buddy
>
>
>   can one guide me how we can use the code of
> *raw2num_f.c* in gnuradio-companion.that code available on line ...just
> type the word.
>
>
> .guide me if you know i need it in my work
>
> --
> *Thanks and regard:*
>
>
> * MR.Maheshkumar Pandit*
>
> *call @ 9662784649*
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Issue with the installation of GNU Radio

[Tom Rondeau]

On Wed, Feb 12, 2014 at 3:55 PM, Ruecan  wrote:
> Hi GR,
>
> I have installed GR 3.7 everything went ok, except that I forgot to set the
> PKG_CONFIG_PATH env. var.
>
> with
> export
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/lib/pkgconfig:/lib/pkgconfig
>
> I just modified "gr-uhd/lib/usrp_source_impl.cc" and
> "gr-uhd/lib/usrp_sink_impl.cc".
> afterwhat I make then make install then got
>
> CMake Error at cmake_install.cmake:36 (FILE):
>   file cannot create directory: /usr/local/lib64/pkgconfig.  Maybe need
>   administrative privileges.
>
> My question is to apply my modifications on gr-uhd and make install, do I
> need to rm CMakeCache and make clean and cmake, make, make install Or I
> should do that the whole GNU Radio to take into account the PKG_CONFIG_PATH
> env. var. ?
>
> Regards,

You are trying to install into /usr/local, which probably is probably
write protected by normal users. You'll need to run 'sudo make
install' at this stage. Unless you aren't meaning to install into
/usr/local, which case, you should rerun cmake and pass it the
appropriate -DCMAKE_INSTALL_PREFIX value.

Tom

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

Re: [Discuss-gnuradio] Resolved CtrlPort build problem

[Tom Rondeau]

On Sun, Feb 9, 2014 at 1:39 AM, Tom McDermott  wrote:
> Have resolved my CtrlPort build problem on Ubuntu.
>
> ICE 3.4 will not build under GCC 4.7 or 4.8.  I installed ICE 3.5 for Ubuntu
> 13.10 using the following script, claimed to work for Raring or later [1].
> ice installed OK, ice-dev did not. Apparently ice-dev not needed, so
> consider eliminating it from the script below.
>
> $ sudo su
> # wget http://www.zeroc.com/download/Ice/3.5/ubuntu/ice3.5-raring.list -O- >
> /etc/apt/sources.list.d/ice3.5-raring.list
> # wget http://www.zeroc.com/download/RPM-GPG-KEY-zeroc-release -O- | apt-key
> add -
> # apt-get update
> # apt-get install ice ice-dev


That's good information. Generally, I've just built ICE for C++ and
Python by hand and install it into /opt/Ice-${version}.


> When running Control Port monitor I get a screen with the running
> performance values for all the blocks, but no graphics of any kind. Is this
> normal?  Is there a way to dump the performance text values to a file?
>
> -- Tom, N5EG
>
>
> [1]
> http://crysol.github.io/recipe/2013-09-19/ice35-deb-packages-from-zeroc/#.UvchUvjiB2W


Sorry, I know you've sent a few mails to the list, so I can't remember
if you've fully solved the display issue (I feel like you have). But
just for the record, given a flowgraph, you can call the
pc__ functions on any given block to retrieve the counter.
During runtime, this is obviously just a sampling, but there is also
the work_time_total PC that accumulates the amount of time the given
work function used during the run of the flowgraph. All this is
described in the manual page:
http://gnuradio.org/doc/doxygen/page_perf_counters.html

Tom

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

Re: [Discuss-gnuradio] Some fairy C++ error in gr-filter

[Tom Rondeau]

On Mon, Feb 10, 2014 at 5:13 AM, Gisle Vanem  wrote:
> "Tom Rondeau"  wrote:
>
>> OS? GNU Radio version?
>>
>
> On Win-XP SP3 + GR version stright from the git-repo (in case it
> matters, but I doubt it). The C++ errors are on generated code
> and AFAICS, the OS is not a variable in this case. But maybe the
> '__declspec(dllexport)' could be an issue.
>
> Thanks for answering.
>
> --gv

No, the error you are showing doesn't really make any sense. But you
also gave us a set of g++ arguments that are not what we would
normally use in GNU Radio. Are you trying to compile this by hand and
not use the cmake/make build system?

Tom



>> On Fri, Feb 7, 2014 at 10:50 AM, Gisle Vanem  wrote:
>>>
>>> Hi list. My 1st post here.
>>> I have a big problem with CMake and some of the generated
>>> files under gr-filter/lib. E.g. here is a snippet from it:
>>>
>>> #include "fir_filter_ccc.h"
>>> #include 
>>> #include 
>>>
>>> namespace gr {
>>>  namespace filter {
>>>   fir_filter_ccc::sptr
>>>fir_filter_ccc::make(int decimation, const std::vector
>>> &taps)
>>>{
>>>  return gnuradio::get_initial_sptr(new fir_filter_ccc
>>> (decimation, taps));  ///  <<< line 40
>>>}
>>>
>>> At line 40 my g++ 4.7.2 starts yelling w/o me understanding what it says.
>>> Here is the 1st error (edited):
>>>
>>> fir_filter_ccc_impl.cc: In static member function 'static
>>> gr::filter::fir_filter_ccc::
>>>  sptr gr::filter::fir_filter_ccc::make(int, const
>>> std::vector >&)':
>>> fir_filter_ccc_impl.cc:40:23: error: cannot allocate an object of
>>> abstract
>>> type
>>>  'gr::filter::fir_filter_ccc'
>>>
>>> What's this? Is this because 'FILTER_API' is an dllexport? Or is my
>>> fir_filter_ccc_impl.cc generated incorrectly? What is that file and
>>> fir_filter_ccc.h supposed to look like?
>>>
>>> Some info for you: 'g++ -fconserve-space -c -DDEBUG -g -O1 -Wall' ..etc.
>>>
>>> Thanks in advance.
>>>
>>> --gv
>
>

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

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Tom Rondeau]

On Sun, Feb 9, 2014 at 4:19 AM, Perper  wrote:
> Hi all,
>
> Interruptions transmission over Gigabit Ethernet when receiving samples
> from USRP can happen at highest data rates no matter how many tricks you
> use with your network card (I have experience with N200/N210).
>
> The loss of part of the signal results with synchronization loss in data
> transmission systems. There is possibility to handle this problem by
> catching rx_time stream tags.
>
> But there might be a solution to keep synchronization that might work
> quite well with gr-blocks that don't handle stream tags.
>
> What if USRP UHD Source gave user an option to fill all of the gaps in
> signal with exact number of lost samples (for example with zeros).
> Additionally it could produce stream tags with position and length of
> each gap so it would be easy to store a file with continuous signal
> stream paired with a file containing metadata describing where and for
> how long the signal samples were lost.
>
> Is it possible to do exactly what I'm describing with current gnuradio
> blocks?
> In my case it would often make many things I do easier.
>
> --
> Best Regards,
> Piotr Krysik


It seems possible. And I recall that someone else asked about this
method before, too. Honestly, though, this falls into the category of
things that "we" (the maintainers) don't have a strong interest in
doing or developing. Which just means that if you need it, experiment
with it and send us a patch if you get it to work really want to get
it into the main code.

Tom

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

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Matt Ettus]

Piotr,

One problem is that if you cannot keep up, adding in all-zeros data will
just make it harder to keep up.  In general, modern PCs should be able to
keep up with 25 MS/s without problem unless you are doing a lot of
processing.  We are actually able to keep up with 300 MS/s on the X300.  So
the question is more about why the app can't keep up.

An alternative might be to stream to a file.  That should keep up without
dropping as long as you have a fast drive.  Then you can process samples
from that file at the pace your app can keep up with.

Matt



On Sun, Feb 9, 2014 at 1:19 AM, Perper  wrote:

> Hi all,
>
> Interruptions transmission over Gigabit Ethernet when receiving samples
> from USRP can happen at highest data rates no matter how many tricks you
> use with your network card (I have experience with N200/N210).
>
> The loss of part of the signal results with synchronization loss in data
> transmission systems. There is possibility to handle this problem by
> catching rx_time stream tags.
>
> But there might be a solution to keep synchronization that might work
> quite well with gr-blocks that don't handle stream tags.
>
> What if USRP UHD Source gave user an option to fill all of the gaps in
> signal with exact number of lost samples (for example with zeros).
> Additionally it could produce stream tags with position and length of
> each gap so it would be easy to store a file with continuous signal
> stream paired with a file containing metadata describing where and for
> how long the signal samples were lost.
>
> Is it possible to do exactly what I'm describing with current gnuradio
> blocks?
> In my case it would often make many things I do easier.
>
> --
> Best Regards,
> Piotr Krysik
>
> ___
> 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] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Marcus D. Leech]

On 02/13/2014 11:19 AM, Matt Ettus wrote:


Piotr,

One problem is that if you cannot keep up, adding in all-zeros data 
will just make it harder to keep up.  In general, modern PCs should be 
able to keep up with 25 MS/s without problem unless you are doing a 
lot of processing.  We are actually able to keep up with 300 MS/s on 
the X300.  So the question is more about why the app can't keep up.


An alternative might be to stream to a file.  That should keep up 
without dropping as long as you have a fast drive.  Then you can 
process samples from that file at the pace your app can keep up with.


Matt

And on a tangentially-related note, SSDs aren't necessarily fast 
writers.   Particularly if they aren't using an AHCI interface and/or, 
they're

  early-generation.  I found this out the hard way...






On Sun, Feb 9, 2014 at 1:19 AM, Perper > wrote:


Hi all,

Interruptions transmission over Gigabit Ethernet when receiving
samples
from USRP can happen at highest data rates no matter how many
tricks you
use with your network card (I have experience with N200/N210).

The loss of part of the signal results with synchronization loss
in data
transmission systems. There is possibility to handle this problem by
catching rx_time stream tags.

But there might be a solution to keep synchronization that might work
quite well with gr-blocks that don't handle stream tags.

What if USRP UHD Source gave user an option to fill all of the gaps in
signal with exact number of lost samples (for example with zeros).
Additionally it could produce stream tags with position and length of
each gap so it would be easy to store a file with continuous signal
stream paired with a file containing metadata describing where and for
how long the signal samples were lost.

Is it possible to do exactly what I'm describing with current gnuradio
blocks?
In my case it would often make many things I do easier.

--
Best Regards,
Piotr Krysik

___
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



--
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-lte updated to GNU Radio 3.7 API

[Passas Virgilios]

Hello,

I ‘m trying to generate the LTE_flowgraph_top_level.grc but the Decode PBCH 
block is missing due to an error in decode_pbch_37.grc .
The error is the following:

Error 0:
Connection (
  Block - lte_qpsk_soft_demod_vcvf_0 - QPSK soft demod(lte_qpsk_soft_demod_vcvf)
Source - out(0)
  Block - lte_pbch_descrambler_vfvf_0 - PBCH 
Descrambler(lte_pbch_descrambler_vfvf)
Sink - in(0)
):
  Source IO size "1920" does not match sink IO size "7680”.

Correlating the grc with the images at docs folder, I can see that the input is 
a vector with length 240 and the input of PBCH Descrambler is a vector with 
length 480.


Also some tests failed due to this error:

import lte_swig as lte
ImportError: No module named lte_swig


How should I proceed?

Virgilios

On Jan 7, 2014, at 9:56, Mike Cornelius  wrote:

> Hi Johannes,
> 
> I'm back at work after the new year break and have had a chance to try this 
> again, and I think I have it working !!
> The problem was with my test waveform, I've captured a new test waveform and 
> I can now sync to the DL signal and decode the MIB.
> 
> Mike
> 
> 
> 
> On 21 December 2013 04:26, Johannes Demel  wrote:
> Hi,
> 
> regarding the different parameters. 'tx_diversity' should always be left as 
> it is. In case of a 1x1 MIMO configuration it will just have no effect. This 
> parameter reflects the LTE standard with its two options 'tx_diversity' and 
> 'spatial_multiplexing'. The latter isn't used for control channels.
> In order to specify a certain bandwidth, use the parameter 'N_rb_dl', which 
> specifies the number of resource blocks used. This will also set the 
> bandwidth as this is the unit given by the system to determine the bandwidth. 
> e.g. have a look at the paper which is included in the project there is a 
> table which shows the dependencies.
> 25 RBs --> 25*12 = 300 subcarrier --> 15kHz * 300 + spacing = 5MHz.
> The FFT length can be chosen freely as long as it provides sufficient bins to 
> match the current number of subcarriers. It will be used to determine the 
> input sample rate. I suggest you stick with power of 2 values. Those are the 
> only ones I tested and the numbers the system is designed for. One more 
> thing, a FFT length shorter than 256 results in fractional CP lengths, which 
> should be avoided. LTE's CP use is already quite tricky and the introduction 
> of fractional CP lengths will not ease the situation.
> PBCH decoding is handled for one and two antenna configurations, so you don't 
> have to worry about configuring the flowgraph there.
> PCFICH decoding will receive a message on runtime which sets the decoded 
> antenna configuration.
> 
> Happy hacking
> Johannes
> 
> 
> On Fri, Dec 20, 2013 at 2:39 AM, Baier  wrote:
> Hi Johannes,
> 
> thank you very much for updating your gr-lte package. I could compiled all 
> .grc files succesfully. Now I would like to test your receiver with a LTE 
> signal saved to a file with the following settings.( 5 MHz, RB 25, fft 512, 
> occupied carriers 300, no tx diversity). So I have started to change the 
> parameters in your grc files.
> RB 25 instead 50
> fftlen 512 instead 2048(is it right?)
> occupied carriers 300 instead 600.
> So I have realized the files decode_pcfich_37.grc and decode_pbch_37 .grc are 
> designed for tx_diversity with two antennas. How can I change it? Removing 
> the blocks for the second antenna perhaps?
> Thank you very much.
> A. Baier
> 
> 
> 
> 
>
> 
> ___
> 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] Half-Duplex Relay

[David Halls]

Hi Martin and all,

I am looking at some AF stuff for now, where the delay is much better.

I am using something similar to HPD at the relay to implement some gain to the 
payload samples only. I call

// Copy header
copy_n_symbols(in, out, 0, samples_per_header);
// Copy payload
copy_n_symbols(in, out, 0, samples_per_payload);

where the function is:

void packet_detector_impl::copy_n_symbols(const unsigned char *in, unsigned 
char *out, int port, int n_symbols)
{
// Copy samples
memcpy((void *) out, (void *) in, n_symbols*sizeof(gr_complex));
// Copy tags
std::vector tags;
get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) + n_symbols);
for (unsigned t = 0; t < tags.size(); t++)
{
int new_offset = tags[t].offset - nitems_read(0);
add_item_tag(port, nitems_written(port) + new_offset, tags[t].key, 
tags[t].value);
}
}

My questions is probably stupid, but I want to multiply the payload symbols by 
a certain gain, say 'G', but I am not clear how to do it.  I am not clear how 
to access the items individually to scale them.

As a first step, I tried first replacing the memcpy with

  for(int i = 0; i < samples_per_packet; i++) out[i] = in[i];

but that of course doesn't successfully replace the functionality?

Regards,

David


From: Martin Braun [martin.br...@ettus.com]
Sent: 30 January 2014 15:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On 30.01.2014 16:49, David Halls wrote:
> Thanks Martin,
>
> So your recommendation would be not to spend too much time poking around
> with USRP latency stuff:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency

This is an excellent guide, and a good read. In this case, I doubt UHD
is the limiting factor.

> Is there an obvious way to benchmark the latency in GNU Radio? I have
> basically stuck your decoder and encoders back to back in the relay
> code, so it is pretty intensive. I suppose that implementing some of it
> in the FPGA may help? I have no experience in that field at all though...

It would certainly help, but you'd be looking at an absurd amount of
work. I can't think of a good pure GNU Radio way to measure latency, though.

> The current implementation is enough to show proof of concept but is
> very inefficient.

That's true, but given that it's clicked together, 10 ms latency is not
all that bad.

> Is there an obvious way to increase the payload length without getting
> buffer issues in the code - have you ever tried increasing it
> significantly in your implementation?

See Aditya's question. Tagged stream blocks operate on one packet at a
time, so it's limited.

MB



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Sylvain Munaut]

Hi,

> One problem is that if you cannot keep up, adding in all-zeros data will
> just make it harder to keep up.  In general, modern PCs should be able to
> keep up with 25 MS/s without problem unless you are doing a lot of
> processing.  We are actually able to keep up with 300 MS/s on the X300.  So
> the question is more about why the app can't keep up.

Well, sometimes the issue isn't so much throughput but latency. Like
you have some ultra high priority task that decides to block all
processing for like 100 ms and some buffer fill up and you miss one
packet ever few minutes. I have that kind of stuff all the time on a
USRP1. It's not a real time OS so it's always better IMHO to be able
to cope gracefully with theses little glitches.

And if you're app expects a continuous stream of data to maintain
alignement, filling with zero is easy enough.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Virgilios,

This sounds like an interface mismatch between blocks. To answer your
question accurately it would be very helpful to know which version of
GNU Radio and which gr-lte version you use. Branch and day of last
commit should be sufficient. Also tell us about your general setup.
Which OS are you using?

happy hacking
Johannes

On 13.02.2014 18:40, Passas Virgilios wrote:
> Hello,
> 
> I ‘m trying to generate the LTE_flowgraph_top_level.grc but the
> Decode PBCH block is missing due to an error in decode_pbch_37.grc
> . The error is the following:
> 
> Error 0: Connection ( Block - lte_qpsk_soft_demod_vcvf_0 - QPSK
> soft demod(lte_qpsk_soft_demod_vcvf) Source - out(0) Block -
> lte_pbch_descrambler_vfvf_0 - PBCH 
> Descrambler(lte_pbch_descrambler_vfvf) Sink - in(0) ): Source IO
> size "1920" does not match sink IO size "7680”.
> 
> Correlating the grc with the images at docs folder, I can see that
> the input is a vector with length 240 and the input of PBCH
> Descrambler is a vector with length 480.
> 
> 
> Also some tests failed due to this error:
> 
> import lte_swig as lte ImportError: No module named lte_swig
> 
> 
> How should I proceed?
> 
> Virgilios
> 
> On Jan 7, 2014, at 9:56, Mike Cornelius  > wrote:
> 
>> Hi Johannes,
>> 
>> I'm back at work after the new year break and have had a chance
>> to try this again, and I think I have it working !! The problem
>> was with my test waveform, I've captured a new test waveform and
>> I can now sync to the DL signal and decode the MIB.
>> 
>> Mike
>> 
>> 
>> 
>> On 21 December 2013 04:26, Johannes Demel
>> mailto:johannes.de...@ettus.com>>
>> wrote:
>> 
>> Hi,
>> 
>> regarding the different parameters. 'tx_diversity' should always 
>> be left as it is. In case of a 1x1 MIMO configuration it will
>> just have no effect. This parameter reflects the LTE standard
>> with its two options 'tx_diversity' and 'spatial_multiplexing'.
>> The latter isn't used for control channels. In order to specify a
>> certain bandwidth, use the parameter 'N_rb_dl', which specifies
>> the number of resource blocks used. This will also set the
>> bandwidth as this is the unit given by the system to determine
>> the bandwidth. e.g. have a look at the paper which is included in
>> the project there is a table which shows the dependencies. 25 RBs
>> --> 25*12 = 300 subcarrier --> 15kHz * 300 + spacing = 5MHz. The
>> FFT length can be chosen freely as long as it provides sufficient
>> bins to match the current number of subcarriers. It will be used
>> to determine the input sample rate. I suggest you stick with
>> power of 2 values. Those are the only ones I tested and the
>> numbers the system is designed for. One more thing, a FFT length
>> shorter than 256 results in fractional CP lengths, which should
>> be avoided. LTE's CP use is already quite tricky and the 
>> introduction of fractional CP lengths will not ease the
>> situation. PBCH decoding is handled for one and two antenna
>> configurations, so you don't have to worry about configuring the
>> flowgraph there. PCFICH decoding will receive a message on
>> runtime which sets the decoded antenna configuration.
>> 
>> Happy hacking Johannes
>> 
>> 
>> On Fri, Dec 20, 2013 at 2:39 AM, Baier > > wrote:
>> 
>> Hi Johannes,
>> 
>> thank you very much for updating your gr-lte package. I could 
>> compiled all .grc files succesfully. Now I would like to test 
>> your receiver with a LTE signal saved to a file with the 
>> following settings.( 5 MHz, RB 25, fft 512, occupied carriers 
>> 300, no tx diversity). So I have started to change the parameters
>> in your grc files. RB 25 instead 50 fftlen 512 instead 2048(is it
>> right?) occupied carriers 300 instead 600. So I have realized the
>> files decode_pcfich_37.grc and decode_pbch_37 .grc are designed
>> for tx_diversity with two antennas. How can I change it? Removing
>> the blocks for the second antenna perhaps? Thank you very much. 
>> A. Baier
>> 
>> 
>> 
>> 
>> 
>> 
>> _ 
>> 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS/Q2rAAoJEO7fmkDsqywMBssP/2JxUEthkQMZsiVSQMGVGkbg
CsdjZCzZjFbSjJrmqCPi

[Discuss-gnuradio] WX GUI FFT sink on Raspberry Pi

[Murat Toloğlu]

Hi Jim,

 

You've made a great help, thank you. GnuRadio together with GRC runs now on
my RPi, modules Sinks and Sources appeared on GRC module menu and I could
build Gqrx as well, it also works. As a side issue I think RPi's onboard
audio circuitry and/or audio drivers cause some incompatibility problems and
GRC's produced Python files are also problematical ( I appreciate your
comments on these problems, can pulseaudio helps? )

 

Regarding install process, your recommended procedure worked quite well with
a few comments: First, I needed to install SWIG to activate Python support.
Second, my Gnuradio install directory was /usr instead of the default
expected /usr/local so I made Cmake with install prefix as "cmake ..
-DCMAKE_INSTALL_PREFIX=/usr " . I think adjusting Gnuradio install directory
to /usr/local during "sudo apt-get install gnuradio" process can be a better
solution but I don't know yet how to make it (I'll search).

 

I have to state also another issue that may be important and should be taken
into consideration : Upon your first advise I added "deb
http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free
rpi" line to the /etc/apt/sources.list file. But afterwards I realized that
there is an existing line same as the new one but with  "wheezy"!
Considering that this may cause problems I had applied the full Jessie
install procedure explained here
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=47944  before I tried
your recent recommendations. This took 2-3 hours operation and added about 1
GB new files, probably slows the RPi and I am not sure whether it was
necessary or not. Today I will make a fresh Raspbian SD card and I'll try
again the full procedure from start but  without installing full Jessie.

 

Keep in touch,

 

73,

Murat

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

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Matt Ettus]

That's true.  You can fix some of the issues by using preemptible kernels
and setting RTPRIO, but there can still be glitches.  Certainly a block
which reads the streams tags and inserts zeros would not be too hard.

Matt



On Thu, Feb 13, 2014 at 10:20 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
> > One problem is that if you cannot keep up, adding in all-zeros data will
> > just make it harder to keep up.  In general, modern PCs should be able to
> > keep up with 25 MS/s without problem unless you are doing a lot of
> > processing.  We are actually able to keep up with 300 MS/s on the X300.
>  So
> > the question is more about why the app can't keep up.
>
> Well, sometimes the issue isn't so much throughput but latency. Like
> you have some ultra high priority task that decides to block all
> processing for like 100 ms and some buffer fill up and you miss one
> packet ever few minutes. I have that kind of stuff all the time on a
> USRP1. It's not a real time OS so it's always better IMHO to be able
> to cope gracefully with theses little glitches.
>
> And if you're app expects a continuous stream of data to maintain
> alignement, filling with zero is easy enough.
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Σχετ: gr-lte updated to GNU Radio 3.7 API

[virgil passas]

Hi Johannes,

Sorry for not mentioned the versions.
GNU Radio 3.7.2.1
gr-lte branch-master, latest commit 3ded865f40cc43224eca66a6692fa90655a25b62
Ubuntu 13.04 64-bit



Virgilios





Στις 8:24 μ.μ. Πέμπτη, 13 Φεβρουαρίου 2014, ο/η Johannes Demel 
 έγραψε:
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Virgilios,

This sounds like an interface mismatch between blocks. To answer your
question accurately it would be very helpful to know which version of
GNU Radio and which gr-lte version you use. Branch and day of last
commit should be sufficient. Also tell us about your general setup.
Which OS are you using?

happy hacking
Johannes

On 13.02.2014 18:40, Passas Virgilios wrote:
> Hello,
> 
> I ‘m trying to generate the LTE_flowgraph_top_level.grc but the
> Decode PBCH block is missing due to an error in decode_pbch_37.grc
> . The error is the following:
> 
> Error 0: Connection ( Block - lte_qpsk_soft_demod_vcvf_0 - QPSK
> soft demod(lte_qpsk_soft_demod_vcvf) Source - out(0) Block -
> lte_pbch_descrambler_vfvf_0 - PBCH 
> Descrambler(lte_pbch_descrambler_vfvf) Sink - in(0) ): Source IO
> size "1920" does not match sink IO size "7680”.
> 
> Correlating the grc with the images at docs folder, I can see that
> the input is a vector with length 240 and the input of PBCH
> Descrambler is a vector with length 480.
> 
> 
> Also some tests failed due to this error:
> 
> import lte_swig as lte ImportError: No module named lte_swig
> 
> 
> How should I proceed?
> 
> Virgilios
> 
> On Jan 7, 2014, at 9:56, Mike Cornelius  > wrote:
> 
>> Hi Johannes,
>> 
>> I'm back at work after the new year break and have had a chance
>> to try this again, and I think I have it working !! The problem
>> was with my test waveform, I've captured a new test waveform and
>> I can now sync to the DL signal and decode the MIB.
>> 
>> Mike
>> 
>> 
>> 
>> On 21 December 2013 04:26, Johannes Demel
>> mailto:johannes.de...@ettus.com>>
>> wrote:
>> 
>> Hi,
>> 
>> regarding the different parameters. 'tx_diversity' should always 
>> be left as it is. In case of a 1x1 MIMO configuration it will
>> just have no effect. This parameter reflects the LTE standard
>> with its two options 'tx_diversity' and 'spatial_multiplexing'.
>> The latter isn't used for control channels. In order to specify a
>> certain bandwidth, use the parameter 'N_rb_dl', which specifies
>> the number of resource blocks used. This will also set the
>> bandwidth as this is the unit given by the system to determine
>> the bandwidth. e.g. have a look at the paper which is included in
>> the project there is a table which shows the dependencies. 25 RBs
>> --> 25*12 = 300 subcarrier --> 15kHz * 300 + spacing = 5MHz. The
>> FFT length can be chosen freely as long as it provides sufficient
>> bins to match the current number of subcarriers. It will be used
>> to determine the input sample rate. I suggest you stick with
>> power of 2 values. Those are the only ones I tested and the
>> numbers the system is designed for. One more thing, a FFT length
>> shorter than 256 results in fractional CP lengths, which should
>> be avoided. LTE's CP use is already quite tricky and the 
>> introduction of fractional CP lengths will not ease the
>> situation. PBCH decoding is handled for one and two antenna
>> configurations, so you don't have to worry about configuring the
>> flowgraph there. PCFICH decoding will receive a message on
>> runtime which sets the decoded antenna configuration.
>> 
>> Happy hacking Johannes
>> 
>> 
>> On Fri, Dec 20, 2013 at 2:39 AM, Baier > > wrote:
>> 
>> Hi Johannes,
>> 
>> thank you very much for updating your gr-lte package. I could 
>> compiled all .grc files succesfully. Now I would like to test 
>> your receiver with a LTE signal saved to a file with the 
>> following settings.( 5 MHz, RB 25, fft 512, occupied carriers 
>> 300, no tx diversity). So I have started to change the parameters
>> in your grc files. RB 25 instead 50 fftlen 512 instead 2048(is it
>> right?) occupied carriers 300 instead 600. So I have realized the
>> files decode_pcfich_37.grc and decode_pbch_37 .grc are designed
>> for tx_diversity with two antennas. How can I change it? Removing
>> the blocks for the second antenna perhaps? Thank you very much. 
>> A. Baier
>> 
>> 
>> 
>> 
>> 
>> 
>> _ 
>> 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.g

[Discuss-gnuradio] testing FLEX modems with gnuradio

[Al Smith]

I am new to gnuradio and have spent the last few days reading every
tutorial I can find.  I have set up both 3.7.1 and 3.6.5 in separate test
environments in 2 VMs.  I am using a BladeRF SDR with dual 900MHz antenna.

I've been asked to test 2 devices which will controlled remotely over the
FLEX paging network. I can see some blocks have been built into
gnuradio-companion, FLEX Deinterleave and FLEX Synchronizer.  I also found
some samples here https://github.com/argilo/sdr-examples but I think these
were built for a different version of gnuradio possibly.  When I run the
python script pager_rx.py or pager_rx_929.py it pops up with a nice
waterfall display and I even get some text decoded signals in the terminal
window, but within a few seconds the display goes gray and I cannot change
any of the sliders and must force quit to get out.  I loaded the
multi_tx.grc in gnuradio-companion just to get an idea of how to build a
flow chart for FLEX, but I get some errors about missing blocks.

Loading: "/home/test/sandbox/gnuradio-builds/sdr-examples/multi_tx.grc"
>>> Error: Block key "iqbalance_fix_cc" not found in Platform - grc(GNU
Radio Companion)
>>> Error: Connection between blocks_add_xx_0(0) and iqbalance_fix_cc_0(0)
could not be made.
sink block id "iqbalance_fix_cc_0" not in block ids
>>> Error: Connection between iqbalance_fix_cc_0(0) and
blocks_add_const_vxx_1(0) could not be made.
source block id "iqbalance_fix_cc_0" not in block ids
>>> Done

If I'm going to build my own flowcharts, I'll need to know what the blocks
in the existing flows are doing, but I haven't seen any good resources for
that.  If I can get some of the existing scripts to run properly that might
help as well.  Any suggestions on that?  Here is the output when I run the
pager_rx.py

gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2

According to the readme this script is meant to be used with an RTL-SDR
rather than my BladeRF but it seems to detect the blade and I don't see any
hardware specific modules being imported.  Am I missing something?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] testing FLEX modems with gnuradio

[Ron Economos]

Clayton's sdr-examples are for GnuRadio 3.7.1. Your
issue is that you haven't built gr-iqbal. It's not really
needed, so you can just delete that block in the
graphs.

Ron

On 2/13/2014 3:31 PM, Al Smith wrote:
I am new to gnuradio and have spent the last few days reading every 
tutorial I can find.  I have set up both 3.7.1 and 3.6.5 in separate 
test environments in 2 VMs.  I am using a BladeRF SDR with dual 900MHz 
antenna.


I've been asked to test 2 devices which will controlled remotely over 
the FLEX paging network. I can see some blocks have been built into 
gnuradio-companion, FLEX Deinterleave and FLEX Synchronizer.  I also 
found some samples here https://github.com/argilo/sdr-examples but I 
think these were built for a different version of gnuradio possibly. 
 When I run the python script pager_rx.py or pager_rx_929.py it pops 
up with a nice waterfall display and I even get some text decoded 
signals in the terminal window, but within a few seconds the display 
goes gray and I cannot change any of the sliders and must force quit 
to get out.  I loaded the multi_tx.grc in gnuradio-companion just to 
get an idea of how to build a flow chart for FLEX, but I get some 
errors about missing blocks.


Loading: "/home/test/sandbox/gnuradio-builds/sdr-examples/multi_tx.grc"
>>> Error: Block key "iqbalance_fix_cc" not found in Platform - 
grc(GNU Radio Companion)
>>> Error: Connection between blocks_add_xx_0(0) and 
iqbalance_fix_cc_0(0) could not be made.

sink block id "iqbalance_fix_cc_0" not in block ids
>>> Error: Connection between iqbalance_fix_cc_0(0) and 
blocks_add_const_vxx_1(0) could not be made.

source block id "iqbalance_fix_cc_0" not in block ids
>>> Done

If I'm going to build my own flowcharts, I'll need to know what the 
blocks in the existing flows are doing, but I haven't seen any good 
resources for that.  If I can get some of the existing scripts to run 
properly that might help as well.  Any suggestions on that?  Here is 
the output when I run the pager_rx.py


gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 
FPGA v0.0.2


According to the readme this script is meant to be used with an 
RTL-SDR rather than my BladeRF but it seems to detect the blade and I 
don't see any hardware specific modules being imported.  Am I missing 
something?




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

Re: [Discuss-gnuradio] Half-Duplex Relay

[Martin Braun]

On 13.02.2014 10:18, David Halls wrote:

My questions is probably stupid, but I want to multiply the payload
symbols by a certain gain, say 'G', but I am not clear how to do it. I
am not clear how to access the items individually to scale them.

As a first step, I tried first replacing the memcpy with

for(int i = 0; i < samples_per_packet; i++) out[i] = in[i];

but that of course doesn't successfully replace the functionality?


Sure, why not? However, it probably be the solution with the best 
performance. You could stick with the memcpy() and use a VOLK kernel 
afterwards. But your solution seems correct.


M


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

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Martin Braun]

On 09.02.2014 01:19, Perper wrote:

Hi all,

Interruptions transmission over Gigabit Ethernet when receiving samples
from USRP can happen at highest data rates no matter how many tricks you
use with your network card (I have experience with N200/N210).

The loss of part of the signal results with synchronization loss in data
transmission systems. There is possibility to handle this problem by
catching rx_time stream tags.


To sum up this thread, it's probably better if you write your own block 
that keeps track of rx_time tags and fills in zeros, instead of patching 
gr-uhd to do this.


MB

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

Re: [Discuss-gnuradio] testing FLEX modems with gnuradio

[Ron Economos]

I've tried pager_rx.py on bladeRF, and it works fine
here (GnuRadio 3.7.2.1 and Ubuntu 13.04). Tons of
traffic on channel 25 here in Silicon Valley.

I've made some changes to the code to work better
with bladeRF (mostly with the gain setting).

http://www.w6rz.net/pager_rx.py

When a flow grays out and you have to force a
quit, it usually means you don't have enough CPU cycles.
However, at 1.2 Msps, pager_rx.py isn't really taking
much CPU. Perhaps it's your VM?

Ron

On 2/13/2014 3:31 PM, Al Smith wrote:
I am new to gnuradio and have spent the last few days reading every 
tutorial I can find.  I have set up both 3.7.1 and 3.6.5 in separate 
test environments in 2 VMs.  I am using a BladeRF SDR with dual 900MHz 
antenna.


I've been asked to test 2 devices which will controlled remotely over 
the FLEX paging network. I can see some blocks have been built into 
gnuradio-companion, FLEX Deinterleave and FLEX Synchronizer.  I also 
found some samples here https://github.com/argilo/sdr-examples but I 
think these were built for a different version of gnuradio possibly. 
 When I run the python script pager_rx.py or pager_rx_929.py it pops 
up with a nice waterfall display and I even get some text decoded 
signals in the terminal window, but within a few seconds the display 
goes gray and I cannot change any of the sliders and must force quit 
to get out.  I loaded the multi_tx.grc in gnuradio-companion just to 
get an idea of how to build a flow chart for FLEX, but I get some 
errors about missing blocks.


Loading: "/home/test/sandbox/gnuradio-builds/sdr-examples/multi_tx.grc"
>>> Error: Block key "iqbalance_fix_cc" not found in Platform - 
grc(GNU Radio Companion)
>>> Error: Connection between blocks_add_xx_0(0) and 
iqbalance_fix_cc_0(0) could not be made.

sink block id "iqbalance_fix_cc_0" not in block ids
>>> Error: Connection between iqbalance_fix_cc_0(0) and 
blocks_add_const_vxx_1(0) could not be made.

source block id "iqbalance_fix_cc_0" not in block ids
>>> Done

If I'm going to build my own flowcharts, I'll need to know what the 
blocks in the existing flows are doing, but I haven't seen any good 
resources for that.  If I can get some of the existing scripts to run 
properly that might help as well.  Any suggestions on that?  Here is 
the output when I run the pager_rx.py


gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 
FPGA v0.0.2


According to the readme this script is meant to be used with an 
RTL-SDR rather than my BladeRF but it seems to detect the blade and I 
don't see any hardware specific modules being imported.  Am I missing 
something?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio