[Discuss-gnuradio] Problem in using trellis Error correction en- and decoder
Hello , I am using trellis encoder and trellis viterbi block, to get a error corecction method. i take a snapshot for you: http://img213.imageshack.us/img213/3435/pantallazoxe.png The flow: ---Packet Encoder---DBPSK Encoder--DBPSK Decoder---Packet Decoder works perfect. Problem is trellis encoder input and trellis viterbi decoder output do not match. why don't match? I, read the documentation about the FSM file format. ( in gr-trellis directory) the example, in the directory don't work (FILE error). Need i chunks to symbols block as the example? Thanks in advance Francisco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Testing GNURadio Feature #400
All,
I'm currently implementing GNURadio's Feature #400
http://gnuradio.org/redmine/issues/show/400. The problem is that I don't
have test equipment or a USRP2. Before I commit this code, I'd like to get
it properly tested. Would it be at all possible for anyone to run this on
the USRP2? I've hooked it up to the waterfall scope, but it's just not the
same. :)
Jojo
#!/usr/bin/env python
#
# Copyright 2010 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#
Read 32-bit little-endian samples from a file and send those samples to the
USRP/USRP2.
from gnuradio import gr, eng_notation
from gnuradio.blks2 import generic_usrp_sink_c
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import sys
n2s = eng_notation.num_to_str
class tx_cfile_block(gr.top_block):
def __init__(self, options, input_filename):
gr.top_block.__init__(self)
gr.enable_realtime_scheduling()
if options.real:
sizeof_input_samples = gr.sizeof_float
else:
sizeof_input_samples = gr.sizeof_gr_complex
self.src = gr.file_source(sizeof_input_samples,
input_filename,
repeat = options.loop)
self.u = generic_usrp_sink_c(interface = options.interface,
mac_addr = options.mac_addr,
subdev_spec = options.tx_subdev_spec)
print 'Using %s' % str(self.u)
print 'Possible tx frequency range: %s - %s' % \
(n2s(self.u.freq_range()[0]), n2s(self.u.freq_range()[1]))
# we need to find the closest decimation rate the USRP can handle
# to the input file's sampling rate
try:
ideal_interp = self.u.dac_rate() / options.rate
# pick the closest interpolation rate
interp = [x for x in self.u.get_interp_rates()
if x = ideal_interp][-1]
self.u.set_interp(interp)
except IndexError:
sys.stderr.write('Failed to set USRP interpolation rate\n')
raise SystemExit, 1
output_rate = self.u.dac_rate() / interp
resamp_ratio = output_rate / options.rate
# since the input file sample rate may not be exactly what our
# output rate of the USRP (as determined by the interpolation rate),
# we need to resample our input to the output rate
num_filters = 32
cutoff = 0.99 * options.rate / 2.
transition = 0.1 * options.rate / 2.
resamp_taps = gr.firdes_low_pass(num_filters * 1.0,
num_filters * options.rate,
cutoff,
transition)
self.resamp = gr.pfb_arb_resampler_ccf(resamp_ratio,
resamp_taps,
num_filters)
if options.gain is None:
# if no gain was specified, use the mid-point in dB
g = self.u.gain_range()
options.gain = float(g[0]+g[1])/2
self.u.set_gain(options.gain)
res = self.u.set_center_freq(options.freq)
if not res:
sys.stderr.write('Failed to set frequency\n')
raise SystemExit, 1
if options.real:
# our samples are real
# we need to convert them to complex without a hilbert filter
self.hilbert = gr.hilbert_fc(64)
self.connect(self.src, self.hilbert, self.resamp, self.u)
else:
# our samples are complex
self.connect(self.src, self.resamp, self.u)
def get_options():
usage=%prog: [options] input_filename
parser = OptionParser(option_class=eng_option, usage=usage)
parser.add_option(-R, --tx-subdev-spec, type=subdev, default=None,
help=select USRP1 Tx side A or B (default=None))
parser.add_option(-e, --interface, type=string, default=None,
help=specify USRP2 Ethernet interface
[default=None])
parser.add_option(-m, --mac-addr, type=string, default=None,
help=specif USRP2 MAC address [default=None])
parser.add_option(-f, --freq,
[Discuss-gnuradio] Problem in using trellis Error correction en- and decoder
Can you be more specific as to WHICH example in the gr-trellis directory does not work. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis: convenc and viterbi with own mapper/de-mapper
Jonas, one idea is to add a method set_K(K) to the viterbi class. This method sets d_K AND calls the set_multiple() method with the new value. This method will be called from , say , the python code. Achilleas On Sat, Oct 23, 2010 at 1:59 PM, Jonas M. Börner jonas.boer...@rwth-aachen.de wrote: Dear Achilleas, I use your Viterbi implementation in a dynamic ressource allocation framework for OFDM. Data is processed frame-wise and in general, every frame carries a different number of coded bits. So I need to tell the Viterbi the number of trellis steps in each step. As far as I can see, there is no way yet to use this block like this since I have to specify the number of trellis steps at initialization. I tried to feed a integer source to the block and read d_K in general_work() from where but the main problem is, that I cannot reset the set_output_multiple thing. If I don't use set_output_multiple function the assertion that noutput_items has to be integer multiple of d_K fails. I'd appreciate any hints you can give me. :) Jonas Am 19.08.2010 um 10:19 schrieb Achilleas Anastasopoulos: Jonas, there is a very extensive doc file in gr-trellis that hopefully answers your questions, as well as a lot of examples. Please read it and let me know if you still have questions about it. BTW: your issue has nothing to do with truncation as was suggested in a reply. In short: one way to implement your system is to mapp the encoded symbols directly to QPSK symbols (essentially this is what you are doing!) and thus produce 5 demodulated symbols that you will feed in the VA. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] audio_alsa: problem with valve at head of audio_alsa sink sub-graph
In my application I have a sub-graph that terminates an an audio_alsa sink. At the head of this sub-graph, I've placed a valve, so that I can turn off data being copied to the audio_alsa sink. When this valve transitions from closed (data flowing) to open (data *not* flowing), it provokes the following error in audio_alsa_sink: audio_alsa_sink[plughw:0,0]: snd_pcm_hw_params failed: File descriptor in bad state terminate called after throwing an instance of 'std::runtime_error' what(): check topology failed on audio_alsa_sink(1) using ninputs=1, noutputs Am I being an idiot here? Should this work? If not, why not? Further, there's a OK to block parameter for an audio_alsa_sink. What does it do? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help to compile gnuradio
How can I get help to build/package Gnuradio. the USRP2 component doesn't build anymore with newest gcc http://pastebin.mandriva.com/21049 -- Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help to compile gnuradio
On Sat, Oct 23, 2010 at 01:43:11PM -0700, Thomas Spuhler wrote: How can I get help to build/package Gnuradio. the USRP2 component doesn't build anymore with newest gcc http://pastebin.mandriva.com/21049 I'm pretty sure this is fixed on master: http://gnuradio.org/redmine/wiki/gnuradio/Download Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio Mode S project released
Hi all, I finally got around to cleaning up my Mode S receiver enough for public release. The following is a short description of the software: The Gnuradio Mode S project implements a Mode S/ADS-B receiver. Mode S is the latest aircraft transponder technology, primarily used in commercial aircraft. Probably 30% of those aircraft currently broadcast their position via ADS-B (more in Europe, less in the US), which is a protocol that uses Mode S extended squitters as the transport layer. By 2020 all aircraft operating in controlled US airspace will be required to broadcast ADS-B. The receiver demodulates and decodes the 1090MHz PPM-modulated Mode S transmissions using industry-standard techniques to mitigate FRUIT (transmissions on top of one another) and correct multiple bit errors. Using a USRP with a DBSRX + LNA + SAW filter, ranges of 220 miles have been regularly seen. The WBX should allow similar ranges without the filter and LNA, although I haven't really tested WBX much. It is of course line-of-sight, making antenna site selection important. TL;DR: Follow airplanes around from 200 miles with your USRP. The receiver allows interfacing to a number of output formats, including KML for Google Earth. Screenshots of the Google Earth interface can be found here: http://nerdnetworks.org/~bistromath/photos/adsb/ There is also a TCP port 30003 interface to use with PlanePlotter, a third-party application to view aircraft data. PlanePlotter isn't free, and I haven't tested it at all, so while it should work, YMMV. If you do test it, let me know. There are definitely still bugs in it -- one thing that comes to mind is that a very few aircraft seem to produce data which uses correct headers for position packets but which contains non-position data. This causes impossible aircraft positions. Luckily it seems to be pretty rare. Future developments for the receiver include implementation of networked multilateration using the VRT timestamps of USRP2. Multilateration allows the time-based triangulation of aircraft which use Mode S but which do not broadcast ADS-B. Three or more networked USRP2s should allow position determination to a reasonable degree of accuracy. Clone the Git repository to build the software with the usual bootstrap/configure/make/make install rigmarole; it should compile on anything you have Gnuradio installed on, although with a 4Msps data rate it does require a bit of CPU power. In order to use the KML output you will have to have libsqlite3 and python-sqlite installed, although since those are Python dependencies it will still compile without them. I think that's it for the dependencies. Oh, it uses UHD, so you should finally get around to building UHD and gr-uhd to use this software. git clone git://github.com/bistromath/gr-air-modes.git There is also a CGRAN page with corresponding SVN repo, which is a mirror of the Github repo: https://www.cgran.org/wiki/gr-air-modes/ The Python executable is src/python/uhd_modes.py. Best, Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Mode S project released
On Sat, Oct 23, 2010 at 06:52:34PM -0700, Nick Foster wrote: Hi all, I finally got around to cleaning up my Mode S receiver enough for public release. The following is a short description of the software: Cool stuff! Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re:[Discuss-gnuradio] Problem in using trellis Error correction en- and decoder
Hello Achilleas. Forgiveness for mysticism about the example. is interference_cancellation.grc (GNU Radio Companion 3.2.2) http://pastebin.com/N61P7tiP /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc the error: [error] Loading: /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc Done Showing: /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc Generating: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py Warning: This flow graph may not have flow control: no audio or usrp blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU congestion. Generating: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py Warning: This flow graph may not have flow control: no audio or usrp blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU congestion. Executing: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py terminate called after throwing an instance of 'std::runtime_error' what(): fsm::fsm(const char *name): file open error Done [/error] i change the path to absolute path, but don't work. the file exist in this directory. i no try to add a Throttle block. i do not care if the example doesn't work, be cause i don't get this error in my work. I must have to go now. sorry. thanks for the fast reply. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
