[Hackrf-dev] FM 96.5MHz rx works but 70cm 441.1MHz rx does not?

[David Hubbard]

On Wed, Nov 9, 2016 at 3:16 PM, Cinaed Simson <cinaed.simson at gmail.com>
wrote:

>
> In the NBFM receive block, try reducing Tau to 50u, and Max deviation to
> 4k.
>
>
(to the hackrf-dev list this time)

Thanks, Cinaed! Playing around with max deviation in particular helps with
reception quality, for the one good recording (see below).

I wasn't hearing anything but noise out the audio sink even eyeballing it
on the FFT plot, the signal is 20dB over the noise floor. So I added a file
sink, saved a few seconds of the 2.4Msps complex data output of the DC
blocker (so almost directly out of the osmocom source). I then used a file
source instead of the osmocom source -> DC blocker, and the result is loud
and clear audio.

Even more puzzling is it only did it once. I collected several more
recordings at 2.4Msps but they do not play back audio. Only the first
recording produces audio. They all show a strong 20dB signal in the FFT
plot and waterfall.

My grc file is attached. Possibly a lack of precision on frequency? I tried
setting the tune_offset to values from 598e3 to 654e3, which has the normal
effect on the first recording, but only static on the subsequent recordings.

I would like to add a "sync block," (is that the right term?) so that the
graph only plays back at real time, to make it easier to change tuning
parameters while playing back a recording. Any tips on how to do that? The
attached grc plays back at real time but buffers a lot of audio at the
audio sink so that changing things like tune_offset cannot be heard for
about 2 sec.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161109/bc4b927c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filesource.grc
Type: application/octet-stream
Size: 53509 bytes
Desc: not available
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161109/bc4b927c/attachment.obj>