Is there a reason why this wouldn't shift the signal that is demodulated?

GNU Radio
1

My goal is to be able to read a frequency other than the frequency that
was
tuned to draw samples using usrp_rcv_cfile (ie I used 93.3M, and want to
be
able to demodulate 92.5M…I’d try to use lessons learned from wfm_rcv2
but
that uses set_rx_freq in the pipelines, which obviously I don’t have
access
to)

Taking a cue from this
http://www.nabble.com/Frequency-Hopping-td20538730.html
I tried to shift by -.8Mhz

    mix_freq = -.8e6
    Cosine = gr.sig_source_f(usrp_rate,gr.GR_COS_WAVE,mix_freq,1,0)
    Sin    = gr.sig_source_f(usrp_rate,gr.GR_SIN_WAVE,mix_freq,1,0)

    self.expjw = gr.float_to_complex()
    self.connect(Cosine,(self.expjw,0))
    self.connect(Sin,(self.expjw,1))

    self.mixer = gr.multiply_cc()

    self.connect (self.u, (self.mixer, 0))
    self.connect (self.expjw, (self.mixer, 1))

    self.connect (self.mixer, gr.throttle(gr.sizeof_gr_complex,

usrp_rate), chan_filt, self.guts, self.volume_control, audio_sink)

I also tried using freq_xlating_fir_filter_ccf (which googling looked
like
it was overkill) to no effect. In both cases I just hear a noisy version
of
93.3M, I can’t get it to focus on something that wasn’t the center of
the
frequency that my samples were taken.

Any ideas?

2

I also tried implementing the same idea thusly

fir_chan_coeffs = gr.firdes.low_pass (1.0, # gain
usrp_rate, # sampling
rate
80e3, # low pass
cutoff freq
5.5e3, # width
of
trans. band
gr.firdes.WIN_HANN) # filter
type

    fir_filter = gr.freq_xlating_fir_filter_ccf (1,

#decimation rate
fir_chan_coeffs,
#taps
-.8e3,
#frequency translation
usrp_rate)

    self.connect (self.u, gr.throttle(gr.sizeof_gr_complex,

usrp_rate),
fir_filter, self.guts, self.volume_control, audio_sink)

to no avail

2009/8/8 Jonathan C. [email protected]

3

On Sat, Aug 08, 2009 at 05:02:55PM -0400, Jonathan C. wrote:

    mix_freq = -.8e6
    Cosine = gr.sig_source_f(usrp_rate,gr.GR_COS_WAVE,mix_freq,1,0)
    Sin    = gr.sig_source_f(usrp_rate,gr.GR_SIN_WAVE,mix_freq,1,0)

Consider using gr.sig_source_c. It generates a complex sinusoid.

I also tried using freq_xlating_fir_filter_ccf (which googling looked like
it was overkill) to no effect. In both cases I just hear a noisy version of
93.3M, I can’t get it to focus on something that wasn’t the center of the
frequency that my samples were taken.

gr.freq_xlating_fir_filter_ccf is the easiest way to extract one or
more frequency bands from a wider band input. usrp_wfm_rcv_sca.py
uses it to extract the SCA channel.

If all you want to do is shift a frequency use gr.sig_source_c and a
gr.multiply_cc

In virtual all cases you do not want to be using throttle…

Eric

4

I know you say not to use a throttle, but for some reason it absolutely
does
not work without one. Any idea why that would be? It sounds very
distorted
and sped up, and then I get a bunch of xO errors. With throttling it
works
perfectly.

2009/8/9 Eric B. [email protected]

5

On Aug 9, 2009, at 5:03 PM, Jonathan C. wrote:

I know you say not to use a throttle, but for some reason it
absolutely does not work without one. Any idea why that would be? It
sounds very distorted and sped up, and then I get a bunch of xO
errors. With throttling it works perfectly.

“oX” means that the data is coming in too fast for the sink to handle
so data is being dropped. I think this notation is non-standard for
audio sinks, but there is it.

The instantiation of an audio_sink is typically:

audio_sink (int sample_rate,
const std::string device_name,
bool do_block)

and by default “do_block” is supposed to be true … but for some
reason either it’s false in your case (instantiated that way?), or
maybe something is broken in the OSX audio sink.

In your Python script, try instantiating the audio_sink with the
sample rate, the device name (I think OSX uses numbers, e.g., “1”,
“2”, etc.), and true for blocking. If that doesn’t work, then
something is broken somewhere. - MLD

6

Who knows how such things got changed, but that would make complete
sense,
and it did indeed fix that problem.

As a nerdy question, are there any particularly amenable ways to
compress
the sample files? 2 seconds of 4MS/s is like 130MB/s. The normal mac
compression gave me about 25% of the size… which is good, but you
never
know.

2009/8/9 Michael D. [email protected]

7

On Monday 10 August 2009 02:41:33 Jonathan C. wrote:
[…]

As a nerdy question, are there any particularly amenable ways to compress
the sample files? 2 seconds of 4MS/s is like 130MB/s. The normal mac
compression gave me about 25% of the size… which is good, but you never
know.

It may be possible to use flac for compression. flac is lossless, and
supports
raw input/output streams, multiple channels (so you use left/right for
i/q),
and arbitrary bit depths.

try:
flac --endian=little --channels=2 --bps=16 --sign=signed
–force-raw-format
input.raw
flac --decode --output-name output.raw input.flac

Not really sure if endianess/signage … is correct, try yourself.

Stefan

–
Stefan Brüns / Bergstraße 21 / 52062 Aachen
mailto:lurch at gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/
phone: +49 241 53809034 mobile: +49 151 50412019