Hi Neal,
I want to modify what I previously said about DRAMFIFO. In recent UHD
versions, the Replay block has taken on the functionality of what used to
be the DRAMFIFO (i.e., the Replay block can act as a FIFO using the onboard
RAM). There is apparently a tx_streamer stream arg "streamer =
replay_buffered" that will cause the multi_usrp object to include the
Replay block in the graph automatically and use it as a FIFO. I have not
tried this, but there is some documentation here
<https://uhd.readthedocs.io/en/latest/page_configuration.html#config_stream_args_args>
.
Rob
On Wed, Jan 8, 2025 at 3:12 PM Martin Braun <martin.br...@ettus.com> wrote:
> Hi Neal,
>
> for continuous streaming, don't use EOB. Just always include timestamps.
> I'm not sure right now on adjacent bursts, you're probably right, but
> they're the wrong tool here anyway.
>
> There is, however, no limit on burst sizes. That means if your application
> is running for days, and let's assume we don't drop anything, you would
> have one very long burst.
>
> The USRP will hold a packet until the transmit-time has been reached. If
> you always add timestamps to the send() call, then every packet will have
> timestamps (if you call send() with more data than fits into one packet,
> then the streamer code will calculate timestamps for all outgoing packets).
> Like I said in the other thread, on X310, you have approx. 500 kB of buffer
> which corresponds to 64 packets of 8000 bytes each.
>
> If you lose a packet between the host and the USRP, then you will
> eventually see an "S" and a "U". And of course, you will have a gap in your
> transmission. But on the next packet, as long as it reaches the radio on
> time, you will be aligned again.
>
> EOBs will only get in the way, because the USRP will ACK every packet. So
> basically, only send an EOB when your application is going into shutdown,
> and you want to cleanly exit the transmit thread.
>
> Side note: You don't need to specify `enable_fc` (it's on by default), and
> you don't need to specify `full_packet` either (that's only relevant for Rx
> raw UDP streaming).
>
> --M
>
> On Wed, Jan 8, 2025 at 7:34 PM <nrie...@serranosystems.com> wrote:
>
>> Hi Martin, Marcus & Rob,
>>
>> Thank you for your previous responses. Cy is working for me on this
>> development. Let me jump in and explain what we are trying to accomplish.
>>
>> We are using an x310 USRP to transmit samples from a custom C++
>> application over a 10Gb Ethernet interface. The target sample rate is 200
>> MSps, with 16-bit I/Q samples. We have receive functions running running
>> reliably over the 10Gb Ethernet interface at the 200 MSps rate.
>>
>> We would like to stream the transmit samples continuously, and we want
>> the sample timing to be synchronized to GPS time (our x310 is fitted with
>> the internal GPSDO).
>>
>> We understand that we may have occasional errors on the 10Gb Ethernet
>> link, and that we will need to recover from them. We are trying to
>> understand the best combination of burst size and packet size to accomplish
>> this.
>>
>> We initially tried making the burst size and the packet size the same. So
>> each packet has 1996 samples, and the metadata in each packet has
>> start_of_burst, end_of_burst, and has_timestamp all set true. The time_spec
>> in the metadata is updated by 1996 ticks for each packet, corresponding to
>> the number of samples in each packet. We have flow control enabled on the
>> transmit stream:
>>
>> uhd::stream_args_t tx_stream_args("sc16", "sc16");
>>
>> tx_stream_args.args["enable_fc"] = "1"; // Enable flow control
>>
>> tx_stream_args.args["stream_mode"] = "full_packet"; // Required for
>> handling flow control responses
>>
>> tx_stream = usrp->get_tx_stream(tx_stream_args);
>>
>> Similar to the tx_timed_samples example, we set the time_spec of the
>> first packet to be 1 second in the future, to be sure that we have enough
>> samples queued up in the USRP before it actually begins transmitting.
>>
>> This approach does not seem to work at all. We observe that after sending
>> 64 packets, the call to tx_send() takes almost one second to return. So we
>> believe the flow control is working, and there are 64 packets queue in the
>> USRP.
>>
>> Very soon after that, we get an async message with EVENT_CODE_BURST_ACK.
>> The time_spec in that message is one sample time after the end of the first
>> packet. Very soon after that, we receive a number of async messages with
>> EVENT_CODE_TIME_ERROR. The time_spec in each of these appears to be 2
>> samples after the end of the corresponding packet.
>>
>> 1. Is is possible to send adjacent bursts? That is, with time_spec values
>> that are exactly 1996 samples after the previous burst? Or is some gap
>> required between the bursts? Based on some experiments with the
>> tx_timed_samples example, I think there must be a gap of at least one
>> sample between the bursts.
>>
>> 2. Is there any limit to how long a burst can be? Currently, we are
>> thinking to send the samples in one continuous burst. Then, if an error is
>> detected, (e.g. EVENT_CODE_TIME_ERROR, EVENT_CODE_UNDERFLOW), we will end
>> the burst and start a new burst. Only the first packet in the burst will
>> include the time_spec parameter.
>>
>> Thanks for your help!
>>
>> Neal Riedel
>>
>> Serrano Systems, Inc.
>> _______________________________________________
>> 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
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
