I have been designing an SDR for a radar application. While I have been getting up to speed regarding IIO, LIBIIO, the HDL reference design, and the Linux kernel, I have not been able to find as much info as I would like regarding the topic of triggers and their use in IIO. I have found the following sources here, here, here, and I've trolled through many forum posts without finding the info I am seeking. I should note I am not very experienced (~6 months post uni), so if this is simple and I am oblivious to that, I apologize. Also, for the following wall of text, I apologize.
For the purposes of radar in general, it is necessary for a time-coordinated transmit/receive to occur. My overarching goal at the moment is to modify the provided SOM firmware/software to incorporate such a time-coordinated Tx/Rx. Essentially, I want to transmit a waveform with some number of samples at some sampling rate. I then want to get Rx data for X amount of seconds after the Tx waveform is finished sending, then repeat. I also want minimal transition time from Tx mode to Rx mode. For the moment, any kind of Tx-Rx time-coordination would be spectacular.
With my current understanding of the software/firmware architecture, I believe this could be implemented using the trigger mechanism built-in to IIO and some FPGA ref design modifications (if it's not or you have a better idea, please let me know). I am confused on how to get there, however.
With my current understanding of triggers with IIO, a device either has trigger capability, or doesn't, and this can be probed from command line with the device in question. Triggers have a limited number of variations (threshold, rising/falling edge), and trigger events can initiate certain events, in this case data capture.
What I am confused about is how to set up a trigger event to do what I would like to do. How I think I could modify the existing SOM firmware/software is to change the HDL design by adding a custom trigger. When a Tx waveform sent to the DMAC is finished, the trigger activates. The trigger will let the Linux side of things know that Rx data is incoming, and to setup buffers/channels accordingly, and either store the data or offload it via Ethernet to a connected PC for storage (this is moot at the moment, I just want a single Tx-Rx time-coordinated pulse/data). Buffer size and other IIO parameters would be modified to handle my expected application requirements. Since sample rate/size is known as well as the receive time, I would set up buffers appropriately for the amount of data I want to get. For example, at 100Msps, 16bit ADC representation, for 1 second: 100Msps *(16bits)*(1 byte/4bits)*(1 sec) = 400Mb of data.
My questions are:
1) Does this seem like a good approach? Or is this functionality already existing (or similar functionality) and I have just missed it?
2) How much overhead time would you expect there to be between setting the trigger, and subsequent setting up of the Rx buffers/channels for such a setup? On the order of a couple hundred nanoseconds, or are we talking microseconds plus?
3) Where is the best location to implement this functionality? I was thinking of adding to the JESD204B Receive Peripheral Linux Driver, is this reasonable? I would route the trigger to a GPIO into the microprocessor.
4) What would be the best way to register the end of the Tx waveform? Have a unique "end of transmit" sequence and poll the DMAC data for that in the HDL, or...?