Greetings;
I have been reviewing various documents/code, including:
TES Software generated output code
The SDK code
The Linux Driver (from the R2019_R2 release)
The ADRV9002-iiostream.c code.
I hae the following questions:
1) the ADRV9002-iiostream.c routine makes this call:
iio_channel_attr_write_longlong (chan, "TX1_LO_frequency", val);
- to change the TX1 Local Oscillator value.
- Can this also apply to the RX LO Frequency?? (our application is RX only, no TX)
- Is this call here, due to previously undocumented Driver setup that maybe "links" these LO's? (based upon the Users Guide documentation)
2. Can I assume that the ADRV9002 driver provided contains the TES generated code that was generated for the specific characteristics of the ZED board the ADRV9002 EVAL board?
- How does one modify/update the driver (via patches) regarding the "configuration structures" that the TES code outputs? (specifically for the REF clock input change we need to do).
3. Looking at the TES generated code, there is alot of setup/initialization for this part, w.r.t the "configuration structures", the loading of profiles, the loading of the onboard microcontroller and it's firmware. None of this seems to be present in the ADRV9002-iiostream.c code. Can I assume this is done by the driver?
- Is there a way to "override" the driver setup to re-initialize the device to this level of detail from user space once the driver has been loaded? (understanding that the part may need to be shutdown, reset, etc in order enforce this low-level re-initialization).
4. I reviewed the libiio call path for the iio_channel_attr_write_longlong() which, from user space, seems to resolve down to a write to SYSFS for the "local" setup. At the driver level, I believe will ultimately resolve to calling the correct sequence of lower level API calls in adrv9002_phy_lo_write() that will change the part's state as documented in the Users Guide in order to affect a change in the LO. Can this be confirmed? This is a follow up to question 1 about changing the RX LO. I understand this may be dependent upon the LO mux setup previously set by the driver via the "configuration structures".
I look foward to your reply.
Regards,
Stephen Beckwith
