<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Wireless MCUのトピックBLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
    <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634976#M2200</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am using the FRDM-KW41Z kit to set up a simple BLE Mesh using the examples that came with the kit. I am using the IAR IDE and have set up one module as the commissioner/configuration client and the other as a temperature server. I created a new shell command on the configuration client that calls MeshTemperatureClient_GetTemperature(destination) with destination set to the address of the temperature server device. Below is an example of the terraterm activity when I type my new command:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt; temp get 1&lt;BR /&gt;&amp;lt; Temp Get command sent to 1 &amp;gt;&lt;BR /&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt;&lt;BR /&gt; -&amp;gt; Received Temperature measurement from ID 1: 27 degrees Celsius.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So far so good but it only works about 50% of the time. When it fails I see the following:&lt;/P&gt;&lt;P&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt; temp get 1&lt;BR /&gt;&amp;lt; Temp Get command sent to 1 &amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Which indicates to me that the call to&amp;nbsp;&lt;SPAN&gt;MeshTemperatureClient_GetTemperature(destination) was successful.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Using IAR on the temperature server end I can see that the &amp;nbsp;MeshTemperatureServerCallback() is not being called when a failure occurs. How can I find out where the command is getting lost?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Philip&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 21 Dec 2016 22:47:20 GMT</pubDate>
    <dc:creator>pbartlett</dc:creator>
    <dc:date>2016-12-21T22:47:20Z</dc:date>
    <item>
      <title>BLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634976#M2200</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am using the FRDM-KW41Z kit to set up a simple BLE Mesh using the examples that came with the kit. I am using the IAR IDE and have set up one module as the commissioner/configuration client and the other as a temperature server. I created a new shell command on the configuration client that calls MeshTemperatureClient_GetTemperature(destination) with destination set to the address of the temperature server device. Below is an example of the terraterm activity when I type my new command:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt; temp get 1&lt;BR /&gt;&amp;lt; Temp Get command sent to 1 &amp;gt;&lt;BR /&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt;&lt;BR /&gt; -&amp;gt; Received Temperature measurement from ID 1: 27 degrees Celsius.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So far so good but it only works about 50% of the time. When it fails I see the following:&lt;/P&gt;&lt;P&gt;BLE MESH &amp;gt;&amp;gt;&amp;gt; temp get 1&lt;BR /&gt;&amp;lt; Temp Get command sent to 1 &amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Which indicates to me that the call to&amp;nbsp;&lt;SPAN&gt;MeshTemperatureClient_GetTemperature(destination) was successful.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Using IAR on the temperature server end I can see that the &amp;nbsp;MeshTemperatureServerCallback() is not being called when a failure occurs. How can I find out where the command is getting lost?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Philip&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 21 Dec 2016 22:47:20 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634976#M2200</guid>
      <dc:creator>pbartlett</dc:creator>
      <dc:date>2016-12-21T22:47:20Z</dc:date>
    </item>
    <item>
      <title>Re: BLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634977#M2201</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Phil,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It is possible that some packets are not received due to the environment of the BLE advertising channels where the mesh nodes are operating, but in case of a mesh nwk when you have several nodes (compared to your test with only 2 nodes) it can happen that a node may miss a packet from a relay and still gets the same packet from another relay.&lt;/P&gt;&lt;P&gt;In actual implementation there isn't any acknowledge algorithm/protocol to confirm a reception of a packet and send it again if it is lost, but this could be implemented at application level (combination of ack and retries mechanism similar to 802.15.4 one).&amp;nbsp;&lt;/P&gt;&lt;P&gt;Please note the BT Mesh specification that is under development introduces the concept of reliable and unreliable messages and therefore we are going to have it in Q1'17.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My best wishes for a Happy 2017,&lt;/P&gt;&lt;P&gt;Antonio&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 28 Dec 2016 11:05:57 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634977#M2201</guid>
      <dc:creator>antonioconcio</dc:creator>
      <dc:date>2016-12-28T11:05:57Z</dc:date>
    </item>
    <item>
      <title>Re: BLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634978#M2202</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Antonio,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What BT Mesh specification were you referring to that introduces the reliable and unreliable messages?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Evgeny&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Feb 2017 16:02:59 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634978#M2202</guid>
      <dc:creator>evgenyerlihman</dc:creator>
      <dc:date>2017-02-15T16:02:59Z</dc:date>
    </item>
    <item>
      <title>Re: BLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634979#M2203</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Antonio,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have the same issue, the KW41Z eval boards are sitting on my desk with 10cm distance between them, and i still get lower than expected percentage of successful messages between them. I think the "environment" in the office should give me 100% providing no physical obstacles between the nodes....&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Evgeny&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 10 Apr 2017 13:57:03 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634979#M2203</guid>
      <dc:creator>evgenyerlihman</dc:creator>
      <dc:date>2017-04-10T13:57:03Z</dc:date>
    </item>
    <item>
      <title>Re: BLE Mesh on the FRDM-KW41Z does not always deliver packets</title>
      <link>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634980#M2204</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Evgeny,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2.4GHz is quite a crowded band, almost impossible to get 100% without any acknowledgment mechanism, that anyway can easily implemented leveraging the callback event and a timer.&lt;/P&gt;&lt;P&gt;I was referring to &lt;SPAN style="color: #51626f; background-color: #ffffff;"&gt;Mesh specification from Bluetooth SIG, that is supposed to be ratified in Q3.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: #51626f; background-color: #ffffff;"&gt;Cheers,&lt;BR /&gt;Antonio&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 10 Apr 2017 17:31:43 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Wireless-MCU/BLE-Mesh-on-the-FRDM-KW41Z-does-not-always-deliver-packets/m-p/634980#M2204</guid>
      <dc:creator>antonioconcio</dc:creator>
      <dc:date>2017-04-10T17:31:43Z</dc:date>
    </item>
  </channel>
</rss>

