samples are dropped!!

[mehdi200180]

until 2M sample/sec your project is doing well. but above it, when i stopped the program running, it still printing the results on the terminal and waits a lot of time to finish the run. then when i check the error rate with simulation, a lot of mismatch have occurred. i think it is dropping some samples, maybe because of printing is engaging some cores of cpu. my sdr is usrpB210 and my system has enough cores (16 cores).

[DavidToddMiller]

Please try the following troubleshooting steps to see whether it clears the issue at high data rates for you:

1. When in the GRC window/GUI ("execute the flowgraph" button on the GRC GUI menu bar should NOT be used), please use the ubuntu/linux command terminal instead to run the flowgraph if you are not already doing that:
   • On GRC GUI menu bar, select "Generate the Flowgraph" button/icon to generate a python script file (.py") at the bottom of the GRC GUI window.
   • Then, copy and paste that .py script file link into the command terminal of ubuntu/linux and run the flowgraph outside of GRC GUI for much faster performance.
   • Running flowgraph at rates well above 2 Msps or so will not work when only using GRC GUI.
2. If steps above do not work, try running the "simulation" flowgraph in the "examples" folder of this site that does not require the usrp (file is "Simulation_No_Limesdr_HighDataRate_UNcoded_QPSK.grc"):
   • Capture the total flowgraph run time in seconds and verify the file size is as expected for the symbol rate you are using. If this works, then issue can be narrowed down to the usrp/Gnuradio interface probably.
   • Again run the simulation flowgraph in the Linux/Ubuntu command terminal after generating the python script file in the GRC GUI window using the above steps.

Regards, Dave

[mehdi200180]

thanks for your answer, i solved the mentioned problem by commenting the debug lines in your code and it works well until 15 Msample/second. but there is a problem. when i compare the output of two unmodulated bitstream {one from sdr path} and {one from simulation path}. it some time gives me a constant error (mismatched bits / total bits) of 0.0047 (a bit more or less) regardless of how many symbols demodulated. some time it gives me underflow/overflow when running with sdr and the error is very high (around 0.5). then i checked the BBFileModQPSK__CCSDS_32ASM with output of simulation and it has always gives me constant error of 0.0047 regardless of rate of sampling :(. are you sure about the correctness of your architecture?

[DavidToddMiller]

On the Bit Error Rate (BER), the first 1-3 frames may be missing at the output due to initial synchronization:

1. Before comparing the input/output files for BER, please delete the first couple of frames of the master "BBFileModQPSK__CCSDS_32ASM" depending on the frame counter value of the first frame on your output. I edit and view the files with the "Okteta" app myself.
2. As stated in the conference paper section 4.4, after the 32 bit ASM is a header of 64 bits that includes a counter at its end that is incremented for each frame. Frame counter is last 16 bits of that 64 bit header.
3. For BER, then compare the output file to the input file when they both begin at the same frame (same counter value). Or at least I think that will solve your issue.
4. In the "examples/QPSK_Generate_Modulator_Files" subfolder I included a file with the first two frames missing which was typical when I ran the flowgraph, but not always 2 frames missing. File is "BBFileModQPSK__CCSDS_32ASM_first_2FramesMISSING".

In the future, I will maybe include a block with a lot less debug lines to print in the terminal when running as you discovered worked better at high rates. I kept the debug lines so far because I thought it would help the user understand the block functions more easily. Your independent feedback on this is helpful.

[mehdi200180]

دمت گرم داداش :). کار رو در آوردی.

[mehdi200180]

Thanks for your help. You made it work out.