Trying to source a 12.288MHz clock for STM32L433

[freeflyer]

I am trying to source a 12.288MHz clock for an STM32L433 but having difficulties finding something.

The clock is required for I2S playback with a bluetooth receiver (BT401).

I have tried using the internal MSI RC to generate the 12.288MHz clock for SAI,  but the BT401 is misbehaving so it might be because the MSI RC clock has too much jitter.

I was wondering if a ASFL1-12.288MHZ-EC-T would be suitable for the clock source for the SAI external clock input....

https://uk.rs-online.com/web/p/crystal-oscillators/2403583

Below is the setup... 

The I2S amplifier (MAX98357A) seems to work fine with the 12.288MHz clock generated by the internal MSI RC and PLL.

But the BT401 either requires multiple attempts to start playing and sometimes plays just a screeching sound for a few seconds then stops.  So I need to rule out whether the issue is caused by clock jitter by trying a more accurate clock source.

I am currently using the STM32L433 Nucleo board which has a footprint for an external HSE crystal, but I cannot find a crystal for that footpring with a 12.288MHz frequency.

The ASFL1-12.288MHZ-EC-T seems to be an all in one device, you just provide power and it generates the output clock.  So its not like a crystal which needs a special drive circuit ?

I have read the application note AN2867 Recommended resonators for STM32 MCUs/MPUs, but its complicated and just confused me.

[freeflyer]

That thought had crossed my mind the other night and I was consdiering implementing it, but the situation has changed as explained in my latest post (BT401 now working as a slave)

[freeflyer]

Due to the issues I was having using two different clock sources (i.e. BT401 as master to the STM32 SAI block A as slave receive / STM32 SAI block B as master transmit to the amplifier) I reverted back to the original configuration where the BT401 is slave and the STM32 is master using MSI as the clock source and the BT401 is now behaving !

I have not changed anything, other than moving jumper wires around on the development board setup when I was testing differnt configurations. 

It does concern me that I dont know why it didnt work but now it does, I would prefer to have known what the issue was and have a fix. 

So after all this effort the BT401 is now behaving.  One positive I guess is that I've learnt some new things and also found a bug in CubeMX regarding the external SAI clock.  Should this bug be reported so it can be fixed in future releases ?

When I design the PCB I plan to design it so that I can fit an external crytsal for HSE or an oscillator for SAI external clock, just in case I have issues with the MSI in the future.

Thankyou to everyone for your support, it’s greatly appreciated especially at this time of year.

PS.  Regarding the "fine and /stuttered" sound and trying a simple sync... if it was out of sync then wouldn't this be the case during the enitre playback session ? i.e. it would always be out of sync, not change from being in sync to out of sync ?  And vice versa, if it was in sync it would remain that way for the enitre playback session ?  I don't understand how it would change from being in sync to being out of sync during a playback session.  I could understand a sync issue each time playback is started, but not during a playback session ?

[AScha.3]

>if it was out of sync then wouldn't this be the case during the enitre playback session ? i.e. it would always be out of sync, not change from being in sync to out of sync ?  And vice versa, if it was in sync it would remain that way for the enitre playback session ?

Basically two different clocks are always out of sync.

But : crystals differ typically on the order of 10 exp -5 , so "not much" ; so about 1 sample in 100000 ;

if we have 2k samples/block, this gives about 2000 * 100000 , at 48k/s -> 4166 sec, or about 1 hour.

So if we do a basic "sync" , by checking which rx bloch is filled ready and use this to play, and so on,

we play "perfect", until the drift is bigger than a buffer and we play (by the simple sync method) one buffer double or miss one, depending on which clock is faster than the other. 

So we could expect: about once per hour we get a "click" or dss-dss , by playing same buffer twice or miss one.

No big problem, if this music or whatever, is not important. But the inserted voice would be always perfect, as we are master here. 

Understand now ?

+

Without the "sync start" , it would be random: playing some time the "right" buffer and same time the "wrong", thats just getting new data and so is more ugly noise, than music. So if this changes every 20 secs or so, it shows, the two clocks are quite different and have to be closer. With the "sync start" , it would give a "click" or similar every 20 secs then, not too bad, but also not really good.

[MM..1]

Maybe to end litte explain A2DP. In basics is async packet protocol. Sender prepare packets for recevier in compressed audio codec and send care to timing decoder can unpack and play it for example 48k. And here start adaptive correction because never sender and player have perfect equal clocks. Then if receiver is slower sender wait little or if limit for this is over stop play. Same , but worse situation is if receiver MSI is quicker , then phone and coder decoder and air transfer need go speed up , but this maybe isnt always possible = limit .

Every phone use different codecs and limits based on sw ... For example 20ppm oscilator is perfect for it, but MSI is 1000x worse.

[freeflyer]

Thanks AScha.3,

What I dont understand is when you say "two clocks are quite different"

The 24MHz crystal fitted on the BT401 is 10ppm...

https://www.aliexpress.com/item/1005010470882406.html?spm=a2g0o.store_pc_home.promoteRecommendProducts_2011698119794.1005010470882406

The 12.288Mhz oscillator (ASFL1-12.288MHZ-EC-T) I was using is +/- 50ppm...

https://docs.rs-online.com/22cb/A700000008748836.pdf

Does this mean the 12.288Mhz oscillator I was using was not accurate enough ?

[AScha.3]

To see whats really going on, you have to measure it; so have the setup, that made the 20sec loop ;

maybe just with a scope, counter function ON ; (the Rigol has it..);

then check the I2S word clock from BT401, and the local I2S word clock from L433 as master (on its own clock);

then we know... 

- the perfect word clock  should give 48000 Hz .