Hello everyone,
we are developing an IOT application and we got impressed with RIOT. It sports some really nice features and it looks like there is a great community over here. On the paper RIOT seems to be perfect for our application, but we need to go deeper before we start investing our resources into this project. We have some questions that are not easy to answer just by looking at the documentation, so your experience is much appreciated.
Hi,
thanks for sharing your architecture with us, it is always interesting to see what people are planning! I will try to answer your questions as good as I can, see answers inline below.
YES indeed! These kind of setups are exactly what RIOT is intended for! On first sight I would use SLIP here, which is already supported by RIOT. Only drawback is that SLIP does as far as I know not support any 802.15.4 link layer specific functionalities, so the PAN coordinator part would need to be handled by the SAMR21. Resource wise this is not problem at all (as the samr21 provides plenty of ressources in terms of memory and processing power to this). Only thing is some missing parts on the implementation side in RIOT, though I am not quite sure about the latest state on this. @Martine, @Oleg: do you know the latest about this? A mean thing to ask developers about the maturity of their code 
No, seriously: IMHO RIOT is ready and mature enough for large scale use since the latest 2015.09 release. We have just recently tested some long-term setups using the samr21 nodes with raspberry pi + at86rf233 based modules as boarder router that were running for weeks without any trouble. As young as RIOT is (and especially the GNRC network stack), I wouldn’t expect it to bug free, but I with little effort one can build very reliable products with it. ‘Without limitations’ might give the wrong impression. In general the situation is quite easy: if you change any of the existing code (e.g. you fix bugs), you have to make those changes available to the community (e.g. commit them into RIOT’s master branch). But you are perfectly fine in linking RIOT together with your disclosed, proprietary application code. There is current work going on to re-implement TCP, and last I heard is that it is already partly working, so I expect TCP support to be back in RIOT rather soonisch, though we can’t give a hard time-frame on this. Further I can’t really tell, which TCP features will be supported. But this process can probably speed up if more people decide to help… In general: Yes. But the current effort is focussing on MQTT-SN (the MQTT variant that works over UDP). But using MQTT-SN might maybe be also a solution for you to use? As far as I know you can have a transparent broker between these two variants on the Linux side (e.g. Paho or similar) and this would remove the need for TCP on the contrained devices side. So far we have pretty stable support for RPL storing mode. Though I am no expert here, work on RPL non-storing as well as work on OLSRv2 is on its way. This is indeed our week spot currently. There is very recent work going on to include tinyDTLS [1] for transport layer security and tweetNACL [2] for end-to-end cryptography. That would be really awesome! As stated above, most of the stuff you need is already there or is being worked on currently - and with some more help it should even be faster to have these features in RIOT. But looking at your general architecture again it feels like this is exactly what RIOT is designed to do! Please let us know where you need more information and how we can help! Cheers, Hauke
Hi,
3) Robustness: please be honest, is RIOT robust and mature enough for a large scale use? Do you know of commercial products that integrates it?
at least there are some companies who explicitly note selling their hw with RIOT, such as
http://www.phytec.de/de/produkte/internet-of-things/evaluierungskit/produktdetails/p/iot-enablement-kit.html http://www.eistec.se/mulle/
Btw, we will work on a more comprehensive overview soon.
Cheers matthias
Whether or not that was the intention when choosing the LGPLv2, I can't say, but that LGPLv2 is actually is significantly different from this description. Patrick is not required to contribute back to RIOT master branch, he is, however, required to:
a.) very clearly indicate to customers who received his product that it uses RIOT. b.) accompany the product with source code to RIOT as well as either HIS source code *OR* object files such that a customer can modify RIOT and link it back to his executable to generate a new binary. c.) note that some of (b) would be unnecessary if using a binary loader of some sort or shared libraries such that an end user could update RIOT independently of Patrick's application.
A lot of this is covered in section 6 of the LGPLv2.
I think it would be a very good idea to consult a lawyer in any case as you will be held to the text of the LGPLv2 not any summary included here.
Cheers, Andy
Perfect! We are almost convinced. Today we cloned from the repository and started playing with the native example and we are even more impressed. It worked flawlessly out of the box. In the next days we will try to implement something on the SAM R21 platform. If I understand well, are you suggesting the following? [Olimex A13] Application <-> MQTT broker <-> Linux TCP/IP stack <-> SLIP <-> Kernel Serial driver <-> USART | [serial from A13 to SAMR21] | [SAMR21] USART <-> SLIP <-> 6LowPAN+Coordinator <-> RF233 I’m not really familiar with SLIP, so I don’t know if I got it right. At which level does SLIP operate? It will send IP packets over serial? SAMR21 is pretty capable, but with 32kB RAM would it be able to coordinate hundreds of nodes? Somebody ever tried with a large number of nodes? The original reasoning behind putting the coordinator on the A13 side was for managing a large number of notes. Sorry, I didn’t want to be mean. I was just seeking a honest answer, to the benefit of everybody. I’m glad to hear about the long term setup. Well done! Please see my next answer to Matthias and Andrew. We can help on this side. I didn’t know about MQTT-SN. Thanks for the hint. I read the specifications this afternoon and it looks even better for our purpose, since it’s optimized for WSN. Plus, we don’t need TCP any more. Perfect. This is another part where we could help. I’ve seen that Paho already offers a C/C++ MQTT-SN client. Could be a starting point? I don’t know what is the difference between the two modes. I need to study a little more… In today’s world, security is very important. For RIOT to be adopted on a large scale, implementing security features must be a priority. As Things got more and more connected, people get more and more afraid of security breaches. Some cases already made the news and some other initiatives (big T for example) put a lot of focus on security. Just my two cents. Great! Regards, Patrick
Dear Matthias, thanks for the links, I will check them out. Nice to hear that some already sell RIOT-powered devices.
Regards, Patrick
Patrick,
Note: I believe you sent this to me privately and I am responding publicly since I think it is good information.
b) Distributing source code of RIOT: no problem. Distributing our source code: I have mixed feelings. On one side, as a free-time developer I understand and sustain the open source movement for all the good it brought to the software scene. I also thank all you developers who make this possible.
You can get by with distributing .o files for your proprietary application, such that the end user can relink (with ld) your application with a new version of riot. That is the recommended approach.
See this for a bit of a HOWTO on how that works:
https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide
and this (regarding licensing):
https://github.com/RIOT-OS/RIOT/wiki/FAQ
Full disclosure, I opened this issue with the project. So I am definitely not 100% neutral in this debate. As a result of this though, RIOT did not change license but did improve the wiki *SIGNIFICANTLY*.
https://github.com/RIOT-OS/RIOT/issues/2128
Ultimately, I regretfully ended up not using RIOT for my products because of these licensing issues and my company's inability to deal with the licensing restrictions (more social issues than technical - I am not the boss! :] ), but it is entirely possible to develop a completely proprietary application around RIOT with care! (And IMO is the best technical solution on the market *by far* even those with other licenses).
Good luck, Andrew Ruder
Note: I repost my entire answer to Andrew to the list. By mistake, before I sent it just to him.
Thank you Andrew for the good information and suggestion. I will checkout the links you mentioned.
Kind regards, Patrick
Hi Patrick,
Good to hear! Again, let us know (or even better: open issues on github) if you stumble upon faulty/unclear/non-RFC complient behavior. Yes. It is basically a link layer over UART. You might have a point here, but I am probably the wrong person to ask. @Cenk, @Oleg, @Martine: can you give some estimates if the above is doable on the SAM nodes? No worries I am no license expert what so ever - my answer above was my personal interpretation of the LGPL, though Andrew has shown that I might be off a little bit… Awesome! Might be. I have not seen their code. From experience with other libraries in similar contexts (e.g. Wakaama) we have seen though, that most use dynamic memory allocation internally, which is not ideal for our kind of very constrained nodes… But I would say its still worth a try. I completely agree! Though for us as RIOT community its a question of manpower. So far we focussed on getting the base system and networking to work stable. As we closed in on this, security is getting more and more on our agenda. Cheers, Hauke
Hi Patrick,
Hi Thomas,
I'm not really an expert in this field, so maybe I used the wrong terminology. For what I could understand (let me know if I'm wrong), for routing packets in 802.15.4 networks, RPL is used. And RPL needs a (DAG) root, that generally is the gateway/border router. This is what I meant with coordinator. I don't know exactly how it works, but I guess that it maintains a list of all the nodes in the network, and from here my consideration that if you have a big network (>1000 nodes?) you need quite some resources to keep the table, hence the idea of running this role in a bigger CPU (Allwinner A13) and using R21 only as transceiver.
Has somebody already tried this kind of setup? (RIOT 6LowPAN <-> RIOT RPL <-> SLIP <-> UART <-----> UART <-> SLIP <-> 802.15.4 <-> RF)
Kind regards, Patrick
Hi Patrick!
I'm not really an expert in this field, so maybe I used the wrong terminology. For what I could understand (let me know if I'm wrong), for routing packets in 802.15.4 networks, RPL is used. And RPL needs a (DAG) root, that generally is the gateway/border router. This is what I meant with coordinator.
Thanks for the clarification. This setup is 100% aligned with anything we have in mind when working on RIOT.
I don't know exactly how it works, but I guess that it maintains a list of all the nodes in the network, and from here my consideration that if you have a big network (>1000 nodes?) you need quite some resources to keep the table, hence the idea of running this role in a bigger CPU (Allwinner A13) and using R21 only as transceiver.
You're right; RPL (in both modes, storing or non-storing) assumes that the root of the DAG is more powerful in terms of memory and maintains some routing information about the nodes in the network.
Some concrete numbers: the gnrc_networking example built for the SAM-R21 requires about 20kB RAM. This example includes most of the components you mentioned in your scenario, like RPL, 6LoWPAN, or transport layer (UDP in this case). But it's missing OTA, security (e.g. tinydtls), and MQTT. However, the RAM overhead for tinydtls is small and I assume it shouldn't be too big for any OTA mechanism or MQTT. But probably your application will require some RAM, too. Currently the routing information per node consumes 20 bytes IIRC. The default configuration used for the gnrc_networking example is able to handle only up to 20 nodes. Given the 32kB RAM of the SAM-R21, one can make this back-of-the-envelope calculation: 32kB RAM - ~20kB for RIOT+network stack - ~5kB for missing features like DTLS and your application = ~7kB / 20 -> about 350 nodes could be possible on a SAM-R21.
All in all, yes, the SAM-R21 might be a bit too small memory-wise to act as a border router for a network with 1000 nodes or more. On the one hand, taking an Cortex-A8 *might* still be overkill, on the other hand, if energy consumption is is not a concern for the gateway it should be okay. Latest plugtest revealed that interoperability between RIOT and Linux for 6LoWPAN and RPL works quite well.
Has somebody already tried this kind of setup? (RIOT 6LowPAN <-> RIOT RPL <-> SLIP <-> UART <-----> UART <-> SLIP <-> 802.15.4 <-> RF)
I'm not sure if I tested exactly this setup, but I ran a lot of tests with similar setups (either without RPL or without the SLIP part) and I'm very optimistic that this setup would work smoothly out of the box.
Cheers, Oleg