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
