Hi Rob,
Yes, it is not possible to transmit 2 channels @ 200 MS/s with a single
X310 using cpu-to-host streaming, because the dma_fifo could not keep up
with this sampling rate on 2 channels.
In my application, it is transmitting a section of baseband data
repeatedly, and each channel has different data. Update the baseband data
to be transmitted in real time when necessary. For rfnoc, the biggest
problem is that I am not familiar with FPGA programming, and the existing
rfnoc module can not meet my needs.
Now I have found a temporary solution: for the frequency and gain settings,
the channel mapping is correct, and the channels are set to {0,2}; for
streaming, the channels are set to {0,1}. In this way, either the RFB side
of the two USRP x310 or the RFA side is selected, so I can run several more
times until the signal is transmitted on the correct channels.
Best regards,
Damon
On Wed, 26 Aug 2020 at 01:13, Rob Kossler <[email protected]> wrote:
> Hi Damon,
> Transmitting at 200 MS/s is very challenging. I'm assuming that you are
> using two X310s with only 1 channel active on each X310 because it is not
> possible to transmit 2 channels @ 200 MS/s with a single X310 using
> cpu-to-host streaming. Is this correct?
>
> Is it possible for your transmission to be implemented in the FPGA using
> either a fixed length arbitrary waveform (such as with the Replay block) or
> with a on-the-fly calculated waveform (such as with SigGen block or perhaps
> your own custom block)? Or does your transmission require continuously
> updated calculations on the CPU?
> Rob
>
> On Tue, Aug 25, 2020 at 12:36 PM Damon qiu <[email protected]>
> wrote:
>
>> Hi Rob,
>>
>> Thank you very much for your reply.I just read through your discussion
>> with Andreas about this issue. However, your temporary solution is not
>> suitable for my case. I need to transmit signals in two channels with
>> 200Msps sample rate for each channel. I can only wait for the Ettus
>> engineers to fix this bug. It's not sure whether Ettus engineers are
>> already investigating the bug, as there are no official replies to two
>> threads about this bug.
>>
>> Best regards,
>> Damon
>>
>> On Tue, 25 Aug 2020 at 03:35, Rob Kossler <[email protected]> wrote:
>>
>>> Hi Damon,
>>> See my other post today regarding "skip_dram=1". I believe there is a
>>> bug. But, if you can skip the Dma FIFO (if your sample rate is low
>>> enough), you can get around the bug.
>>> Rob
>>>
>>> On Mon, Aug 24, 2020 at 3:31 PM Damon qiu via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After repeated tests, we feel that two of the four channels of two
>>>> devices will be randomly selected, and the probability of choosing the
>>>> correct channel is very low. It must be a bug.
>>>>
>>>> Hi Macus,
>>>>
>>>> > try:
>>>> >
>>>> > stream_args.channels.push_back(0);
>>>> > stream_args.channels.push_back(1):
>>>> >
>>>> > Instead of your:
>>>> >
>>>> > stream_args.channels = {0,1};
>>>>
>>>> > I think these should be equivalent, but my C++ fluency is low...
>>>>
>>>> Thank you for your reply, but your suggestion didn't work. Please don't
>>>> forget to cc it to me next time.
>>>>
>>>> Best regards,
>>>> Damon
>>>>
>>>>
>>>>
>>>> On Fri, 7 Aug 2020 at 01:32, Damon qiu <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am using two USRP X310s to transmit signals on 2 channels. The two
>>>>> USRP are synchronized through a octoclock-g.
>>>>>
>>>>> A multi_usrp object is used to control those two USRP, device address
>>>>> is set to addr0=192.168.40.2,addr1=192.168.60.2. I want to set two USRP
>>>>> transmitting signal at RFA at the same time. I tried two ways to set up
>>>>> the
>>>>> tx channel and subdev spec:
>>>>>
>>>>> Method 1: The TX frontend specification is set to A:0 for both two
>>>>> mboard.
>>>>> d_dev->set_tx_subdev_spec("A:0");
>>>>> or
>>>>> d_dev->set_tx_subdev_spec("A:0", 0);
>>>>> d_dev->set_tx_subdev_spec("A:0", 1);
>>>>>
>>>>> uhd::stream_args_t stream_args(tx_cpu, tx_otw);
>>>>> stream_args.channels = {0, 1};
>>>>> uhd::tx_streamer::sptr tx_stream = d_dev->get_tx_stream(stream_args);
>>>>>
>>>>> Method 2: The TX frontend specification is set to "A:0 B:0"for both
>>>>> two mboard.
>>>>> d_dev->set_tx_subdev_spec("A:0 B:0");
>>>>> or
>>>>> d_dev->set_tx_subdev_spec("A:0 B:0", 0);
>>>>> d_dev->set_tx_subdev_spec("A:0 B:0", 1);
>>>>>
>>>>> uhd::stream_args_t stream_args(tx_cpu, tx_otw);
>>>>> stream_args.channels = {0, 2};
>>>>> uhd::tx_streamer::sptr tx_stream = d_dev->get_tx_stream(stream_args);
>>>>>
>>>>> In the above two methods, there is a certain probability (about 10% to
>>>>> 30%) that the two transmission channels are on the same motherboard. I
>>>>> guess this is a bug of UHD.
>>>>>
>>>>> OS: Ubuntu 18.04
>>>>> UHD: UHD-3.15.LTS
>>>>>
>>>>> Please CC me as I can only receive the daily digest of the mailing
>>>>> list.
>>>>>
>>>>> Best regards,
>>>>> Damon
>>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
