locked
What does this mean? RRS feed

  • Question

  • I modified the umxsdrbrick. When I run the executable file, it turns out as follows:

    I find that the error comes from here:

    So, what does that mean? 

    What I have done is adding some code in the process_kb function. Is that wrong? Thanks!

    Tuesday, June 3, 2014 9:12 AM

All replies

  • This block of code is error handling for 2 RxStream synchronization. Each block in RxStream has a timestamp, in MIMO usage, they should be synchronized before further signal processing. Hardware sometimes miss one block, this is as "single timestamp drop". If the hardware is really broken or the synchronization code cannot work correctly, you willl meet "consequent timestamp", means that multiple consequent blocks are missed.

    For your problem, I suggest:

    1. rollback you code change, test our original sample on your hardware, to make sure hardware is working in good condition.

    2. make sure you build with 'fre' profile instead of 'chk'.

    3. check your code for side-effect on RxStream synchronization. Maybe something slows down the realtime signal processing, so it is difficult to synchronize them.


    • Proposed as answer by Qi LuoEditor Thursday, June 5, 2014 7:10 AM
    • Edited by Qi LuoEditor Tuesday, June 10, 2014 5:29 AM refine
    Thursday, June 5, 2014 7:09 AM
    Answerer
  • Thank you for your answer.

    BTW, what do you mean by "Release" mode and "Debug" mode?

    What I have done is as follows:

    I add some codes in the process_kb function, in which I print out some parameters into a file and sleep() for 1000 ms. The parameters are collected in baseband using BB11ACarrierSense function.

    Then, I compile the umxsdrbrick with "x86 Free Build" and generate umxsdrbrick.exe in the target folder. I use that executable file. Is that file "Release" mode or "Debug" mode?

    My operating system is Windows 7 x64. But I find in this forum that if I want build theumxsdrbrick.exe, I should use the x86 Free Build. So I did as that.

    Is there something wrong in what I have done and that causes the problem?

    Thanks.

    Friday, June 6, 2014 1:48 AM
  • I find that if I sleep 2000ms in the process_kb function, it will turn out the "timestamp drop" problem. If I sleep for only 200ms, there is no such problem.

    What I want to do is output some parameters into a text and I will do that continuously.

    At present, I realize the outputing in the process_kb function, but it will turn out the "timestamp drop" problem and the system will crash after a few second.

    So what should I do? Looking forward to your answer. Thanks!

    -Will Qin

    Friday, June 6, 2014 8:14 AM
  • Thank you for your answer.

    BTW, what do you mean by "Release" mode and "Debug" mode?

    What I have done is as follows:

    I add some codes in the process_kb function, in which I print out some parameters into a file and sleep() for 1000 ms. The parameters are collected in baseband using BB11ACarrierSense function.

    Then, I compile the umxsdrbrick with "x86 Free Build" and generate umxsdrbrick.exe in the target folder. I use that executable file. Is that file "Release" mode or "Debug" mode?

    My operating system is Windows 7 x64. But I find in this forum that if I want build theumxsdrbrick.exe, I should use the x86 Free Build. So I did as that.

    Is there something wrong in what I have done and that causes the problem?

    Thanks.

    Yes, you should use 'Free Build' for realtime test. 'x86' is also correct.
    Tuesday, June 10, 2014 5:39 AM
    Answerer
  • I cannot find direct clue in your description. The "timestamp drop" problem is not directly related to the IO operations and sleep statement inside the function process_kb. So you can consider my other suggestions, such as

    1. rollback you code change, test our original sample on your hardware, to make sure hardware is working in good conditions

    2. check your code for side-effect on RxStream synchronization. Maybe something slows down the realtime signal processing, so it is difficult to synchronize them.

    3. incrementally apply your modification to the code base, test and see what's wrong.

    For OS crash, there should be a bug in drivers, please report with a kernel memory dump (not small memory dump) to help us diagnose. Thanks!

    -Qi


    • Edited by Qi LuoEditor Tuesday, June 10, 2014 5:45 AM fix typo
    Tuesday, June 10, 2014 5:44 AM
    Answerer