Even with a single card I still get the same error.
*Creating the usrp device with:
addr0=192.168.60.2,second_addr0=192.168.50.2,recv_buff_size=900000000...Creating
the subdevice with: A:0 A:1 B:0 B:1...Using Device: Single USRP: Device:
X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard:
A RX Subdev: TwinRX RX0 RX Channel: 1 RX DSP: 1 RX Dboard: A
RX Subdev: TwinRX RX1 RX Channel: 2 RX DSP: 0 RX Dboard: B RX
Subdev: TwinRX RX0 RX Channel: 3 RX DSP: 1 RX Dboard: B RX
Subdev: TwinRX RX1 TX Channel: 0 TX DSP: 0 TX Dboard: A TX
Subdev: Unknown (0xffff) - 0 TX Channel: 1 TX DSP: 0 TX Dboard: B
TX Subdev: Unknown (0xffff) - 0Número de canales detectados: 4Número de
tarjetas detectadas: 1Actual RX Rate: 50.000000 Msps...Actual Acquisition
Time to: 0.000000 Seconds.Actual RX Freq: 800.000000 MHz...Actual RX Gain:
5.000000 dB...Actual RX Bandwidth: 50.000000 MHz...Setting LO
source...[INFO] [MULTI_USRP] 1) catch time transition at pps edge[INFO]
[MULTI_USRP] 2) set times next pps (synchronously)Press Ctrl + C to
stop streaming...STAR SAMPLING ...D[ERROR] [STREAMER] The receive packet
handler failed to time-align packets. 1002 received packets were processed
by the handler. However, a timestamp match could not be determined.D[ERROR]
[STREAMER] The receive packet handler failed to time-align packets. 1002
received packets were processed by the handler. However, a timestamp match
could not be determined.^CReceived 199995208 samples in 6.703929
seconds29.8325 MspsDone!*
El lun, 18 dic 2023 a las 17:13, Rob Kossler (<rkoss...@nd.edu>) escribió:
> Several comments:
>
> - It seems like multiple things are going on. You mentioned the
> original "failed to time align" error and below you mentioned 'O' and 'D'.
> - The time-align error I did not expect had anything to do with
> "performance". This seemed to me that the first packet arriving from
> device
> 1 had a different time stamp than the first packet arriving from device
> 2.
> Now, I'm not so sure
> - But, the 'O' and 'D' are often related to "performance".
> Overflow 'O' occurs when the 'Radio' block has A/D samples that it
> needs to
> put in a FIFO but the FIFO is full because it is not being emptied fast
> enough (presumably by the host PC). A dropped packet (or sequence
> error)
> 'D' occurs when the host PC detects that the incoming packets are not in
> sequential order. This can occur if the host PC Ethernet handling
> becomes
> overwhelmed and simply discards a set of incoming packets for a time
> period. Both 'O' and 'D' can imply that the host PC is not keeping up
> with
> incoming data
> - In any case, you may want to simplify the problem by dropping from
> two devices to one device. See if you can eliminate some or all of these
> problems when using only 4 channels.
> - If you drop to one device, you can use benchmark_rate to test
> performance. If you do not use "second_addr", you should be able to get
> 4x50 MS/s. If you use "second_addr", you should be able to get 4x100 MS/s.
> - Regarding your needed changes to "rx_samples_to_file", I guess I was
> thinking about the latest version which supports multiple channels. Perhaps
> UHD 3.12 has a version of this example that only supports a single
> channel. You could compare your version to the latest version (say, UHD
> 4.6) to see the improvements to this example.
>
>
> On Mon, Dec 18, 2023 at 7:44 AM Anabel Almodovar <
> anabel.almodo...@gmail.com> wrote:
>
>> Hi Rob,
>>
>> Thanks for the suggestions. I have tried deleting the LO sharing, and
>> nothing changes. Then removing the second addr, and that leads me to get
>> 'Ds' in addition to the error already mentioned, as it is not able to
>> handle that much information. Although I don't quite understand the
>> difference between 'O' and 'D'.
>>
>> From what I understand the program is set up for a single channel, so I
>> need to modify it to get more than one.
>>
>> Thank you in advance.
>>
>> Regards,
>> Anabel
>>
>> El vie, 15 dic 2023 a las 15:39, Rob Kossler (<rkoss...@nd.edu>)
>> escribió:
>>
>>> Hmmm. I'm not sure. Here are a few comments:
>>>
>>> - Try running without "second_addr". I realize that you will need
>>> it for full rate (4 x 100MS/s for each X310), but you could run at 50
>>> MS/s
>>> without second_addr
>>> - Try running without shared LO. I don't think you would need to
>>> physically change any sharing cables.
>>> - I am curious why you needed to modify the streamer, pointer buffer
>>> and file writing. I would expect that this would scale with the number
>>> of
>>> channels such that you didn't need to modify any code in this area
>>> - If you were using a more recent UHD, I would recommend switching
>>> to the example benchmark_rate which natively supports external PPS and
>>> multiple devices. I noticed that even the most recent rx_samples_to_file
>>> does not support external PPS (without modifying the code)
>>> - I know you mentioned you were unable to upgrade because of
>>> compatibility constraints. But, even if you cannot upgrade the OS, would
>>> you be able to install a new UHD - perhaps in a local folder that did not
>>> interfere with the system-wide UHD 3.12 installation. I typically have
>>> multiple UHD versions on my system and switch among them by "sourcing" a
>>> given setup file as needed.
>>>
>>>
>>> On Fri, Dec 15, 2023 at 12:52 AM Anabel Almodovar <
>>> anabel.almodo...@gmail.com> wrote:
>>>
>>>> Dear Rob,
>>>>
>>>> Yes, I use an external clock configuration.
>>>>
>>>> *std::this_thread::sleep_for( std::chrono::milliseconds(int64_t(1000 *
>>>> setup_time) );*
>>>>
>>>>
>>>>
>>>> *usrp->set_clock_source("external",
>>>> uhd::usrp::multi_usrp::ALL_MBOARDS); usrp->set_time_source("external",
>>>> uhd::usrp::multi_usrp::ALL_MBOARDS);usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));std::this_thread::sleep_for(std::chrono::seconds(1));*
>>>>
>>>> I have only modified the code to get 8 channels and LO sharing. I want
>>>> to get a continuous acquisition setup without losing samples. But I am
>>>> starting with something basic at the moment. Any suggestions are welcome.
>>>> So I've modified the streamer, the pointer buffer, and added writing files.
>>>>
>>>> my line is
>>>> *$sudo ./rx_samples_to_file_v1
>>>> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=900000000"
>>>> --subdev="A:0 A:1 B:0 B:1" --channel="0,1,2,3,4,5,6,7" --freq 800e6 --rate
>>>> 25e6 --bw 25e6 --gain 70 *
>>>>
>>>> Regards,
>>>>
>>>> *Anabel*
>>>>
>>>>
>>>>
>>>> El jue, 14 dic 2023 a las 18:25, Rob Kossler (<rkoss...@nd.edu>)
>>>> escribió:
>>>>
>>>>> Hi Anabel,
>>>>> In my opinion, the error you are experiencing has nothing to do with
>>>>> streaming performance settings (such as "performance" governor, network
>>>>> descriptors, MTU size, etc). The issue seems to be that the two X310
>>>>> devices do not have synchronized clocks. In addition to the physical
>>>>> synchronization using OctoClock, you must also configure each device to
>>>>> use
>>>>> external synchronization and you must tell each device to reset its FPGA
>>>>> clock count at a common PPS. The typical sequence is: (1) wait for a PPS
>>>>> to
>>>>> occur (by querying either device), (2) tell each device to reset its FPGA
>>>>> clock at the subsequent PPS (this step must complete before the next PPS
>>>>> arrives).
>>>>>
>>>>> You mentioned that you are using rx_samples_to_file. Did you modify it
>>>>> in any way? What is your exact command line with all parameters?
>>>>> Rob
>>>>>
>>>>> On Thu, Dec 14, 2023 at 10:29 AM Anabel Almodovar <
>>>>> anabel.almodo...@gmail.com> wrote:
>>>>>
>>>>>> Dear Rob
>>>>>>
>>>>>> Thank you for your answer.
>>>>>> I make use of the CDA-2990 octoclock as a source of synchronization
>>>>>> between both USRPs, in addition to local oscillator sharing. I use dual
>>>>>> 10GigEth connections and a MTU of 9000 to connect the USRPs to the PC.
>>>>>>
>>>>>> Due to various compatibility issues I am unable to upgrade the
>>>>>> system.
>>>>>>
>>>>>> When I work with a sample rate of 10MSps I don't get problems but
>>>>>> when I increase to 25MSps I start to get the error. I need them working
>>>>>> with 100MSps. I have tried changing the CPU governor to "performance" to
>>>>>> get the maximum working frequency (*sudo cpupower frequency-set
>>>>>> --governor performance*), as well as changing the number of network
>>>>>> interface descriptors to maximum (*sudo ethtool -G <interface> tx
>>>>>> <max> rx <max>*), or increasing the dirty memory buffer (*sudo
>>>>>> sysctl -w vm.dirty_ratio=80; sudo sysctl -w
>>>>>> vm.dirty_background_ratio=50*),
>>>>>> but I still get the same problem.
>>>>>>
>>>>>> Regards,
>>>>>> Anabel
>>>>>>
>>>>>> El jue, 14 dic 2023 a las 15:38, Rob Kossler (<rkoss...@nd.edu>)
>>>>>> escribió:
>>>>>>
>>>>>>> Hi Anabel,
>>>>>>> How are you sync-ing the clocks on the two units? Do you have an
>>>>>>> external PPS source and are you configuring both devices to use this
>>>>>>> external source?
>>>>>>>
>>>>>>> Finally, do you have the ability to upgrade your OS and your UHD
>>>>>>> versions? There aren't many user's that are using UHD 3.12 so if you
>>>>>>> have
>>>>>>> issues, it will be hard to get support.
>>>>>>> Rob
>>>>>>>
>>>>>>> On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar <
>>>>>>> anabel.almodo...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I am trying to make an acquisition with two X310 equipped with two
>>>>>>>> TwinRx. I am using Ubuntu 16.04 LTS 64-bit and UHD 3.12. My PC contains
>>>>>>>> 128GB RAM and an Intel® Xeon(R) Silver 4114 CPU @ 2.20GHz × 40 and a
>>>>>>>> 4TB
>>>>>>>> SSD. I have modified the example rx_samples_to_file.cpp code to get 8
>>>>>>>> channels and I get the following error:
>>>>>>>>
>>>>>>>> *D*
>>>>>>>> *[ERROR] [STREAMER] The receive packet handler failed to time-align
>>>>>>>> packets. 1002 received packets were processed by the handler. However,
>>>>>>>> a
>>>>>>>> timestamp match could not be determined.*
>>>>>>>> *Timeout while streaming*
>>>>>>>>
>>>>>>>> *[ERROR] [X300] 192.168.60.2 <http://192.168.60.2>: x300 fw
>>>>>>>> communication failure #1*
>>>>>>>> *EnvironmentError: IOError: x300 fw poke32 - reply timed out*
>>>>>>>> *[ERROR] [UHD] An unexpected exception was caught in a task
>>>>>>>> loop.The task loop will now exit, things may not work.AssertionError:
>>>>>>>> reply.sequence == request.sequence*
>>>>>>>> * in virtual void
>>>>>>>> x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, uint32_t)*
>>>>>>>> * at
>>>>>>>> /home/rs3_lab/workarea-uhd/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:135*
>>>>>>>>
>>>>>>>> I don't know how to solve the Timeout problem, I have tried to
>>>>>>>> start the acquisition 1.1 sg in time. But it didn't work.
>>>>>>>>
>>>>>>>>
>>>>>>>> * stream_cmd.stream_now = false; stream_cmd.time_spec
>>>>>>>> = usrp->get_time_last_pps(0)+1.1;*
>>>>>>>>
>>>>>>>> What is the problem and how can I fix it?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Anabel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>>>>>> To unsubscribe send an email to 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
