Regarding different Adalm Pluto System Objects, internal functionality, simultaneously transmit and receive

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?

Parents
  • +1
    •  Analog Employees 
    on Jun 10, 2019 1:28 PM

    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.

    -Travis

Reply
  • +1
    •  Analog Employees 
    on Jun 10, 2019 1:28 PM

    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.

    -Travis

Children