I’ve been able to do what you’re trying to do, and it is possible. This is the problem that timestamps solve. But it helps a bit to know that the timestamp is basically just a count of how many samples the fpga has received from the lms7002m since RX stream start.
Start the RX and TX streams. Receive data from the RX stream, then look at the timestamp of the last data frame you received and pick a time some way (say 50 ms) in the future. Construct a TX packet that contains the pulse you want to transmit, being sure to turn on the waitForTimestamps bit. Send your packet and continue to receive - make sure the RX fifo never overflows. The signals you’re looking for should come in the right place relative to the pulses. So if you transmit from pulses 21000 to 22500, the signals you’re looking for should come starting after 22500. You can throw away the samples you received before 22500, but you do need to receive them.
Now to do a second transient you have a couple of choices. You can turn off the streams and start everything over again, but if you want precise timing between transients, just keep receiving during the recycle delay, pick the time to send your next pulse and put it in a new packet to transmit.
You can just stop sending transmit packets whenever you like (but don’t turn off the TX stream every time), but you need to keep receiving all the time (well, you need to make sure the rx fifo doesn’t overflow).
There are a few quirks I’ve seen.
-
f you are using a single RX channel - never put an odd number as the timestamp in the tx packet header. Bad things happen. Internally the rx timestamps are only ever even numbers if there’s only one RX channel available, so presumably the odd number never matches.
-
if you do interrupt the TX stream by not sending packets, make sure the TX fifo is empty before you start sending again.
If you are using a buffer size that is an integer multiple of the native packet size, I don’t think that the flushPartialPacket flag does anything - not totally sure about that though.
If your pulse is sometimes not transmitted at higher data rates, it seems likely that it is arriving from the host too late, and the timestamp you’ve requested has been missed? Try picking a time farther in the future for the TX packet. I’ve used 50 MSPS without trouble - of course that’s USB3. For USB 2 I would have thought 1 MSPS would be no problem, though 10 MSPS might be pushing it.
You shouldn’t have to do anything very tricky here to get the TX and RX samples synchronized to each other to within 1 sample. It turns out that the calibration routines do mess with the relative sync of TX vs RX, but its a pretty small effect, and it sounds like you have much bigger problems.