You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been playing around with the X4_1600 image of the USRP X440 using UHD v4.6.0.0. I figured out there is a strange overflow behaviour when using the Replay Block of this image when using 2GHz Master clock rate.
Using the UHD example replay_capture.py works. However, for a more complex setup the overflow occurs. In particular, the overflow happens when recording data from the radio into the replay block, when the replay block's input channel was connected to a TxStreamer beforehand. The overflow happens only at high master clock rates and only if some minimal amount of data is to be recorded.
Setup Details
Using USRP X440, UHD v4.6.0.0, no specific cable connections. Compiling and running the programs directly on the USRP X440 embedded system (same issue occurs when running the program from a different host).
See the test program code at the end of this issue. Compile the program directly on the USRP with
the IP of the USRP (use localhost when running directly on the device)
the master clock rate in Hz
wether or not to connect and disconnect a TxStreamer before recording from the radio (use 1 to connect, anything else to not connect)
the number of samples to record (divided by 1024)
Expected Behavior
I expect the program to run with no errors regardless the Master clock rate and if I connect a TX streamer or not (given that the amount of samples is reasonable).
Actual Behaviour
Running the program with 2GHz master clock rate, connecting+disconnecting a TX Streamer and 20*1024 samples to record, an overflow is indicated. The overflow is shown by a single "O" on the console and the message "ERROR_CODE_OVERFLOW". The overflow results in the replay block not recording the requested amount of data.
root@NE-LAB-X440-01:~# ./replay_x440 localhost 2e9 1 20
hi4.6.0.0-0-g50fa3baa
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.6.0.0-0-g50fa3baa
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=x4xx,product=x440,serial=32896F6,name=NE-LAB-X440-01,fpga=X4_1600,claimed=False,addr=localhost,master_clock_rate=2e9
[INFO] [MPM.PeriphManager] init() called with device args `fpga=X4_1600,master_clock_rate=(2000000000.0, 2000000000.0),mgmt_addr=127.0.0.1,name=NE-LAB-X440-01,product=x440,clock_source=internal,time_source=internal,initializing=True'.
Connect upload
disconnect
Connect for record
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
recording 20480
OERROR: Error at recording: ERROR_CODE_OVERFLOW (Overflow)
root@NE-LAB-X440-01:~#
The program runs fine for different combinations of parameters. It works when either the master clock rate is smaller, fewer samples are recorded or no different rfnoc connections are done to the block.
./replay_x440 localhost 2e9 1 16 # runs fine --> fewer samples to record (65k bytes)
./replay_x440 localhost 2e9 0 20 # runs fine --> no Tx streamer connected
./replay_x440 localhost 2e9 0 200000 # runs fine --> no Tx streamer connected, tons of samples
./replay_x440 localhost 1e9 1 20 # runs fine --> lower master clock rate
I just checked with the new v4.7.0.0-rc1 with usrp_update_fs -t v4.7.0.0-rc1. The behaviour remains the same, though now one needs a few more bytes before the overflow occurs
root@NE-LAB-X440-01:~# ./replay_x440 localhost 2e9 1 21
hi4.7.0.0-214-g327f294e
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107800; UHD_4.7.0.0-214-g327f294e
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=x4xx,product=x440,serial=32896F6,name=NE-LAB-X440-01,fpga=X4_1600,claimed=False,addr=localhost,master_clock_rate=2e9
[INFO] [MPM.PeriphManager] init() called with device args `fpga=X4_1600,master_clock_rate=(2000000000.0, 2000000000.0),mgmt_addr=127.0.0.1,name=NE-LAB-X440-01,product=x440,clock_source=internal,time_source=internal,initializing=True'.
Connect upload
disconnect
Connect for record
recording 21504
OERROR: Error at recording: ERROR_CODE_OVERFLOW (Overflow)
root@NE-LAB-X440-01:~#
Issue Description
I have been playing around with the X4_1600 image of the USRP X440 using UHD v4.6.0.0. I figured out there is a strange overflow behaviour when using the Replay Block of this image when using 2GHz Master clock rate.
Using the UHD example
replay_capture.py
works. However, for a more complex setup the overflow occurs. In particular, the overflow happens when recording data from the radio into the replay block, when the replay block's input channel was connected to a TxStreamer beforehand. The overflow happens only at high master clock rates and only if some minimal amount of data is to be recorded.Setup Details
Using USRP X440, UHD v4.6.0.0, no specific cable connections. Compiling and running the programs directly on the USRP X440 embedded system (same issue occurs when running the program from a different host).
See the test program code at the end of this issue. Compile the program directly on the USRP with
The program has 4 parameters:
localhost
when running directly on the device)Expected Behavior
I expect the program to run with no errors regardless the Master clock rate and if I connect a TX streamer or not (given that the amount of samples is reasonable).
Actual Behaviour
Running the program with 2GHz master clock rate, connecting+disconnecting a TX Streamer and 20*1024 samples to record, an overflow is indicated. The overflow is shown by a single "O" on the console and the message "ERROR_CODE_OVERFLOW". The overflow results in the replay block not recording the requested amount of data.
The program runs fine for different combinations of parameters. It works when either the master clock rate is smaller, fewer samples are recorded or no different rfnoc connections are done to the block.
Steps to reproduce the problem
compile and run the program as described above.
Additional Information
Here's the test program code:
The text was updated successfully, but these errors were encountered: