- THIS IS ANT

Username		Password		Remember Me?	forgot password?

08 January 2016 02:21 PM

r3t5h5 Newbie

Total Posts: 4

Joined 2016-01-08

Hello, I am using burst transfer in a Auto Shared Channel implementation.
The master make a polling and the slaves responds with burst transfer.

However I get an unexpected behavior:

master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_A, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_NEXT_DATA_BLOCK: I do nothing

master does not receive anything.
master send requests to other slaves ...


master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_B, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_TX_START and then EVENT_TRANSFER_TX_COMPLETED

master receive the burst transfer (burst_data_A)
master send requests to other slaves ...


master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_A, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_NEXT_DATA_BLOCK: I do nothing

master does not receive anything.
master send requests to other slaves ...


master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_B, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_TX_START and then EVENT_TRANSFER_TX_COMPLETED

master receive the burst transfer (burst_data_A)
master send requests to other slaves ... 

Is this behavior correct?

Why the packet "burst_data_B" is always "lost"? Should not I receive it on the next polling cycle?
What I can do to receive it?

At the moment I made a dirty fix by sending two consecutive request from master to each slave and by sending the same burst packet two times like this:

master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_A, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_NEXT_DATA_BLOCK: I do nothing

master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_A, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_TX_START and then EVENT_TRANSFER_TX_COMPLETED

master receive the burst transfer (burst_data_A)
master send requests to other slaves ...

master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_B, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_NEXT_DATA_BLOCK: I do nothing

master send request (ack) to slave 1
master receive EVENT_TRANSFER_TX_COMPLETED

slave 1 receive EVENT_RX. I call: sd_ant_burst_handler_request(0, 16, burst_data_B, (BURST_SEGMENT_START | BURST_SEGMENT_END));
slave 1 receive EVENT_TRANSFER_TX_START and then EVENT_TRANSFER_TX_COMPLETED

master receive the burst transfer (burst_data_B)
master send requests to other slaves ... 

But this solution is not optimal and results in an additional polling cycle.

20 January 2016 08:57 AM #1

Harrison Administrator

Total Posts: 745

Joined 2012-09-14

PM

I'm not sure what the timing of your messages are, but you must queue messages before the polling cycle occurs, if you queue just after the master polls the slave, the message will try to go out on the next channel period instead.

Another issue may be that the burst message is changing the slave's address, as if a burst fails, the final message left in the buffer which was unsent can change the slave address accidentally.

20 January 2016 11:10 AM #2

r3t5h5 Newbie

Total Posts: 4

Joined 2016-01-08

PM

Thank you Harrison for your reply.

I am using an ANT period of 16Hz, but this behavior is re-producibile at every frequency, I tested it down to 2Hz.

Each 8-byte packet of the burst message has the shared address set. Moreover, to be sure, I set again the address with a broadcast message if I get a TX failed event on the slave.

To me, it looks like the second burst message (the one that I send at the second polling request) is not queued at all. Is it a limitation of the SDK?
I am using N548M4CB modules with softdevice S210 v4.0.1 for the slave, and S310 v2.0.1 for the master.

Is it correct that I receive the EVENT_TRANSFER_NEXT_DATA_BLOCK even if I use (BURST_SEGMENT_START | BURST_SEGMENT_END) in the sd_ant_burst_handler_request() ?

03 February 2016 01:53 PM #3

Harrison Administrator

Total Posts: 745

Joined 2012-09-14

PM

Would you be able to post (or PM) your project, or at least the minimum code required to run your project with the burst messaging? The expected behaviour would be that the burst message goes out on the next channel period once the buffer is loaded.

What is the size of the burst queue vs the size of the buffer? You should not be seeing the EVENT_TRANSFER_NEXT_DATA_BLOCK message unless these differ.

04 February 2016 11:38 AM #4

r3t5h5 Newbie

Total Posts: 4

Joined 2016-01-08

PM

I made some modification on the auto shared channel example to reproduce the issue.

The code is attached.

File Attachments

nRF_examples.zip (File Size: 399KB - Downloads: 532)

01 March 2016 09:28 AM #5

r3t5h5 Newbie

Total Posts: 4

Joined 2016-01-08

PM

Any clue about how to solve the issue?

04 March 2016 11:23 AM #6

Harrison Administrator

Total Posts: 745

Joined 2012-09-14

PM

Hi,

Do you ensure you've queued up a new message only after the message has succeeded or failed? That wasn't quite clear after trying to run the example, (couldn't get the master example working so we substituted ANTware II), but it looked like the buffer was loaded with a new message before the previous one had been tried.

ANT Forum

burst sending behavior

File Attachments