Re: [Discuss-gnuradio] Using USRP to transmit and receive samples

[Marcus Müller]

Hi!

Quick answer, don't have time right now:
(A) Why did you save them as wav audio? Usually, it's wiser to just store them 
as raw data; see the scripts in gnuradio-core/src/utils/{read,write}*
Note: you're sending symbols from the source, not samples! Use bytes as data 
format.

Answers:
(1) yes, that should do the trick.
(2) no, I think you should replace the CRC generator, unless you want to have 
your symbols interleaved with checksums

Greetings,
Marcus

On 10/19/2013 01:00 AM, JPL wrote:

Hello,

I found out two *.grc files, tx_ofdm and rx_ofdm, under 
gr_digital/examples/ofdm.

Don't know if this can be realized,
first test running the steps without changing any parameters in *.grc.
(A) use *.dat generated from Matlab (I saved a set of wav audio),
(B) place it as input in the tx_ofdm.grc,
(C) send through antenna,
(D) the other USRP execute rx_ofdm.grc
(E) put the output *.dat into Matlab analyzing.

Question:
(1) should I just replace the "Vector Source block" into "File Source" in 
tx_ofdm.grc?
(2) the rx_ofdm.grc, again, am I right just replace "tag debug" with "file 
sink"?

Is this possible?

Sincerely,

















On Fri, Oct 18, 2013 at 5:43 AM, Marcus Müller mailto:mar...@hostalia.de>> wrote:

Hi JPL,

.mat is really just a complicated container format for all kind of matlab 
data -- GNU Radio can't directly deal with that, although with SciPy you could 
create something that will be able to parse .mat files; but that is quite 
useless, as you could as well use Matlab to write something that can be 
directly used with other software.

So to answer question (1.), I'd agree with Nathan: Best way to do it is 
using the existing GNU Radio OFDM tools, not writing code that has already been 
written several times, and start with something that already works. Thereby 
dropping Matlab as your signal processing framework, and only using it for data 
analysis and visualisation.

To comment on (II): GNU Radio has blocks like "file_sink". They will just 
save the samples to a file, in this case, in the format of raw float32s (1 for real, 1 
for imag part) one after another.

To answer (III): If you really want to do that, see the GNU Radio source tree, 
gnuradio-core/src/utils/read_{float,complex,...}_binary.m. There is the same with "write" 
instead of "read".

Greetings,
Marcus



On 10/18/2013 06:53 AM, West, Nathan wrote:

On Thu, Oct 17, 2013 at 11:14 PM, JPL mailto:jplscan...@gmail.com>> wrote:

Hello,

We have used Matlab to generate *.mat file, a file around 1966240 
complex number OFDM samples.
Thinking to (I) transmit between two USRPs, (II) let the receiver side 
saving data into file, and later (III) putting the file on Matlab for 
demodulation.

1. What is the best way to do it? like create GRC blocks? or UHD 
example?
2. How can I make sure that the TX part will stop when those 1966240 
samples are sent. and RX part will stop when completely receiving those 1966240 
samples?
3. Should the file type be the *.dat?

Sincerely,

JPL


I'll attempt to respond to both questions since they are really the same 
thing.

First, this is kind of a weird way to use GNU Radio. GNU Radio provides you an 
environment to do all of the signal processing you want to do in c++ or (if you want) 
python. The flowgraph of file -> transmit antenna --> over the air --> receive 
antenna -> file followed by signal processing in Matlab is sort of not the point of GNU 
Radio. There's nothing saying you cannot do this, but you might look in to  implementing 
whatever signal processing you are doing in GNU Radio. This will reduce the round trip time 
of testing and make the whole experience a little better. ( you're basically doing an even 
slower version of what we call flying blind: 
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Flying-Blind )

Re: your other email and question about GR file sink/source:
About the file sinks... 
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink
Basically it's a binary file just like you would expect if you open a file 
with 'b' flag in most languages I'm familiar with. If you're dumping complex 
floats in there then you'll need to read two float values.

2. There is a block called head. It takes a number of samples to pass 
through and then quits. But again, you might consider your approach here.

3. I've never actually looked in to the format of a .mat file, but 
connecting that (regardless of data inside the file) to a UHD source would be 
spewing garbage out. The .dat extension you might see in GR literature is just 
a convention we use to denote it's data; it's not really a special format.


-Nathan


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

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Marcus Müller]

  
  
Hi Nemanja,
  
  Considering following flowgraph, assume your block is A, and
  assume all blocks work with the same itemsize.
  
  
  good question, but basically, when running, when A is done with a
  run of work, it's thread notifies blocks "upstream" (B in this
  case) that it has consumed  input items, making that space available
  for new output; GNU radio then calls forecast of B with a
  noutput_items  to fill that space. However, if
  the upstream block B needs more input items than C has provided,
  GNU Radio will repeatedly reduce the number of samples it asks for
  until B needs less or equal samples as C has produced. 
  
  In your case, this only happens for 0 output items; thus your
  general_work gets called with 0 input items, as Martin already
  stated. 
  So what happens then? Since A has not provided any more output
  items for the blocks downstream, D can't do anything that it has
  not already been doing. The downstream part of the flowgraph
  stalls. Upstream part: Since GNU Radio has not been able to supply
  you with more than 0 input items, we can assume that the upstream
  part of the flowgraph is stuck, or done.
  Therefore, execution ends here.
  
  Greetings,
  Marcus
  
  
  On 10/18/2013 03:19 PM, Nemanja Savic wrote:


  

  
Thank you Martin, I will try with the sync_decimator,
  but it is also important for me to unterstand what's
  happening here.

So, I have vector source -> throttle -> fsk_modulator
-> scope sink.
  
  Vector source generates 8 symbols. From where scheduler
  starts, from source or from the sink? And why it didn't stop
  for any value before 0? What should I add into general block
  to avoid this?
  

Thank you
  
  

On Fri, Oct 18, 2013 at 2:59 PM, Martin
  Braun (CEL) 
  wrote:
  
On Fri, Oct 18, 2013 at 02:32:48PM +0200,
  Nemanja Savic wrote:
  > The body of my forecast function is:
  >
  > ninput_items_required[0] = noutput_items * d_sym_rate
  / d_sampling_freq;
  > printf("ninput_items_required %d, noutput_items
  %d\n", ninput_items_required
  > [0], noutput_items);
  

If d_sym_rate and d_sampling_freq are integers, integer
division will
cause ninput_items_required to be zero for small values of
noutput_items.

  > when i run execution, the output is following:
  >
  > ninput_items_required 8, noutput_items 4096
  > ninput_items_required 4, noutput_items 2048
  > ninput_items_required 2, noutput_items 1024
  > ninput_items_required 1, noutput_items 512
  > ninput_items_required 0, noutput_items 256
  > ninput: 0, produced: 0
  >
  > The last line of the output comes from general_work
  function and prints number
  > of input items and number of produced output samples.
  >
  > Can somebody explain me why forecast is called 5
  times, till number of input
  > items reach 0, and after that nothing is possible in
  work function, cause it
  > won't enter the loop since ninput_items = 0;
  

Depending on the state of the buffers, the scheduler calls
forecast()
until it finds a value of ninput_items_required that works
(it tries to
process as much as possible). In your case, there is
probably some
situation where the input buffer is not full.
The way you've set up forecast(), the scheduler will
eventually find out
that it doesn't need any items to produce at least 256
output items. So
it calls work() with no input data, expecting 256 output
items.
But since you can't produce anything without input, nothing
happens.

It seems like what you want is a sync_decimator, got a
gr::block. This
means you set relative_rate in the ctor and don't need to
handle all of this
yourself. Make sure you don't set relative_rate to zero,
again!
In a sync_decimator, you won't need forecast() at all and
your work
function is much simpler. The scheduler will also never try
to call a
sycn_decimator w/o input.

MB

--

[Discuss-gnuradio] Complex to bits

[Gui Ritter]

Hi everyone.
Thanks for all the replies on my previous thread. I did some tests and found 
out that the FFT and IFFT do not add noise to my audio signal. It works 
perfectly! The noise is coming from another part of my flowgraph.
Before I introduced the FFT and IFFT, I was working with an audio signal that 
was scaled and converted to int, so it could be unpacked into bits; those bits 
were processed and retrieved, packed, converted to float, descaled and turned 
back to audio. There was no noise then. Adding the FFT and IFFT made me use the 
complex type before the unpacking, so what I was using to make it possible to 
unpack the signal into bits no longer worked properly.
I tried changing the scale constant, converting from complex to IShort and 
unpacking that, but neither worked.
So, my question is: how do I unpack a complex signal into bits, and then pack 
it back? Considering I'm working on a audio signal that shouldn't get noise 
added to it.
Thanks in advance.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Complex to bits

[Gui Ritter]

I just realized that float to bits is also acceptable, as long as the samples 
don't lose precision.
I didn't tacked this by scaling the samples then converting to int because I 
don't know what is the range of values for the outputs of the FFT and IFFT 
blocks.

From: gui--rit...@hotmail.com
To: discuss-gnuradio@gnu.org
Subject: Complex to bits
Date: Sat, 19 Oct 2013 10:11:33 -0300




Hi everyone.
Thanks for all the replies on my previous thread. I did some tests and found 
out that the FFT and IFFT do not add noise to my audio signal. It works 
perfectly! The noise is coming from another part of my flowgraph.
Before I introduced the FFT and IFFT, I was working with an audio signal that 
was scaled and converted to int, so it could be unpacked into bits; those bits 
were processed and retrieved, packed, converted to float, descaled and turned 
back to audio. There was no noise then. Adding the FFT and IFFT made me use the 
complex type before the unpacking, so what I was using to make it possible to 
unpack the signal into bits no longer worked properly.
I tried changing the scale constant, converting from complex to IShort and 
unpacking that, but neither worked.
So, my question is: how do I unpack a complex signal into bits, and then pack 
it back? Considering I'm working on a audio signal that shouldn't get noise 
added to it.
Thanks in advance.  
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to make modified uhd/host/examples

[Naceur]

Thank you Bennett.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-to-make-modified-uhd-host-examples-tp44214p44248.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

Re: [Discuss-gnuradio] Using USRP to transmit and receive samples

[JPL]

Sorry my bad, it's typo.
I actually did save *.wav into *.dat.
and good to hear about that "it will work"

One question,
 *the scripts in gnuradio-core/src/utils/{read,write}*
If I use those scripts in the matlab, I will not need to worry about
setting the format, like float, int, or byte...etc, right?
and default, what type of format will the script save it into the *dat?

Thanks



On Sat, Oct 19, 2013 at 3:02 AM, Marcus Müller  wrote:

>  Hi!
>
> Quick answer, don't have time right now:
> (A) Why did you save them as wav audio? Usually, it's wiser to just store
> them as raw data; see the scripts in gnuradio-core/src/utils/{read,write}*
> Note: you're sending symbols from the source, not samples! Use bytes as
> data format.
>
> Answers:
> (1) yes, that should do the trick.
> (2) no, I think you should replace the CRC generator, unless you want to
> have your symbols interleaved with checksums
>
> Greetings,
> Marcus
>
>
> On 10/19/2013 01:00 AM, JPL wrote:
>
> Hello,
>
>  I found out two *.grc files, tx_ofdm and rx_ofdm, under
> gr_digital/examples/ofdm.
>
>  Don't know if this can be realized,
> first test running the steps without changing any parameters in *.grc.
>  (A) use *.dat generated from Matlab (I saved a set of wav audio),
> (B) place it as input in the tx_ofdm.grc,
> (C) send through antenna,
> (D) the other USRP execute rx_ofdm.grc
> (E) put the output *.dat into Matlab analyzing.
>
>  Question:
> (1) should I just replace the "Vector Source block" into "File Source" in
> tx_ofdm.grc?
> (2) the rx_ofdm.grc, again, am I right just replace "tag debug" with "file
> sink"?
>
>  Is this possible?
>
>  Sincerely,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Oct 18, 2013 at 5:43 AM, Marcus Müller  wrote:
>
>>  Hi JPL,
>>
>> .mat is really just a complicated container format for all kind of matlab
>> data -- GNU Radio can't directly deal with that, although with SciPy you
>> could create something that will be able to parse .mat files; but that is
>> quite useless, as you could as well use Matlab to write something that can
>> be directly used with other software.
>>
>> So to answer question (1.), I'd agree with Nathan: Best way to do it is
>> using the existing GNU Radio OFDM tools, not writing code that has already
>> been written several times, and start with something that already works.
>> Thereby dropping Matlab as your signal processing framework, and only using
>> it for data analysis and visualisation.
>>
>> To comment on (II): GNU Radio has blocks like "file_sink". They will just
>> save the samples to a file, in this case, in the format of raw float32s (1
>> for real, 1 for imag part) one after another.
>>
>> To answer (III): If you really want to do that, see the GNU Radio source
>> tree, gnuradio-core/src/utils/read_{float,complex,...}_binary.m. There is
>> the same with "write" instead of "read".
>>
>> Greetings,
>> Marcus
>>
>>
>>
>> On 10/18/2013 06:53 AM, West, Nathan wrote:
>>
>>  On Thu, Oct 17, 2013 at 11:14 PM, JPL  wrote:
>>
>>> Hello,
>>>
>>>  We have used Matlab to generate *.mat file, a file around 1966240
>>> complex number OFDM samples.
>>> Thinking to (I) transmit between two USRPs, (II) let the receiver side
>>> saving data into file, and later (III) putting the file on Matlab for
>>> demodulation.
>>>
>>>  1. What is the best way to do it? like create GRC blocks? or UHD
>>> example?
>>> 2. How can I make sure that the TX part will stop when those 1966240
>>> samples are sent. and RX part will stop when completely receiving those
>>> 1966240 samples?
>>> 3. Should the file type be the *.dat?
>>>
>>>  Sincerely,
>>>
>>>  JPL
>>>
>>>
>>>  I'll attempt to respond to both questions since they are really the
>> same thing.
>>
>>  First, this is kind of a weird way to use GNU Radio. GNU Radio provides
>> you an environment to do all of the signal processing you want to do in c++
>> or (if you want) python. The flowgraph of file -> transmit antenna --> over
>> the air --> receive antenna -> file followed by signal processing in Matlab
>> is sort of not the point of GNU Radio. There's nothing saying you cannot do
>> this, but you might look in to  implementing whatever signal processing you
>> are doing in GNU Radio. This will reduce the round trip time of testing and
>> make the whole experience a little better. ( you're basically doing an even
>> slower version of what we call flying blind:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Flying-Blind )
>>
>> Re: your other email and question about GR file sink/source:
>> About the file sinks...
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink
>>  Basically it's a binary file just like you would expect if you open a
>> file with 'b' flag in most languages I'm familiar with. If you're dumping
>> complex floats in there then you'll need to read two float values.
>>
>>  2. There is a block called head. It takes a number of samples to pass
>> through and then quits. But a