Matlab to phaser kit communication error

 Hi niharikaechoninjas ,

Can you provide a quick sketch or description of your networking setup - do you have a direct Ethernet connection from your host machine to the phaser, or switch / router between, or USB-Ethernet adapter?

Can you try:
ping phaser.local

and see if it responds? After that, let's see if any of the IIO devices are up and running with:

iio_info -u ip:phaser.local

(and paste the results here.)

We have seen issues in the past where one of the ADAR1000s is running but not the other. I believe this was ultimately traced to a power issue - what 5V / USB-C power adapter are you using, and is it plugged into the USB-C connector on the phaser board (vs. the connector on the Raspberry Pi)?

Hopefully these steps will provide some clues.

-Mark

It is an ethernet to ethernet connection.

The 5v/USB-C adapter in use is from cana kit  plugged into phaser board

update: I changed the 5v supply from phaser kit to pi and iio_info command received a response. 

Okay great!

Any change in the MATLAB behavior?

If not - can you paste the output here? Or at least, can you confirm that you see an ADAR1000_1 and _0? The names may be different in the iio_info output, IIRC it may be BEAM0, 1

-Mark

I have done a lot of trouble shooting, I could see adar1000 when I debugged it few days ago from my windows command prompt. But with recent debugging I get this 

Need to mention that I re-installed communications and transceiver toolbox packages on matlab, suspecting that they might have been corrupted.

to add on , bf() returns a 0 and adi.phaser is being recognized by matlab. I was able to establish matlab to pi 100% communication (verified through pings). I tried downloading the libiio files again from github but that did not work.Not sure, if this is of any help, the green light next to the sd card on pi does not blink. There is a red solid red that is ON.

So I'm not a regular MATLAB user - I did a good chunk of the Python code for the phaser though. In this screengrab - this looks like a MATLAB prompt, correct? I don't know if iio_info can be invoked that way. I do see on your 12/26, 12:13 reply that you have run from the command line (Windows), and later you indicate that iio_info does give a response. Can you paste the output here? The critical thing to sort out - is that both ADAR1000s show up properly. We have seen cases where only one is there, and the theory is that just at the end of initializing the first ADAR1000, it draws a large transient current causing a supply voltage dip that causes the second ADAR1000 to fail, hence the question about the power supply, which I believe you said had a positive effect.

From this response I can't tell if you are up and running successfully - can you clarify?

Re: the green LED next to SD card, that's fine - the heartbeat is assigned to the LED on the phaser board itself, next to the shutdown pushbutton. So you should see that one blinking.

We may have to wait until after ADI shutdown this week is over and someone more familiar with the MATLAB code is back. I can help debug the setup via Python in the meantime. Note that as part of the setup procedure, the entire Python codebase is loaded onto the SD card, so with an external monitor or VNC connection, you can run several utilities that may provide insight.

On that note - part of the setup procedure involves running the (Python) calibration routines:

https://wiki.analog.com/resources/eval/user-guides/circuits-from-the-lab/cn0566/quickstart

https://wiki.analog.com/resources/eval/user-guides/circuits-from-the-lab/cn0566/calibration

- did that go smoothly?

From this response I can't tell if you are up and running successfully - can you clarify?

Re: the green LED next to SD card, that's fine - the heartbeat is assigned to the LED on the phaser board itself, next to the shutdown pushbutton. So you should see that one blinking.

We may have to wait until after ADI shutdown this week is over and someone more familiar with the MATLAB code is back. I can help debug the setup via Python in the meantime. Note that as part of the setup procedure, the entire Python codebase is loaded onto the SD card, so with an external monitor or VNC connection, you can run several utilities that may provide insight.

On that note - part of the setup procedure involves running the (Python) calibration routines:

https://wiki.analog.com/resources/eval/user-guides/circuits-from-the-lab/cn0566/quickstart

https://wiki.analog.com/resources/eval/user-guides/circuits-from-the-lab/cn0566/calibration

- did that go smoothly?

Ok, I will clear it up. I tried isolating the problem. I have figured out a bit that pc to pi communication is an issue while pluto responded to pings. I believe once the pi responds to pings, I can move to matlab for communication, which could be failing due to this. I also want to confirm one thing, If I ping pi, I need to turn off wifi on my system to let the ethernet work right? I am not so proficient in python. I would like to stick to matlab.

I also noticed something, every time I try to address one problem regarding the pings, it gets resolved and another arises. Due to this toggling, I lost the response to former ping for iio which DID in fact respond with both ADAR. I am trying to replicate it again. 

Here is the response to the ping to pi, this is a repetitive problem that I am facing.

UPDATE: I was successfully able to solve the issue. I found out that the pc was talking to itself from the ip address and changed the address of the ethernet port. There was an issue with two ports having the same ip address cauing this confusion. Later, pinging the pi worked. I have also made suitable changes to the matlab code provided to use pi to talk to the beamforming chips directly instead of pluto. I apologize for any confusion.

Also, I did get this error  several times, but I bypassed it byy assigning the specific addressed like (below)

Please let me know if this is valid. I was able to generate the plot on matlab (although not accurate)

Great! Sounds like you are up and running. An Ethernet address conflict is certainly a logical explanation.

And I'd have to defer to the MATLAB experts, but your appending of the Pluto's port number looks valid. The way this works is the phaser Raspberry Pi runs two instances of iiod, one for the onboard ADAR1000s, PLL, monitor chip, and GPIOs, and a second instance to forward the Pluto's USB backend over the network connection, using port 50901.

Re: wifi - an anecdote from my own experience - during development, I would often connect my phaser to my personal WiFi for downloading various Linux and Python packages, since my company laptop does not allow me to forward its internet connection. At one point I noticed that a certain script running on my laptop that plotted out beam patterns either took 4 seconds or 8 seconds, nothing in between. Turns out - the phaser had both wired and wireless connections, and phaser.local would resolve to one or the other, arbitrarily! And it was not so much that the Ethernet connection was slow, rather, each and every iio attribute read / write was a new transaction, with all of its overhead.

So indeed, you can use either, but it's best to explicitly use one or the other.