Re: [riot-devel] Is RIOT right?
Hi Patrick! On Tue, Nov 24, 2015 at 03:42:13PM +0100, Patrick Rota - Swissponic Sagl wrote: > 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 -- printk(KERN_ERR "Danger Will Robinson: failed to re-trigger IRQ%d\n", irq); linux-2.6.6/arch/arm/common/sa.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
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 On 11/23/2015 12:43 PM, Thomas Eichinger wrote: Hi Patrick, On 23 Nov 2015, at 12:07 CET(+0100), Hauke Petersen wrote: On 20.11.2015 20:48, Patrick Rota - Swissponic Sagl wrote: 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. You might have a point here, but I am probably the wrong person to ask. Could you elaborate how you want to use 802.15.4 PAN coordinator role and for what? Do you want to use it combined with a network management protocol? Please note that none of existing or PR'ed MAC protocols for RIOT utilises this role yet. Best, Thomas ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
Hi Patrick, On 20.11.2015 20:48, Patrick Rota - Swissponic Sagl wrote: Dear Hauke, thank you for your answers. Please see my comments inline. On 11/20/2015 01:13 AM, Hauke Petersen wrote: 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. On 19.11.2015 20:09, Patrick Rota - Swissponic Sagl wrote: 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. Let me first introduce our platform. As in many WSN we have multiple wireless nodes and one (or more) router / coordinator / gateway. ++ Nodes ++ Nodes are based on Atmel SAM R21 that, as you know, is basically an Atmel SAM D21 plus an Atmel RF233 in the same package. We already designed the modules and they work well with Atmel code examples. We want to use the following stack: RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application ++ Router / coordinator / gateway ++ Another device acts as PAN coordinator and as router/gateway to the local LAN. This device is based on a Olimex A13-SOM-512 (https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux with a wired Ethernet interface and the same SAM R21 radio module (with a different firmware). The two boards are connected trough a serial connection (USART). Here the communication stack is a little more complex: [Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial driver <-> USART | [serial from A13 to SAMR21] | [SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233 As you can see, we are not sure about the stack composition, see "(???)". We would like to integrate the coordinator and routing functions in the A13 side (since we have more resources there) and basically just use the SAMR21 as a transceiver. I hope I gave enough details to understand the platform. If not, I will be happy to answer your questions. Now, our questions: 1) Architecture: is RIOT viable for this architecture?# YES indeed! These kind of setups are exactly what RIOT is intended for! 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. Good to hear! Again, let us know (or even better: open issues on github) if you stumble upon faulty/unclear/non-RFC complient behavior. 2) Gateway: which stack layers do you advise to include for the "(???)" parts? Is it a good idea to include the coordinator on the A13 side? Or is better to put it into the SAMR21 side? 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. 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? Yes. It is basically a link layer over UART. 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. 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? @Martine, @Oleg: do you know the latest about this? 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? 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
Re: [riot-devel] Is RIOT right?
Hi, On Fri, 20 Nov 2015, Hauke Petersen wrote: > 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 -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
On Fri, Nov 20, 2015 at 01:13:50AM +0100, Hauke Petersen wrote: > On 19.11.2015 20:09, Patrick Rota - Swissponic Sagl wrote: > >4) License: RIOT is published with a LGPLv2 license and if we understand > >well, we can then use it in our product without any limitation. Is this > >right? > '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. 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
Dear Matthias, thanks for the links, I will check them out. Nice to hear that some already sell RIOT-powered devices. Regards, Patrick On 11/20/2015 12:50 PM, Matthias Waehlisch wrote: Hi, On Fri, 20 Nov 2015, Hauke Petersen wrote: 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
Patrick, Note: I believe you sent this to me privately and I am responding publicly since I think it is good information. On Fri, Nov 20, 2015 at 10:31:32PM +0100, Patrick Rota - Swissponic Sagl wrote: > 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
Note: I repost my entire answer to Andrew to the list. By mistake, before I sent it just to him. --- Dear Andrew, thank you for your clarification. I admit that we are not really competent in the legal side of open source. I just read the LGPLv2 to understand the issue better. Regarding the three points you mentioned: a) we don't have any problem to indicate that our device is using RIOT. If we adopt it we will proud to show its nice logo (and, of course, the license, etc.). 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. On the other side, when you have to earn your living and moreover you have the responsibility for others, it's difficult to give away your software. Let me clarify: we will be happy in participating to the growth of RIOT by submitting all the bug-fixing, improvements and new features to the OS that we could help implement. But we feel not ready yet to make our proprietary application that will run above the OS in the nodes free to everyone. We are a small company and one of our most important assets is the know-how embedded into the application. We are not talking about turning on a light or read a temperature sensor. We have much more. In a world where copying the hardware is pretty easy (even IC are faked!), we cannot afford to give away the small advantage we worked so hard to gain. Not yet. Even distributing the object files sounds dangerous for us since today is pretty easy to disassembly everything. Summarizing: we want to use RIOT, we want to contribute back to RIOT, we don't want to disclose our application (yet). This vision is debatable, but I hope you understand our point of view. c) I don't know exactly how to implement this option. Even separating well the application from the OS, it's inevitable to include some OS headers into the application and if I understand well from the LGPL, this is already considered "a work that uses the library" and therefore we must disclose the code/object files. That said, we are still interested in adopting RIOT, but we must understand how we can do it without infringing the license and at the same time protect ourselves. Practically speaking: 1) for the gateway, licensing maybe is not an issue. a) On the main processor, we will use the Linux stack over SLIP, so no RIOT involved. (is it this correct?) b) On the radio module (connected via serial, remember?) we will have an application that exchange the USART SLIP packets and transfer them on air through 6LowPAN. I guess that this is nothing new and already implemented. If not or not completely, we can help to complete the code and there are no problem in disclosing the source. 2) for the nodes, here we have the issue. Nodes will implement RIOT as OS. Over the OS there is our proprietary application. How can we solve this? Does RIOT support loading/unloading of separate applications? (this feature BTW could be also useful for an OTA update mechanism where OS doesn't change but only the application). Hopefully we will find a solution... Kind regards, Patrick On 11/20/2015 10:58 PM, Andrew Ruder wrote: Patrick, Note: I believe you sent this to me privately and I am responding publicly since I think it is good information. On Fri, Nov 20, 2015 at 10:31:32PM +0100, Patrick Rota - Swissponic Sagl wrote: 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 -- **
Re: [riot-devel] Is RIOT right?
Thank you Andrew for the good information and suggestion. I will checkout the links you mentioned. Kind regards, Patrick On 11/20/2015 10:58 PM, Andrew Ruder wrote: Patrick, Note: I believe you sent this to me privately and I am responding publicly since I think it is good information. On Fri, Nov 20, 2015 at 10:31:32PM +0100, Patrick Rota - Swissponic Sagl wrote: 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Is RIOT right?
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. Let me first introduce our platform. As in many WSN we have multiple wireless nodes and one (or more) router / coordinator / gateway. ++ Nodes ++ Nodes are based on Atmel SAM R21 that, as you know, is basically an Atmel SAM D21 plus an Atmel RF233 in the same package. We already designed the modules and they work well with Atmel code examples. We want to use the following stack: RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application ++ Router / coordinator / gateway ++ Another device acts as PAN coordinator and as router/gateway to the local LAN. This device is based on a Olimex A13-SOM-512 (https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux with a wired Ethernet interface and the same SAM R21 radio module (with a different firmware). The two boards are connected trough a serial connection (USART). Here the communication stack is a little more complex: [Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial driver <-> USART | [serial from A13 to SAMR21] | [SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233 As you can see, we are not sure about the stack composition, see "(???)". We would like to integrate the coordinator and routing functions in the A13 side (since we have more resources there) and basically just use the SAMR21 as a transceiver. I hope I gave enough details to understand the platform. If not, I will be happy to answer your questions. Now, our questions: 1) Architecture: is RIOT viable for this architecture? 2) Gateway: which stack layers do you advise to include for the "(???)" parts? Is it a good idea to include the coordinator on the A13 side? Or is better to put it into the SAMR21 side? 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? 4) License: RIOT is published with a LGPLv2 license and if we understand well, we can then use it in our product without any limitation. Is this right? 5) TCP: we have seen that some TCP support has been temporarily removed and being refactored. What is the plan for reintroducing it? (MQTT is based on TCP) 6) MQTT: is there any plan to develop a MQTT client for RIOT? Is anybody already developing it? 7) Mesh: what is the status of meshing networks? Is it working well / stable? 8) Security: which level of security RIOT provides? For a commercial use, it is important that security (authentication, authorization, encryption) is well implemented. Is this the case? --- We hope that you can shed some light on our doubts. In that case we will be happy to join your community and adopt RIOT as our base. We are ready to contribute to the project, in particular by working on the TCP, MQTT and OTA update, or where needed. We could also provide some HW if anybody is interested. Kind regards, -- *Patrick Rota* ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
