Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| resources:eval:user-guides:ad-fmcomms2-ebz:hardware:tuning [04 Apr 2017 01:29] – [Oscillators] Robin Getz | resources:eval:user-guides:ad-fmcomms2-ebz:hardware:tuning [22 Feb 2023 15:15] (current) – An error in some calculations David Lacasse | ||
|---|---|---|---|
| Line 17: | Line 17: | ||
| When discussing parts per million (or ppm) stability issues - the size of the actual impact is sometimes is lost. | When discussing parts per million (or ppm) stability issues - the size of the actual impact is sometimes is lost. | ||
| - | The 40MHz crystal on the FMCOMMS2/ | + | The 40MHz crystal on the FMCOMMS2/ |
| This ppm specification indicates how much the crystal frequency may deviate from the nominal value. ±10 ppm is ±0.001%, 18.1ppm is 0.00181%. For a 40.000000 MHz crystal, that means 39.99928 to 40.00072 MHz. When this is multiplied up in the baseband PLL and then decimated down this can mean rather than a nominal output data rate of 30.72 MSamples per second, it can be anywhere between 30.72055296 and 30.71944704 MSamples per second, and a 2.400000000 GHz nominal center frequency might be anywhere between 2.4000432 and 2.3999568 GHz. That's a frequency offset of ± 43.2 kHz. | This ppm specification indicates how much the crystal frequency may deviate from the nominal value. ±10 ppm is ±0.001%, 18.1ppm is 0.00181%. For a 40.000000 MHz crystal, that means 39.99928 to 40.00072 MHz. When this is multiplied up in the baseband PLL and then decimated down this can mean rather than a nominal output data rate of 30.72 MSamples per second, it can be anywhere between 30.72055296 and 30.71944704 MSamples per second, and a 2.400000000 GHz nominal center frequency might be anywhere between 2.4000432 and 2.3999568 GHz. That's a frequency offset of ± 43.2 kHz. | ||
| Line 132: | Line 132: | ||
| * F< | * F< | ||
| * F< | * F< | ||
| - | * F< | + | * F< |
| * FFT bin size (for 16384 samples) = 7.680768 MHz / 16384 = 468.796875 Hz/bin | * FFT bin size (for 16384 samples) = 7.680768 MHz / 16384 = 468.796875 Hz/bin | ||
| Line 160: | Line 160: | ||
| since everything is a known, but PPM, it can be solved by simple substitution. You can also see from that that lots of bins are good, and things that are away from the LO (have a large bin number) will provide more detail to work on. The actual frequency shouldn' | since everything is a known, but PPM, it can be solved by simple substitution. You can also see from that that lots of bins are good, and things that are away from the LO (have a large bin number) will provide more detail to work on. The actual frequency shouldn' | ||
| + | |||
| + | In this example, we : | ||
| + | * send 2401.0000 MHz tone, | ||
| + | * think we have a 40.000 MHz oscillator (which we know is wrong) | ||
| + | * set the LO to 2400 MHz, (have a < | ||
| + | * set the sample rate to 7.68 MSPS (have a < | ||
| + | * do a 16384 point FFT, | ||
| + | * read the peak of the FFT at bin number 2210.166486 | ||
| < | < | ||
| Line 167: | Line 175: | ||
| The more accurate the bin number, the more accurate the ppm offset result will be. You may think a bin number of '' | The more accurate the bin number, the more accurate the ppm offset result will be. You may think a bin number of '' | ||
| - | Once we find the offset in terms of ppm, it is a quick matter of programming the system with the correct oscillator value. In the case of -15ppm offset, that would be 39.999400 MHz, or a value of 39,999,400 Hz to be used to set the value in sysfs. | + | Once we find the offset in terms of ppm, it is a quick matter of programming the system with the correct oscillator value. In the case of -15ppm offset, that would be 39.999400 MHz, or a value of 39,999,400 Hz to be used to set the value in [[/ |
| + | |||
| + | <WRAP box bggreen>< | ||
| + | < | ||
| + | C: | ||
| + | Using auto-detected IIO context at URI " | ||
| + | dev ' | ||
| + | </ | ||
| + | |||
| + | ==== Pluto SDR ==== | ||
| + | |||
| + | To make this easier for ADALM-PLUTO users, the [[https:// | ||
| + | |||
| + | <WRAP box bggreen>< | ||
| + | < | ||
| + | login as: **root** | ||
| + | root@192.168.2.1' | ||
| + | Welcome to: | ||
| + | %%______ _ | ||
| + | | ___ \ | | | / ___| _ \ ___ \ | ||
| + | | |_/ / |_ _| |_ ___ \ `--.| | | | |_/ / | ||
| + | | __/| | | | | __/ _ \ `--. \ | | | / | ||
| + | | | | | |_| | || (_) /\__/ / |/ /| |\ \ | ||
| + | \_| | ||
| + | %% | ||
| + | v0.31-dirty | ||
| + | http: | ||
| + | # **cal_ad9361** | ||
| + | |||
| + | </ | ||
| + | |||
| + | |||
| + | |||
| + | ===== Practical considerations ===== | ||
| + | |||
| + | In the above examples, if you do not account for ADC sample rate offset, you will never be able to get an exact reading. but it might be close enough. For example, if we take the previous example: | ||
| + | |||
| + | In this example, we : | ||
| + | * send 2401.0000 MHz tone, | ||
| + | * think we have a 40.000 MHz oscillator (which we know is wrong) | ||
| + | * set the LO to 2400 MHz, (have a < | ||
| + | * set the sample rate to 7.68 MSPS (have a < | ||
| + | * do a 16384 point FFT, | ||
| + | * read the peak of the FFT at bin number 2210.166486 | ||
| + | |||
| + | And only worry about LO offset, we think the FFT is at 1036015.54 Hz offset from the LO (since we don't correct for 7.68MHz being wrong), and that the actual LO is 36015.54031 Hz off (which gives us a simple -15.0064751302 ppm); and we set the XO correction to 39999399 (which is a small error, but still wrong). | ||
| + | |||
| + | In most practical examples, it would be fine to ignore this when the sampling rate to RF LO frequency is high (in this case 2400:7.68 or 312.5:1). When LOs are low, and sample rates increase, it creates a larger impact, and can't be ignored. | ||
resources/eval/user-guides/ad-fmcomms2-ebz/hardware/tuning.1491262161.txt.gz · Last modified: 04 Apr 2017 01:29 by Robin Getz