Hi Wade, I, too, thought that the E320 could run both channels at the higher rate. My understanding was that the E320 implemented the RFIC LVDS mode rather than the TTL mode (or something like that) such that the 2x30.72 limitation of the B210/E310 was removed to allow 2x61.44. Is the limitation due to the RFIC itself or in the way in which Ettus is using it? Rob
On Wed, May 4, 2022 at 2:24 PM Wade Fife <wade.f...@ettus.com> wrote: > Hi Martin, > > I'm sorry for the confusion. The maximum rate for E320 is 61.44 Msps, so > when you do dual channel, the maximum rate per channel is 30.72 Msps. You > can do 61.44 Msps with a single channel. The fact that you don't see an > error message when setting it too high is a known issue. > > Wade > > On Wed, May 4, 2022 at 8:54 AM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 2022-05-04 08:43, Martin wrote: >> > Hi, >> > >> > I have data corruption problems with high speed dual channel capturing >> > on USRP E320 over 10 gbit ethernet. >> > >> > Medium rate, dual channel, everything seems fine. >> > High speed, single channel, everything also seems fine. >> > High speed, dual channel capturing. Problems. High amount of random >> > high values in datastream even with low gain and low signal level) >> > >> > I do not seem to get U or O (Underrun, Overrun) errors >> > >> > >> > I was under the impression that with E320 you should be able to >> > capture dual channel 56 Msps signals. If that is not feasable then we >> > have a serious problem. >> > I also do not see any error messages. >> > We tested on two different E320ś on two different host-PC's. Same >> result. >> > >> > >> > Do you also have these problems? >> > >> > Do you have tips on how to solve or check what the issue is? >> > >> > Thanks in advance. >> > >> > Please see below for details >> > >> > >> > When captured with uhd_rx_cfile or our own capture scripts. >> > The output data shows random very high, usualle even full scale values >> > even if the input signal is small and gain low. >> > With int 16 output values are between 32768 and -32767. With complex >> > float from -1.0 to 1.0 >> > >> > The capture is done from a host-pc using the E320 as remote capture >> > device over 10 Gbit ethernet. >> > >> > The USRP E320 is running UHD 4.0.0.0 >> > root@ni-e320-321D09C:~# uhd_config_info --version >> > UHD 4.0.0.0-0-g90ce6062 >> > >> > The host pc is also running uhd_4.0.0.0: >> > nldudok1@noisegate:~$ uhd_config_info --version >> > UHD 4.0.0.0-133-g7ec04886 >> > >> > >> > dual channel high speed test with complex int16 (complex short) >> > wrong values in both channels. Whatever the gain. values go from >> > -32767 to 32768 >> > uhd_rx_cfile -a master_clock_rate=56e6 -c 0,1 -g 44.0 -r 56e6 -f >> > 105.0e6 -N 56e6 -s tmp_cshort_56M_g44.raw >> > uhd_rx_cfile -a master_clock_rate=56e6 -c 0,1 -g 0.0 -r 56e6 -f >> > 105.0e6 -N 56e6 -s tmp_cshort_56M_g0.raw >> > >> > Same result with complex float32 output, values fo from -1.0 to +1.0 >> > whaterver the gain. >> > uhd_rx_cfile -a master_clock_rate=56e6 -c 0,1 -g 44.0 -r 56e6 -f >> > 105.0e6 -N 56e6 tmp_cfloat_56M_g44.raw >> > uhd_rx_cfile -a master_clock_rate=56e6 -c 0,1 -g 0.0 -r 56e6 -f >> > 105.0e6 -N 56e6 tmp_cfloat_56M_g0.raw >> > >> > >> > Same test at medium datarate. Values are OK. complex float or complex >> > short output. Note >> > uhd_rx_cfile -a master_clock_rate=16e6 -c 0,1 -g 44.0 -r 16e6 -f >> > 105.0e6 -N 16e6 -s tmp_cshort_16M.raw >> > uhd_rx_cfile -a master_clock_rate=16e6 -c 0,1 -g 44.0 -r 16e6 -f >> > 105.0e6 -N 16e6 tmp_cfloat_16M.raw >> > >> > Single channel test at high rate also seems OK with eather complex >> > int16 or complex float32 output values. >> > Note that with complex float output the same writespeed to the ssd is >> > needed as with dual channel and complex int16 output. So it does not >> > seem to be a slow disk issue. Would also not be very likely since we >> > are storing only 1 second of data which should fit in linux disk write >> > buffer. >> > uhd_rx_cfile -a master_clock_rate=56e6 -g 44.0 -r 56e6 -f 105.0e6 -N >> > 56e6 -s tmp_cshort_56M_g44_single.raw >> > uhd_rx_cfile -a master_clock_rate=56e6 -g 44.0 -r 56e6 -f 105.0e6 -N >> > 56e6 tmp_cfloat_56M_g44_single.raw >> > >> > >> > You can look at complex float output data with gr-plot_iq and >> gr_plot_fft >> > complex short data can be converted to complex float with our own >> > little conversion script. >> > cshort_to_cfloat.py -i inputfilename.raw -o outputfilename.raw >> > (I can send the conversion script if you need it. It is just a file >> > source, interleaved short to complex block and file sink) >> > >> > >> > Example: >> > uhd_rx_cfile -a master_clock_rate=56e6 -c 0,1 -g 0.0 -r 56e6 -f >> > 105.0e6 -N 56e6 -s tmp_cshort_56M_g0.raw >> > #first channel >> > cshort_to_cfloat.py -i tmp_cshort_56M_g0.0.raw -o >> > tmp_cshort_56M_g0_converted_to_cfloat.0.raw >> > #second channel >> > cshort_to_cfloat.py -i tmp_cshort_56M_g0.1.raw -o >> > tmp_cshort_56M_g0_converted_to_cfloat.1.raw >> > >> > #show data >> > gr-plot_iq -R 56e6 tmp_cshort_56M_g0_converted_to_cfloat.0.raw >> > gr-plot_iq -R 56e6 tmp_cshort_56M_g0_converted_to_cfloat.1.raw >> > >> > >> > Best regards, >> > >> > Martin Dudok van Heel >> > _______________________________________________ >> > >> Martin: >> >> I've forwarded your note to Ettus R&D. >> >> But in the meantime, are you running the latest UHD? >> >> What happens if you reduce the sample rate "a little" -- like down to >> 52Msps? >> >> I know that on other platforms that use the AD9361 (as the E320 does) >> that the maximum supported rate for dual-channel is 32Msps, but that may >> just be because of the >> type of clocking+data interface used on those platforms--the AD9361 >> supports a couple of different interface regimes... >> >> >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
