I have a few questions regarding the available Adalm Pluto System Objects for MatLab like adi.AD9361.Tx/Rx from the ADI github (MathWorks_tools), or the sdrtx/rx from the MathWorks Communication Systems Toolbox Support Package. 1) Why are there 2 classes of System Objects, and which one is recommended to use? Whats the difference between them in terms of configurability, are both capable of turning on/off the cyclicity of the TX buffer for example?2) Is it possible to simultaneously transmit and receive at the same time? In particular I want to try to capture the signal from my car remote, and as soon as the beginning of a signal is detected, transmit a short frame of jam signal to prevent my car from unlocking. This means however to continuously receive, otherwise the key signal isn't completely captured for further processing.3) Relating to 2): How do the aforementioned TX / Rx System Objects internally work? Are the RX buffers continuously filled by the ADC, and calling rx() only reads out the last N samples with N being the number of samples per frame? Or does the method rather block the program flow, by waiting until the receive buffer received N new samples?What about the tx() methods? Do they block the programm flow by waiting until the whole signal was clocked into the DAC, or do they rather return directly after putting the whole frame into a TX queue?4) Is it in the obligation of the user to scale the TX signal into the 12b, -2^11,...,+2^11-1 range expected by the ADC? If values outside this range are passed to the tx() methods, does this lead to a DAC overflow?
1.) They are all built upon the same bindings or core interfaces with libiio. The ones directly from MathWorks are generally recommended for initial users and will contain more doc specific to MATLAB. The ADI authored interfaces are open and meant to be extended to other functionality of the radio, but are recommended for more seasoned users.
2.) No, since the driver for TX and RX are separate, and their DMAs internally within the FPGA are separate. We are internally discussing some functionality like this since it would be useful for our radar products and it would be extended to the transceivers like Pluto (eventually).
3.) For RX when the operator (or step method) is called for the first time, the buffers are created within the DMA on Pluto itself. By default 4 are created and start to be filled. The first buffer is returned once it is filled and the other will continue to fil. Together they form a circular buffer and as soon as one is requested/pulled it frees up space for the next one. Therefore, you are guaranteed for the first 4 buffers to be contiguous. However, if you do not request/pull buffers fast enough data can be dropped between buffers after the first 4. Tx simply works in the opposite way where you must constantly feed the DAC where a number of buffers are queued (4 by default). If you starve the DAC the DMA will insert zeros between buffers.
4.) The DAC FPGA interface accepts 16-bit numbers and will remove the 4 lower LSBs. This is documented here: https://wiki.analog.com/resources/fpga/docs/axi_ad9361#internal_interface_description
For the MathWorks interfaces, it will scale doubles if passed but not int16 data. For the ADI interfaces, we do not scale and simply cast your input to int16 always. The recommended approach is to provide full-scale data to the DAC by using as much of the int16 type as possible.
Thank you for the clarification sir. However I'm still a bit confused:
2) Does this imply that the TX and RX drivers simply cannot operate at the same time? 3) implies for me, that once the TX/RX buffers are written-to/read-out with a average rate of R = f_sa / NsaPerFrame continuous simultaneous operation was possible.
However this would be a great feature. Just out if interest: How long would you expect this to take until a beta is available?
3) Is it possible to set the number of buffers created over the ADI interface?
2.) No, this just means they are not synchronized in anyway.
No ETA, we are still whiteboarding things to understand requirements better. The end product will require both HDL and software pieces so it can take some time.
3.) Yes, just use the "kernelBuffersCount" property on the object.
Ok, thank you. Just two final questions:
1) Is there a way to get() the currend numer of frames in the buffers?
2) What happens with an tx() call when the TX buffer is already full? Is the frame dropped? Is a flag set if this happens?
Thank you for the excellent support and your book SDR4Enineers, which i read and apply (or at least try do so) with great pleasure.
1.) Not from MATLAB, it's hard coded and hidden from MathWorks. From raw libIIO, you would put the buffers in non-blocking mode and do a buffer_refull. They the number of bytes would tell you this.
2.) It will block.