Re: [USRP-users] USRP and Bladerf Sync
Hi Michael, Thanks for the valuable information. Is there any external software which will sync this both *Internally*? If yes, How? Please share the details of *external hardware required for this both devices to synchronize*. Regards, Rigiel On Mon, Oct 5, 2020 at 8:07 PM Michael Dickens wrote: > Hi Rigiel - At least in theory both the Bladerf XA4 and USRP B210 provide > external input for a 10 MHz REF, which -might- allow for some sense of > synchronization between them. It's really not clear to me whether that will > be enough, and whether the software controlling these devices can be > coerced into producing even vaguely time-aligned samples based on the > common REF signal. Maybe others here have used this particular combination > of SDR hardware in a synchronized manner? Good luck! - MLD > > > On Mon, Oct 5, 2020 at 2:37 AM Anes Rose Rigiel Anony via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Team, >> >> We are using *Bladerf XA4 as Base station 1 and USRP B210 as Base >> Station 2*. Since both devices use an internal clock as the clock >> source, both are *not in sync* so our application fails. >> >> I need to sync these both devices. >> >> *Is there any way to synchronize without an external clock and with an >> external clock?* >> >> Please share the detailed information on this. >> >> -- >> Regards, >> Rigiel, >> Cellular. >> >> Disclaimer:This message is intended only for the designated recipient(s). >> It may contain confidential or proprietary information and may be subject >> to other confidentiality protections. If you are not a designated >> recipient, you may not review, copy or distribute this message. Please >> notify the sender by e-mail and delete this message. GlobalEdge does not >> accept any liability for virus infected mails. >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > -- Regards, Rigiel, Cellular. -- Disclaimer:This message is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to other confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. Please notify the sender by e-mail and delete this message. GlobalEdge does not accept any liability for virus infected mails. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Compiling custom C++ code on E320
Hi Mark - Yeah you can't compile your UHD application for your host
computer (not cross-compiled using the USRP's SDK) and expect it to run on
the USRP. The USRP comes with a full UHD and development install, so you
should be able to compile your UHD application directly on the USRP. It
might not be fast, but it should work -- and, be compatible for
execution on the USRP to boot! You can alternatively obtain the USRP's SDK
and cross-compile the UHD application on your host computer with the USRP
as the target processor; then, move the resulting executable to the USRP
and it should work natively there. The E320 also works in "network mode",
meaning that you can use your host computer to run the UHD application and
transport data samples from the USRP to the host computer. This option is
useful and attractive for some users, and the USRP's embedded processor has
significant limitations for processing capabilities. I hope this helps! -
MLD
On Mon, Oct 5, 2020 at 10:17 AM Andrews, Mark J. via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I'm pretty new to SDR and am trying to run a custom C++ program on an
> E320. I modified the "rx_ascii_art_dft.cpp" file on my host computer so
> that it saves the DFTs to files instead of displaying them on the screen
> (with a 1 second delay between DFTs to prevent a million files being
> created). I recompiled UHD and tested the new rx_ascii_art_dft executable
> and it seems to be doing what I want. I was hoping (though not really
> expecting) that I could just copy the executable to the E320 and run it on
> there, but that does not work ("cannot execute binary file: Exec format
> error"). I've tried looking at the manual and searching the internet for
> how this is supposed to work, but it's not clear to me. Am I supposed to:
>
> 1) Rerun the mender filesystem update? Will this include the newly
> compiled files or will it simply reinstall the original files?
>
> https://kb.ettus.com/E320_Getting_Started_Guide#Updating_the_file_system_with_Mender
>
> 2) Compile directly on the E320?
>
> https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_mpm_native
>
> 3) Obtain an SDK and cross-compile?
> https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk
>
> 4) Something else?
>
> If anyone can point me in the right direction or include a link to a good
> "hello world" example/tutorial on creating custom programs that run on the
> E320, it would be greatly appreciated.
>
> Thank you,
> Mark
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP and Bladerf Sync
Hi Rigiel - At least in theory both the Bladerf XA4 and USRP B210 provide external input for a 10 MHz REF, which -might- allow for some sense of synchronization between them. It's really not clear to me whether that will be enough, and whether the software controlling these devices can be coerced into producing even vaguely time-aligned samples based on the common REF signal. Maybe others here have used this particular combination of SDR hardware in a synchronized manner? Good luck! - MLD On Mon, Oct 5, 2020 at 2:37 AM Anes Rose Rigiel Anony via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Team, > > We are using *Bladerf XA4 as Base station 1 and USRP B210 as Base Station > 2*. Since both devices use an internal clock as the clock source, both > are *not in sync* so our application fails. > > I need to sync these both devices. > > *Is there any way to synchronize without an external clock and with an > external clock?* > > Please share the detailed information on this. > > -- > Regards, > Rigiel, > Cellular. > > Disclaimer:This message is intended only for the designated recipient(s). > It may contain confidential or proprietary information and may be subject > to other confidentiality protections. If you are not a designated > recipient, you may not review, copy or distribute this message. Please > notify the sender by e-mail and delete this message. GlobalEdge does not > accept any liability for virus infected mails. > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Installation from source (Gnuradio 3.8.2.0 on Ubuntu 18.04.05) - test failure qa_cpp_py_binding (Failed) ...
Hi Emil - Your comment (3) is interesting ... it very well might be that CTRLPORT / Thrift no longer works reliably; as I noted: both interfaces have not been actively maintained for years. I don't see this changing any time soon either. Anyway: Disabling them as you note is the way to go & I hope that takes care of the issues for you so you can get on to your actual USRP work. Cheers! - MLD On Mon, Oct 5, 2020 at 5:25 AM Emil Bjelski wrote: > Hi Michael, > > I agree with you comments 1) and 2) therefore I will disable Thrift and > CTRLPORT. > > Related to 3) before posting questions I was checking mailing lists and I > read that CTRLPORT should work well with thrift *0.10.0.* > Therefore I have installed thrift version 0.10.0., however there are still > errors. > > Kind Regards, > > Emil > > On Sun, Oct 4, 2020 at 5:33 PM Michael Dickens > wrote: > >> Hi Emil - A few thoughts: >> >> 1) This is a GNU Radio question; not a USRP one. You'd be better served >> by querying the GR discussion list < >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >. >> >> 2) Those failing tests are related to CTRLPORT and it's use of Thrift. >> Unless you are going to be using the CTRLPORT feature of GNU Radio, then >> you should disable that component as well as the use of Thrift ... just >> don't use it. If you don't know what it is, then you don't need it. >> >> 3) CTRLPORT / Thrift interface has not been actively maintained for >> years, and Thrift keeps moving forward ... so, there are likely to be >> incompatibilities between them ... might be there already. If I recall >> correctly, CTRLPORT's Thrift interface works with Thrift versions 0.10.0 >> and 0.11.0 ... might work with 0.12.0 ... and has issues with 0.13.0 (the >> current Thrift release). I might be wrong here too. Hence: What version of >> Thrift are you using? Can you revert to, say, 0.11.0? That might help here. >> >> I hope this is useful! - MLD >> >> >> >> On Sun, Oct 4, 2020 at 5:28 AM Emil Bjelski via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hi All, >>> >>> I getting errors when calling make test, while installing Gnuradio >>> 3.8.2.0 on Ubuntu 18.04.05. >>> I have also installed thrift version 0.10.0. >>> >>> These are errors >>> `99% tests passed, 3 tests failed out of 368 >>> Total Test time (real) = 166.29 sec >>> The following tests FAILED: >>> 171 - qa_cpp_py_binding (Failed) >>> 172 - qa_cpp_py_binding_set (Failed) >>> 173 - qa_ctrlport_probes (Failed) >>> Errors while running CTest` >>> >>> Further if I call >>> >>> ctest --output-on-failure >>> >>> I get following >>> >>> `170/368 Test #170: qa_copy >>> Passed0.46 sec >>> Start 171: qa_cpp_py_binding >>> 171/368 Test #171: qa_cpp_py_binding >>> ..***Failed0.83 sec >>> EE >>> == >>> ERROR: test_001 (__main__.test_cpp_py_binding) >>> -- >>> Traceback (most recent call last): >>> File >>> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >>> line 111, in test_001 >>> rval = v1.get() >>> File >>> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >>> line 7519, in get >>> return _runtime_swig.RPC_get_string_get(self) >>> RuntimeError: basic_string::_M_construct null not valid >>> >>> == >>> ERROR: test_002 (__main__.test_cpp_py_binding) >>> -- >>> Traceback (most recent call last): >>> File >>> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >>> line 162, in test_002 >>> radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') >>> TypeError: __init__() got an unexpected keyword argument 'argv' >>> >>> -- >>> Ran 2 tests in 0.352s >>> >>> FAILED (errors=2) >>> DEPRECATED: Using filename with gr_unittest does no longer have any >>> effect. >>> >>> Start 172: qa_cpp_py_binding_set >>> 172/368 Test #172: qa_cpp_py_binding_set >>> ..***Failed0.71 sec >>> EE >>> == >>> ERROR: test_001 (__main__.test_cpp_py_binding_set) >>> -- >>> Traceback (most recent call last): >>> File >>> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", >>> line 107, in test_001 >>> rval = g3.get() >>> File >>> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >>> line 7519, in get >>> return _runtime_swig.RPC_get_string_get(self) >>> RuntimeError:
[USRP-users] Compiling custom C++ code on E320
Hello,
I'm pretty new to SDR and am trying to run a custom C++ program on an E320. I
modified the "rx_ascii_art_dft.cpp" file on my host computer so that it saves
the DFTs to files instead of displaying them on the screen (with a 1 second
delay between DFTs to prevent a million files being created). I recompiled UHD
and tested the new rx_ascii_art_dft executable and it seems to be doing what I
want. I was hoping (though not really expecting) that I could just copy the
executable to the E320 and run it on there, but that does not work ("cannot
execute binary file: Exec format error"). I've tried looking at the manual and
searching the internet for how this is supposed to work, but it's not clear to
me. Am I supposed to:
1) Rerun the mender filesystem update? Will this include the newly compiled
files or will it simply reinstall the original files?
https://kb.ettus.com/E320_Getting_Started_Guide#Updating_the_file_system_with_Mender
2) Compile directly on the E320?
https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_mpm_native
3) Obtain an SDK and cross-compile?
https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk
4) Something else?
If anyone can point me in the right direction or include a link to a good
"hello world" example/tutorial on creating custom programs that run on the
E320, it would be greatly appreciated.
Thank you,
Mark
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Installation from source (Gnuradio 3.8.2.0 on Ubuntu 18.04.05) - test failure qa_cpp_py_binding (Failed) ...
Hi Michael, I agree with you comments 1) and 2) therefore I will disable Thrift and CTRLPORT. Related to 3) before posting questions I was checking mailing lists and I read that CTRLPORT should work well with thrift *0.10.0.* Therefore I have installed thrift version 0.10.0., however there are still errors. Kind Regards, Emil On Sun, Oct 4, 2020 at 5:33 PM Michael Dickens wrote: > Hi Emil - A few thoughts: > > 1) This is a GNU Radio question; not a USRP one. You'd be better served by > querying the GR discussion list < > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >. > > 2) Those failing tests are related to CTRLPORT and it's use of Thrift. > Unless you are going to be using the CTRLPORT feature of GNU Radio, then > you should disable that component as well as the use of Thrift ... just > don't use it. If you don't know what it is, then you don't need it. > > 3) CTRLPORT / Thrift interface has not been actively maintained for years, > and Thrift keeps moving forward ... so, there are likely to be > incompatibilities between them ... might be there already. If I recall > correctly, CTRLPORT's Thrift interface works with Thrift versions 0.10.0 > and 0.11.0 ... might work with 0.12.0 ... and has issues with 0.13.0 (the > current Thrift release). I might be wrong here too. Hence: What version of > Thrift are you using? Can you revert to, say, 0.11.0? That might help here. > > I hope this is useful! - MLD > > > > On Sun, Oct 4, 2020 at 5:28 AM Emil Bjelski via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi All, >> >> I getting errors when calling make test, while installing Gnuradio >> 3.8.2.0 on Ubuntu 18.04.05. >> I have also installed thrift version 0.10.0. >> >> These are errors >> `99% tests passed, 3 tests failed out of 368 >> Total Test time (real) = 166.29 sec >> The following tests FAILED: >> 171 - qa_cpp_py_binding (Failed) >> 172 - qa_cpp_py_binding_set (Failed) >> 173 - qa_ctrlport_probes (Failed) >> Errors while running CTest` >> >> Further if I call >> >> ctest --output-on-failure >> >> I get following >> >> `170/368 Test #170: qa_copy >> Passed0.46 sec >> Start 171: qa_cpp_py_binding >> 171/368 Test #171: qa_cpp_py_binding >> ..***Failed0.83 sec >> EE >> == >> ERROR: test_001 (__main__.test_cpp_py_binding) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >> line 111, in test_001 >> rval = v1.get() >> File >> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >> line 7519, in get >> return _runtime_swig.RPC_get_string_get(self) >> RuntimeError: basic_string::_M_construct null not valid >> >> == >> ERROR: test_002 (__main__.test_cpp_py_binding) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding.py", >> line 162, in test_002 >> radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') >> TypeError: __init__() got an unexpected keyword argument 'argv' >> >> -- >> Ran 2 tests in 0.352s >> >> FAILED (errors=2) >> DEPRECATED: Using filename with gr_unittest does no longer have any >> effect. >> >> Start 172: qa_cpp_py_binding_set >> 172/368 Test #172: qa_cpp_py_binding_set >> ..***Failed0.71 sec >> EE >> == >> ERROR: test_001 (__main__.test_cpp_py_binding_set) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", >> line 107, in test_001 >> rval = g3.get() >> File >> "/home/tkazaz/workarea/gnuradio/build/gnuradio-runtime/python/gnuradio/gr/../../../swig/runtime_swig.py", >> line 7519, in get >> return _runtime_swig.RPC_get_string_get(self) >> RuntimeError: basic_string::_M_construct null not valid >> >> == >> ERROR: test_002 (__main__.test_cpp_py_binding_set) >> -- >> Traceback (most recent call last): >> File >> "/home/tkazaz/workarea/gnuradio/gr-blocks/python/blocks/qa_cpp_py_binding_set.py", >> line 129, in test_002 >> radiosys = GNURadioControlPortClient(argv=argv, rpcmethod='thrift') >> TypeError: __init__() got an unexpected keyword argument 'argv' >> >>
[USRP-users] USRP and Bladerf Sync
Hi Team, We are using *Bladerf XA4 as Base station 1 and USRP B210 as Base Station 2*. Since both devices use an internal clock as the clock source, both are *not in sync* so our application fails. I need to sync these both devices. *Is there any way to synchronize without an external clock and with an external clock?* Please share the detailed information on this. -- Regards, Rigiel, Cellular. -- Disclaimer:This message is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to other confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. Please notify the sender by e-mail and delete this message. GlobalEdge does not accept any liability for virus infected mails. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
