13 Feb
2014
13 Feb
'14
9:35 p.m.
I'm getting some errors when using gnuradio-companion with the osmocom
source that I think might be a bug related to this patch:
cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b6583af…
This is the output I get:
Using Volk machine: avx_32_mmx_orc
gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2
Failed to set out of bound frequency: 1.37912e+08
aUaUaUaUaUaUaU
When I look at the patch in the commit I linked above that error relates to
setting the input frequency. There are 2 expected parameters
get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the GUI
osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth, both
of which I have set. I don't see a way to define the start and stop
frequency which seems to be generating this error.
13 Feb
13 Feb
9:49 p.m.
Al,
bladeRF can't tune down to 1.37912e+08.
Best regards,
Dimitri
On Thu, 13 Feb 2014 21:35:58 +0100, Al Smith <sdradio65(a)gmail.com> wrote:
I'm getting some errors when using
gnuradio-companion with the osmocom
source that I think might be a bug related to this patch:
cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b6583af…
This is the output I get:
Using Volk machine: avx_32_mmx_orc
gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2
Failed to set out of bound frequency: 1.37912e+08
aUaUaUaUaUaUaU
When I look at the patch in the commit I linked above that error relates
to
setting the input frequency. There are 2 expected parameters
get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the
GUI
osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth,
both
of which I have set. I don't see a way to define the start and stop
frequency which seems to be generating this error.
10 p.m.
That is true, but I am still getting this aUaU thing even with a different
frequency.
Using Volk machine: avx_32_mmx_orc
gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU
On Thu, Feb 13, 2014 at 12:49 PM, Dimitri Stolnikov <horiz0n(a)gmx.net> wrote:
Al,
bladeRF can't tune down to 1.37912e+08.
Best regards,
Dimitri
On Thu, 13 Feb 2014 21:35:58 +0100, Al Smith <sdradio65(a)gmail.com> wrote:
I'm getting some errors when using gnuradio-companion with the osmocom
source that I think might be a bug related to
this patch:
cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b
6583af7021
This is the output I get:
Using Volk machine: avx_32_mmx_orc
gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2
Failed to set out of bound frequency: 1.37912e+08
aUaUaUaUaUaUaU
When I look at the patch in the commit I linked above that error relates
to
setting the input frequency. There are 2 expected parameters
get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the
GUI
osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth,
both
of which I have set. I don't see a way to define the start and stop
frequency which seems to be generating this error.
10:05 p.m.
Hi,
On 13.02.2014 22:00, Al Smith wrote:
That is true, but I am still getting this aUaU thing
even with a
different frequency.
aU means audio underflow and is a problem/rate mismatch in your
flowgraph. It's printed by the Audio Sink and not related to gr-osmosdr
in any way.
Regards,
Steve
10:12 p.m.
Sorry. My mistake. Thanks for the assistance.
On Thu, Feb 13, 2014 at 1:05 PM, Steve Markgraf <steve(a)steve-m.de> wrote:
Hi,
On 13.02.2014 22:00, Al Smith wrote:
That is true, but I am still getting this aUaU
thing even with a
different frequency.
aU means audio underflow and is a problem/rate mismatch in your
flowgraph. It's printed by the Audio Sink and not related to gr-osmosdr
in any way.
Regards,
Steve
3726
days inactive
3726
days old
4 comments
3 participants
participants (3)
-
Al Smith -
Dimitri Stolnikov -
Steve Markgraf