ADRV9002
Recommended for New Designs
The ADRV9002 is a highly integrated RF transceiver that has dual-channel transmitters, dual-channel receivers, integrated synthesizers, and digital signal...
Datasheet
ADRV9002 on Analog.com
In our project, we aim to perform frequency hopping across up to 300 frequencies in a random order. The exact hop duration is still under evaluation, but we assume it will be compatible with all supported hopping modes of the ADRV9002.
We would like to understand whether it is feasible to achieve this using PLL MUX mode with real-time frequency hopping and ping-pong table indexing.
Our current concept is as follows:
Use both frequency hopping tables (Table A and Table B).
Load only one frequency entry into each table at any given time.
While one PLL is actively in use (via one FH table), the BBIC updates the other FH table with the next frequency from the set of 300.
Since ping-pong table indexing is enabled and each table contains only a single entry, the active FH table should switch automatically as the PLL MUX switches between PLLs.
Based on this approach, we expect that:
The FH table update occurs while the corresponding PLL is inactive.
When the PLL MUX switches, the newly updated table becomes active, effectively hopping to the next frequency.
Questions:
Is it supported to update an FH table while frequency hopping is active, provided that the table corresponds to the inactive PLL?
Are there any timing, synchronization, or state-machine constraints that would prevent this approach from working reliably?
Is there a minimum table depth, guard time, or API sequencing requirement that must be respected when modifying FH tables in real time?
Are there any known limitations or recommended alternatives for supporting large (>128) random hop sets using PLL MUX mode?
Any guidance on whether this architecture is supported or recommended would be greatly appreciated.
Is it supported to update an FH table while frequency hopping is active, provided that the table corresponds to the inactive PLL?
Yes, the ADRV9001 does support updating an FH table while frequency hopping is active, if you update the table that is NOT currently in use by the active PLL.
For example, you can update Table B while Table A is actively being used and vice versa.
Are there any timing, synchronization, or state-machine constraints that would prevent this approach from working reliably?
For the PLL mux mode along with hop table real time process - Ensure that the total frame duration should be 25us.
Refer to modes of operation section -Page 117 in UG1828 for more details.
Below is the TRX timing for the PLL mux mode. Refer to page 127 from UG 1828 for more details.
Is there a minimum table depth, guard time, or API sequencing requirement that must be respected when modifying FH tables in real time?
At any given time, only 128 frequency entries are possible. For additional frequencies beyond this limit, you must reload the hopping table with the next set of entries. To obtain the API sequence, please configure the carrier configuration mode to Frequency hopping in TES GUI, upload the hopping table, set the required hop frequencies. Then navigate to View -> driver debugger, where you can view the generated API sequence and modify it as needed.
Is it supported to update an FH table while frequency hopping is active, provided that the table corresponds to the inactive PLL?
Yes, the ADRV9001 does support updating an FH table while frequency hopping is active, if you update the table that is NOT currently in use by the active PLL.
For example, you can update Table B while Table A is actively being used and vice versa.
Are there any timing, synchronization, or state-machine constraints that would prevent this approach from working reliably?
For the PLL mux mode along with hop table real time process - Ensure that the total frame duration should be 25us.
Refer to modes of operation section -Page 117 in UG1828 for more details.
Below is the TRX timing for the PLL mux mode. Refer to page 127 from UG 1828 for more details.
Is there a minimum table depth, guard time, or API sequencing requirement that must be respected when modifying FH tables in real time?
At any given time, only 128 frequency entries are possible. For additional frequencies beyond this limit, you must reload the hopping table with the next set of entries. To obtain the API sequence, please configure the carrier configuration mode to Frequency hopping in TES GUI, upload the hopping table, set the required hop frequencies. Then navigate to View -> driver debugger, where you can view the generated API sequence and modify it as needed.
