Re: [Discuss-gnuradio] Ettus X310 FPGA Compatibility Number

[Zhan Yanjun]

Hi Derek,
Thanks for the reply! Yes, it turns out that we didn’t rebuild GNU Radio. It’s 
working fine now, thanks for your help!

From: Derek Kozel 
Sent: Monday, 30 July 2018 23:49
To: Zhan Yanjun 
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Ettus X310 FPGA Compatibility Number

Hello YJ,
Each version of UHD knows where to download the correct matching FPGA image. 
What has most likely happened is that when you installed the new UHD you did 
not also rebuild GNU Radio. Is it possible that you did not install the newer 
UHD? normally it would overwrite the older UHD and you would actually see a 
different error where GNU Radio recognizes that UHD has been updated and that 
GNU Radio needs to be rebuilt.
After you have GNU Radio using the version of UHD that you want, then follow 
the instructions from the error message to download the matching FPGA image and 
load it onto the X310.

"Please run:

 "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"/usr/bin/uhd_image_loader" --args="type=x300,addr=192.168.30.2"
"

On Mon, Jul 30, 2018 at 10:35 AM, Zhan Yanjun 
mailto:zyan...@dso.org.sg>> wrote:
Hello,

I am relatively new to the SDR scene, and I have set up the UHD and X310 
drivers in my computer. I used gnuradio-companion to create a simple flowchart 
to test the receiving and recording of signals, and I came across this error:

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Traceback (most recent call last):
  File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 340, in 
main()
  File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 328, in main
tb = top_block_cls()
  File "/home/user/Desktop/ZYJ X310 files/top_block.py", line 106, in __init__
channels=range(4),
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, 
in constructor_interceptor
return old_constructor(*args)
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2683, 
in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

 "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"/usr/bin/uhd_image_loader" --args="type=x300,addr=192.168.30.2"

For more information, refer to the UHD manual:

 http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash


According to this line:
RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:
This means that the UHD version, which I installed to be 3.10.3.0, is expecting 
an FPGA version lower than that flashed in the X310. As a result, I installed 
the latest UHD version 3.13.0.0, and tried it again. However, the same error 
was shown. This seems very strange, as now the newest UHD version expects an 
older FPGA image version.

Please correct me if I misinterpret the error message.

Please advise me on this matter, what should I do in this scenario? The X310 is 
not mine, and I cannot just flash another FPGA version into the hardware.

Is there a list of corresponding FPGA compatibility numbers with the matching 
UHD versions? This may help me to troubleshoot and match the FPGA image with 
the correct UHD version.

Thanks in advance,
YJ


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-inspector failing with "AttributeError: 'module' object has no attribute 'signal_detector_cvf'"

[mail]

Hi Robert,

looks like the the signal_detector_cvf block is not properly loaded in 
Python land.
You can try to inspect the inspector module by running the necessary 
part of python manually and maybe catch another error there.


Cheers
Andrej

Am 2018-08-01 20:35, schrieb Robert Stanford:
After a lot of hard work I finally have gr-inspector loading in 
gnuradio.
I am trying to execute the signal detection example in 
gnuradio-companion

and am getting this error:

Generating: '/gr-inspector/examples/signal_detection.py'

Executing: /usr/bin/python2 -u 
/gr-inspector/examples/signal_detection.py


Traceback (most recent call last):
  File "/gr-inspector/examples/signal_detection.py", line 151, in 


main()
  File "/gr-inspector/examples/signal_detection.py", line 139, in main
tb = top_block_cls()
  File "/gr-inspector/examples/signal_detection.py", line 72, in 
__init__

self.inspector_signal_detector_cvf_0 =
inspector.signal_detector_cvf(samp_rate, 4096, 
firdes.WIN_BLACKMAN_hARRIS,

AttributeError: 'module' object has no attribute 'signal_detector_cvf'

 Any idea what's going on?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --GRC testcase created

[Edwin Li]

Hi Michael,

Since you said you did not have the problem I mentioned, I guess the change
is not written into the GNURadio. So I uninstall the module, re-make it,
re-installed it. After some adjustment about the vector size, it worked!
Thank you so much for shedding light on me!

Regards,
Edwin

On Wed, 1 Aug 2018 at 14:18 Michael Dickens 
wrote:

> Hi Edwin - You're welcome for the compatibility notes. Your changes work
> for me out of the box now, so: well done & keep it up!
>
> OK so a few things:
>
> (1) when I execute the GRC script you mention (as checked into your repo),
> I see the following:
> {{{
> Generating:
> '/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py'
> >>> Warning: This flow graph may not have flow control: no audio or RF
> hardware blocks found. Add a Misc->Throttle block to your flow graph to
> avoid CPU congestion.
>
> Executing: /opt/local/Library/Frameworks/
> Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> -u /Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py
>
> Traceback (most recent call last):
>   File
> "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py",
> line 218, in 
> main()
>   File
> "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py",
> line 206, in main
> tb = top_block_cls(Init=options.Init,
> Map_parameter=options.Map_parameter, spreading_gain=options.spreading_gain,
> sps=options.sps)
>   File
> "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py",
> line 87, in __init__
> self.blocks_vector_source_x_0 =
> blocks.vector_source_c(chaos.chaotic_prefix_bc(0.8,3.98,50,'len_tag_key'),
> False, 1, [])
>   File "/opt/local/Library/Frameworks/
> Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/blocks/blocks_swig1.py",
> line 1531, in make
> return _blocks_swig1.vector_source_c_make(*args, **kwargs)
> TypeError: in method 'vector_source_c_make', argument 1 of type
> 'std::vector< gr_complex,std::allocator< gr_complex > > const &'
> }}}
>
> which doesn't have the issue you're having ... but, this leads to the next
> item:
>
> (2) The method "chaotic_prefix_bc_impl::Logistic_map" returns as
> "std::vector", while in your GRC script you've made the vector
> source and file sink both complex ... correcting that helps but doesn't
> solve the issue because ...
>
> (3) "chaotic_prefix_bc_impl::Logistic_map" is a method in a class, not a
> function; it is meant to be called from some instantiation of the class,
> not directly like a function as you're doing in the GRC script. You can
> make it a static function inside the class & then what you're doing might
> work; might take some special SWIG sauce to get working.
>
> Hope this is useful. - MLD
>
> On Wed, Aug 1, 2018, at 3:40 PM, Edwin Li wrote:
>
> Hi Michael,
>
> Wow! Thanks for pointing out the compatibility issue in my DCSK block. I
> will modify that according to your suggestion.
> I added  chaotic_prefix_generator_template.grc
> 
>  to
> my repository. I use it to test.
> Inside there is a vector source. I tried to set the data as the output of
> Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr' object has
> no attribute 'Logistic_Map'
>
> Regards,
> Edwin
>
>
>
> On Wed, 1 Aug 2018 at 12:59 Michael Dickens 
> wrote:
>
> Hi Edwin - Is there a test or example in your repo that's failing? I have
> built it successfully; "make test" fails for a couple reasons but not for
> the specific issue you're having. I don't see any specific use of the
> method you're having issues with; hence my query. - MLD
>
> On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote:
> > Hi Michael,
> >
> > Thank you so much for your reply.
> >
> > I did add the method after building SWIG for the first time. And I have
> > tried "make clean" in  build/ and make again. I even tried deleting the
> > entire build/ folder and CMake. Still the same problem.
> >
> > I created a repository if you want to have a look.
> > https://github.com/lbyhp/gr-chaos
> >
> > Or you can tell me where to look to see whether the SWIG has made
> > corresponding changes.
> >
> > Regards,
> >
> > Edwin
> >
> >
> >
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --GRC testcase created

[Michael Dickens]

Hi Edwin - You're welcome for the compatibility notes. Your changes work
for me out of the box now, so: well done & keep it up!
OK so a few things:

(1) when I execute the GRC script you mention (as checked into your
repo), I see the following:{{{
Generating: 
'/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py'>>> 
Warning: This flow graph may not have flow control: no audio or RF
>>> hardware blocks found. Add a Misc->Throttle block to your flow graph
>>> to avoid CPU congestion.
Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py
Traceback (most recent call last):
  File "/Users/mlk/Desktop/TMP/gr-
  chaos/chaotic_prefix_generator_template.py", line 218, in main()
  File "/Users/mlk/Desktop/TMP/gr-
  chaos/chaotic_prefix_generator_template.py", line 206, in maintb = 
top_block_cls(Init=options.Init,
Map_parameter=options.Map_parameter,
spreading_gain=options.spreading_gain, sps=options.sps)  File 
"/Users/mlk/Desktop/TMP/gr-
  chaos/chaotic_prefix_generator_template.py", line 87, in __init__
self.blocks_vector_source_x_0 = blocks.vector_source_c(chaos.chaoti-
c_prefix_bc(0.8,3.98,50,'len_tag_key'), False, 1, [])  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/li-
  b/python2.7/site-packages/gnuradio/blocks/blocks_swig1.py", line
  1531, in makereturn _blocks_swig1.vector_source_c_make(*args, **kwargs)
TypeError: in method 'vector_source_c_make', argument 1 of type 'std::vector< 
gr_complex,std::allocator< gr_complex > > const &'}}}

which doesn't have the issue you're having ... but, this leads to the
next item:
(2) The method "chaotic_prefix_bc_impl::Logistic_map" returns as
"std::vector", while in your GRC script you've made the
vector source and file sink both complex ... correcting that helps
but doesn't solve the issue because ...
(3) "chaotic_prefix_bc_impl::Logistic_map" is a method in a class, not a
function; it is meant to be called from some instantiation of the
class, not directly like a function as you're doing in the GRC
script. You can make it a static function inside the class & then
what you're doing might work; might take some special SWIG sauce to
get working.
Hope this is useful. - MLD

On Wed, Aug 1, 2018, at 3:40 PM, Edwin Li wrote:
> Hi Michael,
> 
> Wow! Thanks for pointing out the compatibility issue in my DCSK block.
> I will modify that according to your suggestion.> I added  
> chaotic_prefix_generator_template.grc[1] to my repository. I
> use it to test.> Inside there is a vector source. I tried to set the data as 
> the output
> of Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr'
> object has no attribute 'Logistic_Map'> 
> Regards,
> Edwin
> 
> 
> 
> On Wed, 1 Aug 2018 at 12:59 Michael Dickens
>  wrote:>> Hi Edwin - Is there a test or example in 
> your repo that's failing? I
>> have built it successfully; "make test" fails for a couple reasons
>> but not for the specific issue you're having. I don't see any
>> specific use of the method you're having issues with; hence my
>> query. - MLD>> 
>>  On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote:
>>  > Hi Michael,
>>  > 
>>  > Thank you so much for your reply.
>>  > 
>>  > I did add the method after building SWIG for the first time. And I
>>  > have>>  > tried "make clean" in  build/ and make again. I even tried
>>  > deleting the>>  > entire build/ folder and CMake. Still the same problem.
>>  > 
>>  > I created a repository if you want to have a look. 
>>  > https://github.com/lbyhp/gr-chaos
>>  > 
>>  > Or you can tell me where to look to see whether the SWIG has made>>  > 
>> corresponding changes.
>>  > 
>>  > Regards,
>>  > 
>>  > Edwin
>>  > 
>>  > 
>>  > 


Links:

  1. 
https://github.com/lbyhp/gr-chaos/blob/master/chaotic_prefix_generator_template.grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --GRC testcase created

[Edwin Li]

Hi Michael,

Wow! Thanks for pointing out the compatibility issue in my DCSK block. I
will modify that according to your suggestion.
I added  chaotic_prefix_generator_template.grc

to
my repository. I use it to test.
Inside there is a vector source. I tried to set the data as the output of
Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr' object has
no attribute 'Logistic_Map'

Regards,
Edwin



On Wed, 1 Aug 2018 at 12:59 Michael Dickens 
wrote:

> Hi Edwin - Is there a test or example in your repo that's failing? I have
> built it successfully; "make test" fails for a couple reasons but not for
> the specific issue you're having. I don't see any specific use of the
> method you're having issues with; hence my query. - MLD
>
> On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote:
> > Hi Michael,
> >
> > Thank you so much for your reply.
> >
> > I did add the method after building SWIG for the first time. And I have
> > tried "make clean" in  build/ and make again. I even tried deleting the
> > entire build/ folder and CMake. Still the same problem.
> >
> > I created a repository if you want to have a look.
> > https://github.com/lbyhp/gr-chaos
> >
> > Or you can tell me where to look to see whether the SWIG has made
> > corresponding changes.
> >
> > Regards,
> >
> > Edwin
> >
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Issues with gr-fosphor in gnuradio

[Jose Ruvalcaba]

Hello,

I am experiencing an issue when running gr-fosphor in GNU Radio. I am
getting the following issue when ever I run my flowgraph:


*[+] Selected device: GeForce GTX 1080[!] CL Error (-5,
/home/ruvalcab/prefix/src/gr-fosphor/lib/fosphor/cl.c:480): Unable to share
spectrum VBO into OpenCL context*

I followed the install instructions for both the drivers and the gr-fosphor
block as was instructed in the fosphor wiki page. When I run it, my
Spectrum plot does not appear. I am currently running Ubuntu 16.04 LTS, GNU
Radio 3.7.12 and I have a GeForce GTX 1080 GPU.

Has anyone seen this issue before, and if so, can’t anyone shine some loft
in how to go about solving it?

Thanks,
Jose
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --Git repository created

[Michael Dickens]

Hi Edwin - Is there a test or example in your repo that's failing? I have built 
it successfully; "make test" fails for a couple reasons but not for the 
specific issue you're having. I don't see any specific use of the method you're 
having issues with; hence my query. - MLD

On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote:
> Hi Michael,
> 
> Thank you so much for your reply.
> 
> I did add the method after building SWIG for the first time. And I have 
> tried "make clean" in  build/ and make again. I even tried deleting the 
> entire build/ folder and CMake. Still the same problem.
> 
> I created a repository if you want to have a look. 
> https://github.com/lbyhp/gr-chaos
> 
> Or you can tell me where to look to see whether the SWIG has made 
> corresponding changes.
> 
> Regards,
> 
> Edwin
> 
> 
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-inspector failing with "AttributeError: 'module' object has no attribute 'signal_detector_cvf'"

[Robert Stanford]

 After a lot of hard work I finally have gr-inspector loading in gnuradio.
I am trying to execute the signal detection example in gnuradio-companion
and am getting this error:

Generating: '/gr-inspector/examples/signal_detection.py'

Executing: /usr/bin/python2 -u /gr-inspector/examples/signal_detection.py

Traceback (most recent call last):
  File "/gr-inspector/examples/signal_detection.py", line 151, in 
main()
  File "/gr-inspector/examples/signal_detection.py", line 139, in main
tb = top_block_cls()
  File "/gr-inspector/examples/signal_detection.py", line 72, in __init__
self.inspector_signal_detector_cvf_0 =
inspector.signal_detector_cvf(samp_rate, 4096, firdes.WIN_BLACKMAN_hARRIS,
AttributeError: 'module' object has no attribute 'signal_detector_cvf'

 Any idea what's going on?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --Git repository created

[edwin]

Hi Michael,

Thank you so much for your reply.

I did add the method after building SWIG for the first time. And I have 
tried "make clean" in  build/ and make again. I even tried deleting the 
entire build/ folder and CMake. Still the same problem.


I created a repository if you want to have a look. 
https://github.com/lbyhp/gr-chaos


Or you can tell me where to look to see whether the SWIG has made 
corresponding changes.


Regards,

Edwin




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to read .dat file saved via the file sink

[CEL]

Hi Linda,

first off: https://wiki.gnuradio.org/index.php/FAQ is your friend!

On Tue, 2018-07-31 at 13:42 -0400, Linda20071 wrote:
> Where could I find this command? I started Octave from Ubuntu command window.
> 

Sumit already answered that:
> 
> On Tue, Jul 31, 2018 at 1:24 PM, sumit kumar  wrote:
> > There is an octave script in gnuradio utilities. read_complex_binary.m

Look for the read_complex_binary.m

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation error for USRP N200

[Ayaz Mahmud]

Thanks Marcus,

I should have restarted the device. It solved.

Ayaz

From: Marcus D. Leech
Sent: Tuesday, July 31, 2018 7:12 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Installation error for USRP N200

On 07/31/2018 02:38 PM, Ayaz Mahmud wrote:

Hi,

I have already been using two USRP B210 over Gnuradio 3.7.10.1 which works 
perfect.

Now I am trying to bring in a N200 USRP, and installing it.


  1.  I can ping the IP 192.168.10.2/24 from my PC 192.168.10.1/24
  2.  I can also detect all the 3 devices with “uhd_find_devices”
  3.  When I run “uhd_usrp_probe” it gives error:

Please update the firmware and FPGA images for your device. See the….

Please run:

“/usr/local/lib/uhd/utils/uhd_images_downloader.py”

“/usr/local/bin/uhd_image_loader –args=”type=usrp2,addr=192.168.10.2”

  1.  I have run both the above command, 1st command says that all the targets 
are up to date and the 2nd command erases and re-wrights the firmware. But then 
returns the same error for “uhd_usrp_probe”.

Can you please let me know if I am doing anything wrong here and how should I 
fix it?

Thanks,
Ayaz

Did you power-cycle the N210 after you updated the firmware image?  The 
firmware is loaded at boot time into the SRAM of the FPGA.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python

[Michael Dickens]

Hi Edwin - Your C++ coding looks fine (to me).

 If you added this method -after- building SWIG for the first time, you
 generally need to "clean" the SWIG build (or, just "make clean" in the
 top-level build directory; maybe this is the "clean trick" you
 mention?), since oftentimes CMake doesn't catch these changes for
 rebuilding SWIG.
If this doesn't work it's much easier for us to help debug if you use a
public repo (e.g., on GitHub) & tell us what it is so we can work with
the whole OOT.
Hope this is useful. - MLD

On Tue, Jul 31, 2018, at 7:09 PM, Edwin Li wrote:
> Hi,
> 
> I've been trying to make a function in my OOT module public. The
> module is called chaotic_prefix_bc.> I declare a pure virtual function called 
> **Logistic_map()** in
> chaotic_prefix_bc.h, and overload it in chaotic_prefix_bc_impl.h and
> chaotic_prefix_bc_impl.cc.> When I call this function in a vector source(in 
> GNURadio) using: chao-
> s.chaotic_prefix_bc(0.8,3.98,50,'len_tag_key').Logistic_map(0.8,3.98,-
> 50), it says 'chaotic_prefix_bc_sptr' object has no attribute
> 'Logistic_map'.> I tried the make clean trick mentioned in the mailing list, 
> but to
> no avail.> I attached my code below. Please help me~
> 
> Regards,
> Edwin
> 
> 
> _
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Email had 3 attachments:


>  * chaotic_prefix_bc_impl.h 2k (text/x-chdr)
>  * chaotic_prefix_bc_impl.cc 5k (text/x-c++src)
>  * chaotic_prefix_bc.h 3k (text/x-chdr)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Regarding USRP_ECHOTIMER in gr-radar

[Prabhat Kumar Rai]

Hello to all,

I have been facing problem regarding the values to be filled in
USRP_ECHOTIMER in gr-radar block such as clock source, time source

return _radar_swig.usrp_echotimer_cc_make(*args, **kwargs)
RuntimeError: RuntimeError: Invalid option chosen for: clock source

Anyone help me by sending Some documents or suggesting link where I
can learn about this.


Regards,
Prabhat

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio