Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
When I wrote a fast atan table look algorithm a long time ago ( and I have no recollection if our stuff traces its ancestry to that or not) I picked the table size for my problem at the time. There is a large speed up using the table lookup algorithm even on today's machines but there is no reason we can't increase the size of the table to get a better approximation and the theoretical speed will be the same but with decreased average error. The trade off is that the table becomes very large as you demand higher accuracy. We could in fact make the error demand an input and compute the table on set up. Things to think about when you are otherwise indisposed. ;-). Bob Johnathan Corgan wrote: Steven Clark wrote: Do you have a sense of how much slower the regular atan2f function is than gr_fast_atan2f? I don't think there were any formal benchmarks done, but IIRC the fast atan2 reduced CPU utilization by a factor of 5 for a WFM demodulator. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you're going to be crazy, you have to get paid for it or else you're going to be locked up." Hunter S. Thompson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make a modulated signal
hello I want to simulate a mobile station and I need to modulate frames I make with GMSK but the problem is that I can't make the modulation just during one time slot and let the other time slots without modulating. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about transmiting and receiving signals
Hi All, I am trying to use one USRP board to tranmit some audio file, say at 900MHz, and use another USRP board as the receiver to receive this audio file @ 900MHz. How should I start it? Could anyone give me some hint to start it? Thanks a lot, Ruby - Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make a synchronized block
Hello I made with my friends a block in witch we simulate channel coding interleaving desinterleaving and channel decoding with viterbi hard to correct errors, now we want to simulate a BTS so we need to know how to make a synchronized block using options in gr_block. I hope that some one answer to my demand. And thinks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Steven Clark wrote: > Do you have a sense of how much slower the regular atan2f function is > than gr_fast_atan2f? I don't think there were any formal benchmarks done, but IIRC the fast atan2 reduced CPU utilization by a factor of 5 for a WFM demodulator. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Steven Clark wrote: > Thanks Matt, I understand the issue now and switching atan functions > does indeed make the glitches go away. Great! > Do you have a sense of how much slower the regular atan2f function is > than gr_fast_atan2f? I think Eric looked at it a while ago when he wrote it. > If the performance hit isn't too bad, I might leave it in for peace of > mind. You are dealing with very low sample rates, so I wouldn't worry about the performance. > What is the best strategy when you want to rx a signal at a very slow > symbol rate? Max decimation (256?) on the USRP, then decimate/filter > some more in software? As an arbitrary example, symbol rate 7812.5 > sym/sec: have the usrp decimate by 256 and you're still at 32 > samp/sym. What is the best way to partition decimation between hw and > sw? Which sw blocks are ideal for this? In general, decimate as much as possible in hardware, where it is free. However, I usually try leaving the last 2x (or more) for the software decimator, which will have higher precision and better filter skirts. In software, use the standard gr_fir_filter blocks, and just set the decimation rate (which is the first parameter, I think). Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Thanks Matt, I understand the issue now and switching atan functions does indeed make the glitches go away. Do you have a sense of how much slower the regular atan2f function is than gr_fast_atan2f? If the performance hit isn't too bad, I might leave it in for peace of mind. Regarding excessive oversampling: I agree that 64, 128, etc. samples per symbol is pretty ridiculous, I was just seeing how the issue scaled with sps. What is the best strategy when you want to rx a signal at a very slow symbol rate? Max decimation (256?) on the USRP, then decimate/filter some more in software? As an arbitrary example, symbol rate 7812.5 sym/sec: have the usrp decimate by 256 and you're still at 32 samp/sym. What is the best way to partition decimation between hw and sw? Which sw blocks are ideal for this? On 9/21/07, Matt Ettus <[EMAIL PROTECTED]> wrote: > > Steven Clark wrote: > > Hi all- > > please look at this sequence of eye diagrams: > > http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches > > > > These are from a gmsk mod/demod pair, showing the output of the TX's > > gaussian filter (blue) overlaid with the output of the RX's fmdemod > > (red). BT = 0.35. > > > > At 8 samples per symbol, everything looks ok. Red is pretty much right > > on top of blue, as we'd expect. > > As I increase samples per symbol, however, something strange happens, > > shown in plot sequence. The RX's fmdemod output gets successively more > > "glitchy". > > > > This might be because of the use of gr_fast_atan2f. This function is an > approximation used in order to speed things up since the real atan2f is > slow. Could you try replacing line 58 of gr_quadrature_demod_cf: > > out[i] = d_gain * gr_fast_atan2f(imag(product), real(product)); > > > with > > out[i] = d_gain * atan2f(imag(product), real(product)); > > and see if the problem persists? When doing very high oversampling like > you are, the difference in phase angles between successive samples is > very small. If the error when doing the lookup table interpolation > changes a bit when crossing over the endpoints of the table, you could > see this sort of effect. You'll notice that the errors are always at > the same point in the diagram, around the mid-level, which is where the > frequency is lowest. > > Matt > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Steven Clark wrote: > Hi all- > please look at this sequence of eye diagrams: > http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches > > These are from a gmsk mod/demod pair, showing the output of the TX's > gaussian filter (blue) overlaid with the output of the RX's fmdemod > (red). BT = 0.35. > > At 8 samples per symbol, everything looks ok. Red is pretty much right > on top of blue, as we'd expect. > As I increase samples per symbol, however, something strange happens, > shown in plot sequence. The RX's fmdemod output gets successively more > "glitchy". One other thing -- you really shouldn't be going to more than 8:1 oversampling on GMSK anyway -- all the timing recovery stuff will have trouble with that high of an oversampling rate when you have noise on the signal. We still need to fix this problem, but I would advise staying at 8:1 or lower. Your bandpass filtering also becomes harder at the higher oversampling ratios. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Steven Clark wrote: > Hi all- > please look at this sequence of eye diagrams: > http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches > > These are from a gmsk mod/demod pair, showing the output of the TX's > gaussian filter (blue) overlaid with the output of the RX's fmdemod > (red). BT = 0.35. > > At 8 samples per symbol, everything looks ok. Red is pretty much right > on top of blue, as we'd expect. > As I increase samples per symbol, however, something strange happens, > shown in plot sequence. The RX's fmdemod output gets successively more > "glitchy". > This might be because of the use of gr_fast_atan2f. This function is an approximation used in order to speed things up since the real atan2f is slow. Could you try replacing line 58 of gr_quadrature_demod_cf: out[i] = d_gain * gr_fast_atan2f(imag(product), real(product)); with out[i] = d_gain * atan2f(imag(product), real(product)); and see if the problem persists? When doing very high oversampling like you are, the difference in phase angles between successive samples is very small. If the error when doing the lookup table interpolation changes a bit when crossing over the endpoints of the table, you could see this sort of effect. You'll notice that the errors are always at the same point in the diagram, around the mid-level, which is where the frequency is lowest. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Hi all-
please look at this sequence of eye diagrams:
http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches
These are from a gmsk mod/demod pair, showing the output of the TX's
gaussian filter (blue) overlaid with the output of the RX's fmdemod (red).
BT = 0.35.
At 8 samples per symbol, everything looks ok. Red is pretty much right on
top of blue, as we'd expect.
As I increase samples per symbol, however, something strange happens, shown
in plot sequence. The RX's fmdemod output gets successively more "glitchy".
If I (in python) do the same thing that gr_quadrature_demod_cf is doing in
C, ie:
def fm_quadrature_demod(re, im, gain):
num_c = min(len(re),len(im))
out = []
for i in range(1,num_c):
prod = complex(re[i],im[i])*(complex(re[i-1],im[i-1]).conjugate())
out.append(gain*atan2(prod.imag, prod.real))
return out
the glitches do not exist. This tells me that TX fmmod output is fine.
Something is going wonky as gr_quadrature_demod_cf does its work. Any ideas?
Is this a problem with the scheduler?
Code attached (incidentally, I tried using the old style flowgraph, without
hier_block2 / top_block, glitches were still present).
#!/usr/bin/env python
#
# GMSK modulation and demodulation.
#
#
# Copyright 2005,2006,2007 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.
#
# See gnuradio-examples/python/digital for examples
from gnuradio import gr
from gnuradio import modulation_utils
from math import pi
import numpy
from pprint import pprint
import inspect
import time
import struct
import pylab as p
import sys
from math import atan2
# default values (used in __init__ and add_options)
_def_samples_per_symbol = 2
_def_bt = 0.35
_def_verbose = True
_def_log = True
_def_gain_mu = 0.05
_def_mu = 0.5
_def_freq_error = 0.0
_def_omega_relative_limit = 0.005
# /
# GMSK modulator
# /
class gmsk_mod(gr.hier_block2):
def __init__(self,
samples_per_symbol=_def_samples_per_symbol,
bt=_def_bt,
verbose=_def_verbose,
log=_def_log):
"""
Hierarchical block for Gaussian Minimum Shift Key (GMSK)
modulation.
The input is a byte stream (unsigned char) and the
output is the complex modulated signal at baseband.
@param samples_per_symbol: samples per baud >= 2
@type samples_per_symbol: integer
@param bt: Gaussian filter bandwidth * symbol time
@type bt: float
@param verbose: Print information about modulator?
@type verbose: bool
@param debug: Print modualtion data to files?
@type debug: bool
"""
gr.hier_block2.__init__(self, "gmsk_mod",
gr.io_signature(1,1,gr.sizeof_char), # Input signature
gr.io_signature(1,1,gr.sizeof_gr_complex)) # Output signature
self._samples_per_symbol = samples_per_symbol
self._bt = bt
if not isinstance(samples_per_symbol, int) or samples_per_symbol < 2:
raise TypeError, ("samples_per_symbol must be an integer >= 2, is %r" % (samples_per_symbol,))
ntaps = 4 * samples_per_symbol # up to 3 bits in filter at once
sensitivity = (pi / 2) / samples_per_symbol # phase change per bit = pi / 2
# Turn it into NRZ data.
self.nrz = gr.bytes_to_syms()
# Form Gaussian filter
# Generate Gaussian response (Needs to be convolved with window below).
self.gaussian_taps = gr.firdes.gaussian(
1, # gain
samples_per_symbol,# symbol_rate
bt, # bandwidth * symbol time
ntaps # number of taps
)
self.sqwave = (1,) * samples_per_symbol # rectangular window
self.taps = numpy.convolve(numpy.array(self.gaussian_taps),numpy.array(self.sqwave))
self.gaussian_filter = gr.interp_fir_filter_fff(samples_per_symbol, self.taps)
# FM modulation
self.fmmod = gr.frequency_modulator_fc(sensitivity)
# Connect components
self.connect(self, self.nrz, self.gaussian_filter, self.fmmod, self)
if verbose:
self._print_verbage()
if log:
self._setup_logging(
Re: [Discuss-gnuradio] Capturing 12-bit data at 10MHz sample clock?
Dan Halperin wrote: >> From poking around, it appears to me that the data transfer across the >> USB is either 2 * 8 bits/sample or 2 * 16. 2 * 12 should be easy enough >> to disentangle? > It'll involve hacking the FPGA code, but no, it shouldn't be especially > hard. The problem with 12 bit code is that it does not fit 1:1 in 16 bit streams. This means that you must send halve samples to the PC. and the driver must know which is MSB and which is LSB determined by the position in the 512 byte USB packet. But it can be done of course. One other way is using the new m-block code. This supports much more flexibility on what data formats you send over the bus. > > -Dan > > Jan Schiefer wrote: >> This may be a dumb question, but suppose I changed the USRP ADC clock to >> 10MHz. If you just change the 64 MHZ clock, this means that the FPGA will also run on 10 MHz. I am not sure that the communication with the FX2 chip (USB chip) will still work because the FX2 runs at 48 MHz. > Would there be a way to get 12-bit integer data across the USB, >> using usrp_rx_cfile.py or something similar? This would result in a >> manageable USB transfer rate of 30MB/s and line up pretty well with the >> bandwidth of the TVRX tuner. The bandwith of the TVRX is 6 MHz. and it uses real sampling (not complex) That means you need a sampling freq of at least 12 MHz. This could be converted inside the FPGA to a 6 Msamples/sec complex stream. Since the IF of the TVRX is located at 44 MHz, you also need to consider where the niquist freq lies. The TVRX uses real sampling of an IF of 44 MHz (or was it 48 MHz). This goes well with a 64 Msamples/sec samplerate. The niquist frequency is 64/2 = 32 Mhz, so you get the 44 Mhz mirrored about this which results in a IF freq seen by the FPGA at 20 MHz (which is about 6 MHz wide). This is downconverted by the cordic in the FPGA to a complex IF at 0. which can the be decimated to the rate you want. This whole story will not work with a 10 Msamples/sec samplerate. the 44 MHz will mirror around to 4 MHz and be 6 MHz wide. This means from 1 to 7 Mhz. But the niquist freq of 10 Msamples/sec is 5 Mhz, which lies inside the 1 - 7 Mhz range. A better way is running the ADC and FPGA at 40 MHz. The IF will come out at 4 Mhz (1 to 7 MHz) but this time your samplerate is high enough. You can then decimate by 4 inside the FPGA, like it is done now. Yet another way involves no clock change at all. I have been working with fractional rate decimaters/interpolators inside the USRP FPGA. You can put a fractional rate decimater inside the FPGA which decimates by 6.4. It is a bit hard to get them to fit but you get a lot of flexibility out of them without changing the clocks. > > >> Just curious, >>Jan > > >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Capturing 12-bit data at 10MHz sample clock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It'll involve hacking the FPGA code, but no, it shouldn't be especially hard. - -Dan Jan Schiefer wrote: > This may be a dumb question, but suppose I changed the USRP ADC clock to > 10MHz. Would there be a way to get 12-bit integer data across the USB, > using usrp_rx_cfile.py or something similar? This would result in a > manageable USB transfer rate of 30MB/s and line up pretty well with the > bandwidth of the TVRX tuner. > > From poking around, it appears to me that the data transfer across the > USB is either 2 * 8 bits/sample or 2 * 16. 2 * 12 should be easy enough > to disentangle? > > Just curious, >Jan > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG84yay9GYuuMoUJ4RAvjhAKC+VoYbVeE+iakEsoaGvkSjjEvjLwCghgP0 gdhp/Qk4wWoxs+BAo0ZHNjc= =oQqz -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Capturing 12-bit data at 10MHz sample clock?
This may be a dumb question, but suppose I changed the USRP ADC clock to 10MHz. Would there be a way to get 12-bit integer data across the USB, using usrp_rx_cfile.py or something similar? This would result in a manageable USB transfer rate of 30MB/s and line up pretty well with the bandwidth of the TVRX tuner. From poking around, it appears to me that the data transfer across the USB is either 2 * 8 bits/sample or 2 * 16. 2 * 12 should be easy enough to disentangle? Just curious, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
Vijay Ramasami wrote: On 8/17/07, Jan Schiefer <[EMAIL PROTECTED]> wrote: Vijay Ramasami wrote: Thanks for the information David. I will look up ITU-J.83B ... Do you happen to have any captured QAM cable data (or any website that lists the data) ? I wanted to see if I can put together a software demod for digital cable ... On 8/13/07, David I. Emery <[EMAIL PROTECTED]> wrote: On Mon, Aug 13, 2007 at 10:52:54AM -0400, Vijay Ramasami wrote: Hi, I have a couple of questions: 1. Does the US digital cable system follow the DVB-C standard (or one of its annexes) ? Is there any information (website) on the typical symbol rates, bandwidths (I am guessing approx 6 MHz), used ? There is a Cablelabs spec that defines what is used. The ETSI standards (ITU-T J.83B) also define the particular parameters as well. I can look up detailed references if needed... The are actually only two standard modulations in wide use 64QAM with a particular set of parameters that yields a 30 Mb/s signal with a 5.056941 Msym/symbol rate and a 256QAM signal which yields a 38.9 Mb/s signal with a symbol rate of 5.360537 Msym/s Both signals are 6 MHz wide as US CATV is universally 6 MHz channel based. 2. Has anyone successfully captured (preferably unencrypted) digital QAM transmissions using the USRP ? If so, can you please send me a link to the data ? Given that the symbol rates are in the range of 5-6 Ms/s, it must be possible to use 16 MHz sampling frequency to demodulate the signals. I have used a number of purpose built demods, but not yet tried a USRP solution. Some of the cable transport streams have open channels, but you will find most are encrypted except the local OTA HD signals and a few freebie promos. It is also possible to MODULATE QAM cable standard signals, something that gets more useful every month as more QAM/ATSC tuners are shipped for cable ready setups with CableCards rather than set top boxes. This of course allows direct input of MPEG transport streams into the digital domain of LCD/plasma panels with no analog step... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." If you can't find any, let me know and I might be able to help. I have access to 2 QAM-64 channels and 15 or so QAM256 channels, some HD, all unencrypted. I probably have some encrypted ones too, but I don't know how many, as they are encrypted... If you can write a little capture program, I can try to hook up the USRP to the cable jack and see whether I can capture something. Problem is, I don't have a TVRX (yet), but this that may be a good excuse to order one. :-). Provided the phase response of the TVRX is sufficiently flat for this kind of signal. Anybody have a guess? Cheers, Jan Hi Jan, I would highly appreciate it if you can capture a few QAM-64 snapshots. I was able to successfully demodulate signals captured from a QAM modulator, but I don't have access to a real-world cable source. I guess the python script "usrp_rx_cfile.py" (in the examples directory) can be used to capture samples. We need at least 16 MHz sampling frequency for symbol timing recovery to work properly. Thanks, Vijay. Hi Vijay, sorry this is taking so long, but I think I have what you need now. With a 16MHz sampling frequency you get only 8 bits of resolution, so I was a little skeptical as to whether this would be sufficient. I played around with a 10 second QAM64 snapshot (640MB, stored as 16-bit signed ints, which gzips down to around 270MB). I put a chunk of this data into the Agilent 89600 Vector Signal Analyzer software, and with equalization turned on, the constellation actually looks pretty reasonable. So what I captured must not be complete garbage :-). Let me know if you still need this and I find a shady spot on the web to put it. Or if you'd rather have something shorter, or stored as floats, let me know. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
