ANT Forum

Hi All,

I read the page (with the video) about the practical mesh lighting system:

http://www.thisisant.com/news/ants-practical-mesh-network-solution-simplifies-home-automation

What I do not quite understand from this video and the article are a few things:
1) He mentions that ANT is a mesh enabled protocol though the auto shared channel is a Star topology if I understand it correctly, how is the system he describes a mesh (practical or connected star?)
2) He mentions that multiple masters can connect to this shared channel. Does he imply that the slaves have all 8 channels configured to listen for masters? New masters would check which channels already have a master then start a 'clean' channel?

I read the ANT protocol docs and they seem to state that there is no auto-configured message relaying in a shared channel. Lines like "ANT can connect to 65k lights" is all very nice but isnt that IF and only IF the master can reach all of them on that auto shared channel?

Could someone please clarify this for me? I want to create an automatic meshing system similar to the auto shared channels but with smart connecting to get an efficient and redundant mesh. If what he says is true, and his simple shared channel is ALSO meshing, I'd be reinventing a wheel.

Regards,

Alex      

Hi AlexDM0,

Thanks for your questions!

The solution demonstrated in this video was created to be a demonstration that would work in a tradeshow environment approx 1 year ago. The purpose was to show that ANT can be in used in home automation, and to help people visualize the end result. Changes would be needed to take this from a trade floor demo (designed to illustrate the technology's capabilities and potential uses) to a final solution.

Having said that, the demo application has been further developed to show how to handle some of the missing pieces in the original application.

So, to specifics:

In ANT, a shared channel is different to a normal star topology in that it uses just one synchronous channel on the master device to connect to many other devices. You are correct that these devices do all need to be within range of the master device. Being on one channel allows all the connected devices to be commanded using the same message - making it much simpler to get the lights to all turn on at once (for example). The shared channel also uses addressing so that the master can poll each shared address, allowing each slave to reply to the master in turn (and avoiding data collisions). A shared channel can use a 1 or 2 byte address field - hence up to 250 or 65k devices can connect to one shared channel. The demo uses 1 byte addressing as it seemed unlikely that we'd need to control more than 250 lights within the range of the hub (the master device in this system).

In this demo, an auto-shared channel (where the lights handshake with the hub to obtain their address automatically) is used to connect a hub to the lights.

In addition the hub opens another independent (non-shared) channel broadcasting its capabilities and information about the lights. This channel is found and connected to by one or more remote control device(s) (in this demo I think a PC app and mobile phone app were used as remote controls). These remote controls can send commands to the hub to control the lights, individually, in groups, or all at once. The number of remote controls that can synchronize with the hub to control the lights at once is theoretically unlimited. However as a normal non-shared channel is used, the reverse channel commands sent from the remotes may collide if both were to send commands at once. Given how infrequently people change the settings of their lights, this was considered to be a minor issue.

So looking at the whole system many possible remotes may be used to control many possible lights, in groups or specifically. This is a common goal of mesh networks, but achieved using a simpler system -> hence the term 'practical mesh'.

To move this to being a true mesh solution, we would also need to provide at least one redundant path for the information. This is not included in the demo shown on the video, but has since been created and demonstrated as part of the Nordic Tech Tour. This is done by adding additional hubs that are able to handshake with the lights, and create hub to hub connections.

The demo shown in the video is largely based on the new ANT+ Hub Controls Device Profile (currently only available to ANT+ members), which is implemented by the Garmin Virb (many cameras are able to be controlled by many remotes).

Hope that helps clear things up,

Kind regards,

Kat


     

Hi Kat,

Thank you for the explaination! If a shared channel's master broadcasts (to [0][0]), is only one message sent or is it sending it addressed to all slaves one by one?

If you're not using device profiles, is there any benefit to ANT+ over normal ANT?

Regards,

Alex      

Hi Alex,

Address 0 sends a single message that all slaves receive. (This will be repeated by the master unless you send new data to be transmitted.)

By definition, if you are using ANT+, then you are using a device profile. It is not allowed to use the ANT+ network for anything else. See here: http://www.thisisant.com/developer/ant-plus/ant-antplus-defined/

and: http://www.thisisant.com/developer/ant-plus/ant-plus-basics/

Hence the major of advantage of using ANT+ is the interoperability between products from diverse manufacturers.

More information about using shared channels is available in the ANT message protocol and usage doc (see section 8 example) and the AN07 Shared Channel Application Note.

Enjoy!

Kat      

Hi Kat,

If the host goes down and all (say 20) slaves are still listening, how does it work when the host comes back? It will start to send ADDRESS AVAILABLE, and 20 slaves will simultaneously send I WANT IT! When using an 1:N non-shared channel, how do you avoid the collisions when the slaves all try to register for the new address?

Regards,

Alex

EDIT: I cannot find the EXT_PARAM_AUTO_SHARED_SLAVE parameter info in the ANT documentation. What does this do? It's available for the nrf51422, and implies an
Extended Assign Channel Parameters with value 0x08. Does using this mean you get the auto-shared channel out of the box? Are there any C examples available for both master and slave nodes? The C sharp example on the website is mostly interface work...      

Hi,

You are correct, a random backoff period (within a controlled range) is a good way to help speed up devices which need to gather an address. As you have more devices which need an address, it's a good idea to expand that range to give devices more time to get an address. Even if you don't use a back-off period, because each slave uses a differently timed search waveform, all devices will be able to get addresses eventually.

The EXT_PARAM_AUTO_SHARED_SLAVE define does not actually do anything and is just a placeholder for the time being, sorry if it got any hopes up...

Since we're discussing practical mesh, depending on power requirements, it may be easier to implement a distributed, self-healing network using a fast background scanning channel and a master channel. The devices can be configured to re-broadcast new messages such as on/off which the one's in range can receive. ANT isochronous adaptive coexistence will ensure the master channel's don't interfere with one another over the air, and can help reduce each other's latency as a result. Of course your power budget must allow for continuous background scanning as this is an asynchronous topology instead.

Cheers,
Harrison