CC1110-CC1111: Syncing problem between Master and slave in I2S communication

Jack,

Are you performing over the air tests or do you have a RF cable between the two boards. I suggest performing tests using a cabled setup first. This helps you separate packet loss issues with other software issues.

Regards,
/TA

One very important issue is to make sure that you are testing at a frequency that is not used for mobile phone services. I believe the default operation for this software is 902-928MHz (targeting US operation). However if you are performing testing outside of the US, you will need to modify the frequency of operation to reflect your regions ISM bands.

If you are testing on the same frequency as the mobiles phone service in your area, the CC1110 will not see a "clear channel" and therefore they will not transmit or they will have very high error rates.

Regards,
/TA

thank you for responding ,i'm performing air tests and i currently don't have RF cable to link them,In the setup the the problem is solved when i change the I2SCLKF1 = 0x59 to I2SCLKF1 = 0x57 and then back to I2SCLKF1 = 0x59 using manual buttons.I think the problem is a synchronization issue quoting "Application Note AN069 "

Synchronization
An additional complication can arise due to the fact that the oscillators on the transmitter and
receiver are not at precisely the same frequency. This causes the received packet to
occasionally arrive too soon or too late; when the software detects that this will happen, a few
of the samples (18) are skipped in order to re synchronize the receiver to the transmitter. See
Figure 5. In this figure, ‘A Valid’ indicates that data in the ‘A’ buffer is valid; similarly, ‘B Valid’
indicates that data in the ‘B’ buffer is valid. A buffer becomes ‘invalid’ while data is being
moved from the RX buffer and unpacked into Buffer A or buffer B – about 200 usec. ‘Using A’
and ‘Using B’ indicate that the receiver is currently ‘playing back’ data in the A or B buffers,
respectively. In the first case (‘Good’), buffer A becomes valid 846 usec before it is used. In
the second case (‘Poor’), the receiver’s oscillator has drifted relative to the transmitter’s, such
that buffer A is received 3.9375 msec before it is used. In the third case (‘Bad’), buffer A is
received 4.7835 msec before it is used. Notice that buffer B now becomes invalid while it is
being used; a ‘Bad’ situation indeed. To correct for this, the software will ‘skip ahead’ 18
samples to re position the ‘valid’ and ‘using’ timings.

I can't sync the master and slave audio automatically when I correct I2SCLKF1 values manually it gets perfect and speech is great,how can I sync the master and slave ?

Jack,

Can you use more accurate clocks, maybe perform a calibration of the clocks before you start sending audio data. I think having the clocks better than 3-4ppm is a good starting point.

Regards,
/TA

thanks I will check that ,Can you help me with understanding the logic of the following code from two way audio communication code example "CodecEVM_TwoWay_CC1110_8kHz8bits"
here how can one arrive in "bad zone" and "good zone" values like 0x80,0x9C,0x10 and 0x5F.simply put how can i get my bad and good zones values any mathematical relationship between them and clock timing,I have tested a ton of them and no improvement in the performance

if (frametime > 0x80 && frametime < 0x9C) // if in the so called 'bad zone'
I2SCLKF1 = 0x57; // speed up the I2S bit clock

if (frametime > 0x10 && frametime < 0x5F) // if in the so called 'good zone'
I2SCLKF1 = 0x59;
from my testing I found that the good zone and bad zone are deviating and I can't get a precise point using trail and error methods.