Hello,
I am trying to find an easy/approachable way of altering sample-rates at run-time for the 9002 without requiring re-compilation or storing large binary files. From what I can tell:
- In the non-TES Linux IIO workflow, switching sample-rates was a matter of generating a stream.bin and profile.json file which were several 30-40 kilobyte files each and loading them in sequentially.
- In the No-OS workflow, I believe the current procedure is to use the TES ADRV9002 software to generate sample-code for a given profile (ie: sample rate / filter) settings and then use the No-OS code here: https://github.com/analogdevicesinc/no-OS/tree/master/drivers/rf-transceiver/navassa
The No-OS code is then modified to point to the variables that are part of the generated TES software instead of using the JSON/Bin files that were specified above.
The source files containing the binaries that TES generates are rather large. In the Argo Navis version (0.21.0) I see a Stream Image (151 KB), an Arm Image (1.19 MB) and a Arm Profile (44 KB) which is much larger in terms of file-size compared to the non-TES Linux IIO workflow.
Questions:
1) If we are designing something that is required to operate at different sample rates for different scenarios, do we need to create profiles for each mode? Or is there an easier approach of creating a single profile that can switch to different rates?
2) Do we need to create a different ARM image (1.19MB) for each sample rate we need to support OR can it be re-used for different rates?
3) If all we're doing is changing sample rate and RF BW with no custom FIR filter, is there a simpler approach we can take without needing to generate several profile binary files for each rate?
We would like to seek ways to reduce binary-file size footprint as much as we can for the various rates we need to support as we are targeting a small-form factor design. We are not working with LTE rates - i know that dynamic switching profile seems to be supported here so long as the rates are of multiples of 2 but that will not apply for our use-case.
Thanks
