Any way to reset hvx Tx buffer not losing connection?

RE: Any way to reset hvx Tx buffer not losing connection?

Fanis — Mon, 13 Nov 2017 22:49:22 GMT

I just rearanged code flow with moving out time consuming action from BLE callbacks and it works better.

RE: Any way to reset hvx Tx buffer not losing connection?

Petter Myhre — Mon, 13 Nov 2017 13:29:28 GMT

I'm not sure I understand completely, but can't you just don't send notification if you haven't filled the buffer with new data?

RE: Any way to reset hvx Tx buffer not losing connection?

Fanis — Sat, 11 Nov 2017 07:28:53 GMT

Thank you for your suggestions. In my case connection is established for short periods (1s-2s) and then disconnection is forced by central. 1 packet per connection interval is not a problem, the priority is continous sequence of the buffer in central input. Unfortunately the central requires transfer with notification, so i can't establish stream using indication. I have to find a way to track sequentally every output packet successfully received by the central. I've already tried to just once send a hvx transfer task and wait until i pull up my flag on BLE_EVT_TX_COMPLETE, but with this rapid connection/disconnection it seems to hang the stream. It looks like i schedule one Tx, all works well several cycles until the tranfer couldn't be sent, BLE_EVT_TX_COMPLETE is not reached and i can't start new one. I also pull the flag ON_CONNECTED and ON_DISCONNECTED but i miss something else...

RE: Any way to reset hvx Tx buffer not losing connection?

RK — Sat, 11 Nov 2017 00:53:19 GMT

it's rather hard to work out what your problem is from this description. It sounds to me however like you are filling one large buffer, then sending bits of it in multiple HVX packets. However you are then rewriting the buffer when the first TX complete notification comes in and not after the last one arrives.

If you queue up an HV packet for transmission and it points to a chunk of memory, you can't use, change or update that memory until the TX notification for that packet has been returned to you. Between the sending and the TX received, the softdevice stack really owns the memory.

Sounds like you need two buffers to write your data into. One for the transmission going out, one for the next transmission you're calculating.

If that's not what you're doing then perhaps you can write a better explanation.

And if you only want to send out one HVX notification, then send out only one HVX notification. But you'll only get to send 20+ bytes at a time if you do that.