-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing XTAL with a more accurate one #4
Comments
Firstly - Highly recommended that you program the Pico BEFORE replacing components, that way you'll have indications of a working board (flashing LED/serial output/etc)... 12.0MHz 3V0 - https://www.digikey.ca/en/products/detail/ilsi/i538-2o7-12-000-mhz/13682056 This has a different footprint, we can see that the part should be rotated:
Once the part is placed, add a small 'fly-wire' from small cap near CPU to Pin 4 of the TCXO module. Double check this is not shorted to ground before power-up. Not my best soldering, but it seems to work. Real test will take more time to evaluate it's timing performance. I also realized that I order the WRONG part for a 3V0 (not 3V3) VCC - oh well will try it anyway... Mouser have an equivalent for 3V3, but wants to sell a full real of qty 3000. |
After spending some time digging through DigiKey, I think that this might be the 'Best' replacement... There is also this (much more expensive) 12.8MHz part with really low PPM that will fit on the footprint. The following is a suggestion to modify the Pico PCB, should it ever be relaid: By adding 2 resistor footprints to connect to pin 2 of the XTAL, we could configure the board to take either a passive XTAL or a (user performed modification) TCXO. Only extra one resistor, connecting to ground, would be fitted for mass production. |
I was able to automate the testing of the stock XTAL, where performance is inferred from what the unit determines the 'calibration' value to be. This conclusively shows that the calibration DOES change with temperature. The temp shown is not itself calibrated, but shows first plot at ambient (purple trace before I realized unit(s) were in the sun) and then second plot in the freezer. Note: the fractional part of the calibration value represents modulating the between smallest fractional values of the PIO divider, ie between '1562+(128/256)' and '1562+(127/256)'. So a 'calibration delta' of 1.0, would be roughly equivalent to 2.5PPM XTAL variance. Note: Temp vs Freq will not be linear, it depends on XTAL type. Some plots are 'S' shaped. |
I modified a total of 6 boards with TCXO's, although I struggled with recreating my 'ugly' mod. I actually found it easier to stand the TCXO on end, and fly-wire 3.3v to power it... maybe not mechanically sound, but good enough for now. I'm trying to understand the best way(s) to validate these, on the outset it looks like they are much better than the stock XTAL, but there still seems to be some temperature variance.... This is the one I used: |
At 10'C
At 40'C
I also found that the Hub in my test setup doesn't apparently like the higher temps... as it locked up several times. :-( |
Calibration sheet: So the 'temp shift' in calibation depends on each unit (there may have also been temp variation within the oven), the WORST shift between 10'C and 40'C is 152ppb for 'average vs nominal/null calibration' and the typical is in the 10's of ppb. This is SIGNIFICANTLY better than the shift we saw in calibration with the stock XTAL.... For reference our target is: +/-0.5 frames in 8hrs; ie '8 * 3600 * 30fps = 864000 frames', so for accuracy we'd want '864000.5 / 864000 = 1.000000579' (around +/-0.6 ppm). |
It would seem that the stock XTAL (with current code implementation) is not meeting the timing accuracy required - less than 1frame drift in 8hours.
Fortunately we can replace the XTAL with a more accurate TCXO module. I have 2 candidate parts:
The 2nd is more accurate/precise, but with a slightly different frequency it might mean more work. The Pico's SDK has a override for building at different frequencies, so a custom build of microPython is likely needed. The boot-rom also expects 12.0MHz, so using this part might mean that USB is not functional - and 'we' might have to rely on the SWD interface to program the board.
2nd part is also bigger....
The text was updated successfully, but these errors were encountered: