[USRP-users] Too Many Samples in a Single Burst
Hello, In trying to test the ‘rx_multi_samples’ example with all four channels on an n310. I run into an error of “Requesting too many samples in a single burst” when I attempt a longer record (really anything over a few seconds). Seems to be my nsamps value, but I am unsure how to remedy the issue. Below is my argument and the terminal output for an attempt to receive for 10 seconds: ./rx_multi_samples --args "type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo" --rate 6.25e6 --subdev "A:0 A:1 B:0 B:1" --channels "0,1,2,3" --nsamps 62500 Creating the usrp device with: type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo [INFO] [MPM.PeriphManager] init() called with device args `clock_source=gpsdo,time_source=gpsdo,product=n310,mgmt_addr=192.168.10.2'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 62500 samples, 1.50 seconds in the future... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decimation factor. Your application may have requested fewer samples. Error: ValueError: Requested too many samples in a single burst. Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Too Many Samples in a Single Burst
Hi Marcus, No, I have not attempted on UHD 4+. Due to some other software constraints I am only able to use 3.15 at the moment. Thanks, Jonathan From: Marcus D. Leech Sent: Friday, August 6, 2021 3:56 PM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: Too Many Samples in a Single Burst On 08/06/2021 07:26 PM, Jonathan Tobin wrote: Hello, In trying to test the ‘rx_multi_samples’ example with all four channels on an n310. I run into an error of “Requesting too many samples in a single burst” when I attempt a longer record (really anything over a few seconds). Seems to be my nsamps value, but I am unsure how to remedy the issue. Below is my argument and the terminal output for an attempt to receive for 10 seconds: ./rx_multi_samples --args "type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo" --rate 6.25e6 --subdev "A:0 A:1 B:0 B:1" --channels "0,1,2,3" --nsamps 62500 Creating the usrp device with: type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo [INFO] [MPM.PeriphManager] init() called with device args `clock_source=gpsdo,time_source=gpsdo,product=n310,mgmt_addr=192.168.10.2'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 62500 samples, 1.50 seconds in the future... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decimation factor. Your application may have requested fewer samples. Error: ValueError: Requested too many samples in a single burst. Thanks, Jonathan That looks like a bug--have you tried this on UHD 4.recent? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Too Many Samples in a Single Burst
Reducing nsamps to below 268435455/2 works - but at 6.25Msps for all four channels (two daughterboards) this is very short amount of time. I can try changing channels but for my application I do need all four channels receiving - though this will have to be on Monday. Yes, rx_multi_samples "out of the box" (no modifications to the example). Thanks, Jonathan From: Marcus D. Leech Sent: Saturday, August 7, 2021 5:30 AM To: Jonathan Tobin ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On 08/06/2021 10:47 PM, Jonathan Tobin wrote: Hi Marcus, No, I have not attempted on UHD 4+. Due to some other software constraints I am only able to use 3.15 at the moment. Thanks, Jonathan Does reducing nsamps help? What about channel count? Just looking for clues as to what might be going on. Looking at the code, nothing really leaps out at me. You're using rx_multi_samples "out of the box" or with modifications? From: Marcus D. Leech <mailto:patchvonbr...@gmail.com> Sent: Friday, August 6, 2021 3:56 PM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: Too Many Samples in a Single Burst On 08/06/2021 07:26 PM, Jonathan Tobin wrote: Hello, In trying to test the ‘rx_multi_samples’ example with all four channels on an n310. I run into an error of “Requesting too many samples in a single burst” when I attempt a longer record (really anything over a few seconds). Seems to be my nsamps value, but I am unsure how to remedy the issue. Below is my argument and the terminal output for an attempt to receive for 10 seconds: ./rx_multi_samples --args "type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo" --rate 6.25e6 --subdev "A:0 A:1 B:0 B:1" --channels "0,1,2,3" --nsamps 62500 Creating the usrp device with: type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo [INFO] [MPM.PeriphManager] init() called with device args `clock_source=gpsdo,time_source=gpsdo,product=n310,mgmt_addr=192.168.10.2'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 62500 samples, 1.50 seconds in the future... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decimation factor. Your application may have requested fewer samples. Error: ValueError: Requested too many samples in a single burst. Thanks, Jonathan That looks like a bug--have you tried this on UHD 4.recent? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Too Many Samples in a Single Burst
I was just using it more as an example. The same error occurs when using txrx_loopback_to_file - but I can provide that output and more info on that come Monday. Thanks, Jonathan From: Marcus D. Leech Sent: Saturday, August 7, 2021 7:16 AM To: Jonathan Tobin ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On 08/07/2021 12:23 PM, Jonathan Tobin wrote: Reducing nsamps to below 268435455/2 works - but at 6.25Msps for all four channels (two daughterboards) this is very short amount of time. I can try changing channels but for my application I do need all four channels receiving - though this will have to be on Monday. Yes, rx_multi_samples "out of the box" (no modifications to the example). Thanks, Jonathan Given that rx_multi_samples doesn't actually *DO* anything with the samples, I'm curious about how it's actually useful for you in any production sense--it is just a demo app to show some of the API usage. It may be the case that this example needs to be updated because it's mis-using the API in some what that isn't immediately obvious to me. But again, it doesn't actually *DO* anything with the samples, so I don't know how it's useful other than as a learning tool... From: Marcus D. Leech <mailto:patchvonbr...@gmail.com> Sent: Saturday, August 7, 2021 5:30 AM To: Jonathan Tobin <mailto:to...@augustusaero.com>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On 08/06/2021 10:47 PM, Jonathan Tobin wrote: Hi Marcus, No, I have not attempted on UHD 4+. Due to some other software constraints I am only able to use 3.15 at the moment. Thanks, Jonathan Does reducing nsamps help? What about channel count? Just looking for clues as to what might be going on. Looking at the code, nothing really leaps out at me. You're using rx_multi_samples "out of the box" or with modifications? From: Marcus D. Leech <mailto:patchvonbr...@gmail.com> Sent: Friday, August 6, 2021 3:56 PM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: Too Many Samples in a Single Burst On 08/06/2021 07:26 PM, Jonathan Tobin wrote: Hello, In trying to test the ‘rx_multi_samples’ example with all four channels on an n310. I run into an error of “Requesting too many samples in a single burst” when I attempt a longer record (really anything over a few seconds). Seems to be my nsamps value, but I am unsure how to remedy the issue. Below is my argument and the terminal output for an attempt to receive for 10 seconds: ./rx_multi_samples --args "type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo" --rate 6.25e6 --subdev "A:0 A:1 B:0 B:1" --channels "0,1,2,3" --nsamps 62500 Creating the usrp device with: type=n3xx,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2,time_source=gpsdo,clock_source=gpsdo [INFO] [MPM.PeriphManager] init() called with device args `clock_source=gpsdo,time_source=gpsdo,product=n310,mgmt_addr=192.168.10.2'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Using Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX S
[USRP-users] Re: Too Many Samples in a Single Burst
Hi Marcus, Here is the output from a simple run of txrx_loopback_to_file "out of the box." As can be seen, the same error occurs (along with dropped packets this time). ./txrx_loopback_to_file --tx-args "addr=192.168.10.2" --rx-args "type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal" --rx-freq 2500e6 --rx-rate 6.25e6 --rx-subdev "A:0 A:1 B:0 B:1" --rx-channels "0,1,2,3" --rx-gain 60 --nsamps 6250 --tx-rate 6.25e6 --tx-freq 2500e6 Creating the transmit usrp device with: addr=192.168.10.2... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2 [INFO] [MPM.PeriphManager] init() called with device args `product=n310,mgmt_addr=192.168.10.2,time_source=internal,clock_source=internal'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Creating the receive usrp device with: type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal... Using TX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Using RX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting TX Rate: 6.25 Msps... Actual TX Rate: 6.25 Msps... Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting TX Freq: 2500.00 MHz... Actual TX Freq: 2500.00 MHz... Configuring RX Channel 0 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 1 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 2 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 3 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Checking TX: all_los: locked ... Checking RX: all_los: locked ... Setting device timestamp to 0... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125000, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decimation factor. Your application may have requested fewer samples. LLLError: ValueError: Requested too many samples in a single burst. Thanks, Jonathan From: Marcus D. Leech Sent: Saturday, August 7, 2021 7:16 AM To: Jonathan Tobin ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On 08/07/2021 12:23 PM, Jonathan Tobin wrote: Reducing nsamps to below 268435455/2 works - but at 6.25Msps for all four channels (two daughterboards) this is very short amount of time. I can try chan
[USRP-users] Re: Too Many Samples in a Single Burst
Meant late packets. From: Jonathan Tobin Sent: Monday, August 9, 2021 5:41 AM To: Marcus D. Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst Hi Marcus, Here is the output from a simple run of txrx_loopback_to_file "out of the box." As can be seen, the same error occurs (along with dropped packets this time). ./txrx_loopback_to_file --tx-args "addr=192.168.10.2" --rx-args "type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal" --rx-freq 2500e6 --rx-rate 6.25e6 --rx-subdev "A:0 A:1 B:0 B:1" --rx-channels "0,1,2,3" --rx-gain 60 --nsamps 6250 --tx-rate 6.25e6 --tx-freq 2500e6 Creating the transmit usrp device with: addr=192.168.10.2... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2 [INFO] [MPM.PeriphManager] init() called with device args `product=n310,mgmt_addr=192.168.10.2,time_source=internal,clock_source=internal'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Creating the receive usrp device with: type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal... Using TX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Using RX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting TX Rate: 6.25 Msps... Actual TX Rate: 6.25 Msps... Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting TX Freq: 2500.00 MHz... Actual TX Freq: 2500.00 MHz... Configuring RX Channel 0 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 1 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 2 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 3 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Checking TX: all_los: locked ... Checking RX: all_los: locked ... Setting device timestamp to 0... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125000, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decimation factor. Your application may have requested fewer samples. LLLError: ValueError: Requested too many samples in a single burst. Thanks, Jonathan From: Marcus D. Leech Sent: Saturday, August 7, 2021 7:16 AM To: Jonathan Tobin ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samp
[USRP-users] Re: Too Many Samples in a Single Burst
Just as an additional update - I was able to test with UHD 4.1 and there is no issue - seems to be something with UHD 3.15 then. Thanks, Jonathan From: Jonathan Tobin Sent: Monday, August 9, 2021 5:42 AM To: Marcus D. Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst Meant late packets. From: Jonathan Tobin Sent: Monday, August 9, 2021 5:41 AM To: Marcus D. Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst Hi Marcus, Here is the output from a simple run of txrx_loopback_to_file "out of the box." As can be seen, the same error occurs (along with dropped packets this time). ./txrx_loopback_to_file --tx-args "addr=192.168.10.2" --rx-args "type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal" --rx-freq 2500e6 --rx-rate 6.25e6 --rx-subdev "A:0 A:1 B:0 B:1" --rx-channels "0,1,2,3" --rx-gain 60 --nsamps 6250 --tx-rate 6.25e6 --tx-freq 2500e6 Creating the transmit usrp device with: addr=192.168.10.2... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,claimed=False,addr=192.168.10.2 [INFO] [MPM.PeriphManager] init() called with device args `product=n310,mgmt_addr=192.168.10.2,time_source=internal,clock_source=internal'. [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0) Creating the receive usrp device with: type=n3xx,addr=192.168.10.2,time_source=internal,clock_source=internal... Using TX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Using RX Device: Single USRP: Device: N300-Series Device Mboard 0: ni-n3xx-3218B5F RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: Magnesium RX Channel: 1 RX DSP: 1 RX Dboard: A RX Subdev: Magnesium RX Channel: 2 RX DSP: 0 RX Dboard: B RX Subdev: Magnesium RX Channel: 3 RX DSP: 1 RX Dboard: B RX Subdev: Magnesium TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: Magnesium TX Channel: 1 TX DSP: 1 TX Dboard: A TX Subdev: Magnesium TX Channel: 2 TX DSP: 0 TX Dboard: B TX Subdev: Magnesium TX Channel: 3 TX DSP: 1 TX Dboard: B TX Subdev: Magnesium Setting TX Rate: 6.25 Msps... Actual TX Rate: 6.25 Msps... Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting TX Freq: 2500.00 MHz... Actual TX Freq: 2500.00 MHz... Configuring RX Channel 0 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 1 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 2 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Configuring RX Channel 3 Setting RX Freq: 2500.00 MHz... Actual RX Freq: 2500.00 MHz... Setting RX Gain: 60.00 dB... Actual RX Gain: 60.00 dB... Checking TX: all_los: locked ... Checking RX: all_los: locked ... Setting device timestamp to 0... [ERROR] [RFNOC RADIO] Requesting too many samples in a single burst! Requested 125000, maximum is 268435455. [INFO] [RFNOC RADIO] Note that a decimation block will increase the number of samples per burst by the decima
[USRP-users] Re: Too Many Samples in a Single Burst
Hi Brian, No - only intention would be to receive for 10 seconds and save data. What would you suggest? Thanks, Jonathan From: Brian Padalino Sent: Monday, August 9, 2021 6:01 PM To: Jonathan Tobin Cc: Marcus D. Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On Mon, Aug 9, 2021 at 2:12 PM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Just as an additional update - I was able to test with UHD 4.1 and there is no issue - seems to be something with UHD 3.15 then. Just chiming in here to ensure you understand that your test of receiving 625M samples using that particular program will keep all those samples in memory for all the channels while you receive. In other words, 10GB of RAM (625M samples * 4 bytes/sample/channel * 4 channels) will be used just to hold your received signal. Is this what you really intend to do? The error you received before was a 32-bit/4GB limit I am pretty sure (268435455*4*4 = 4294967280 ~= 2^32). Brian ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Too Many Samples in a Single Burst
To follow up, This seems to be the limit now that I have updated to UHD 4.1.0.1: [ERROR] [0/Radio#0] Requesting too many samples in a single burst! Requested 18446744028430598144, maximum is 281474976710655. This occurs with the key arguments: --rx-rate 4.8e6 --rx-subdev "A:0 A:1 B:0 B:1" --rx-channels "0,1,2,3" --nsamps 288000 The nsamps value is for 10 minutes of recording (sample rate * 60 seconds * 10 minutes). Thanks, Jonathan From: Marcus D. Leech Sent: Tuesday, August 10, 2021 4:58 AM To: Brian Padalino ; Jonathan Tobin Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Too Many Samples in a Single Burst On 08/10/2021 10:34 AM, Brian Padalino wrote: On Tue, Aug 10, 2021 at 9:39 AM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Hi Brian, No - only intention would be to receive for 10 seconds and save data. What would you suggest? Modify the program to write out to a file on a high performance drive and receive smaller parts at a time from UHD. Brian I suspect what's going on is that the various streaming modes are implemented by the HARDWARE, and the control-word for "NUM_SAMPS_AND_DONE" prior to UHD 4.x was only 32 bits--looks like it's now 48 bits. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] N310 Phase Coherence
Hi all, For those that have used the N310 for phase coherent applications, what was your approximate phase difference between channels? Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] UHD 3.15 on Windows
Hello - I am attempting to install UHD 3.15 on my Windows 10 PC. I am able to ping and find the device, but currently unable to probe. Not sure what the issue is - any recommendations? Command Prompt output: C:\Program Files\UHD3\bin>uhd_find_devices [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de -- -- UHD Device 0 -- Device Address: serial: 3218B5F claimed: False mgmt_addr: 192.168.10.2 product: n310 reachable: No type: n3xx C:\Program Files\UHD3\bin>uhd_usrp_probe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD session. Specify find_all to find all devices. Error: LookupError: KeyError: No devices found for -> Empty Device Address Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: UHD 3.15 on Windows
I am only connected to the USRP via ethernet to SFP+0 port. I have no problems with a Linux Host running 3.15. From: Rob Kossler Sent: Thursday, October 7, 2021 11:56 AM To: Jonathan Tobin Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] UHD 3.15 on Windows Also, does the N310 have the 3.15 file system / MPM installed? On Thu, Oct 7, 2021 at 1:54 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote: Perhaps you are just finding the address of the N310 RJ45 Ethernet port, but not the address of the SFP+ ports? These are needed for UHD (at least one of them). Are you only connected via 1GB? Do you have a direct link between host PC and one of the SFP+ ports? Rob On Thu, Oct 7, 2021 at 1:37 PM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Hello – I am attempting to install UHD 3.15 on my Windows 10 PC. I am able to ping and find the device, but currently unable to probe. Not sure what the issue is – any recommendations? Command Prompt output: C:\Program Files\UHD3\bin>uhd_find_devices [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de -- -- UHD Device 0 -- Device Address: serial: 3218B5F claimed: False mgmt_addr: 192.168.10.2 product: n310 reachable: No type: n3xx C:\Program Files\UHD3\bin>uhd_usrp_probe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD session. Specify find_all to find all devices. Error: LookupError: KeyError: No devices found for -> Empty Device Address Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: UHD 3.15 on Windows
It does indeed fail. I updated the image on the N310, but the issue remains the same. Thanks, Jonathan From: Marcus D. Leech Sent: Thursday, October 7, 2021 1:27 PM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: UHD 3.15 on Windows On 2021-10-07 2:31 p.m., Jonathan Tobin wrote: I am only connected to the USRP via ethernet to SFP+0 port. I have no problems with a Linux Host running 3.15. Yup, so try: uhd_usrp_probe --args addr=192.168.10.2,type=n3xx,product=n310 If that *still* fails, then you probably have a much-older image on the N310, and should follow the directions for updating it: https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card From: Rob Kossler <mailto:rkoss...@nd.edu> Sent: Thursday, October 7, 2021 11:56 AM To: Jonathan Tobin <mailto:to...@augustusaero.com> Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] UHD 3.15 on Windows Also, does the N310 have the 3.15 file system / MPM installed? On Thu, Oct 7, 2021 at 1:54 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote: Perhaps you are just finding the address of the N310 RJ45 Ethernet port, but not the address of the SFP+ ports? These are needed for UHD (at least one of them). Are you only connected via 1GB? Do you have a direct link between host PC and one of the SFP+ ports? Rob On Thu, Oct 7, 2021 at 1:37 PM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Hello – I am attempting to install UHD 3.15 on my Windows 10 PC. I am able to ping and find the device, but currently unable to probe. Not sure what the issue is – any recommendations? Command Prompt output: C:\Program Files\UHD3\bin>uhd_find_devices [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de -- -- UHD Device 0 -- Device Address: serial: 3218B5F claimed: False mgmt_addr: 192.168.10.2 product: n310 reachable: No type: n3xx C:\Program Files\UHD3\bin>uhd_usrp_probe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD session. Specify find_all to find all devices. Error: LookupError: KeyError: No devices found for -> Empty Device Address Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: UHD 3.15 on Windows
: 1 | | | | Name: Magnesium | | | | Antennas: TX/RX | | | | Sensors: lo_locked, lowband_lo_locked, ad9371_lo_locked | | | | Freq range: 1.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 65.0 step 0.5 dB | | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB | | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB | | | | Gain range amp: 0.0 to 0.0 step 0.0 dB | | | | Bandwidth range: 2000.0 to 1.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: B | | | | Name: AD9371 Dual DAC | | | | Gain Elements: None | | _ | |/ | | | RFNoC blocks on this device: | | | | | | * Replay_0 | | | * Radio_0 | | | * Radio_1 | | | * DDC_0 | | | * DDC_1 | | | * DUC_0 | | | * DUC_1 | | | * FIFO_0 | | | * FIFO_1 | | | * FIFO_2 | | | * FIFO_3 From: Marcus D. Leech Sent: Friday, October 8, 2021 11:07 AM To: Jonathan Tobin ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: UHD 3.15 on Windows On 2021-10-08 1:02 p.m., Jonathan Tobin wrote: It does indeed fail. I updated the image on the N310, but the issue remains the same. Thanks, Jonathan Could you share with us the output of the (newly) failing uhd_usrp_probe? And you confirm that the SAME device works from Linux under the same physical configuration? From: Marcus D. Leech <mailto:patchvonbr...@gmail.com> Sent: Thursday, October 7, 2021 1:27 PM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: UHD 3.15 on Windows On 2021-10-07 2:31 p.m., Jonathan Tobin wrote: I am only connected to the USRP via ethernet to SFP+0 port. I have no problems with a Linux Host running 3.15. Yup, so try: uhd_usrp_probe --args addr=192.168.10.2,type=n3xx,product=n310 If that *still* fails, then you probably have a much-older image on the N310, and should follow the directions for updating it: https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card From: Rob Kossler <mailto:rkoss...@nd.edu> Sent: Thursday, October 7, 2021 11:56 AM To: Jonathan Tobin <mailto:to...@augustusaero.com> Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] UHD 3.15 on Windows Also, does the N310 have the 3.15 file system / MPM installed? On Thu, Oct 7, 2021 at 1:54 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote: Perhaps you are just finding the address of the N310 RJ45 Ethernet port, but not the address of the SFP+ ports? These are needed for UHD (at least one of them). Are you only connected via 1GB? Do you have a direct link between host PC and one of the SFP+ ports? Rob On Thu, Oct 7, 2021 at 1:37 PM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Hello – I am attempting to install UHD 3.15 on my Windows 10 PC. I am able to ping and find the device, but currently unable to probe. Not sure what the issue is – any recommendations? Command Prompt output: C:\Program Files\UHD3\bin>uhd_find_devices [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de -- -- UHD Device 0 -- Device Address: serial: 3218B5F claimed: False mgmt_addr: 192.168.10.2 product: n310 reachable: No type: n3xx C:\Program Files\UHD3\bin>uhd_usrp_probe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.2; Boost_107200; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD session. Specify find_all to find all devices. Error: LookupError: KeyError: No devices found for -> Empty Device Address Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] TX from N310 External LO Error
Hello all - I am trying to transmit a test waveform from an N310 using the sample program tx_waveforms. When I set "tx_lo_source=external" I get the error below. When I set it to internal, the program runs smoothly, but there is no output. I am supplying an external LO at twice the desired output frequency. I am using uhd 4.3.0.0. ./tx_waveforms --args "addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external" --freq 1e9 --gain 10 --bw 1e6 --rate 9.6e6 --subdev "A:1" --channels "0" --wave-freq 100e3 Creating the usrp device with: addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_4.3.0.HEAD-0-g1f8fd345 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,name=ni-n3xx-3218B5F,fpga=HG,claimed=False,addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external [INFO] [MPM.PeriphManager] init() called with device args `fpga=HG,master_clock_rate=153.6e6,mgmt_addr=192.168.10.2,name=ni-n3xx-3218B5F,product=n310,tx_lo_source=external,clock_source=internal,time_source=internal'. [ERROR] [RPC] RuntimeError: MYKONOS_waitInitCals() returned an ARM error [ERROR] [MPM.RPCServer] init() failed with error: RuntimeError: MYKONOS_waitInitCals() returned an ARM error Error: RuntimeError: Error during RPC call to `init'. Error message: RuntimeError: MYKONOS_waitInitCals() returned an ARM error Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: TX from N310 External LO Error
Thanks for the responses everyone. Adding the "init_cals=BASIC" argument got rid of the error (I suppose a band-aid until I can grab a higher frequency sig gen). I was only supplying a 2 GHz signal, but it was at +3 dBm. I'll have to experiment the power. Thanks for the help. Thanks, Jonathan From: Kenneth Burchfield Sent: Wednesday, November 30, 2022 4:20 PM To: Rob Kossler Cc: Jonathan Tobin ; usrp-users Subject: Re: [USRP-users] Re: TX from N310 External LO Error Hi Jonathan, What Rob said is correct. You need to supply a 5 GHz LO initially so that the startup calibrations for the N310 will be correct. However, if I recall correctly, the device should still initialize even with an LO not equal to 5 GHz (though your going to see imaging / possible LO leakage in the frequency domain if this is the case). Is your LO power within spec of the device? The ad9371 requires an external LO between +0 dBm and +6 dBm with higher frequencies requiring higher power. Providing an LO below that power spec will give you the MYKONOS_waitInitCals() error. If you are within that spec, then you can modify your init_cals and incrementally test adding calibrations until you figure out which calibration is throwing the error. So your args would look like this initially ( --args "addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external,init_cals=BASIC") and then you can add more init_cals by doing init_cals=BASIC|TX_ATTENUATION_DELAY|PATH_DELAY etc. The | is the append operation. The calibrations are listed in the link below. https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_mg_calibrations Hope this helps Scott On Wed, Nov 30, 2022 at 4:48 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote: Hi Jonathan, At startup, the init_cal will always be conducted at 2.5GHz requiring an external LO at 5 GHz. After the init cal, then you can re-tune your external LO to twice the desired operating frequency. It wasn't clear to me from your comment if your external LO is initially configured to 5 GHz or to 2 GHz. If the latter, try with 5 GHz and if startup occurs correctly, retune it to 2 GHz after that point. Rob On Wed, Nov 30, 2022 at 1:43 PM Jonathan Tobin mailto:to...@augustusaero.com>> wrote: Hello all - I am trying to transmit a test waveform from an N310 using the sample program tx_waveforms. When I set "tx_lo_source=external" I get the error below. When I set it to internal, the program runs smoothly, but there is no output. I am supplying an external LO at twice the desired output frequency. I am using uhd 4.3.0.0. ./tx_waveforms --args "addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external" --freq 1e9 --gain 10 --bw 1e6 --rate 9.6e6 --subdev "A:1" --channels "0" --wave-freq 100e3 Creating the usrp device with: addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external... [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_4.3.0.HEAD-0-g1f8fd345 [INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3218B5F,name=ni-n3xx-3218B5F,fpga=HG,claimed=False,addr=192.168.10.2,master_clock_rate=153.6e6,tx_lo_source=external [INFO] [MPM.PeriphManager] init() called with device args `fpga=HG,master_clock_rate=153.6e6,mgmt_addr=192.168.10.2,name=ni-n3xx-3218B5F,product=n310,tx_lo_source=external,clock_source=internal,time_source=internal'. [ERROR] [RPC] RuntimeError: MYKONOS_waitInitCals() returned an ARM error [ERROR] [MPM.RPCServer] init() failed with error: RuntimeError: MYKONOS_waitInitCals() returned an ARM error Error: RuntimeError: Error during RPC call to `init'. Error message: RuntimeError: MYKONOS_waitInitCals() returned an ARM error Thanks, Jonathan ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
