Re: [Discuss-gnuradio] UHD Underrun with Wav File Source and USRP Sink
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
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
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
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
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
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
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
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
> 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
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.
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