• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 57 subscribers
  • Views 4322 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.

CC1310: Network topology Ti 15.4 or contiki

Tom De Smet
Prodigy 165 points

Part Number: CC1310
Other Parts Discussed in Thread: CC2650, CC1350

We are designing a sensor system and are looking for the best solutions. Our use case is the following:

We have multiple devices (around 100) that measure data and transmit every 5 minutes, these devices can also receive messages, for example to sound an alarm when needed.

These sensors are battery powered and will be worn by people inside a building or campus.

So we need a system that can cover this building or campus, through multiple walls and floors.

For this we were thinking of having one device that sets up the network (mains powered) and multiple devices that are mains powered to increase coverage (repeaters, mesh nodes, ...)

I was looking at the Ti 15.4 stack but as it is setup as a star network this seems limited in coverage for indoor usage.

I then looked at contiki but I don't know if this handles mobile leafs very well. There also seems to be alot of overhead that we do not need (like ipv6 addresses)

My questions:

1: If we use the Ti 15.4 stack can we have a device act as a repeater? If this can be done, can we still use frequency hopping?

2: If one is not possible, could a collector act as both a collector and a device? My thinking here is that is joins the network created by the edge collector and sets up its own network to increase the range...

3: If we use contiki, how does the network handle leafs that move around a lot and thus need to jump from one mesh device to another?

4: In contiki each device is connected to the internet, but in our use case we do not need nor want this. The devices should send their data to the edge router, which is responsible for the communication with our servers and integrations with other on site systems (for example we will have a knx integration). So can we use contiki but have all devices communicate with the edge router instead of the internet?

5: In contiki: ipv6 addressing is used, is it possible to use simpler addressing to reduce overhead? For example for now we don't need more that 200 devices in a network so a single byte would be enough, perhaps 2 bytes just to be sure.

6: In the contiki wiki it states that you need the SmartRF06, why is this device needed? Can't I flash the firmware on the CC1310? If the SmartRF06 is needed with the launchpad, does this mean that we also need to add it to our custom design?

  • 0
    Guru 735695 points
    There's no repeater role in TI 15.4 Stack and collector cannot act as both a collector and a device. According to my experiences on Contiki, it's not suitable for mobile node application. If a leaf node change parent node, it takes some time to rebuild routing path and might cause messages cannot be delivered in time.
  • 0 in reply to YiKai Chen
    Prodigy 165 points
    Thanks for your answer,

    So contiki is out.

    Is there another software stack we could run besides Ti 15.4 stack or contiki or should we write our own?
  • 0 in reply to Tom De Smet
    Guru 735695 points
    I suggest you to test with TI 15.4 Stack example first. If it cannot fulfill your demands, you might need to write your own.
  • 0 in reply to YiKai Chen
    Prodigy 165 points
    Something that is not clear to me and perhaps someone from ti could explain:

    On the Ti 15.4 stack you state:
    TI 15.4-Stack is part of the SimpleLink CC13x0 SDK. The SimpleLink CC13x0 SDK includes the software stack from Texas Instruments that implements the standard IEEE 802.15.4e and 802.15.4g specification

    see dev.ti.com/.../overview.html

    I looked at the 802.15.4 standard found at standards.ieee.org/.../802.15.html and the standard defines star and peer to peer networks. (including cluster tree network)

    So if Ti states that it implements this standard does this mean that peer to peer and cluster tree networks work? Or is the statement in the documentation wrong and should it be ïmplements a part of the specifications"?
  • 0 in reply to Tom De Smet
    Intellectual 580 points

    If I'm not mistaken, the 802.15.4 states only that peer to peer and multi hop networks are possible using the standard, but they are not defined or implemented in any way in the document.

    I'd sugest you try something along the lines of DASH7 - http://www.dash7-alliance.org/. It is a full stack protocol, with one-hop capabilities, based on ISO/IEC 18000-7 (that, in its extended version, is compliant with IEEE 802.15.4).

    I don't think it has been ported to CC13xx but at least it could give you some insight and ideas on how to implement one/multi-hop networks in sub-GHz, WSN and such.

    Just to be clear, I have no affiliation or relation with DASH7, but I've been looking into it to build my own protocols or maybe adopt it in full.

  • 0
    Intellectual 630 points

    Hi Tom,

    we (Thingsquare) have a commercial solution that sounds like it may be possible to use as-is for your use-case. In general, the scenario you are looking at is technically challenging to implement, with several challenges you need to be prepared for (see below). So I can't say for sure that our system would fit the bill, but we do support battery-powered nodes, that can be reached from the outside, mesh routing, backend servers deployed at the network edge, and 200+ devices in each network.

    But be prepared for a set of significant challenges:

    • Wireless is hard. It is unpredictable and unstable, and many of the assumptions we may have from other types of systems do not hold.
    • Scale is hard. 4+ nodes is one order of magnitude harder than 2 nodes. It is no longer possible to do things like single-step debugging of individual nodes. 10+ nodes is yet another order of magnitude harder than 4 nodes - at one step above "desktop scale", it starts to get very difficult to understand what is going on inside the network. It is no longer possible to look at only one node to understand what happens. And 100+ nodes is yet another leap of difficulty. Not impossible, but be aware that 100+ nodes is much, much harder than a desktop scale setup.
    • Low-power operation is hard. Again, because the network is large, it is difficult to measure individual nodes to see what happens at scale.

    The reason I say this is that many have played around with a handful of nodes at desktop scale, and hit a wall once they start to go beyond that. And even with a ready-made solution the underlying challenges are still there, so be prepared for this.

    Regarding battery-life, we recently posted an in-depth article about how to achieve multi-year lifetime on a coin cell battery with the CC2650 (and the TI Sensortag):  

    Feel free to reach out if you'd be interested in talking more!

    /adam

  • 0 in reply to Adam Dunkels
    Prodigy 165 points

    Hi Adam

    Battery life is not that big a problem since the nature of our application allows for regular battery swaps.

    Regarding your commercial solution. I assume this is based on contiki. Another user in this thread said that contiki is not suited for mobile applications.

    We are working on a wearable monitoring solution, so people wear the sensors and walk around a campus while we are transmitting sensor data in bursts. Does your commercial solution handle this well?

    And yes wireless is indeed hard :)

  • 0 in reply to Tom De Smet
    Intellectual 630 points

    Hi Tom,

    if you have people doing regular battery swaps, you will definitely value a low power consumption and a long battery lifetime! If users themselves will be forced to swap batteries, they will be annoyed if they have to do it too often, and if you have personnel doing the battery swapping, that budget post will be directly proportional to the power consumption of the devices. The higher the power consumption, the more money you will have to spend on swapping batteries (and the budget posts for anything involving people tend to be high).

    The Thingsquare platform does support mobile nodes. Nodes can freely move within the mesh network and when they want to send data to the backend, they send to the nearest mesh router. Data from the backend to the nodes will be distributed throughout the mesh and will reach the mobile nodes just as if they would have been static. Mobile nodes do need a bit of additional application-level code to make them operate as mobile nodes, and they will not be quite as power-efficient as non-mobile nodes though. This is due to the fundamental optimization that can be done for non-mobile nodes: build the network once, then focus on maintaining it. Mobile nodes will have to search for their network potentially each time they send data, which inevitably has a non-zero power cost.

    Regarding Contiki, as with any software framework, it becomes what you make of it. We are indeed using Contiki as one piece of the puzzle in our system, adapted to our own needs which includes extreme low-power operation, security, channel hopping, support for mobility, among other things. By default, vanilla Contiki only provides mechanisms for static network applications and there is not much support for mobility.

    /adam

  • 0
    Intellectual 630 points
    Hi Tom,

    if you are still working with this, we just published a post showing how to set up a large-scale sensor network with Sensortags and a Raspberry Pi Zero W with a serial gateway: www.thingsquare.com/.../

    This post shows how to set things up with a sub-GHz configuration (CC1350) but everything is the same for the 2.4 GHz setup (CC2650), except you need to use the CC2650 firmware files instead of the CC1350 files.

    /adam