Other Parts Discussed in Thread: AFE58JD28, RFSDK, 66AK2L06
Hello TI experts,
We are in the early phase of a project that uses the TI 66AK2LX SoC combined with the TI Analog front end AFE58JD28.
This is a re-implementation of a legacy design on older hardware from different vendors.
Here is my question: Is the following general system design feasible? Does it fit within the "mainstream/normal" usage that has been designed into the K2L SoC and the AFE?
Are we kinda barking up the wrong tree here, or at a 35,000-foot glance does this look like a sensible thing to be trying to do?
We are using the AFE/SoC combination for processing receive (Rx) frequency-encoded data. The inbound data is running at a carrier frequency of 2Mhz.
The baseband signal causes the carrier to vary in frequency between about 1.96Mhz to 2.04Mhz. We sample chunks of data of 125 uSec in length. We expect that the frequency characteristics of the signal vary much slower than that, so a 125-uSec chunk of data should be reasonably stable in frequency.
In the legacy system, we sampled at 48 Mhz. (I.e., 6,000 samples per 125-uSec sample window.) We used 24-element sin/cos vectors to create quadrature signals (i.e. IQ pairs (complex scalar values)). This shifts the FFT frequencies down 2Mhz. So, the positive 2Mhz frequencies are shifted down to around a frequency of zero.
Then, we add up the blocks of 24 elements, to get a 2Mhz signal based on this summation process. This implicitly removes the 2Mhz carrier frequency, because it is aliased to DC after the summation.
We then do a lot of post-processing on this stream of 2Mhz IQ pairs.
We expect to do a similar train of post-processing steps on one of the DSP processors in the K2L SoC.
Key 35,000-foot questions:
1 - Is there anything inherently wrong with trying to map this kind of problem into the K2L/AFE hardware/software combination?
2 - Should this be reasonably straightforward, i.e., would this problem be in the "comfort zone" and design intent of the K2L/AFE combination?
3 - Should we do some of the "cooking" of data from 48Mhz (or some other high sample rate) down to 2Mhz IQ pairs in the AFE/DFE/IQNET hardware, or just capture and dump 48-Mhz data right into the DSP and have the DSP do all data reduction?
4 - The Digital Front End (DFE) on the K2L SoC looks like it has two frequencies that it can run at under normal circumstances: 245.76 Mhz or 368.64 Mhz. Does this mean that we could get (resp.) 15 million 16-bit samples per second or 23 million 16-bit samples per second through the DFE over into DSP memory?
5 - Can we configure the AFE/DFE/IQNET combination so that we stick with one of the two DFE frequencies, but send data at a slower effective rate to the DSP? As an analogy, if I have a gigabit ethernet connection to my PC, I can send data a lot more slowly than 1gps. I could send one byte per second if that was all I needed! If I only need IQ data at a rate of 2 Mhz over in the DSP, can I easily (i.e., within the design intent of the AFE/DFE/IQNET hardware) set up that effective 2Mhz rate to the DSP, using (for example) the 245 Mhz configuration of the DFE?
6 - Or, do I need to go down into the weeds on the DFE and configure it to generate some sort of custom data rate?
7 - Or, should I select some data rate for IQ pairs to arrive at the DSP that is higher than 2 Mhz but still allows me to process the 2Mhz carrier data?
Thanks a million!
I noticed that Joe Quintal is one of the TI experts in the AFE/DFE/IQNET hardware chain, and have been amazed at how helpful and responsive the TI engineering community is to people new to the TI platforms.
Greg Johnson
