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 with Contiki/6lowpan or TI-15.4 Stack for street lighting application

Other Parts Discussed in Thread: CC1310

Hi Folks,

I am currently working on developing street light system based on cc1310. I already have Zigbee based solution but I find range will be a limiting factor there and would like to have sub 1ghz solution ready there. I tend to go with TI-15.4 stack as it is straight forward, but I am worried that having no mesh capabilities will be a limiting factor? Few points to consider:

  • I feel if I get 1 km radius, I am happy. I can cover most. ~150 lights is okay for me. Also very low data rates.
  • The nodes can be outside mounted or soldered down on LED driver.
  • IP compatibility is not an issue. Using proprietary protocol is okay for me for now.
  • The nodes will be mounted a bit high on the poll so I assume less noise? This is for Indian applications to begin with.

Anything else I should consider? Would TI-15.4 be a good choice? I really need help here..

Thanks!

  • I think TI 15.4 is a good solution for your application but you have to test to know. However, you should note that TI 15.4 stack only supports up to 50 sensor nodes when security function is enable and I don't know if it is enough for your application..
  • Thanks YiKai,

    100 lights is optimum for me. Wonder why such a restriction of 50 lights? Is it temporary restriction or it is like that by design?

    -D

  • It's flash size constraints. If you disable security, you can have more sensor nodes but not 100 nodes. If I remember correctly, it can be 80 at most without security enable.
  • Hey D,

    It is possible to increase the number of nodes past 50 or even 80. Like YK stated, mac layer security is the culprit for this limitation. Using a Beagle Bone Black or linux host as the collector it is possible to implement security on the application side to have a theoretical limit of 2^16 nodes. Please refer to this e2e post  for more information:

    https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/p/534371/1948520


    Regards,


    Brock Allen

  • I'd say not having a mesh in such an application would be a strongly limiting factor in the network scalability. You could get around this if the street light network is more (physically) laid out in "circles" than in "lines", ie like residential areas rather than highways, in combination with more gateways. I can imagine that such a limitation would both be more expensive (due to the gateways) and severely less appealing from a buyers perspective, so you might lose sales there.


    The cc1310 is perfect for the application though, and as a example, we recently helped a customer deploy street lights in a residential area with about 200 lights based on cc1310, with a cc1310-based gateway. The resulting network topology showed the benefits of a mesh, and since I can't show you the actual graph, I'll instead show you a similar graph that shows that for some devices, being able to mesh is crucial. All these devices can be updated over the air, full link-layer and end-to-end security, user management, offline autonomous mode with schedules and so on.

  • Can you describe the mesh solution you used in this project? TI 15.4 Stack, Contiki OS, Proprietary code?

    It is not clear from the thread if you achieved mesh topology developing an application over TI 15.4 stack or not.

    Thank you in advance.

  • I think mslothy uses thingaquare solution which you can refer to http://www.thingsquare.com
  • Absolutely. First a disclaimer, I work at Thingsquare.

    So, our system is a 6lowpan mesh network with many parts - some free and open standards, others are not. The firmware is built on top of Contiki (one of Thingsquare co-founders is also the creator of Contiki, Adam Dunkels) but differs in many ways - for example, we run our own proprietary protocols and mechanisms that are not in Contiki, on top of websockets (our PR to Contiki just got merged), TLS for end-to-end security, dynamic security, firmware updates over the air, and 15.4e CSL (Contiki 15.4e TSCH) in the bottom layer, since it scales better with density, data, network size.

    Feel free to send me an email if you have any needs you think Thingsquare may help you with, marcus@thingsquare.com