It's a limitation of the FPGA interface to the RFIC. It doesn't support the tight setup/hold requirements for operation at the higher clock clock rate required for 2 x 61.44 Msps.
Wade On Wed, May 4, 2022 at 2:38 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
