Use of twi_manager with Ant

[bgarrood]

I am using the TWI manager to schedule transactions with a number of sensors, over two seprate twi instances, and then sending that data over Ant.

The twi manager scheduling is done on timer which fires every 10ms,  We are sending data over Ant at 80Hz.

The problem is that at this rate of data acquisition I am getting a large drop-out rate, of around 10%, i.e. my receiver only receives 90% of the transmitted packets.  If I remove the twi scheduling then this goes down to less than 2% drop-out rate.

Therefore I think the twi manager is somehow interfering with the ant events.  I have tried different settings of the .intterupt_priority property of the nrf_drv_twi_config_t object I am using but without any change in dropout rate.

Can anyone tell me how to avoid interference between the twi manager and ant?

Is there another way that I should be going about this?

[Kenneth]

Hello,

Is this using your own PCB or an nRF52-DK? What gpio# have you used for the TWI instances? What pull up resistors have you used?

My first assumption is that if you are using pins close to the ANT pin, then this may affect the radio. For instance check out ("GPIO usage restrictions"-chapter in product specifications):
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/pin.html?cp=2_1_0_3_2#concept_rfc_x1z_2q 

Best regards,
Kenneth

[bgarrood]

Hi Kenneth,

Thank you for that.  

I am using my own PCB where the nrf52 is on a dynastream D52M D2M8IA board.

I use pins 2,3,4,5 for the two TWI instances, in order to steer clear of the radio.  I am using the internal pull-ups on the nrf52 chip.

I believe the issue is software rather than hardware.  Would yuo expect this sort of problem using twi manager with ant?  Previously I just used twi master in blocking mode and that was causing big dropout issues due to the twi blocking the ant events.

Thank you
Barney

[Kenneth]

Hi Barney,

"Previously I just used twi master in blocking mode and that was causing big dropout issues due to the twi blocking the ant events."

That should not be possible, because all ANT radio events are occurring on higher interrupt priority, are you somehow disabling all interrupts here?

What kind of range are you experiencing here? 

Best regards,
Kenneth

[bgarrood]

Hi Kenneth,

No, I am not (as far as I am aware) disabling interrupts.  

Does the TWI read take place entirely in hardware when using the twi manager schedule method?  Is there any way it can block if reading is happening at the same time as ant radio?

Range makes no difference - whether it is right next to the receiver or 1m away I get the same drop rate.

Many thanks

[Kenneth]

bgarrood said:

Does the TWI read take place entirely in hardware when using the twi manager schedule method? 

Yes and no. There is no dependency or resource conflicts between the radio and twi peripherals that may explain your issue, exception is the GPIO usage restrictions"-chapter in product specifications. This means that a twi transfer may occur during a radio event with no issue. That said, the twi transfer will create some noise, and if for instance you are using a module, it is especially important that you have followed the guidelines from the module manufacturer in terms of placement, grounding, and power routing, to prevent digital noise to influence analog performance. Using a nRF52-DK for comparison may be a good idea to isolate if the problem is hardware related.

It is possible for software to prevent the softdevice stack to execute as planned, either by disable interrupts, or the twi transfer is executed from an interrupt with high priority.

[bgarrood]

Understood.  Thank you Kenneth.

Is it possible that I am just asking too much of the chip?  I am running the twi sampling loop at 100Hz, and streaming over ant at 80Hz (i.e. 80 Ant packets per second).

Otherwise I will try looking at the DK.

I have followed all guidelines on circuit layout etc..

Thank you for your help.