I have tested new configuration (T_data=50ms, Tburst=250ms) on two different, quite modern laptops (i7- and i5-based) and got the same result in both cases: transmission received via RX channel 0 was unreliable as timing of RX bursts was incorrect (only ca. 40 ms long part of TX burst was actually received). However, the problem does not occurr for the same configuration on another very powerful, desktop computer (i7-7700K) with recent motherboard. Also, if I increase Tburst to 300ms, the problem no longer occurr even on mentioned laptops.
So, it looks like this is hapenning when LimeSDR is receiving late RX requests. But this is very wrong that device is not reporting this problem at all (not a single error code is returned via readStream(), device is claiming that is was able to successfully receive all the requested samples). Moreover, I don’t understand why it fires RX burst too soon in that case (I am able to see the beginning of actual transmitted burst in the received data). If the RX call is late indeed, I would rather expect firing RX burst too late as well and thus seeing only end of actual transmitted burst in the received data. Why only channel 0 is affected? This is another mystery.
@andrewback, is anybody going to look into this?