ask a Thingsquare engineer

Dear Marcus,
i have project, but i don't know what mcu to chose. The project related to street lighting i want to connect 200 nodes to a gateway. As you can see, the nodes will be scattered. I will receive less than 200 bytes in ten minutes at each node.
1) Can I use 1310 at each node
2) Which processor should I use for the gateway and which transceiver(cc1310 + am3352 or only cc1310 is suitable .....?)

Thank you for your suggestions.

Hi,

I hope your holidays were great, as mine were :).

Yes, a cc1310 will be sufficient for a 200-device network on both luminairs and gw, but it of course depends on many factors. For example, after the OS and relevant protocols, do you have sufficient flash and RAM for prop sensor and actuator drivers and application? Do you need the gw to handle eg data concentration/buffering/caching/analysis or does it send the data directly to a server backend? In fact, we have recently helped a customer with eerily close to what you ask for: a 200-device, multi-hop smart street lighting product, which uses a cc1310-based gateway and cc1310 on the lamps, no am3352 or similar.

Note that street light deployments may look quite different, it may be clustered such as in a neighborhood, or it could be spread out over a long rural road. In the latter case, each hop will effectively half the available data bandwidth and may risk RF/CPU/RAM starvation on devices close to the gateway. I would suggest you simulate such a network in a number of configurations (ie line, cluster, and everything in between) to find pain points and acceptable limits. The benefit with a lean gateway such as the cc1310-based one I described above, it's cheap to install a second gateway in the middle to partition the network if you are closing in on acceptable limits. Do note that especially in an application like this, end-to-end and link-local encryption is crucial, as well as frequency hopping, but also commissioning since the amount of lamps means even personell without special training must be able to install such a device.

Hope this helps,
Marcus

Thanks! We always perform simulations in addition to real tests, and it's part of our automated regression test suite.

I'm familiar with TSCH (as in the time slotted channel hopping protocol from 15.4e-2012), but I haven't tried/looked at the Contiki implementation. I'm guessing you are familiar with how TSCH works, but for completeness, TSCH divides time into slots in which each participating node can exchange a frame+ack. All slots together is called a slotframe. Slotframes of varying length can be put back to back, and all this is repeated. A device may participate in one or more slotframes. Slotframes can be modified during runtime, but I don't know whether Contiki does this. The timeslot duration is configurable and up to around 65ms.

At Thingsquare, we use another power-saving mechanism/protocol defined in 15.4e called CSL (coordinated sampled listening), which is similar to ContikiMAC or X-MAC. Devices wake up from time to time and samples the rf medium. If over a threshold, it starts up the rx. Transmitters use WUF, or wake-up frames to indicate an upcoming transmission (where ContikiMAC just use the actual data packet repeatedly, and X-MAC uses a long back to back pre-amble). The device waking up reads out the destination address and data transmission time from the WUF (eg "to ABC, will send in 12 ms") and can go back to sleep until then.

In the standard, multi-channel is implemented as the sender sending on one of the channels for (channel sleep duration * number of channels), meaning a huge waste of rf bandwidth, long latency, and power consumption. This is to accomodate not having a synch across devices. We move from the standard in this aspect through disseminating a dynamically generated hopping schema which devices follow. Thus, a device basically just sends as if on one channel, but is really traversing a list of channels, minus a list of blacklisted channels. This makes it really flexible to accomodate everything from low-latency devices (always on) to long life-time (always off except when transmitting something) and everything in between, using the same protocol and settings in the same network. Wasn't easy to get here though :) Finally, while this is all complex and hard and all, we don't want our customers to need to learn this, so this all happens automatically. Our customers can focus on what's important to them, getting the product out there.

If you haven't yet, you should try it out! You need a couple of Launchpads and an enc28j60 ethernet module (~10USD). Would be interesting to hear more about what you are building, and how you experience TSCH and the Contiki implementation!

Best,
Marcus

Hello Marcus,

I was browsing the web looking for solution to a problem I'm having with Weptech gateway and bumped into this thread. Thought I just try my luck ;p

I bought a Weptech Saker gateway, flashed Thingsquare's firmware binaries in it and connected it to my Wi-Fi router. I powered up the gateway via USB from my laptop and opened a com port to Terminal i.e. 115200 baud, 8 data bit, 1 stop bit, no parity. But the gateway's red LED keeps blinking and I did not see anything in Terminal. Not sure whether the gateway is running or not. Do you know what's going on?

Best regards,

Roslee