UHD Receive Stream for large sample rate/ bw causing SEGV #335
Comments
|
Thanks for these detailed information! I tried to reproduce this behaviour with a USRP-N210 on linux, but could not provoke any error. Unfortunately, I do not possess a B200, so we cannot be sure if the error is related to this device or to OS X. Do you have the option to try out the B200 with URH on Windows and/or Linux? This way, we may get nearer to the true error that is causing this behaviour. |
|
I’ll try Ubuntu 16.04 /Python 3.6 today. I might have a Debian machine as well.
I’ve only got virtualbox for Windows, and it’s usb handling is appalling, so I’m sure there will be more issues there than just the above.
|
Update:Repro'd on Ubuntu, so it might be a B200 USRP issue. If you need more logs from other processes, I can grab those. Expected Behavior
Actual Behavior
Steps to Reproduce the Problem
Platform Specifications
|
|
Thanks for this test, so now we know it is nothing OS X exclusive. Could you try if the high sampling rates with B200 are working in other applications like GNU Radio? |
|
Tested on the above two machines (OS X 10.12.1 & Ubuntu 16.04) Test Specifications
Result:
|
|
Interesting...is it also working from URH if you switch the backend for USRP to GNU Radio via Options -> Device? |
|
GNU Radio backend works as expected on the ubuntu machine, full 20M visible. I can't test it on the OS X machine due to conflicting python versions. |
|
No problem, thanks for all your information so far. So to summarize, the problem appears with native backend for USRP B200 regardless of the OS. I will see what I can do, might be an issue of buffer sizes. Just out of curiousity: Why do you work with a high sample rate like 20M? For all devices I investigated so far, I found 2M-5M sufficent. |
|
Summary seems correct. I’d also note this issue is present with any sufficiently large increase in bandwidth or sample rate, say from 1 to 2 M or from 10 to 20 M. I’m looking at spread spectrum devices, often using up to 75M in bandwidth. I know URH doesn’t have decode for the schemes, but the timeline tools have been useful. |
UpdateI was able to recreate the bug by leaving a 1MHz / 1MSps spectrum analyzer open for a few minutes. Same issues as before, with no logged indication of an error. |
|
Had a deeper look on this, but without the B200 at hand it seems impossible to locate the error. I suspect something in cpdef uhd_error recv_stream(connection, int num_samples):
print("entering receive stream")
num_samples = (<int>(num_samples / max_num_rx_samples) + 1) * max_num_rx_samples
cdef float* result = <float*>malloc(num_samples * 2 * sizeof(float))
cdef int current_index = 0
cdef int i = 0
print("Allocating buffer")
cdef float* buff = <float *>malloc(max_num_rx_samples * 2 * sizeof(float))
cdef void ** buffs = <void **> &buff
cdef size_t items_received
print("Entering while loop")
while current_index < 2*num_samples:
print("Calling uhd api")
uhd_rx_streamer_recv(rx_streamer_handle, buffs, max_num_rx_samples, &rx_metadata_handle, 3.0, False, &items_received)
print("performing memcpy")
memcpy(&result[current_index], &buff[0], 2 * items_received * sizeof(float))
#for i in range(current_index, current_index+2*items_received):
# result[i] = buff[i-current_index]
current_index += 2*items_received
print("Sending result...")
connection.send_bytes(<float[:2*num_samples]>result)and then call |
|
Will do, I’ll test later today.
… On Oct 10, 2017, at 04:52, Johannes Pohl ***@***.***> wrote:
Had a deeper look on this, but without the B200 at hand it seems impossible to locate the error. I suspect something in urh/dev/native/lib/usrp.pyx:94-114 causes the issue, because this is the only place where the USRP process can really segfault. Could you add some print statements to the function there, so it looks something like this:
cpdef uhd_error recv_stream(connection, int num_samples):
print("entering receive stream")
num_samples = (<int>(num_samples / max_num_rx_samples) + 1) * max_num_rx_samples
cdef float* result = <float*>malloc(num_samples * 2 * sizeof(float))
cdef int current_index = 0
cdef int i = 0
print("Allocating buffer")
cdef float* buff = <float *>malloc(max_num_rx_samples * 2 * sizeof(float))
cdef void ** buffs = <void **> &buff
cdef size_t items_received
print("Entering while loop")
while current_index < 2*num_samples:
print("Calling uhd api")
uhd_rx_streamer_recv(rx_streamer_handle, buffs, max_num_rx_samples, &rx_metadata_handle, 3.0, False, &items_received)
print("performing memcpy")
memcpy(&result[current_index], &buff[0], 2 * items_received * sizeof(float))
#for i in range(current_index, current_index+2*items_received):
# result[i] = buff[i-current_index]
current_index += 2*items_received
print("Sending result...")
connection.send_bytes(<float[:2*num_samples]>result)
and then call python src/urh/cythonext/build.py and run it again? This way we can at least see at which line it segfaults.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Closing here, as discussion has stalled. Drop a comment if you want me to reopen. |
|
Ref to new family of USRP B200 Issues. #608 |
Expected Behavior
Actual Behavior
Steps to Reproduce the Problem
Open URH (verbose used after crash discovered)
File -> Spectrum Analyzer
Click Start
Log window shows:
USRP-OPEN: Success
USRP: Single USRP:
Device: B-Series Device
Mboard 0: B200
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX1
USRP-SET_FREQUENCY to 433920000.0: Success
USRP-SET_SAMPLE_RATE to 20000000.0: Success
USRP-SET_BANDWIDTH to 20000000.0: Success
USRP-SET_RF_GAIN to 0.2: Success
USRP: Initializing stream...
USRP: Initialized stream
Somewhere during the USRP-SET actions the system launches a crash report for Python
Freqency graph stops updating (no recv)
URH Log does not show error
Platform Specifications
The text was updated successfully, but these errors were encountered: