Thanks Thomas.

Is reasonable to assume that the SPI bus is idle on when there are no command being sent by the Openbts apps running on the PC? ie no one else is using the SPI bus during that time?

For an experiment, I'm looking at hooking an microcontroller directely on this SPI bus and tune the RX frequency in a more dynamic way w/o going through the PC. Any risk of conflict?

Rgds
Nghia

2011/6/30 Thomas Tsou <ttsou@vt.edu>
On Thu, Jun 30, 2011 at 10:08 AM, nghia phan <nghia.phan31@gmail.com> wrote:
> Hello everyone
> I'm trying to understand better the whole path of the RXTUNE command all the
> way from sendCommand("RXTUNE",rxFreq); in the bool ::ARFCNManager::tune(int
> wARFCN) function
> down to the SPI packets sent to the ADF4360 chip.
> Is there any documention that could help me understand this?
> What value should be programmed into the ADF6430 to tune the daughterboard
> RXB for a given ARFCN, say  ARFCN 8?

AFAIK, documentation beyond the data sheet is currently limited. You
could look at how the register values are currently determined.

http://github.com/ttsou/openbts-uhd/blob/b2e807b8b633453abba7b951e9990c74f936ff75/public-trunk/Transceiver/USRPDevice.cpp#L56

> I'm lost after the mControlSocket.write(command); in the int
> ::ARFCNManager::sendCommandPacket(const char* command, char* response)
> function. I understand  this function sends the command via an UDP port,
> dedicated to the control.
> Where are the control UDP packet being parsed and processed? Somewhere in
> the USRPDevice, rigth?

Take a look at Transceiver::driveControl() in Transceiver.cpp

> Then the command should be routed via USB endpoint 0 to the FX2. The FX2
> then finally sends it to the RXB daughterboard via SPI, right?

Correct.

 Thomas