Transmit buffer clear up

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
4 posts / 0 new
Last post
BenjaminDu
Offline
Last seen:1 month 2 weeks ago
Joined:2016-03-14 02:38
Transmit buffer clear up

Hi MT_dialog team,

My application needs instantaneous data transmit between a server and a client(or device and host),some times due to noise or other reasons, the data accumulated in the buffer(the data will not be so useful as not so fresh),and the old data will hinder the fresh data to be transmitted.

I want to know how many data not transmitted in buffer, and how to clear up(cancel the transmission) the un-transmitted data.

Thanks a lot

Device:
MT_dialog
Offline
Last seen:2 months 1 week ago
Staff
Joined:2015-06-08 11:34
Hi BenjaminDu,

Hi BenjaminDu,

I suppose that the buffers that you mention are the low level stack buffers, i am afraid that what you are asking is not possible (and in a way is a violation of the spec), from the time that you ve send data to the stack, you can't just retract them, they are send to the stack and the BLE protocol will take care of the rest, also i suppose that you are talking about notifications, where there is no high level confirmation by the protocol that the device has succesfully transmited the data, this is taken care of low level protocols of the BLE based on the sequence number of the packets. Perhaps you should consider using indications instead of notifications, since in that case the central device is obligated to send a confirmation to the peripheral that the data send are indeed received, so you can just wait from a confirmation from the central before placing fresh data that should be send over, but once you ve send the data towards the stack there is no way to retract them. Additionally there is a plausible way to do the same with the notifications and check if the data are send on the other side, you can check the buffers using the l2cm_get_nb_buffer_available() before and after the BLE_END_EVENT and be aware of how many data have been send through the particular connection interval, but again this is just an idea.

Thanks MT_dialog

BenjaminDu
Offline
Last seen:1 month 2 weeks ago
Joined:2016-03-14 02:38
Hi MT_dialog team,

Hi MT_dialog team,

Thanks and yes,the buffer I mean is low level stack buffers, and if there is no high level call( or function) available to retract the data, then I will find other way to solve the problem.

Another reason why I want to retract the data is as the following :
sometimes, when the master and slave get disconnected due to long distance, but after I put then together, it's very difficult for them to get connected again, I doubt this is because the buffer are full when they get disconnected, so if possible, I want to try if I trtract the data, maybe they can get connectted easily.
因为它是不可能收回数据,我不能try if tetraction can get them connected.
So I want to know, what's the reason why after disconnection while tranmitting data and get separated, it's diffcult to get connected again when they get together.

I think l2cm_get_nb_buffer_available() will be useful and I will try this function.

Thanks again.

MT_dialog
Offline
Last seen:2 months 1 week ago
Staff
Joined:2015-06-08 11:34
Hi BenjaminDu,

Hi BenjaminDu,

From the fact that the devices are having trouble in re-connecting you cannot assume that the buffers are filled with data, i doubt that this is because the buffers are filled with data since when the device is disconnected the buffers are flushed by the stack. I cannot also assume a reason for that, a sniffer log would perhaps be usefull in that case (check if there is a connection but the devices get disconnected due to a malfunction). Most probably the reason for that is that your timeout is very large, so both of the devices, if there is no activity from the other side its takes time before they consider themselves disconnected so you can tackle that using a smaller timeout period, so they are both disconnected faster and the peripheral can start advertise.

Thanks MT_dialog