comm.SDRuReceiver on X310 throws receiveDat​a:ErrLateC​ommand

I am trying to receive data from a USRP X310 in MATLAB using comm.SDRuReceiver, and I keep hitting the error:

Receive unsuccessfully: Could not execute UHD driver command in 'receiveData_cont_c': receiveData:ErrLateCommand. A stream command was issued in the past.

Running the benchmark_rate reports: * 0 dropped samples * 0 overflows * 0 late commands * 0 timeouts

Answer 1

[Umar]

Hi @Hepzibah, Thanks for raising this. I looked into the ErrLateCommand error you are seeing with comm.SDRuReceiver on the X310, and here is a plain-English explanation of what is happening and how to fix it. What the error actually means: When MATLAB starts receiving data from the X310, it sends a timed instruction to the radio telling it when to begin streaming. If the radio's internal clock has already passed that scheduled start time by the time the instruction arrives, the radio rejects it with the message "a stream command was issued in the past." This is purely a startup timing problem, not a problem with the data transfer itself — which is exactly why benchmark_rate comes back clean (it only tests what happens once streaming is already running). The most likely causes and what to do about each: 1. Wrong FPGA image loaded on the X310 If you have used the basebandTransmitter app at any point, it loads a custom FPGA image onto the radio. The comm.SDRuReceiver object requires the standard Ettus default image and will not automatically switch back. Run the following command in MATLAB to reload the correct image before trying again: sdruload('X310', '192.168.10.2') 2. Incorrect master clock rate The X310 only supports two valid master clock rates: 200 MHz and 184.32 MHz. Any other value (including 120 MHz, which was removed in R2020a) can cause timing issues at startup. Make sure your object is set to one of these: rx.MasterClockRate = 200e6; % or 184.32e6 3. Host computer too slow on the first call MATLAB has some overhead the very first time it talks to the radio, which can push the stream command past its scheduled time. A simple fix is to add one dummy call before your main loop to absorb that startup cost: rx(); % discard this first call, then start your real loop 4. Clock source set incorrectly If ClockSource or PPSSource is set to External or GPSDO but no external reference is physically connected, the radio's sense of time becomes unreliable. Unless you have an external 10 MHz reference or GPS disciplined oscillator plugged in, keep both set to Internal: rx.ClockSource = 'Internal'; rx.PPSSource = 'Internal'; 5. Previous session not properly closed If a prior MATLAB session crashed without releasing the radio, the X310 may still think it is busy. Run findsdru to check the radio status and use clear rx or release(rx) to free it before reconnecting. 6. Network connection On a 1GigE connection the round-trip time for the startup command is longer, making the timing race more likely. If your X310 is connected via the SFP+ port (10GigE), prefer that. On Linux, also consider increasing the UDP socket buffer size. Quick sanity-check sequence to try: findsdru % confirm radio is idle probesdru % confirm firmware versions sdruload('X310','192.168.10.2') % reload default FPGA image rx = comm.SDRuReceiver(Platform='X310', IPAddress='192.168.10.2', MasterClockRate=200e6, DecimationFactor=200, CenterFrequency=2.4e9, ClockSource='Internal', PPSSource='Internal'); rx(); % warm-up call % now run your actual receive loop If the error persists after these steps, it would be worth opening a case with MathWorks Support and sharing the output of probesdru along with your MATLAB and support package version (run ver in the Command Window). Hope this helps get you unblocked.