Hi all, I am working with the UHD Python API to handle burst-mode data transmission and reception. Both the transmitter and receiver are set to be active at specific times, for a fixed number of samples per burst. This process occurs approximately 100 times per second.
Currently, the transmit and receive processes are handled in separate threads, where they wait for a timestamp to start their respective operations. When both are finished, a new loop begins. The waiting however can create some late commands. I would like to process the buffer separately. For each RX burst, the following function is called: *rx_buffer_size = int(5000) # each recv is 500 samples, but we want more space for multiple bursts* *rx_buffer = np.zeros(rx_buffer_size, dtype=np.complex64)* *def rx(start_time, rx_streamer, rx_buffer, rx_metadata):* * global rx_time* * rx_stream_cmd = uhd.types.StreamCMD(uhd.types.StreamMode.num_done)* * rx_stream_cmd.num_samps = 500* * rx_stream_cmd.stream_now = False* * rx_stream_cmd.time_spec = start_time* * rx_streamer.issue_stream_cmd(rx_stream_cmd)* * num_rx_samps = rx_streamer.recv(rx_buffer, rx_metadata, timeout=1.0)* * rx_time = rx_metadata.time_spec.get_real_secs()* Each receive burst consists of exactly 500 samples. However, this approach feels inefficient as I am processing each burst individually. My goal is to: 1. *Optimize Efficiency*: Fill a larger buffer with multiple bursts (e.g., 10 bursts = 5000 samples) before processing. 2. *Preserve Timestamps*: Retain the metadata timestamp for each burst (i.e., every 500th sample) within the larger buffer. For example, if a buffer holds 10 bursts, I would like: - The buffer to contain 5000 samples. - To retrieve the rx_metadata timestamp for the first sample of each burst (at indices 0, 500, 1000, ...). How can I achieve this efficiently while ensuring accurate timestamp extraction for each burst? Best regards, Tim
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
