Zynq Radio Software Interface Model: UDP send/receive blocks not working

Working through the HW/SW Co-Design QPSK Transmit and Receive Using Analog Devices AD9361/AD9364 reference design, I have loaded the image onto the FPGA of an ADI RF SOM - ADRV9361.

I'm now trying to run the 'software interface model' supplied on the same page, along with the UDP_HostPrintout model for data reception, but I'm having trouble with the UDP send/receive blocks.

Everything runs nicely with no errors and I've got a busy blinking light on Ethernet port 1 of the carrier board, but I can not get the UDP send/receive blocks to do anything - I can not view the data that is supposedly being sent and received.

I think I've got the IP addresses right - Using the default 192.168.3.2 for the board and 192.168.3.1 for the host, and according to 'netstat' the port '25000' is not already in use.

When I run the simulation and call 'netstat' in 'cmd' there are no new UDP connections appearing and there is no data showing in the Diagnostics Viewer.

Am I supposed to be using the second Ethernet port on the carrier board? If so how do I first configure that?

Otherwise is there something else that I'm missing?

I have the following toolboxes/addons installed:

 MATLAB                                                Version 9.4         (R2018a)
 Simulink                                              Version 9.1         (R2018a)
 Communications System Toolbox                         Version 6.6         (R2018a)
 DSP System Toolbox                                    Version 9.6         (R2018a)
 Embedded Coder                                        Version 7.0         (R2018a)
 Fixed-Point Designer                                  Version 6.1         (R2018a)
 HDL Coder                                             Version 3.12        (R2018a)
 HDL Verifier                                          Version 5.4         (R2018a)
 LTE HDL Toolbox                                       Version 1.1         (R2018a)
 LTE System Toolbox                                    Version 2.6         (R2018a)
 MATLAB Coder                                          Version 4.0         (R2018a)
 Phased Array System Toolbox                           Version 3.6         (R2018a)
 RF Blockset                                           Version 7.0         (R2018a)
 RF Toolbox                                            Version 3.4         (R2018a)
 Signal Processing Toolbox                             Version 8.0         (R2018a)
 Simulink Coder                                        Version 8.14        (R2018a)
 Stateflow                                             Version 9.1         (R2018a)
 WLAN System Toolbox                                   Version 1.5         (R2018a)

Any help would be greatly appreciated!

Kind regards

Harry

EDIT: The receive side appears to work - when I give it an active port number listed in netstat, it sends garbled text to the Diagnostics Viewer.

Answer 1

[Paul]

Hi Harry,

The setup details you are providing are correct. The Ethernet port you are currently using will be fine if it is the same one that has been used during the hardware configuration at installation.

There are a few things you can try to understand what is happening:

• The example's log file on the target will display some details about potential errors. You should see Hello World written in that file. You can read it with these commands:

 >> devzynq = zynq('linux','192.168.3.2','root','root','/tmp');
 >> system(devzynq, 'cat /tmp/zynqRadioHWSWQPSKAD9361AD9364SL_interface.log')
 % If that was the wrong filename, you can find the right one by listing the files in the /tmp folder:
 >> dir(devzynq, '/tmp')

• We should check if the hardware is the cause of the issue. There might be no data being received.

What have you connected on the Rx and Tx ports of the RF board? A loopback cable or two antennas will ensure a good communication.

Running other examples will make sure the hardware and antennas are working. For example you can start the QPSK transmit repeat on MATLAB and then the Rx Simulink examples together to see if you receive the data correctly:

 >> zynqRadioQPSKTransmitRepeatAD9361AD9364ML
 >> zynqRadioQPSKRxAD9361AD9364SL

You should see the Hello World message printed out in the Diagnostic view of zynqRadioQPSKRxAD9361AD9364SL once it is running.

Let me know if that helps you getting further,

Paul

[Hewy.j]

Hi Paul,

Thankyou for the response, it's much appreciated.

I'm using a loopback cable and running the TransmitRepeat and Simulink receiver examples displays the indexed hello world as expected. However, the hello world message continues to display and update if I disconnect the loopback cable! Running the examples with no link between the Tx and Rx ports somehow still displays the message, so I feel as though the hardware is not really being tested properly. I have had a similar issue troubleshooting the 802.11 beacon receiver example that I've mentioned here . (EDIT: It's as though the SDR receiver block simulates the data instead of actually reading it from the hardware)

Anyway, the log file shows that everything loaded successfully but the data transmitted is just '^^^^^^^^^^^^^^^'. Throwing the Tx switch does not change the content of that string but it does enlarge it to the correct character length for 'txtstr'. Does this give you any clues that I'm not experienced enough to interpret?

[EDIT: The 'BitsToASCII' MATLAB function block immediately before the UDP Send block converts all values larger than 126 and smaller than 32 to 94 (94 = ^ in ASCII). A 'To-workspace' block before this converter shows just shows a string of 0s. So no signal is being received. I'll investigate this but it still doesn't explain why there is no data being sent from the UDP Block - even a string of '^' should get sent surely?]

I'll add the log below. Thanks again Paul!

Kind regards, Harry.

    '--- SetReset(TXFPGA_DEV) Success 
     --- InitAction(TXRFBOARD_DEV) Success 
     --- InitAction(TXRFBOARD_DEV) Success 
     --- InitAction(TXRFBOARD_DEV) Success 
     ad9361_init : AD936x Rev 2 successfully initialized

     ####################################################

     ### INIT RF

     ####################################################

     ad9361_init : AD936x Rev 2 successfully initialized

     ####################################################

     ### INIT RF COMPLETE

     ####################################################

     --- SetReset(RXFPGA_DEV) Success 
     --- InitAction(RXRFBOARD_DEV) Success 
     --- InitAction(RXRFBOARD_DEV) Success 
     --- InitAction(RXRFBOARD_DEV) Success 

     Set Tx design type = 0

     ****************************************************

     Set rx filters

     filter_design_type_rx_desired = 1

     filter_design_type_tx_desired = 0

     filter_design_type_rx_last = 4

     filter_design_type_tx_last = 4

     ****************************************************

     ****************************************************

     Set tx filters

     filter_design_type_rx_desired = 1

     filter_design_type_tx_desired = 0

     filter_design_type_rx_last = 4

     filter_design_type_tx_last = 4

     ****************************************************

     Program both

     *** Set new tx and rx values

     ****************************************************

     ****************************************************

     Clocks setup ok. Actual:Desired

     Tx 0, 800011776:800011776          Rx, 800011776:800011776

     Tx 1, 25000368:25000368          Rx, 25000368:25000368

     Tx 2, 8333456:8333456          Rx, 8333456:8333456

     Tx 3, 4166728:4166728          Rx, 4166728:4166728

     Tx 4, 2083364:2083364          Rx, 2083364:2083364

     Tx 5, 520841:520841          Rx, 520841:520841

     ####### DMA Source selected #######

     Set Tx design type = 1

     ****************************************************

     Set rx filters

     filter_design_type_rx_desired = 0

     filter_design_type_tx_desired = 1

     filter_design_type_rx_last = 1

     filter_design_type_tx_last = 0

     ****************************************************

     Transmit already programmed

     *** Set new rx values

     ****************************************************

     ****************************************************

     Set tx filters

     filter_design_type_rx_desired = 0

     filter_design_type_tx_desired = 1

     filter_design_type_rx_last = 0

     filter_design_type_tx_last = 0

     ****************************************************

     ****************************************************

     Clocks setup ok. Actual:Desired

     Tx 0, 800011776:800011776          Rx, 800011776:800011776

     Tx 1, 25000368:25000368          Rx, 25000368:25000368

     Tx 2, 8333456:8333456          Rx, 8333456:8333456

     Tx 3, 4166728:4166728          Rx, 4166728:4166728

     Tx 4, 2083364:2083364          Rx, 2083364:2083364

     Tx 5, 520841:520841          Rx, 520841:520841

     ####### Resetting to DMA Source #######

     ** starting the model **
     ########## Start Continuous Tx Transfers ##########
     ########## Start Continuous Rx Transfers ##########
     Xt^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^:^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^  <- correct number of characters for Hel Wrld xxx 
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^^^^^^^^  <-- Tx switch thrown
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^^P^^^^^^^^^^^^^^  <- Correct number or characters for txtstr
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^@^^^^^^^^^h^^^^^
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^^^^^^^^
     ^^^^^^^^^^^^^^^^^:^^^^

Answer 2

[Paul]

Thanks for the details Harry.

About the loopback cable: you will have enough leakage from the unconnected antennas for them to work.

So there are two separate issues:

• The first problem where no data is received on MATLAB via UDP;
• The new one where ^^^^^^^^ is being printed in the log.

1. The only thing I can suggest is to check if you don't have any firewall blocking the communication between the host and the target via UDP.

2. ^^^^^ means some non-valid data is received. The length of each line on the log does not mean anything at that point as the model knows what is the expected data size. If the UDP connection was working, you would be able to see these ^^^^^ characters on the diagnostic viewer.

Have you edited the log file? It looks like you have truncated some lines at the end as the line length changes only a dozen lines after the acquisition started. That would be suprising to be able to switch Tx so quickly. If you didn't edit the log, that means the acquisition is very slow.

Could you attach your generated bitstream to your next message, so that we can try it here please? You will find it in 'hdl_prj\vivado_ip_prj\vivado_prj.runs\impl_1\system_wrapper.bit.

[Hewy.j]

Hi Paul,

Thanks again for your help. You're right about the leakage - I should have realised that.

Yes I did edit the log to shorten the post, sorry I didn't mention it. The filepath you gave to find the Bitstream made me realise I had changed the name of the simulation file and I wondered if this could be causing the problem - I regenerated the bitstream using the default file names and filepaths and ran the originally named Simulink Interface with it and the problem was solved! The log file now shows the Hello World and txtstr contents as expected.

The UDP problem persists however and I am trying to find out about any firewall issues that might be causing it.

In the meantime, I thank you for your help Paul. It's been much appreciated.

Regards, Harry