Re: [riot-devel] OTA meetup 11.2.2015
Hi, Ludwig, how is the planning going ? Could you create a wiki page (like [1]) or an issue (like [2]) with description of the work to do as well as assignment for each task? Everybody will know how it is going then. What do you think about it? Cheers, [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann ludwig.ortm...@fu-berlin.de: Hi, On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote: the minutes from the meeting have been added to our wiki: https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015 Have there any concrete next steps been identified? Did you conclude in some kind of a schedule for upcoming tasks and who is gonna work on what? There has been some preliminary scheduling, we will announce more concrete planning soon, possibly in the form of an issue. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- *Clenet Baptiste* ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] printing uint64_t
Hi Ralph! Is there something I'm doing that's obviously wrong? I guess this problem is related to the Newlib-Nano [1] we're using if the toolchain supports it. This library doesn't support 64-bit printing. If it's required for you, you could try to disable it in the Makefile (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may run into memory problems then. Cheers, Oleg [1] https://github.com/32bitmicro/newlib-nano-1.0 -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ linux-2.0.38/net/ipv4/ip_fw.c pgpGPfDCkGzFQ.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] A2 Project Details
Hi Shubham, we are using the stm32f4discovery boards for our testing with CAF and C++. However, the board does not have a transceiver. Maybe Martin or Peter can help with that. The r-idge [1] USB dongles enable 6lowpan on desktop hardware, raspberry pis and similar devices. To begin with, I would recommend to get the actors and their work flow running on a desktop first before moving to embedded devices. This eases debugging and helps to get familiar with CAF. I don’t have any experience with predictive algorithms, so you would have to do some research on that topic. Raphael [1] http://rosand-tech.com/products/r-idge/prod.html On Mar 9, 2015, at 4:50 AM, SHUBHAM CHHABRA chhabra...@gmail.com wrote: Hi all, I see a new project (A2: Intelligently Interacting Light Switches) added to the ideas list and would like to know about hardware requirements and predictive analysis involved in it. Can anyone help me? Thanks Shubham Chhabra ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] printing uint64_t
I'm testing three different boards and native mode RIOT. It seems I may have a problem with printing 64 bit ints (for example, an EUI-64 address). Here's the code fragment (modified from examples/hello-world.c): uint64_t longnum = 0x1234567812345678; puts(Hello World!); printf(You are running RIOT on a(n) %s board.\n, RIOT_BOARD); printf(This board features a(n) %s MCU.\n, RIOT_MCU); printf(longnum %016PRIx64 %016llx\n, longnum, longnum); Here's a summary of the output from the 4 devices: cc2538dk: longnum 1234567820001350 1234567812345678 samr21-xpro: longnum 000lx 000lx redbee-econotag: longnum 1234567812345678 1234567812345678 native: longnum 1234567812345678 1234567812345678 and the compilers I'm using for each: cc2538dk:gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) samr21-xpro: gcc version 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278] (GNU Tools for ARM Embedded Processors) redbee-econotag: gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) native: gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Is there something I'm doing that's obviously wrong? - Ralph ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] printing uint64_t
On Mar 9, 2015, at 8:55 AM 3/9/15, Oleg Hahm oliver.h...@inria.fr wrote: Hi Ralph! Is there something I'm doing that's obviously wrong? I guess this problem is related to the Newlib-Nano [1] we're using if the toolchain supports it. This library doesn't support 64-bit printing. If it's required for you, you could try to disable it in the Makefile (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may run into memory problems then. Ah, OK. Is printing the only limitation to use of 64-bit datatypes? - Ralph Cheers, Oleg [1] https://github.com/32bitmicro/newlib-nano-1.0 -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ linux-2.0.38/net/ipv4/ip_fw.c ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] printing uint64_t
Hi Ralph! I guess this problem is related to the Newlib-Nano [1] we're using if the toolchain supports it. This library doesn't support 64-bit printing. If it's required for you, you could try to disable it in the Makefile (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may run into memory problems then. Ah, OK. Is printing the only limitation to use of 64-bit datatypes? Yes, everything else regarding 64-bit datatypes should work as expected. Cheers, Oleg -- printk(Penguin %d is stuck in the bottle.\n, i); linux-2.0.38/arch/sparc/kernel/smp.c pgpREyXDy5tPW.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Contributing to RIOT
Hi , My name is Nasrin Jaleel. I am a final year Computer Science undergraduate from BITS Pilani Goa. I would like to contribute to RIOT OS. I have a basic familiarity with RIOT as I studied it as part of a project I did last semester. I was very excited to see RIOT in the GSoC organisations list and look forward to delve into it deeper. Any guidance is greatly appreciated. *Regards ,Nasrin Jaleel* || +91 95614 36072 4th Year Engineering Undergraduate B.E (Hons) Computer Science *BITS PILANI K.K.BIRLA Goa Campus http://www.bits-pilani.ac.in/goa/* email : nasrin.jaleel...@gmail.com ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] [GSOC 2015] Project A2
Hi Samarth, yes, I agree with your analysis. One aspect I'd like to emphasize, though, is that with 'intelligence' we need distribution, i.e., the sensors need to talk to each other. Now for the discussion on the use case: You're perfectly right, if we predict we are operating under probabilities. First assumption is that the person continues moving and does not simply stop. Sometimes these probabilities are very high, for example, when a person walks down a hallway or opens a door. Sometimes these probabilities are lower, if a person can walk right or left for instance. Our use case is that we want (with some threshold) support continuous lightening on some price of energy consumption. Typically light sources (incl. the sensors) are not densely covering the area. In our university for example, I have to deeply enter a lecture hall until a sensor detects me and switches on the light. This is really unpleasant at complete darkness. It is also inconvenient, if people walk down a path and lights turn on too late. Then a steady change in brightness is affecting the vision. However, there is some tunable parameter (energy versus comfort) and there is learning potential (i.e., how often did a prediction succeed?). I guess this gives a rather rich field of building a solution that covers quite a number of aspects and focuses on the really exciting topic of a distributed intelligent system. Does this help? Best regards, Thomas On 09.03.2015 09:03, Samarth Bansal wrote: Hello! I just got across Project A2 : Intelligently interacting light switches. Sounds really interesting. I have a few questions: 1. The most naive approach I can think about it is this - When a motion detector sensor detects the presence of a person, the light turns on. 2. Now that we are adding intelligence - is it that basically we are trying to determine the path that a person might take and then turn on lights accordingly? Lets suppose that the particular person has an ID, and our devices have historical data about that person as well as of other people. So the path is determined by taking into context and giving apt weight to both forms of data - to predict a path. 3. If that is the case, I have a concern. As for any learning problem, we will be operating under probabilities. Given the nature of the problem in hand, there maybe multiple paths possible with high probability(Right?). For energy efficiency, we won't really like the lighting system to turn on all the probable lights. That is the precise reasons for having sensors. So how does the intelligent lighting system help? The hardware part looks simple. I guess that any micro-controller with a PIR motion sensor attachment and a bunch of LEDs should be good enough for prototyping. Although I think we can simulate the environment by laying down a graph of motion sensors and lights instead of setting up hardware. Does this make sense? Looking forward to the comments! Thanks, Samarth -- Samarth Bansal 4th Year Undergraduate Department of Mathematics and Statistics IIT Kanpur E-Mail: samar...@iitk.ac.in mailto:samar...@iitk.ac.in, samarthbansa...@gmail.com mailto:samarthbansa...@gmail.com Phone: +91-9871551169 Blog : samarthbansal.com/blog http://samarthbansal.com/blog -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] [GSOC 2015] Project A2
Hello! I just got across Project A2 : Intelligently interacting light switches. Sounds really interesting. I have a few questions: 1. The most naive approach I can think about it is this - When a motion detector sensor detects the presence of a person, the light turns on. 2. Now that we are adding intelligence - is it that basically we are trying to determine the path that a person might take and then turn on lights accordingly? Lets suppose that the particular person has an ID, and our devices have historical data about that person as well as of other people. So the path is determined by taking into context and giving apt weight to both forms of data - to predict a path. 3. If that is the case, I have a concern. As for any learning problem, we will be operating under probabilities. Given the nature of the problem in hand, there maybe multiple paths possible with high probability(Right?). For energy efficiency, we won't really like the lighting system to turn on all the probable lights. That is the precise reasons for having sensors. So how does the intelligent lighting system help? The hardware part looks simple. I guess that any micro-controller with a PIR motion sensor attachment and a bunch of LEDs should be good enough for prototyping. Although I think we can simulate the environment by laying down a graph of motion sensors and lights instead of setting up hardware. Does this make sense? Looking forward to the comments! Thanks, Samarth -- Samarth Bansal 4th Year Undergraduate Department of Mathematics and Statistics IIT Kanpur E-Mail: samar...@iitk.ac.in, samarthbansa...@gmail.com Phone: +91-9871551169 Blog : samarthbansal.com/blog ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
