<?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>Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/24145/synchronization-of-actions-between-different-nodes-in-a-mesh</link><description>Hi, when reading BLE Mesh specs, this paragraph caught my attention: 
 
 Messages may support a delay parameter that indicates a delay between receiving a message and
starting the state transition. This helps when synchronizing actions of multiple</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 14 Aug 2017 11:16:22 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/24145/synchronization-of-actions-between-different-nodes-in-a-mesh" /><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95068?ContentTypeID=1</link><pubDate>Mon, 14 Aug 2017 11:16:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:355b459e-01d0-4ec8-b1dd-d9ab46b05c79</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;I don&amp;#39;t know what you put into the Shockburst term, if you find it misleading?&lt;/p&gt;
&lt;p&gt;Shockburst is getting pretty old by now, and was introduced before BLE was even specified. I think the &amp;quot;burst&amp;quot; part of the name points to the fact that the radio would send short bursts (packets), rather than the older radios where you sent/received a continuous stream and had to assemble/de-assemble the packet manually.&lt;/p&gt;
&lt;p&gt;BLE happens to look a lot like ShockBurst (partly because Nordic was heavily involved in the spec process), and as mentioned except for a minor change in modulation characteristics and a slightly different packet structure, the physical layer is very similar.&lt;/p&gt;
&lt;p&gt;11-12m outdoor range is pretty poor. Assuming you have Nordic devices in both ends you should be able to go further than that, especially if you increase the output power beyond 0dBm.&lt;/p&gt;
&lt;p&gt;If you use a phone to receive the advertisement packet then the receiver sensitivity of the phone makes a difference, and this is outside our control (obviously).&lt;/p&gt;
&lt;p&gt;Best regards&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95067?ContentTypeID=1</link><pubDate>Mon, 14 Aug 2017 06:09:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b46da9bd-5732-4253-9351-ce3b419fda8f</guid><dc:creator>Mitch996</dc:creator><description>&lt;p&gt;Hi then the whole &amp;quot;Shockburst&amp;quot; is kind of misleading isn&amp;#39;t it?&lt;/p&gt;
&lt;p&gt;I was under the impression that typical BLE ad packets goes no further (and rightly so) than 11 or 12 meters outdoor?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95066?ContentTypeID=1</link><pubDate>Thu, 10 Aug 2017 06:55:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9f6771d0-b7a7-4be8-a692-08dcbe665ab5</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Do you mean combining Bluetooth mesh and Shockburst, or using Shockburst only?&lt;/p&gt;
&lt;p&gt;As for range it is more or less the same between Shockburst and BLE. There is a small difference in the modulation, and the packet format is different, but nothing that makes a big impact on the range.&lt;/p&gt;
&lt;p&gt;In a line of sight scenario you can reach 200m, but indoor I would expect significantly lower range.&lt;/p&gt;
&lt;p&gt;Best regards&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95065?ContentTypeID=1</link><pubDate>Thu, 10 Aug 2017 02:03:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:23bb46cd-89f6-4ee1-ab51-75e2dc91c9c0</guid><dc:creator>Mitch996</dc:creator><description>&lt;p&gt;You are right, I&amp;#39;m not there yet, but so far I&amp;#39;m thinking about utilizing the &amp;quot;shockburst&amp;quot; TM feature: find out the &amp;quot;central&amp;quot; (spacially  speaking) node, and assign her with the task of sending out synchronizing bursts periodically. The Shockburst has a max range of 200m, which is more than enough for us.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95064?ContentTypeID=1</link><pubDate>Wed, 09 Aug 2017 10:08:06 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:9b9f7799-8e8b-406e-8afc-5c04f97bcbb5</guid><dc:creator>David Edwin</dc:creator><description>&lt;p&gt;You want a message with ack if you want reliability, you also want to ensure that all motors have got the message before starting up.
You may also want a fallback to cancel and restart if one of the nodes did not ack within your timeout.
The mesh already has a hop count that can be used for re-transmits.&lt;/p&gt;
&lt;p&gt;You can use the mesh for this but since the node count is low (only 6 nodes), it is also possible use a simple scanner/advertiser to achieve this level of synchronization.&lt;/p&gt;
&lt;p&gt;All motors can be started within 20ms of each other with sync either on the 16MHz or 32KHz clocks&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Synchronization of actions between different nodes in a mesh?</title><link>https://devzone.nordicsemi.com/thread/95063?ContentTypeID=1</link><pubDate>Wed, 09 Aug 2017 09:22:35 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:12a5e02c-47d6-401f-aa07-ab94e116a773</guid><dc:creator>ovrebekk</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;The most common way to synchronize activities across a mesh is to establish a synchronized clock, and use that to schedule actions in the future. Then it doesn&amp;#39;t matter how long the packet takes to reach the recipient, as long as it arrives before the scheduled time.&lt;/p&gt;
&lt;p&gt;The &lt;a href="https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634&amp;amp;_ga=2.41693862.501930818.1502269755-1506417192.1497526221"&gt;mesh model specification&lt;/a&gt; includes a mechanism for synchronizing time (see chapter 5 - Times and Scenes), but unfortunately we don&amp;#39;t support this in the current mesh implementation.&lt;/p&gt;
&lt;p&gt;As one of the mesh guys pointed out, if you really need to synchronize motors accurately then a mesh is not really a good option. As you can see from the time sync specification they allow for an inaccuracy in the 10ms - 2.5s range, and there is always a chance that a packet to one of the recipients will be delayed or lost, so getting reliable accurate synchronization below 20ms is probably not realistic.&lt;/p&gt;
&lt;p&gt;Best regards&lt;br /&gt;
Torbjørn&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>