<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Writing long characteristic values</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/1917/writing-long-characteristic-values</link><description>Hi,
I&amp;#39;ve the need to write a characteristic value of 65 bytes, from my central device (iPhone/iPad) to a nRF51822 peripheral device, so I was looking at this document for how to implement the write long characteristic on nRF51822. 
 So in my service</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 24 Mar 2014 10:05:53 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/1917/writing-long-characteristic-values" /><item><title>RE: Writing long characteristic values</title><link>https://devzone.nordicsemi.com/thread/8247?ContentTypeID=1</link><pubDate>Mon, 24 Mar 2014 10:05:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6922a160-062e-42d6-9a28-0827a1fdc372</guid><dc:creator>Samuele Forconi</dc:creator><description>&lt;p&gt;Hi Ole,
thanks for your answer and sorry for my late reply, but I was sick.&lt;/p&gt;
&lt;p&gt;Your answer is very well explained, so I managed to get the handle written doing some little modifications to the on_write function and instead of checking the value_handle I setup this code:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;
if(p_evt_write-&amp;gt;op == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW)
{
	if(*((uint16_t *)m_mem_block.p_mem) == p_actrl-&amp;gt;dhc_handles.value_handle)
	{
            printf(&amp;quot;LONG CHARACTERISTIC WRITTEN!\r\n&amp;quot;);
        }
}

&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;And now the program prints also the &amp;quot;LONG CHARACTERISTIC WRITTEN!&amp;quot; on the console.&lt;/p&gt;
&lt;p&gt;Thanks for your support.&lt;/p&gt;
&lt;p&gt;Regards,
Samuele.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Writing long characteristic values</title><link>https://devzone.nordicsemi.com/thread/8246?ContentTypeID=1</link><pubDate>Tue, 18 Mar 2014 14:05:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f08af4c2-9916-4efd-b2da-a49f9b56f954</guid><dc:creator>Ole Morten</dc:creator><description>&lt;p&gt;Your implementation seems correct, but you may have misunderstood somewhat how the conclusion of a long write is.&lt;/p&gt;
&lt;p&gt;In summary, a handle is only included in each Prepare Write Request, and these are not directly given to your application when not using authorization (since they include partial values and are in general not very useful, since they haven&amp;#39;t yet been written). Instead, only the Execute Write is given as an event to the application, and this contains no handle information by spec. Hence, the event that comes to the application is also without handle, but with a specific type; BLE_GATTS_OP_EXEC_WRITE_REQ_NOW (ble_gatts.h).&lt;/p&gt;
&lt;p&gt;At this point, if you want to know which handle(s) were written, you&amp;#39;ll have to manually parse the memory block you gave to the softdevice. The format for this memory is given &lt;a href="https://devzone.nordicsemi.com/documentation/nrf51/6.0.0/s110/html/a01006.html"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Depending on what you want, it may also be an option to just look at the actual value the attribute contains at this point. When you get the write event, the data in the GATT Table have already been updated, be it in the memory you&amp;#39;ve set aside for the block (in case of VLOC_USER), or inside the stack (in case of VLOC_STACK). If the latter, you can get the new value only by using sd_ble_gatts_value_get().&lt;/p&gt;
&lt;p&gt;Part of the reason for doing it this way is as I mentioned above that the partial writes could in some cases be aborted and not committed. Also, as part of one queued write any number of handles could in theory be written to.&lt;/p&gt;
&lt;p&gt;If you need further information on how this works, I&amp;#39;d recommend you to take a close look at MSC you link to, and combine it with the information in the Core Specification about the different requests involved (Volume 3, Part F, section 3.4.6). Please let me know if you need elaborations on something.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>