I'm not sure how you are responding, but it is still not threading correctly. Thanks for trying though.
I would not expect the C API to make a performance difference like that since it is only a wrapper. Are you still using timed commands? If not then the additional overhead of sending commands from the host computer to the USRP and back could account for some of the performance difference. On Mon, Feb 26, 2018 at 3:53 PM, Андрей 1 via USRP-users < usrp-users@lists.ettus.com> wrote: Thank you for the clarification about set_rx_lo_freq. Can the problem with long setup time arise due to the fact that I use C API? Thank you On Mon, Feb 26, 2018 at 3:44 PM, Derek Kozel <derek.ko...@ettus.com> wrote: > Hello, > > Please can you keep your emails in a single thread so it is easier to read. > > The goal with the frequency hopping example is to instantly jump between > frequencies. Normally those 3-5 ms of tuning would be dead time, no > meaningful signal could be received. By using the RF synthesizers of both > channels and switching the LO source back and forth you are always jumping > to a frequency after the synthesizers have already tuned and settled. > > The text written at the top of the example should be rewritten to be a bit > clearer. There are other situations, such as using an external LO, where > the set_rx_lo_freq call is useful. In this example however the benefit > comes from tuning the unused synthesizers. If all the frequencies which you > wish to tune to the receiver to are known ahead of time it would be > possible to have UHD pre-calculate all the LO frequencies, store them in > your application, and then save a few microseconds by using the > set_rx_lo_freq function to avoid UHD doing extra work to configure the > filters on the unused channel. This is almost never useful since there is > some margin in the 5 ms frequency hopping time. Also often applications > will actually want to sit on one frequency longer than 5 ms and are only > using the LO source swapping ability to avoid the dead time of synthesizer > tuning. > > Regards, > Derek > > On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users < > usrp-users@lists.ettus.com> wrote: > I have no any error in twinrx_recv. > If the tuning frequency is already sufficiently small, then why these > special calls(set_rx_lo_freq) for twinRX? > > Thank you > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1 <andrew4...@rambler.ru> wrote: > >> Im using UHD 3.10.3 and have no error in twinrx_recv >> >> >> 26.02.2018, 17:01, Derek Kozel <derek.ko...@ettus.com> >> Hello, >> >> The tuning time is approximately 5 ms, which is why the example uses that >> number. The example should work the same on either Windows or Linux. What >> version of UHD are you using on Windows which does not include it? >> >> Are you seeing any streaming errors on Windows? >> >> Regards, >> Derek >> >> On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> >> Hello >> >> Im using X300+TwinRX in Windows. >> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping. >> How much I understand in this example the receiver is tuned with the >> period 5ms.As written in the title of the example, I need to use >> set_rx_lo_freq.But it is not in the source code of the example. >> When I compile and run this example in windows I found much more begger >> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as >> in the example, then there are no parts of the spectrum and so the receiver >> does not have time to tune in). >> >> My questions >> >> What minimum tuning time for TwinRX+X300? >> Why is there no such example for Windows? >> Is it necessary to use set_rx_lo_freq to reduce setup time? >> >> Thank you >> >> . >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <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
