Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink

2012-11-16 Thread Marcus D. Leech
On 16/11/12 07:15 PM, Tom Hendrick wrote:
> Does anyone have some ideas on what else I can try right now?  I'm out
> of ideas on what is causing the underruns at the start of running the
> script that reads the WAV file and outputs to the USRP LFTX.
>
> Thank you, -Tom
>
Most systems like this have startup glitches.  The analog hardware is
one source, and in your case, it's the
  kernels buffer management getting "ramped up".  Back in the 1980s, we
had to deal with this a lot on
  low-speed packet-radio systems layered on top of ordinary analog FM
radios.  There was no way to make
  the radios not glitch on startup, so we simply devised mechanisms to
deal with it.


My suggestion is to setup up a *continuous* transmitter graph, and
gate-in "real" samples when you need them.

Also, I'd gently suggest that a receiver chain that can't handle the odd
glitch isn't much of a receiver chain, in
 the signal-processing sense.  Radio is analog. It's subject to
distortions, glitches, pops, wheezes, snorts and
 shudders that are utterly outside of your control.  Your receiver has
to be able to deal with them, regardless
 of whether the source is "natural", or a quirk of the buffer-startup
behaviour.




-- 
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] UHD Underrun with Wav File Source and USRP Sink

2012-11-16 Thread Tom Hendrick
Does anyone have some ideas on what else I can try right now?  I'm out of ideas 
on what is causing the underruns at the start of running the script that reads 
the WAV file and outputs to the USRP LFTX.

Thank you, -Tom




 From: Tom Hendrick 
To: Tom Hendrick ; "discuss-gnuradio@gnu.org" 
 
Sent: Wednesday, November 14, 2012 8:52 AM
Subject: Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink
 

As an additional check, I reduced the signal amplitude further in the WAV file 
to make sure there is no truncation.  I still see the same two underruns at the 
start of running the script.
Thanks, - Tom





 From: Tom Hendrick 
To: "discuss-gnuradio@gnu.org"  
Sent: Wednesday, November 14, 2012 8:22 AM
Subject: Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink
 

Hello Josh,

The wav file has float values in the -1 to 1 range.  In the old GRC script I 
had used a constant multiplier of (2**15-1) to get the correct amplitude.
In the newer GRC script I took that out since it was already in the correct 
range.

When I check the output of the LFTX with an oscilloscope, they both look 
identical except that I see the blip/noise (which I think is from underrun) 
show up right at the start of the transmission.  I have added zero padding to 
the signal.  This is for an audio recording project and the blip/noise causes 
problems on the receive side because I am listening continuously for the 
incoming signal and the blip causes unwanted effects.

Any other suggestions?
Thanks so much for your responses, - Tom




 From: Josh Blum 
To: discuss-gnuradio@gnu.org 
Sent: Tuesday, November 13, 2012 9:50 PM
Subject: Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink
 


On 11/12/2012 02:10 PM, Tom Hendrick wrote:
> 
> 
> Hello Josh,
> 
> Thanks for the suggestion.  Yes I had zero padded the file with about 1 
> second of zero signal prior to the signal I want to transmit.  I had still 
> seen the blip/noise when running the script even when there was 1 second of 
> zero padded signal.  Is there anything else I should try?
> 

Well, then perhaps it not the result of an underflow.

What is your transmit amplitude? In the old libusrp1 floats were
+/-2**15, but now they are +/-1.0 fullscale. So you must have had to
adjust the amplitude of the baseband samples; but are they scaled small
enough to avoid truncation?

-josh

> Thanks, -Tom
> 
> 
> 
>  From: Josh Blum 
> To: discuss-gnuradio@gnu.org 
> Sent: Monday, November 12, 2012 1:03 PM
> Subject: Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP 
> Sink
>  
> 
> 
> On 11/11/2012 01:21 PM, Tom Hendrick wrote:
>> Hello all,
>>
>> I am using a USRP1 and an LFTX daughtercard and Ubuntu 12.04.
>>
>> I am having an issue with a simple GRC script I made which has three
>> blocks. A WAV file source connects to a resampler block and then to
>> the UHD USRP sink.
>>
>> When I run the script I get a single underun right at the start of
>> running the script and no other underrun. When I run the script using
>> the sudo in front of it, I get two
 underruns right at the start of
>> running the script and no other underrun. I monitored the
 signal out
>> of the LFTX using an oscilloscope and noticed some blips/noise when
>> the script is run and I believe they correspond to the underruns.  I
>> tried this with and without real-time scheduling enabled and didn't
>> see any difference.
>>
>>
>> I tried the same exact type of script with an older version of GRC on
>> a different laptop with Ubuntu 10.04.  This uses the USRP sink block
>> not the UHD sink block.  This script plays the file perfectly without
>> any underruns at all and I don't see the blips/noise at the beginning
>> of the signal.
>>
>> I am using the LFTX for an audio application and the blips/noise will
>> cause a problem for me.  Does anyone know why I am seeing this
>> behavior with the newer UHD block?  Is there anything I can do to
>> eliminate
 it?
>>
> 
> Hi Tom,
> 
> If I am understanding correctly, you are getting some initial underflows
> when the flow graph begins processing. This is causing some
> discontinuous stream interruption over on the receiver side.
> 
> If thats the case, I dont know of anything specifically to cause this,
> so it might just be the issue of interrupt coalescing. That is the host
> isnt initially ramped up to push out USB packets at full speed. So,
> driver wise, there may have been a subtle difference thats brining this
> out, USB 1.0 vs .1 for example.
> 
> I'd like to replicate it over on end. But if I have a quick suggestion,
> it may be helpful to zero-pad the beginning of the wavefile so those
> initial discontinuities are only lost in the padding.
> 
> -josh
> 
> ___
>
 Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.g

[Discuss-gnuradio] writing packet payloads to file

2012-11-16 Thread Colleen Josephson
Hello all,

I am researching a new coding algorithm. I am transmitting and coding a
text file using payload_tx.py and then write the binary of the packet
payload to a file to do offline analysis.

I am having trouble writing packet payloads to file, however, because the I
can't seem to find a way to get data out of a gr_message except for the
to_string() method. If I try and convert the string back to binary (my
attempt involved python's binascii module), I get an "Error: illegal char"
message.

This makes sense, since the data is still coded, and should not be a valid
ascii string. But how can I get around this problem and write binary to
file?

-- 
Colleen Josephson
http://www.cjosephson.net
Dept. of Electrical Engineering and Computer Science
Massachusetts Institute of Technology
Class of 2013
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] I could use guidance

2012-11-16 Thread Marcus D. Leech

Hello,

I created a noise source and a tcp sink (server).  I connect to it 
with SDR# (on another machine) and get plenty of noise.  Next I 
created a signal source of 1khz and add that to my noise source.  The 
unexpected result:  carriers all over the spectrum.  None of which are 
at 1khz.


You're probably having a good laugh.  You're welcome.

I'd like to modulate the amplitude of a carrier and drop that into a 
randomly-generated noise floor. And I'd like to stream the whole thing 
to sdr-software across the network.  Are my expectations too wild?  Is 
this possible?


Thanks for your time,
Ashworth





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

WHat does the attached flow-graph produce for you?

My guess is that you have the amplitudes set so that they're saturating 
whatever SDR# is doing with the I/Q signal from the TCP

  channel, or that it's a typing/endianness issue.



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

#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Noise Signal
# Generated: Fri Nov 16 17:13:40 2012
##

from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import window
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import fftsink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class noise_signal(grc_wxgui.top_block_gui):

	def __init__(self):
		grc_wxgui.top_block_gui.__init__(self, title="Noise Signal")
		_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
		self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

		##
		# Variables
		##
		self.samp_rate = samp_rate = 250e3

		##
		# Blocks
		##
		self.wxgui_fftsink2_0 = fftsink2.fft_sink_c(
			self.GetWin(),
			baseband_freq=0,
			y_per_div=10,
			y_divs=10,
			ref_level=0,
			ref_scale=2.0,
			sample_rate=samp_rate,
			fft_size=1024,
			fft_rate=8,
			average=False,
			avg_alpha=None,
			title="FFT Plot",
			peak_hold=False,
		)
		self.Add(self.wxgui_fftsink2_0.win)
		self.gr_throttle_0 = gr.throttle(gr.sizeof_gr_complex*1, samp_rate)
		self.gr_sig_source_x_0 = gr.sig_source_c(samp_rate, gr.GR_COS_WAVE, 1000, 0.5, 0)
		self.gr_noise_source_x_0 = gr.noise_source_c(gr.GR_GAUSSIAN, 0.1, 57)
		self.gr_add_xx_0 = gr.add_vcc(1)

		##
		# Connections
		##
		self.connect((self.gr_noise_source_x_0, 0), (self.gr_add_xx_0, 0))
		self.connect((self.gr_sig_source_x_0, 0), (self.gr_add_xx_0, 1))
		self.connect((self.gr_add_xx_0, 0), (self.gr_throttle_0, 0))
		self.connect((self.gr_throttle_0, 0), (self.wxgui_fftsink2_0, 0))

	def get_samp_rate(self):
		return self.samp_rate

	def set_samp_rate(self, samp_rate):
		self.samp_rate = samp_rate
		self.gr_sig_source_x_0.set_sampling_freq(self.samp_rate)
		self.wxgui_fftsink2_0.set_sample_rate(self.samp_rate)

if __name__ == '__main__':
	parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
	(options, args) = parser.parse_args()
	tb = noise_signal()
	tb.Run(True)

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


[Discuss-gnuradio] I could use guidance

2012-11-16 Thread Ashworth Payne
Hello,

I created a noise source and a tcp sink (server).  I connect to it with
SDR# (on another machine) and get plenty of noise.  Next I created a signal
source of 1khz and add that to my noise source.  The unexpected result:
carriers all over the spectrum.  None of which are at 1khz.

You're probably having a good laugh.  You're welcome.

I'd like to modulate the amplitude of a carrier and drop that into a
randomly-generated noise floor. And I'd like to stream the whole thing to
sdr-software across the network.  Are my expectations too wild?  Is this
possible?

Thanks for your time,
Ashworth
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Channel Impulse Response

2012-11-16 Thread Nazmul Islam
Hello Daviko,

I used gnuradio in channel sounding experiments during the summer. I did
not use gr-sounder. Rather, I designed my own transmitter and receiver
block diagrams using GRC.

You can do both sliding correlator and frequency domain channel sounding
using GNUradio. Sliding correlator method directly generates the channel
impulse response. Frequency domain sounding allows you to find the impulse
response through inverse FFT procedure. There might be other methods that I
am unaware of.

In general, the frequency domain channel sounding method gives you the
channel strengths at different carrier frequencies.Let's say, your desired
frequency band is 700-720 MHz region. You can transmit a sinusoid from the
transmitter that repeatedly hops at 700, 701, 702, ..., 720, 700, 701, .. ,
720 MHz. Your receiver's carrier frequency should hop repeatedly in the
same list. If you can time synchronize your Tx & Rx, you will know the path
loss by taking FFT and observing the strength of the floating points in the
desired FFT bin.

Thanks,

Nazmul


On Fri, Nov 16, 2012 at 3:30 PM, daviko  wrote:

> Hi
> I want to find *"channel impulse response"* for my project using sounding
> techniques
> I came to know about the 'gr-sounder' application which does just the thing
> and was implemented in previous versions of gnuradio. I have version 3.6.0
>
> how can I use this app for my purpose?
> any help is appreciated
>
> Thanks in advance
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Channel-Impulse-Response-tp38383.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
>



-- 
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Channel Impulse Response

2012-11-16 Thread Johnathan Corgan
On Fri, Nov 16, 2012 at 12:30 PM, daviko  wrote:


> I came to know about the 'gr-sounder' application which does just the thing
> and was implemented in previous versions of gnuradio. I have version 3.6.0
>
> how can I use this app for my purpose?
> any help is appreciated
>

The gr-sounder app was a custom FPGA implementation based off the obsolete
GNU Radio libusrp2 package for USRP2.  It would have to reimplemented from
scratch using the current UHD package from Ettus Research.

The use of the FPGA was to enable the sounding waveform to cover a wider
bandwidth than could be sent over the GbE transport for processing on the
PC.  If your channel is narrow enough, you could implement the same
algorithm in GNU Radio.  The transmitter was sending BPSK modulated PN
sequences and the receiver was calculating correlation at successive time
lags to estimate the channel impulse response.

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


[Discuss-gnuradio] Channel Impulse Response

2012-11-16 Thread daviko
Hi 
I want to find *"channel impulse response"* for my project using sounding
techniques 
I came to know about the 'gr-sounder' application which does just the thing
and was implemented in previous versions of gnuradio. I have version 3.6.0 

how can I use this app for my purpose? 
any help is appreciated 

Thanks in advance 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Channel-Impulse-Response-tp38383.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] compiling and working with gnuradio in windows

2012-11-16 Thread Josh Blum

> Per the hash problem:
> 
> To run the GRC examples, I need to delete the first line that starts
> with the hash '#'.  It seems like GRC expects the bracket '<' as the
> first line.
>>> Is this a .py file or a .grc file? Sorry, can you post a snippet or
>>> link.
> 
> Resampler_demo.grc's first few lines are here:
> 
> #!C:\Python27\python.exe
> 
> 
>   Tue Jun 19 21:31:30 2012
>   
> 

I think its a typo, the grc file is being installed with
GR_PYTHON_INSTALL, so its appending the shebang to it. You would
probably just want to use the grc file from the source tree.

Devs should probably pull this out:

diff --git a/gr-filter/examples/CMakeLists.txt
b/gr-filter/examples/CMakeLists.txt
index a3901b6..57dbab9 100644
--- a/gr-filter/examples/CMakeLists.txt
+++ b/gr-filter/examples/CMakeLists.txt
@@ -30,7 +30,6 @@ GR_PYTHON_INSTALL(PROGRAMS
 interpolate.py
 reconstruction.py
 resampler.py
-resampler_demo.grc
 synth_filter.py
 synth_to_chan.py
 DESTINATION ${GR_PKG_FILTER_EXAMPLES_DIR}


-josh

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


Re: [Discuss-gnuradio] compiling and working with gnuradio in windows

2012-11-16 Thread Seth Hollar

Hi Josh,
Thank you so much for your help.  I replaced fir_filter.cc and 
fir_filter_with_buffer.cc per the fix below.  I recompiled and now 
filter/resampler_demo.grc works!  Thanks!


I just fixed some pretty bad bug in the gr-filter that was causing
access violations. You might be seeing that at play.
http://gnuradio.org/cgit/gnuradio.git/commit/?h=maint&id=64913ee414f2c8a51afb2277b16b957fa2e7e066



Per the hash problem:


To run the GRC examples, I need to delete the first line that starts
with the hash '#'.  It seems like GRC expects the bracket '<' as the
first line.

Is this a .py file or a .grc file? Sorry, can you post a snippet or link.


Resampler_demo.grc's first few lines are here:

#!C:\Python27\python.exe


  Tue Jun 19 21:31:30 2012
  

When I load the resampler_demo.grc into companion, it errors out with the 
message below.  However, when I remove the first line 
(#!C:\Python27\python.exe), it loads just fine.

Loading: "C:\grctestcode\resampler_demo.grc"
Error: Start tag expected, '<' not found, line 1, column 1

Failure

Traceback (most recent call last):
  File "C:\gnuradio\install\lib\site-packages\gnuradio\grc\gui\MainWindow.py", l
ine 178, in new_page
file_path=file_path,
  File "C:\gnuradio\install\lib\site-packages\gnuradio\grc\gui\NotebookPage.py",
 line 47, in __init__
initial_state = flow_graph.get_parent().parse_flow_graph(file_path)
  File "C:\gnuradio\install\lib\site-packages\gnuradio\grc\base\Platform.py", li
ne 113, in parse_flow_graph
ParseXML.validate_dtd(flow_graph_file, FLOW_GRAPH_DTD)
  File "C:\gnuradio\install\lib\site-packages\gnuradio\grc\base\ParseXML.py", li
ne 38, in validate_dtd
xml = etree.parse(xml_file, parser=parser)
  File "lxml.etree.pyx", line 2942, in lxml.etree.parse (src/lxml/lxml.etree.c:5
4187)
  File "parser.pxi", line 1528, in lxml.etree._parseDocument (src/lxml/lxml.etre
e.c:79485)
  File "parser.pxi", line 1557, in lxml.etree._parseDocumentFromURL (src/lxml/lx
ml.etree.c:79768)
  File "parser.pxi", line 1457, in lxml.etree._parseDocFromFile (src/lxml/lxml.e
tree.c:78843)
  File "parser.pxi", line 997, in lxml.etree._BaseParser._parseDocFromFile (src/
lxml/lxml.etree.c:75698)
  File "parser.pxi", line 564, in lxml.etree._ParserContext._handleParseResultDo
c (src/lxml/lxml.etree.c:71739)
  File "parser.pxi", line 645, in lxml.etree._handleParseResult (src/lxml/lxml.e
tree.c:72614)
  File "parser.pxi", line 585, in lxml.etree._raiseParseError (src/lxml/lxml.etr
ee.c:71955)
XMLSyntaxError: Start tag expected, '<' not found, line 1, column 1


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


Re: [Discuss-gnuradio] Paper: DCSK chaotic modulations with GNU Radio.

2012-11-16 Thread Julien.Olivain

From: discuss-gnuradio-bounces+julien.olivain=lacime.etsmtl...@gnu.org 
[discuss-gnuradio-bounces+julien.olivain=lacime.etsmtl...@gnu.org] on behalf of 
Martin Braun (CEL) [martin.br...@kit.edu]
Sent: Wednesday, November 14, 2012 12:29 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Paper: DCSK chaotic modulations with GNU Radio.

On Tue, Nov 13, 2012 at 07:31:30PM +, julien.oliv...@lacime.etsmtl.ca wrote:
>   Feedback and comments are welcome.  If somebody thinks this has a
> place in the main repo, let me know what remain to be done.

Out of curiosity, how were you able to determine Eb/N0 in Fig. 3? Could
you use the SNR measurement blocks in GNU Radio?


  Hi Martin,

  Basically, we measured everything "by hand", using the standard
block in GNU Radio 3.5 (plus some modifications in the "simple
framer").  So, no, we didn't use the SNR estimation blocks in GNU
Radio (if I remember well, these blocks were not merged in GNU Radio
when we did these experiments, last year).  We had the setup described
in section 5 of the paper (2 usrp, a noise generator with a mixer).
For each point of the graph, we measured the noise power alone, the
signal power alone, then the bit error rate when mixing the noise and
the signal.  With some matlab code we converted the SNR to Eb/N0 to
generate the Fig 3 (instead of using a SNR estimation technique).  We
did this because we wanted to actually measure the total performance
loss of the whole transmission system (modulation, implementation,
sync. recovery, usrp) and compare the results with the theoretical
limits.  Moreover, I have no idea how far is a usrp transmit channel
from a pure theoretical AWGN one.

  Other things that would be nice to test would be to compare this
"hand made" SNR measures with SNR estimation techniques, both in a lab
setup and in a real-world outdoor environment.

-- Julien Olivain.

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