Can the AD9363 be "Hacked" into an AD9361?

When first getting started with the AD9363 SDR, I came across many online posts mentioning that the AD9363 could be "hacked" to become an AD9361 or AD9364. Initially, I was also puzzled: How is this so-called "hacking" actually achieved? We know that the AD936x series are configured via registers through the SPI interface. Could it be that there are undisclosed secret registers inside the chip, and that writing specific values could magically transform the AD9363 into an AD9361/AD9364?

Here is the official introduction for the AD9361:

Here is the official introduction for the AD9363:

From the official parameter comparison, it can be seen that the core differences between the two mainly lie in the following three points:

1.Frequency Range: The AD9361 supports up to 6 GHz, with a minimum transmit frequency of 47 MHz and a minimum receive frequency of 70 MHz. In contrast, the AD9363 only supports up to 3.8 GHz, with a minimum frequency of 325 MHz for both transmit and receive.

2.Bandwidth: The AD9361 supports a maximum bandwidth of 56 MHz, while the AD9363 is limited to 20 MHz.

3.TxEVM: The AD9363 also performs slightly worse than the AD9361 in terms of TxEVM (Transmit Error Vector Magnitude).

Apart from these, the two chips are essentially identical in functionality and other performance aspects.

After all, there is a significant price difference between the AD9361 and AD9363. If the AD9363 could indeed be "hacked" to achieve the performance of the AD9361 or AD9364, its cost-performance ratio and practical value would be exceptionally high.

The claim that the AD9363 can be "hacked" into an AD9361/AD9364 originally originated with the PlutoSDR. The official ADI wiki documentation for Pluto clearly records the relevant implementation method, which is the primary source of this technique.

The fw_setenv command is used to update Linux U-Boot environment variables. Upper-layer software, such as IIO, identifies the current hardware model and the number of antennas by reading the environment variables compatible and mode. Therefore, by simply modifying these two environment variables, one can bypass the software restrictions on frequency and bandwidth imposed by IIO. This is essentially not a physical hardware limitation at the chip level, but a software limitation in the driver layer. By directly modifying this configuration in the PlutoSDR source code project, causing the upper-layer software to misidentify the driven device as an AD9361, the original restrictions on frequency range and bandwidth are lifted.

Even if we fool the driver and upper-layer software, this whole operation would be futile if the AD9363 chip itself had hard hardware limitations on frequency and bandwidth.

However, the actual test results brought a pleasant surprise: After modifying the driver configuration, it was indeed possible to transmit signals exceeding 20 MHz normally through IIO. The image below shows a 4-carrier LTE 10 MHz template waveform built into the IIO software. It can be clearly seen from the signal bandwidth that it has significantly exceeded the AD9363's nominal 20 MHz limit.

Could there be undisclosed details hidden in the official code? After all, I haven't delved deeply into the source code yet. To rule out interference from the driver and software layers, we switched to verification purely under Programmable Logic (PL).

In the pure FPGA logic, we directly configured the RF bandwidth of the AD9363 to 56 MHz and generated a 5G NR signal source with a 50 MHz bandwidth inside the PL, transmitting it through the AD9363. Next, we observed the actual transmitted signal using a spectrum analyzer.

The results clearly show that the 50 MHz bandwidth signal is transmitted completely, without being restricted by the AD9363's nominal 20 MHz bandwidth limit.

Next, we performed a loopback test using an SMA cable and captured the loopback signal with ILA to verify the bandwidth capability of the receive side. As can be seen from the MATLAB waveform, the received signal bandwidth also reached 50 MHz, indicating that the receive chain of the AD9363 also supports 50 MHz bandwidth.

Combined with previous experiments using the PlutoSDR, such as the FM radio experiment (operating around 100 MHz) and the openwifi experiment (operating near 5 GHz), both have exceeded the official frequency range specified for the AD9363.

Based on the above experimental phenomena, it can be concluded that the AD9363 does not have hard physical limitations on frequency range and signal bandwidth at the chip level and can effectively be used as an AD9361. The reason the official documentation never mentions this is likely because performance outside the specified range is not guaranteed.

Nevertheless, knowing this characteristic still holds some significance:

For certain products where RF (RF specifications) are not extremely stringent, but larger bandwidth or operating frequencies exceeding 3.8 GHz are needed, it's possible to consider directly substituting an AD9363 for an AD9361. The significant price difference between the two could potentially lead to substantial cost reductions.

For learners, the AD9363 is sufficient for learning all the functionalities of the AD936X series. Beginners typically do not have strict requirements for(ultimate performance), making it a cost-effective choice.