• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 56 subscribers
  • Views 4477 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Contiki CC26xx / CC1310 Platform Demos - experiences?

Ron Segal
Prodigy 185 points

Other Parts Discussed in Thread: CC1310, CC2650, CC2538, CC1350

Hi All. The advertised functionality of both the 'very sleep demo' and the 'cc26xx web demo' is very impressive. So I am wanting to know if there is any experience out there yet, modifying their functionality for practical application. In particularly the sleepy 'leaf' capability and MQTT client?  Anybody combined them? Is it feasible?

These would both be useful (possibly essential) to support an end-to-end WSN capability for outdoor solutions that we are working on using a CC2650 board that we've developed (which is shortly to be modified to provide a CC1310 sub-GHz equivalent). For example I am currently developing an animal traps sensor solution for use by a government conservation agency.  In this case the 'sleepy leaf node' is exactly what's needed to provide long battery life for nodes attached to traps, which are likely to be in forested areas with no sunlight for solar power. Whereas 'backbone' nodes can be positioned to make use of small solar panels.

In addition, having implemented a CoAP based 'observe' solution (where a trap node pushes its change of state to observers rather than being polled, again to save battery, and avoid network congestion), I am thinking that MQTT might provide a more reliable link.  However, its unclear whether the overhead of MQTT TCP vs CoAP UDP could be a network killer, particularly with a fairly large number of nodes.  Any informed views, experiences would be useful.

Actually rather than a 'standard' observe approach, we have currently implemented a simple WAMP (Web Application Messaging Protocol) to CoAP proxy. So CoAP server, observe, update messages are sent to the proxy, which itself handles the list of subscribers to which updates are to be published via WAMP websockets.  So when a trap is sprung all observing browsers and/or applications are immediately updated.  I think something like this is necessary to avoid limited resource WSN CoAP servers having to directly manage a potentially large numbers of subscribers.  So although this is working pretty well, there is a question whether to replace CoAP entirely with MQTT, and whether the current Contiki, CC26xx MQTT client is robust enough to achieve something like this without a lot of testing and tweaking. Views would be appreciated.   Cheers  Ron.

  • 0 in reply to YiKai Chen
    Prodigy 185 points
    Actually I was hoping to get some kind of critical appraisal from anybody that has already been using / testing these demo functions with a few nodes. Or perhaps from the author(s). The question is whether they are robust enough to be embedded in real applications? (Note that I am familiar with the references that you provided. We have been running Contiki on our CC2650 based boards for a while. Also with bespoke CC2538 boards)
  • 0 in reply to Ron Segal
    Guru 735705 points
    I tested on Contiki mesh CC2650 and CC1350 for months and it is robust on 6LoWPAN itself. As for MQTT or other application, it depends on Bluemix MQTT service and your application. Since they are application level things, you should take care of them when you do it.
  • 0 in reply to YiKai Chen
    Prodigy 185 points
    Ok, my interest is a view on whether the specific CC26xx etc demo functions that I mentioned (provided by TI) are robust enough for deployment, i.e. sleepy nodes and MQTT client, the latter irrespective of the broker, IBM or whatever.

    These are very significant functions, into which clearly a lot of effort has been expended.

    Is this the right forum to have such a discussion?
  • 0 in reply to Ron Segal
    Guru 735705 points
    When I tested sleepy nodes and MQTT client, I won't say they are robust but they are stable. From my point of view, there are lots of things need to be test then I will say it is robust.
  • 0 in reply to YiKai Chen
    Prodigy 185 points
    Thanks YiKai, 'stable' is a good start. I'd like to leave this open, see if anybody else has been successful (or otherwise) using these functions in real solutions.
  • 0 in reply to Ron Segal
    Guru 735705 points
    You are welcome.
  • 0
    Expert 1525 points
    Hi,

    they are demos meant to demonstrate the low-power abilities of the chip, and MQTT respectively.

    There are a number of challenges the demos don't take into account. As for the low-power mode, a large part of RAM is lost when in sleep as it is not retained. This means that data that you want to retain must not reside there. There is no support for this in stock Contiki (we built this ourselves when porting to cc1310 and cc2650). As for the MQTT client, that too is a demo and I wouldn't trust it to be anywhere close to production ready. Further, the big part is getting all the other things ready. Security, routing, low-power etc. So the demos are a start, but very far from what makes a production-ready system. But, it is very achievable to reach low-power while maintaining functionality: our devices we put into dead leaf mode has a radio duty cycle at around 0.2% while still maintaining a frequency hopping schema and rapporting data every ten minutes to a multihop mesh network.
    Of course I'm biased (see my bio) :).
  • 0 in reply to mslothy
    Prodigy 185 points

    Hi Marcus, thanks for the very useful information. For a demo there has clearly been a lot of thought and effort put into the 'sleepy leaf' and 'MQTT client' functions at least. A 'sleepy leaf' node (effectively an RDC on top of an RDC) could hugely increase the range of battery only solutions supported by a Contiki CC26xx/CC13xx combination (Google Thread seems to have headed that way, which a Contiki combination of sleepy leaf and RDC mesh nodes could trump).  It does seem though that robust, low power configurations typically require some kind of non volatile ram.  Ideally that would be supported on board the SoCs.  I would be interested in your view on how TCP connectivity, used by MQTT,  is likely to stack-up against CoAP with UDP, from a battery and network congestion perspective.  Do you think the differences are likely to be significant?