https://devzone.nordicsemi.com/f/nordic-q-a/28941/att-mtu-20-and-dle-enabled---central-write-issueSDK12 and SD 132 v3. I have my code working for HVX from the peripheral. I can HVX send up to 80 bytes on one characteristic in one call (ATT MTU was set to 83 and DLE negotiated for 83 as well [also tried 87]) and I see it arrive on the central noen-USTelligent Community 13Thu, 04 Jan 2018 20:43:19 GMThttps://devzone.nordicsemi.com/thread/114503?ContentTypeID=1Thu, 04 Jan 2018 20:43:19 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8e48cddc-8661-4ec0-9e86-20a6b6d851b3Jim Dattolo<p>so it was user error as one of the obj files wasn&#39;t rebuilding and that caused the issue. Cleaning the project set things back running!</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/114502?ContentTypeID=1Thu, 04 Jan 2018 20:42:45 GMT137ad170-7792-4731-bb38-c0d22fbe4515:6018592f-aa5e-4e45-9dd7-562127a23ec7Jim Dattolo<p>the problem is that the product has multiple layers of security and app level authentication that gets in the way of debug. The problem actually fixed it self. A file must not have recompiled when I made a change in the Eclipse project. After cleaning everything and rebuilding on one of the steps things just magically fixed themselves. It was too weird only working in one direction like that to not be an evironment problem. Tests are running well now against the code so the transport is solid with the long MTU. - Thanks!</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/114501?ContentTypeID=1Thu, 04 Jan 2018 14:58:56 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2f676430-c81d-4bed-8b3d-8e94d40a0fc9Petter Myhre<p>Maybe you can do a sniff without doing encryption? If the issue is still there without encryption that is.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/114500?ContentTypeID=1Thu, 04 Jan 2018 14:47:14 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c572394c-a26b-4d68-836f-7ea6a9392384Jim Dattolo<p>I don&#39;t see any EVT_WRITE events. I need to instrument the TX_COMPLETE event. I used to use it but there was an issue at one point where I didn&#39;t get one as expected and my state machine locked. I just moved to a main loop queue pumper to keep the TX buffers always full if there were BLE writes to process. I was going to start on the sniffer but it&#39;s a pain due to the encryption as I need to make special builds with known keys (I&#39;m using LESC) I figured I would ask to make sure that there wasn&#39;t some known issue on SD V3 and SDK12</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/114499?ContentTypeID=1Thu, 04 Jan 2018 11:48:26 GMT137ad170-7792-4731-bb38-c0d22fbe4515:7adcb6ae-6681-4f5a-b823-3d9cf3d811ddPetter Myhre<p>Strange. Do you get the <a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v3.0.0/group___b_l_e___g_a_t_t_c___v_a_l_u_e___w_r_i_t_e___m_s_c.html?cp=2_3_1_1_2_2_2_3_5">BLE_EVT_TX_COMPLETE</a> event?</p> <p>You do not get any BLE_GATTS_EVT_WRITE event on the server/peripheral?</p> <p>Have you done a sniffer trace to see what is happening on air?</p><div style="clear:both;"></div>