Re: [USRP-users] B200mini vs B205mini - is there any performance difference?
Marcus, Thanks for the answer. I look at the stock FPGA images and B205mini’s file is almost twice larger. Are they actually the same by functionality/resources used by stock image, or 205 has some more buffers or something like that? Vladimir >Четверг, 20 августа 2020, 0:24 +03:00 от Marcus D Leech >: > >The FPGA on the B205 is larger and also has the extended industrial >temperature range. But apart from that they are identical. > >Sent from my iPhone > >> On Aug 19, 2020, at 5:17 PM, Vladimir via USRP-users < >> usrp-users@lists.ettus.com > wrote: >> >> >> Hello! >> >> Is there any performance difference between subjects if we’re going to use >> stock fpga firmware? I see that B205mini has twice larger fpga, but does it >> really influence perfomance/capabilities and how? Are there any other >> differences between them? Is B200mini in some way limited in comparison to >> B205mini, if we’re not going to forge our own fpga fw for it? We are >> speaking about some regular stream-based sdr applications like experimental >> gsm-umts-lte setups with sampling rates up to ~15-20 MSps. Currently we have >> done some experiments with B205mini, and need more boards, so we need to >> understand if B200mini would suffice. >> >> Thank you, >> Vladimir Pavlenko >> >> >> ___ >> 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
[USRP-users] B200mini vs B205mini - is there any performance difference?
Hello! Is there any performance difference between subjects if we’re going to use stock fpga firmware? I see that B205mini has twice larger fpga, but does it really influence perfomance/capabilities and how? Are there any other differences between them? Is B200mini in some way limited in comparison to B205mini, if we’re not going to forge our own fpga fw for it? We are speaking about some regular stream-based sdr applications like experimental gsm-umts-lte setups with sampling rates up to ~15-20 MSps. Currently we have done some experiments with B205mini, and need more boards, so we need to understand if B200mini would suffice. Thank you, Vladimir Pavlenko ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] UHD performance on Odroid XU4 with B210
Hi all, We are trying to run UHD on Odroid XU4 which has Samsung Exynos 5244 (4xA15 cores @ 2 GHz + 4xA7 cores @ 1.4 GHz with NEON support) and USB 3.0 onboard. UHD version is 003.010.002. We managed to build it (essentially just having added compiler flags to enable neon support), and it is able to run rx_samples_to_file at 20 MHz (w/o storing, since SD is not fast at all), but trying to run rx_samples_to_file --rate 30e6 --freq 1e9 --null I get permanent OOO series from the very capture start. Did anyone succeed to run the capture on XU4 at 30 MSps? With htop I can see that the example runs on lower 4 cores of XU4 which are low-rate A7 cores (it uses them at average 50% though). Is it possible to force it to run on high-power cores? I tried to put 4 lower cores offline, but then rx_samples_to_file freezes the whole system after printing "Waiting for "lo_locked": ++" (the following " locked." never gets printed, and all other remote connections to the system freeze; only power cycle helps). What is the decent way to test usb3 input speed with such a setup? Vladimir ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] R: X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
Daniele, Thank you for your advice! The problem here (not so big though) is that upon receiving of needed number of samps you need to stop streaming and that implies waiting for some timeout while excess samps being flushed (as I understood, after issuing STREAM_MODE_STOP_CONTINUOUS you have to clear input buffers using something like streamer->flush_all(0.01);). I'm trying to estimate how long that timeout should be, and in some cases it obviously would be more or less worse than a possible scenario without timeouting. Vladimir >Понедельник, 2 октября 2017, 16:05 +03:00 от Disco Daniele >: > >I have the same problem. >In the generation of the streamer >uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS); >erase the instruction stream_cmd.num_amps = total_num_samps; (or similar) > >and instead to use a counter over the samples use a counter over the blocks of >data that the streamer acquires. > >In b210 each acquisition is of 2044 samples >In E310 is of 1016 (samps_per_buff) > > >You can divide the number of samples (>0xfff) for samps_per_buff and make >a for loop to acquire all the data that you need >rx_stream->revc(buff_ptrs, samps_per_buff, md, timeout) > >I hope this help you > >Da: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] Per conto di >Vladimir via USRP-users >Inviato: venerdì 29 settembre 2017 16:53 >A: usrp-users >Oggetto: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation > >Hello, > >Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter >some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 sec >of time. A bit surprised to see this in 64-bit environment... The assertion is >in module rx_vita_core_3000.cpp: > >UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff); > >Is this some physical limit, or it can be patched to a larger value? It's kind >of inconvenient to solve this through continuous streaming when you need a >trace of a certain length... > >Vladimir > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora >abbiate ricevuto questo documento per errore siete cortesemente pregati di >darne immediata comunicazione al mittente e di provvedere alla sua >distruzione, Grazie. > > >This e-mail and any attachments is confidential and may contain privileged >information intended for the addressee(s) only. Dissemination, copying, >printing or use by anybody else is unauthorised. If you are not the intended >recipient, please delete this message and any attachments and advise the >sender by return e-mail, Thanks. > > >Rispetta l'ambiente. Non stampare questa mail se non è necessario. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
Derek, Thanks for the reply! When you say "try modifying that area of the logic", you refer to FPGA code (which I assume is related with rebuilding the firmware image)? Or to host side code where I can simply increase that assertion limit to some more bits (say to 0x7fff ) and see if it produces problems receiving samples? > so if the DDC is used to lower the sample rate then the maximum number of > samples which can be received with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced > by the decimation factor. When (under what condition) should I notice the effect of this factor? Because now I use 200 MHz master clock and sample at 100 MSps rate, and I'm able to receive all 0x0fff samples which is the assertion limit. > While the continuous mode is less convenient when you need a very specific > number of samples it does not require very much helper code to receive any > arbitrary number of samples and flush any excess ones away. I understand that, still additional efforts are needed here. Eg, are there any example code on how to do this flushing correctly? Because rx_samples_to_file stops streaming just by Ctrl-C handler, without any additional actions. After I issued stop streaming cmd, how should I do such a flush operation? I mean I want to avoid waiting for any timeouts which will prolongate the overall input duration. If it's not possible without waiting for time out, then of which order this time out should be, to make it minimal? Vladimir >Понедельник, 2 октября 2017, 16:59 +03:00 от Derek Kozel >: > >That assertion is protecting a register in the Radio Block on the FPGA. You >could try modifying that area of the logic which is counting the outputted >samples as they are packetized. I do not believe that other areas of the code >would be impacted (other than that assertion in the host code of course). > >While the continuous mode is less convenient when you need a very specific >number of samples it does not require very much helper code to receive any >arbitrary number of samples and flush any excess ones away. The overhead of >doing so is minimal when only done once every few seconds. > >A related note to be aware of is that the num_samps value is actually at the >radio clock sample rate not the final sample rate, so if the DDC is used to >lower the sample rate then the maximum number of samples which can be received >with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced by the decimation factor. > >Regards, >Derek > >On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users < >usrp-users@lists.ettus.com > wrote: >>Hello, >> >>Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter >>some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 >>sec of time. A bit surprised to see this in 64-bit environment... The >>assertion is in module rx_vita_core_3000.cpp: >> >>UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff); >> >>Is this some physical limit, or it can be patched to a larger value? It's >>kind of inconvenient to solve this through continuous streaming when you need >>a trace of a certain length... >> >>Vladimir >> >> >> >>___ >>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
[USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
Hello, Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 sec of time. A bit surprised to see this in 64-bit environment... The assertion is in module rx_vita_core_3000.cpp: UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff); Is this some physical limit, or it can be patched to a larger value? It's kind of inconvenient to solve this through continuous streaming when you need a trace of a certain length... Vladimir ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Trying to build v. 003.010 Win64
BTW, I indeed forgot to mention that we use X300 over 10G interface, of course without usb. Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall jsend...@csir.co.za : >Hi Vladimir, > >You need to link with libusb. It seems to be needed regardless of whether you >enable the sub module or not. > >Kind regards, >Joshua Sendall > >On 25 Sep 2017 6:18 PM, Vladimir via USRP-users < usrp-users@lists.ettus.com > >wrote: >>[The e-mail server of the sender could not be verified (SPF Record)] >> Hello USRP team! >> >>In our Linux application for quite a while we use some��3.10 version of UHD >>(which requires FPGA ver. 33) and it works fine. Now we want to use the same >>version in Windows app, to match the FPGA ver. But trying to build any of >>3.10 versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two >>strange linking errors: >> >>Error ��500 ��error LNK2019: unresolved external symbol "public: >>virtual __cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" >>(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: >>virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting >>destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z) >> >>Error ��501 ��error LNK2019: unresolved external symbol "public: >>virtual __cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" >>(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: >>void __cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" >>(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ) >> >>in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj >> >>Looks like it's related with boost libs, which I'm not familiar with. I >>switched to last boost 1.65.1 (started with 1.60 with the sme results), tried >>UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. >>Ver. 3.9.7 builds OK. >> >>BTW, I use the following sequence to build boost: >> >>bootstrap >>b2 toolset=msvc-12.0 address-model=64 >>b2 toolset=msvc-12.0 address-model=64 --with-test link=shared As I see you >>have binaries for VC2013 available, obviously it should build correctly. Do >>you have any idea of what could be the problem here? I use MS Visual Studio >>2013 Ultimate with Update 5. >> >>Thank you! >>Vladimir Pavlenko >> >> >> >> >> >> >> >> > >-- >This message is subject to the CSIR's copyright terms and conditions, e-mail >legal notice, and implemented Open Document Format (ODF) standard. >The full disclaimer details can be found at >http://www.csir.co.za/disclaimer.html . > >Please consider the environment before printing this email.___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Trying to build v. 003.010 Win64
Joshua, Thanks for your reply! It was my first thought too. But 1) ver 3.9.7 as I wrote builds w/o a glitch, and 2) looking at the error messages it's not obvious how libusb could help here. Those functions that it misses are compiler-generated helper-funcs for uhd::... class(es), so I doubt it will find them in libusb... May be I don't see something, but it would be good if someone from USRP team confirmed that libusb is absolutely required here (starting from v. 3.10.0.0). Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall jsend...@csir.co.za : >Hi Vladimir, > >You need to link with libusb. It seems to be needed regardless of whether you >enable the sub module or not. > >Kind regards, >Joshua Sendall > >On 25 Sep 2017 6:18 PM, Vladimir via USRP-users < usrp-users@lists.ettus.com > >wrote: >>[The e-mail server of the sender could not be verified (SPF Record)] >> Hello USRP team! >> >>In our Linux application for quite a while we use some��3.10 version of UHD >>(which requires FPGA ver. 33) and it works fine. Now we want to use the same >>version in Windows app, to match the FPGA ver. But trying to build any of >>3.10 versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two >>strange linking errors: >> >>Error ��500 ��error LNK2019: unresolved external symbol "public: >>virtual __cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" >>(??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: >>virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting >>destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z) >> >>Error ��501 ��error LNK2019: unresolved external symbol "public: >>virtual __cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" >>(??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: >>void __cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" >>(??_Dusb_zero_copy@transport@uhd@@QEAAXXZ) >> >>in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj >> >>Looks like it's related with boost libs, which I'm not familiar with. I >>switched to last boost 1.65.1 (started with 1.60 with the sme results), tried >>UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. >>Ver. 3.9.7 builds OK. >> >>BTW, I use the following sequence to build boost: >> >>bootstrap >>b2 toolset=msvc-12.0 address-model=64 >>b2 toolset=msvc-12.0 address-model=64 --with-test link=shared As I see you >>have binaries for VC2013 available, obviously it should build correctly. Do >>you have any idea of what could be the problem here? I use MS Visual Studio >>2013 Ultimate with Update 5. >> >>Thank you! >>Vladimir Pavlenko >> >> >> >> >> >> >> >> > >-- >This message is subject to the CSIR's copyright terms and conditions, e-mail >legal notice, and implemented Open Document Format (ODF) standard. >The full disclaimer details can be found at >http://www.csir.co.za/disclaimer.html . > >Please consider the environment before printing this email.___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Trying to build v. 003.010 Win64
Hello USRP team! In our Linux application for quite a while we use some 3.10 version of UHD (which requires FPGA ver. 33) and it works fine. Now we want to use the same version in Windows app, to match the FPGA ver. But trying to build any of 3.10 versions in MS Visual Studio 2013 (Release x64 cfg) I'm getting two strange linking errors: Error 500 error LNK2019: unresolved external symbol "public: virtual __cdecl uhd::transport::usb_device_handle::~usb_device_handle(void)" (??1usb_device_handle@transport@uhd@@UEAA@XZ) referenced in function "public: virtual void * __cdecl uhd::transport::usb_device_handle::`vector deleting destructor'(unsigned int)" (??_Eusb_device_handle@transport@uhd@@UEAAPEAXI@Z) Error 501 error LNK2019: unresolved external symbol "public: virtual __cdecl uhd::transport::usb_zero_copy::~usb_zero_copy(void)" (??1usb_zero_copy@transport@uhd@@UEAA@XZ) referenced in function "public: void __cdecl uhd::transport::usb_zero_copy::`vbase destructor'(void)" (??_Dusb_zero_copy@transport@uhd@@QEAAXXZ) in file D:\VS\uhd\host\build\lib\usb_dummy_impl.obj Looks like it's related with boost libs, which I'm not familiar with. I switched to last boost 1.65.1 (started with 1.60 with the sme results), tried UHD 3.10.0.0, 3.10.2.0 and some one in between like 3.10.1.0 - all the same. Ver. 3.9.7 builds OK. BTW, I use the following sequence to build boost: bootstrap b2 toolset=msvc-12.0 address - model = 64 b2 toolset=msvc-12.0 address - model = 64 --with-test link=shared As I see you have binaries for VC2013 available, obviously it should build correctly. Do you have any idea of what could be the problem here? I use MS Visual Studio 2013 Ultimate with Update 5. Thank you! Vladimir Pavlenko ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
