Post Go back to editing

libad9361-iio FMCOMMS5

Hello,

We have recently purchased the FMCOMMS5 and ZC702 Evaluation kit.This is our first time working with these products so we are pretty novice. One of the main questions I have is phase syncing through IIO-scope vs libad9361-iio. Do both of these processes produce the same result? Does one have an advantage over another? Related to this we are not really sure what is meant/ how to function call the ad9361_fmcomms5_mulichip_sync to align the chip sampling instances. We have been using GNU Radio to preform some of these DOA estimates but not sure how to perform the function call into this process.

Thanks!



Thanks!
[edited by: mriley at 5:47 PM (GMT -4) on 26 Jul 2021]
  • Do both of these processes produce the same result?

    They use the same process but the code is slightly different.

    Does one have an advantage over another?

    No, just their forms of consumption.

    Related to this we are not really sure what is meant/ how to function call the ad9361_fmcomms5_mulichip_sync to align the chip sampling instances. We have been using GNU Radio to preform some of these DOA estimates but not sure how to perform the function call into this process.

    There are some notes on some assumptions for the function call here: http://analogdevicesinc.github.io/libad9361-iio/group__TopLevel.html#gaeeb859740d88a808adc2dcc41c473495

    If you are using FMComms5 in GNU Radio you will need to modify the FMComms5 block to call this function or perform it externally in a small app. Note that once the function is called, setting the sample rate, LO frequency, gain modes, gain or settings will change the phase relationship. So you will likely need to modify the FMComms5 block to not perform these actions. It might be easier to use the IIO Device Source block which will only pull data and not interact with the transceivers.

    -Travis 

  • Thank you that helps a lot but now I have a few more questions. We are working from the doa_whitepaper and other adi resources. This is our first time working with these boards so I would like to clarify the phase sync options:

    • For libad-9361: https://wiki.analog.com/_media/resources/tools-software/linux-software/doa_whitepaper.pdf 

      "The FMComms5 evaluation board utilizes two AD9361 transceivers, providing a 4x4 system where all receivers and transmitters are phase aligned. This requires no external cabling or splitters since the FMComms5 board is outfitted with a RF switches allowing phase matched analog loopback between transceivers."

      For this process we need 3 functions calls:
      1. Phase calibrate between individual chips starting with chip A to DDS using the function call ad9361_fmcomms5_multichip_sync
      2. Phase synch using function call ad9361_fmcomms5_phase_sync
      3. Phase calibrate (to align transmitters) chip B to DDS using the same function call ad9361_fmcomms5_multichip_sync

      Is the only way to verify this process with a power splitter and view_FMComms5_op_with_corrected_phase_offsets.grc or could we just no power splitter and use calculate_FMComms5_phase_sync_accuracy.grc or possibly using osc? 

    • For osc: https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/phase-sync 

      We are very confused about the physical setup "With loopback cables connecting RX and TX and DDSs set to -18 dB RSSI should be ~37-43 dB".

      To calibrate the phase-sync do we need loopback cables connecting RX and TX (a total of 4 cables for each of the RX1A-TX1A, RX1B-TX1B, ..etc) or are these loopbacks embedded into the board (not external cables) so we just need to apply these settings > Reset Calibration > MCS Sync > Calibrate

    • Do you have a recommendation for following the doa_whitepaper? We were going to follow the flowgraphs presented in gr-doa since the FMCOMMS5 blocks were used but now we might look into your method mentioned in the previous reply by using the IIO Device source block into the run_DoA_transmitter.grc. Im not sure how you originally implemented the phase sync in your research.


    Again thank you so much for your help! Look forward to hearing back.

  • A. The single function call to ad9361_fmcomms5_phase_sync handles all these operations. Take a look at the steps: https://github.com/analogdevicesinc/libad9361-iio/blob/master/ad9361_fmcomms5_phase_sync.c#L507

    Is the only way to verify this process with a power splitter and view_FMComms5_op_with_corrected_phase_offsets.grc or could we just no power splitter and use calculate_FMComms5_phase_sync_accuracy.grc or possibly using osc? 

    Not all channels can be active simultaneously with the switches, so you must verify with external equipment. Also note that since the switches are a different RF path, they may have slight phase differences when comparing to the SMA connectors.

    B. 

    To calibrate the phase-sync do we need loopback cables connecting RX and TX (a total of 4 cables for each of the RX1A-TX1A, RX1B-TX1B, ..etc) or are these loopbacks embedded into the board (not external cables) so we just need to apply these settings > Reset Calibration > MCS Sync > Calibrate

    For calibration, external cables are not necessary. The library can support this mode but it's not required.

    C.

    You need to understand how the phase can change between the transceivers on the FMComms5 based on the different actions you perform with the device. This is examined on these pages:

    https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/multi-chip-sync#synchronizing_multiple_ad9361_devices

    https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/phase-sync

    You also need to understand how the gr-iio blocks control the transceivers based on the constructor calls if you want to use the top-level ones (FMComms2/3/4/5). Since once the system is calibrated certain changes to the transceiver will disrupt the calibration or phase relation between the transceivers which you want to avoid. This is why I meantion the use of the generic IIO Device blocks.

    Near the end of this talk, we discuss the generic blocks and how they work: https://www.youtube.com/watch?v=05nLPVJW9Uo

    This block is specific to the transmitter, which could be anything. We ended up using a Pluto in our measurements, but it can use the FMComms5 TX ports as well. However, it just assumes a single source.

    -Travis

  • Hello again,

    Thank you, all of these resources have been very helpful. If you have time, would you mind looking over our procedure?

    If we were to repeat the doa experiment where we want to set up a ZC702/FMCOMMS5 and a 2.4 GHz source using a bladeRF would this be a valid approach:

    1. Phase sync with osc: 

    Recieve Chain:

    • RX LO Freq: 2400 MHz
    • RX1-4: manual 60dB
    • RF Bandwidth: 18M
    • Sampling Rate: 10M

    Transmit Chain:

    • TX LO Freq: 2400 MHz
    • RF Bandwidth: 18M
    • Sampling Rate: 10M

    FPGA:

    • DDS: -18dB

    Confirm relative sync by opening a a capture window to view received data on the SMA connected receivers.

    2. Using GNURadio and following Figure 7: DOA Estimation Flowgraph) can we just set the FMCOMMS5 Source block to same parameters as the phase sync process or will this also reset the phase relationship? Or should we just pull data using our own device block with four receive channels? 

    We appreciate your time. Thanks

  • 1. This is fine, but note the ad9361_fmcomms5_multichip_sync function will change the gains and scale of the DDSs.

    2. If you use the FMComms5 block as is it will update the sample rate and LO (even if its the same) . You will either need to remove the attribute updates within the block or use the IIO Device source block.

    -Travis 

  • Hello,

    So we do not have a power splitter to view the relative sync, by looking at the received data on the SMA connected receivers. After the phase sync process the results look better but still do not look very phase synced do you have any suggestions? See image below

    Thanks.

  • That just looks like noise. I would highly recommend getting a power splitter. You will have no idea if the system is truly synced otherwise.

    -Travis