SDP-S with 4 ADAR100 SPI bus and questions

Hi,

I'm not familiar with the ADAR1000 but I've assigned another engineer to this thread who is. 

The SDP-S is limited to 10MHz SPI. The SDP-B is capable of 30MHz SPI but I do not think this is the cause of your issues. As the SPI is used for config only, I suspect the SPI frequency in use is well within the capabilities of the SDP-S.

Based on my limited experience of this board - the same SPI bus should be reaching all of the boards, and whether a given board listens/responds depends on the A0, A1 address pin setting on that board.

Please check your SPI lines - SCLK, MISO, MOSI, Chip Select. If activity is not seen on these lines on an unresponsive ADAR1000 board, please check your SPI connections.

If activity is seen on these lines, please check the A0, A1 settings on the unresponsive board or the commands sent from your software.

USB2.0 cable length

Another board in the SDP family is currently supplied with a USB cable that is between 2m  and 2.5m long. The limit of 5m for USB2.0 is for the highest speed possible on USB 2.0  - 480Mbit/s. The Blackfin chip that implements USB functionality on the SDP-B can operate at 480Mbit/s, so you would be at the limit of what is allowed for in the USB 2.0 specification at 5m. If it's operating at 12Mbit/s, then you should be OK at 5m. I'll try to find the information on the bitrate for use with the Eval software. In the meantime - if you have to use 5m cables, try to use good cables.

Unstable phase - I will leave this for @jdobler to answer. 

Thanks for the response David.

We have purchased a second SDP-S to send the SPI data to the Line S boards 3 and 4.

We have tried the 5m cables, some times specific channels seems to not receive the information and the information needs to be sent again. 

Also, once the calibration information is applied (putted the 32 channels in RX mode and then sent the correct phase shifts to get constant absolute phase) it did not allow us to change the phase shift (even though we were correctly loading the new information with 2801-202801-402801-402801).

How we solve this issue for the moment is by resetting every time the beam needs to change and again put them in RX mode and so on...

Questions:

- Is there something we can do to solve this? What consequence can have if we use the boards like this?

- Could a single SDP-B be used for Line B and Line S? How could I activate the other Sel-B and Sel-C from the SDP-B? Can it be done via MATLAB? (I have previously tested the SPI signals using the Breakout board and a logic analyser and only Sel-A was active or low when sending information.)

- What recommendation can I have for the power supply?

Thanks for the help.

Hi,

I think a diagram of your setup, or perhaps a few diagrams of setups that you are considering may help. I'm having trouble visualizing this.

I don't have enough experience of the ADAR1000 to answer the question of phase shift and whether you can continue to reset/setupA/reset/setupB etc continuously. jdobler may be able to.

Theoretically, yes, an SDP-B (or SDP-S) can control 3 separate SPI lines, Sel-A, Sel-B, Sel-C. Using the on board address selectors to give 4 ADAR1000 per SPI line, and thus allowing up to 12 ADAR1000 per SDP-B (or SDP-S). The SDP-S,SDP-B, SDP-H1 were not really intended for prototyping use. "Plug and play" evaluation use with dedicated, supplied software is fine. Prototyping can be tricky or almost impossible depending on the Eval board and the original evaluation software (Note - we are working on better prototyping support in general).

However, from looking at previous threads like ADAR1000 SPI - Q&A - System Demonstration Platform (SDP) Support - EngineerZone (analog.com) and ADAR1000-EVAL Automated Control via SPI - Q&A - RF and Microwave - EngineerZone (analog.com) it looks like jdobler may have some examples to help with this eval board. I'm not sure if the support forums are currently alerting members to relevant threads outside their assigned areas. You may need to open a thread in Q&A - RF and Microwave - EngineerZone (analog.com) to get access to any examples for this board.

If you have SDP-B (or SDP-S)  trouble with any examples that are provided to you I will try to help. If you find that any examples that exist for the SDP-B or SDP-S cannot be adapted to your use case there is one other option that may work. For the ADAR1000, there is the option to control it through open source IIO code using a suitable Linux board. ADAR1000 8 GHz to 16 GHz, 4-Channel, X Band and KuBand Beamformer Linux device driver [Analog Devices Wiki]

For example, a Raspberry Pi with ADI Kuiper Linux image should allow you to control enough ADAR1000 for your use case. I say should as I'm not 100% sure about using multiple SPI buses on the RPI simultaneously - I've never used more than 2 devices on one bus. The members of Linux Software Drivers - EngineerZone (analog.com) will be able to help if you have Linux driver questions before committing to that course.

From above:

Also, once the calibration information is applied (putted the 32 channels in RX mode and then sent the correct phase shifts to get constant absolute phase) it did not allow us to change the phase shift (even though we were correctly loading the new information with 2801-202801-402801-402801).

I assume the bold was a typo - it should be 602801, to control 'Chip 3' on the bus.  Assuming that was a typo, there is bug in the Memory Control in the 'MISC" that doesn't always write the BEAM RAM BYPASS bit and thus the part still pulls data from the RAM.  Try using the manual register write instead when writing to Register 0x38. 

Also ensure that the ADDR0 and ADDR1 pins are pulled low/high to address the chip uniquely on the SPI bus. 

The current ADAR1000 evaluation boards and software only use SPI_SEL_A.

Thanks for the responses.

Yes you are correct, I meant to put 602801. I am currently applying all the registers in the manual write, are you suggesting on not including the 3860? Is there more information about this error somewhere?

Thanks.

No, you should include the 0x3860 in the manual write. 

I do not believe I've documented the GUI bug yet.  It should not affect you since you are using he manual register write and the error is in the MISC/Memory Control section of the GUI.