How data is sent

[ell_pass]

As far as I can see, when sending data via Bluetooth, the data is first stored in the buffer and then sent out together when the buffer is full. Is this the right idea? But now I want to implement real-time data transfer, is it possible to not use this buffer?

Here is how I send the data.

void ble_write_thread(void)
{
	int err = 0;
	uint8_t dummy[244];

	/* Don't go any further until BLE is initialized */

	k_sem_take(&ble_init_ok, K_FOREVER);
	k_sem_take(&ble_button_start,K_FOREVER);

	k_timer_start(&m_throughput_timer, K_SECONDS(1), K_SECONDS(1));

	memset(dummy, 0xAA, sizeof(dummy));

	for (;;) {
		/* Send as many notifications as possible to test the throughput
		 * of the connection. 
		 */

		dummy[0]++;

		err = bt_nus_send(NULL, dummy, m_nus_max_send_len);
		k_sleep(K_MSEC(2));
		if (!err) {
			m_total_num_bytes += m_nus_max_send_len;
		}
	}
}

K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL, NULL, PRIORITY, 0, 0);

[ovrebekk]

Hi 

the data is first stored in the buffer and then sent out together when the buffer is full. Is this the right idea?

Not quite, the data will be sent as soon as possible, which normally means on the next connection event. 

In a Bluetooth LE connection it is always the central that starts communication, by sending a packet at a fixed rate set by the connection interval. 

If the peripheral has data in the buffers when the packet from the central arrives, it will then include the first packet in the buffer when it responds to the central. 

If the peripheral has multiple packets in the buffer it will set a bit in the packet header telling the central that is has more data to send. In this case the central and peripheral can exchange multiple packets back to back without having to wait for the next connection event. 

In other words the peripheral to central latency is mainly determined by the connection interval, and you should scale the connection interval according to your application requirements. 

The minimum connection interval supported by the specification is 7.5ms, while the maximum is 4 seconds, and it is worth mentioning that it is the central that has final say regarding which connection interval to use (many mobile phones for instance will not allow you to go as low as 7.5ms). 

Best regards
Torbjørn

[ell_pass]

Hi, 

Now there is a piece of DK that needs to receive data and forward the received data at the same time, and I want to make the transmission as real-time as possible. But in reality, what is observed with sniffer is that there is a long delay after a period of normal data forwarding. 

I'm wondering if it's because a DK has only one antenna and can't send and receive data at the same time? 

Is there something that can be done at the software level to enable real-time forwarding of data?

[ovrebekk]

Hi 

ell_pass said:

Now there is a piece of DK that needs to receive data and forward the received data at the same time, and I want to make the transmission as real-time as possible. But in reality, what is observed with sniffer is that there is a long delay after a period of normal data forwarding. 

How big is your connection interval, and how long is the delay that you observe?

ell_pass said:

I'm wondering if it's because a DK has only one antenna and can't send and receive data at the same time? 

It is true that the nRF radio can not send and receive at the same time, it will switch rapidly between TX and RX under normal operation. 

Architecturally you can't do anything with an incoming packet until you have received the full packet into RAM, checked if the CRC is OK, and then triggered the corresponding event that signals to the CPU that a new packet is ready. Then you can make the decision what to do with the packet, such as forwarding it to someone else. 

ell_pass said:

Is there something that can be done at the software level to enable real-time forwarding of data?

It is impossible to forward the data without any delay, the question is how much delay you can accept? 

In other words, what is your definition of 'real time'?

Is using Bluetooth a requirement, or would using a proprietary protocol also be an option?
Then you have more flexibility regarding packet timing, but since you are not following a standard anymore you are limited to using Nordic devices only in your network. 

Best regards
Torbjørn

[ell_pass]

ovrebekk said:

How big is your connection interval, and how long is the delay that you observe?

The connection interval is 7.5ms, but the delay that I observed is more than 80ms.

ovrebekk said:

It is impossible to forward the data without any delay, the question is how much delay you can accept? 

I want to be able to send 1056 bits of data in 4ms.

If I cannot modify the rules for sending data at the software level, can I modify the protocol at the link layer? Does your company have an interface that can be provided for us to modify the link layer protocol?

[ovrebekk]

Hi 

ell_pass said:

The connection interval is 7.5ms, but the delay that I observed is more than 80ms.

If you experience such a large delay then either you must have a very poor link, or there is something in the application that is holding up the processing and forwarding of data. 

Have you made sure that both the links have a connection interval of 7.5ms? 

Is the relaying device the central for one of the links and the peripheral of the other? 

ell_pass said:

I want to be able to send 1056 bits of data in 4ms.

That would be 132 bytes, which fits in one packet, but sending it in 4ms can not be guaranteed when you have a connection interval of 7.5ms. Still, a delay of 80ms points to something else being the issue rather than just the connection interval. 

ell_pass said:

If I cannot modify the rules for sending data at the software level, can I modify the protocol at the link layer? Does your company have an interface that can be provided for us to modify the link layer protocol?

There is an open source controller in Zephyr which can be modified at will, but if you do that you will no longer be Bluetooth compliant. 

If being Bluetooth compliant is not a requirement I would recommend doing something proprietary instead. Then you can get around a lot of the complexities of the Bluetooth implementation, and implement a smaller and more application specific protocol. 

Best regards
Torbjørn