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

6 views (last 30 days)
Hewy.j
Hewy.j on 15 Aug 2018
Commented: Hewy.j on 21 Aug 2018
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.

Accepted Answer

Paul
Paul on 17 Aug 2018
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
  1 Comment
Hewy.j
Hewy.j on 20 Aug 2018
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^^^^^
^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^:^^^^

Sign in to comment.

More Answers (1)

Paul
Paul on 20 Aug 2018
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.
  1 Comment
Hewy.j
Hewy.j on 21 Aug 2018
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

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!