CYBLE-012011 ECO cap trim disagrees with KBA

[Renate]

The CYBLE-012011 BLE modules uses digitally tuned trimmer caps on the xtal to be on frequency. The example projects leave you with values of 0x2d6a (8.2pF, 14.3 pF) which by my measurements is way off by +100 ppm. There is a KBA that tells you to make it 0xbcbc (17.8 pF, 17.8 pF) which by my measurements is off by +19 ppm. https://community.infineon.com/t5/Knowledge-Base-Articles/ECO-Capacitance-Trim-Values-for-EZ-BLE-Mod...

I'm using the raw PPS off a locked GPS (not a GPSDO) to gate the 24 MHz and measure the frequency. I've got three brand new CYBLE-012011 on completely different layouts and they all measure exactly +19 ppm hot using the recommended 0xbcbc. I find that 0xd9d9 (20.7 pF, 20.7 pF) gets them right around 0 ppm. Even with jitter a locked GPS PPS should give you significantly less than 1 ppm error.

SInce the KBA is from 4 years ago was there a change in the xtal in the module? I notice that some other modules have a recommended 0xd0d0. In any case, 2 x 20 pF on a xtal seems like a lot to me.

Could someone with a calibrated frequency counter double-check my results?

[Yugandhar]

Hello,

Is the frequency measured by bringing out through a buffer on a GPIO or directly on XO or at RF ?

Thanks,
P Yugandhar.

[Renate]

I'm measuring by taking the 24 MHz HF clock from the ECO into a timer/counter. I have the "Period" (bad name, "Top" or "High" would have been better) set to 65535 which I think (please correct me) makes this a 2^16 counter. 24 MHz for one second is 24,000,000 cycles, modulo 2^16 = 13824. So I capture every second on a pin fed by the GPS PPS, subtract the previous capture, subtract 13824 and I have the number of cycles it has gained/slipped in one second. Divide that by 24 (skipping the Mega part) and you get ppm. The raw number of cycles gained/slipped is very consistent, bobbing up and down one, as to be expected from unsynchronized things. The only way that I think that I could be totally off would be if the timer/counter wasn't dividing 2^16.

[Yugandhar]

Hello, 

Could you please let me know which clock is giving to the timer ? I would recommend you to measure the ECO clock with a frequency counter. 

Thanks,

P Yugandhar.

[Renate]

I'm using the 24 MHz HF clock fed from the ECO. I know it's the ECO because I can adjust the ECOTRIM and it follows.

I don't have a frequency meter. Even if I did the calibration would be an uncertainty.

By using a GPS PPS I'm using a standard locked to the NIST time standard. I could even use a regular PC using NTP but I'd have to sample and average for much longer as the jitter/uncertainty is greater than the 60 nS or so with GPS.

Unless you can tell me exactly how my methodology is wrong I'll have to go with it. A $25 GPS module is cheaper and more accurate than a frequency meter. It is also easier to use a GPIO for 1 Hz than 24 MHz.

[Renate]

As I said, the only part that I was unsure of was whether 65535 as "PERIOD" meant a divide by 2^16 counter.

24,000,000 divided by 2^16 gives 366 and a remainder of 13824

24,000,000 divided by 2^15 gives 732 and a remainder of 13824

24,000,000 divided by 2^14 gives 1464 and a remainder of 13824

I tested using "PERIOD"s of 65535, 32767, 16383 and they all gave the same results, which means that they are truly 2^16, 2^15, 2^14. If I had made an "off by one" error they could not have all returned the same results. Yes, I tried other "PERIOD" values like 16384 and they returned results that were far off.

[Renate]

I hate to see this topic languish when I've verified this on three different layouts. Everybody has come back with advice but not a single person has actually measured anything.

Ok, to get a 24 MHz output, you have to use "Routed1", you can't route "HFClk". So I have a 24 MHz output now. I still don't have a frequency counter, but I do have a calibrated frequency generator. I built a one transistor mixer and fed it into a headphone. Using the datasheet recommended 0xbcbc for CAPTRIM I find that it nulls at 24.000450 MHz, 450 Hz too high, which divides down to +19 ppm, exactly the same as I've measured on three layouts already. I can set the generator for 24.000000 MHz and use the pushbuttons on my layout to increment the CAPTRIM. The beat tone goes down and down and finally nulls at a CAPTRIM values of 0xd9d9. This is exactly the same results as using the CYBLE internal counter and GPS.

Could somebody actually measure a recent CYBLE-012011 to see if the numbers agree? Or even measure anything. It seems silly to perpetuate this 0xbcbc if that's not the right value. For me, I'm using 0xd9d9, but I'm sure going to check new shipments for frequency.

[Yugandhar · Accepted solution]

Hello,

According to CYBLE-012011 24M crystal spec, the frequency tolerance is +/- 20 ppm, it means that even though our BLE silicon contribute zero tolerance, the total system tolerance we can promise will be  +/- 20 ppm. 0 ppm for all the BLE module is impossible even though if got 0 ppm for one module.

According to BLE spec, the radio frequency tolerance shall not exceed +/- 150K, it is about  +/-60ppm, our module meet the BLE spec

Then we do not need update the KBA value since we did not see any BLE communication issue caused by 24M clock.

Thanks,

P Yugandhar.