Hi, we recently ran into problems when operating the STM32WLE5CCU6TR (LoRaWAN sensor) in combination with a TCXO featuring digital compensation => data errors. Anyone who knows of this problem?

[GNeyn.1]

..

[Tesla DeLorean]

Which part specifically?

Does it work in point-to-point mode with test firmware?

Does it work if you use a regular TCXO?

How are you controlling the TCXO compensation?

[GNeyn.1]

Well, this looks like a normal TCXO (3225 package); the thermal compensation is integrated , but apparently this compensation circuit can be analog or digital. Analog is hard to find these days because of shortage in raw material (AKM), digital is probably cheaper, but works with (tiny) discrete compensation steps.

The device works perfectly with a TCXO featuring analog compensation and also using an external clock generator.

Example of the TCXO with digital compensation: STC32K30P48-32.000M (https://suntsu.com/wp-content/uploads/2021/01/STC32K-Series.pdf)

[Tesla DeLorean]

Ok, Have you looked at the clock signal with a modulation domain analyzer?

[GNeyn.1]

No, we logged the clocksignal using a spectrum analyser (zero span, 30Hz res. BW) and see discrete steps; one of these 'steps' within an active transmission leads to CRC errors on the receiving side.

We're quite sure aboute cause & effect; would be good to hear if someone experienced the same or can explain exactly why this type of TCXO is incompatible with the LoRa Xcvr-HW.

[GNeyn.1]

The exact magnitude of the step has not been identified (we don't have the equipment available), but the TCXO is spec'ed for 2ppm and I'm sure it operates within spec so it's probably a sub-ppm shift.

All measurements took place in a lab-environment; the TCXO is positioned next to the xcvr, which means the compensation of the TCXO is caused by self-heating (PA).

Indeed, milling could reduce this effect, but it will not guarantee error-free operation in the field.