The first module contains 38.4Mhz XTAL oscillator, The second module contains 0.8Vpp 38.4Mhz TCXO, Transmitting data from first module is received in second module, but sending data from second module always causes SFD timeout error in first module, What would be the reason behind it ?
Hi PREDATOR,
I experienced a problem very similar to yours when I developed my own driver. It was caused by the XTAL trim setting (register 0x2B:0E FS_XTALT). The Decawave driver checks for a saved XTAL trim value in the OTP memory, and if no valid data found it sets XTAL trim to a middle value. In my DW1000 there was no XTAL trim value stored in OTP memory, and this middle value setting messed up the transmission when using 0.8Vpp clipped sine wave output 38.4 MHz TCXO. Removing this middle value setting and leaving FS_XTALT on reset value solved the problem.
If you use the original Decawave DW1000 driver, modify the dwt_initialise() function to not set XTAL trim, or reset the register manually after initialization when using TCXO.
Best wishes.
1 Like
Hi btprg,
We are not setting crystal trimming value , It is already in reset state.
Also using your own driver, not the Decawave?
You probably should on the xtal based device.
I suggest looking at the continuous wave output of your devices to validate they operate at the correct frequencies, with a low enough center frequency offset.
Correct, I have been bitten by this as well. I believe this trim value is based on the reference design using a xtal. I agree this behavior is a confusing and unexpected when using a TCXO, but it prevents designs using a xtal from using incorrect load capacitors. Sadly there is no way for the firmware to know what clock source is used.
Actually ,we’re using a VCTCXO . We tuned VCTCXO to exact frequency of the receiver, the same setup is working perfectly with 3.3Vpp TCXO, But the transmission is corrupted with 0.8Vpp TCXO, Is the amplitude of oscillator has any direct relation with transmitting power?