ANT Forum

We have ARM7 based processor, which communicates with cc2571(ANT) via SPI.

After powerup the processor successfully sends three configuration commands: setnetworkkey, assignchannel, setchannelid. We get no_errror responses.

Finally openchannel command is sent to ANT, but here ANT stops communicating over the SPI. The pin neccessary for SPI handshake - 'SEN' stays inactive forever (ANT is holding this pin high - disabling further communication).

What could be the problem? The digital part of the ANT seems to work ok, perhaps it is something wrong with analog - rf design?

We tried different timings, and numerous configurations but no success.

Any ideas would be most apperciated.

Here is the typical configuration we use:
cc2571 Configuration:
Network number: 0
Network key: 0,0,0,0,0,0,0,0
Channel number: 0
Channel type: 0x00 (slave)
Device number: 49
Device type: 1
Transmition type: 1
Channel frequency: 66
Channel period 8192


BR uros vovk      

Hi Uros,

Can you send timing diagrams of your SPI implementation when the OpenChannel command is sent and the SEN line starts being held high?
Was the CC2571 reset after power up?
Were there success responses after each configuration command was sent?
Another configuration which would check if your slave can receive wireless ANT messages would be to wildcard your device number, device type, and transmission type by setting them to 0.

Best regards,
Harrison      

Hi Harrison

To answer your questions first:
1.Can you send timing diagrams of your SPI implementation when the OpenChannel command is sent and the SEN line starts being held high?
U>> Not at this point. Would have to move to another lab/location for this, solder pins etc.

2. Was the CC2571 reset after power up?
U>> Yes, first by HW pin and later by SW reset command prior to all other commands.

3. Were there success responses after each configuration command was sent?
U>> Yes, except from the last problematic openchannel cmd.

4. Another configuration which would check if your slave can receive wireless ANT messages would be to wildcard your device number, device type, and transmission type by setting them to 0.
U>> Tried this already, but no help.



Now, we also tried calling the initCwTestMode(0) and setCwTestMode(0,66) as described in the manual.
ANT chip stops responding(right after inicwtestmode call) in the same way as for openchannel cmd.

I am thinking that turning on the radio internally confuses the ant chip somehow.

BR uros      

Hi Uros,

Can you describe the format of the messaging you are using to communicate with the CC2571?

A timing diagram would be the most accurate way of assuring the communication is behaving correctly. Also to confirm if the CC2571 is returning a proper open channel confirmation message.

The radio under normal operation and with proper layout should not affect the Host/ANT messaging.

Best regards,
Harrison      

Hi Harrison

Thank you for your answers.

Currently, we are waiting for HW redesign, which should have flawless RF part. Original version had really poor RF part.

One thing I noticed was that replacing the ANT's quartz with one of much lower frequency (by weird mistake) had the effect that all commands go trough ok, and ant ends in the 'searching' status after calling the openchannel cmd. It is followed by search timeout after 30sec.

The RF seems to matter.

Also we changed the communicatio channel to UART.
I will get back to you on my results in a week or so ...

BR uros      

uros wrote:

Hi Harrison

Thank you for your answers.

Currently, we are waiting for HW redesign, which should have flawless RF part. Original version had really poor RF part.

One thing I noticed was that replacing the ANT's quartz with one of much lower frequency (by weird mistake) had the effect that all commands go trough ok, and ant ends in the 'searching' status after calling the openchannel cmd. It is followed by search timeout after 30sec.

The RF seems to matter.

Also we changed the communicatio channel to UART.
I will get back to you on my results in a week or so ...

BR uros

Hey UROS,

We actually had the same error it turned out to be the oscillator. It was the 24 MHz osc. The communication will work fine with the part up until the channel is opened.