[riot-devel] Reminder: Register to the RIOT forum!
Dear RIOTers, Here is anotherreminder to register at the forum dedicated to RIOT: https://forum.riot-os.org/ <https://forum.riot-os.org/> Please note that thismailing list isscheduled to close on *10th of February*. We thus invite you to register to the forum as soon as possible. You can post your next messages there, instead of on this mailing list. *Email archive migration**:* As of yesterday afternoon, all email discussions archived from this list have been migrated to the forum. The migrated discussions can be found in archive subcategories of the 'help' and 'development' categories. *Email interaction as of 2021:* We leave noone behind: if you have a strong preference for email interaction still, simple settings in Discourse enable posting and receiving forum messages via email [2]. Looking forward to see you on the Forum! Cheers, Koen [1]: https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84 <https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84> [2]: https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46 <https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46> OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Reminder: Register to the RIOT forum!
Dear RIOTers, Here is the first reminder to register at the new forum dedicated to RIOT:https://forum.riot-os.org/ <https://forum.riot-os.org/> The current mailing lists are scheduled to close on 10th of February. We thus invite you to register to the forum soon, and to post your next messages there, instead of on this mailing list. * * *Migration planned by end of 2020:* Please be informed that we plan to migrate all email discussions to the forum, gradually, over the next ~4 weeks. *Email interaction as of 2021:* We leave noone behind: if you have a strong preference for email interaction still, simple settings in Discourse enable posting and receiving forum messages via email [2]. Looking forward to see you on the Forum! Cheers, Koen [1]: https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84 <https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84> [2]: https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46 <https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46> OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Register to the RIOT Forum!
Dear RIOTers, We have set up a forum dedicated to RIOT, which you can now enjoy at https://forum.riot-os.org/ <https://forum.riot-os.org/> This process follows the conclusions of our recent survey on this topic [1]. The forum is a Discourse instance. *Migration planned by end of 2020:* Please be informed that we plan to migrate all email discussions to the forum, gradually, over the next ~4 weeks. We thus invite you to register to the forum soon, and to post your next messages there, instead of on this mailing list. *Email interaction as of 2021:* We leave noone behind: if you have a strong preference for email interaction still, simple settings in Discourse enable posting and receiving forum messages via email [2]. Looking forward to see you on the Forum! Cheers, Koen [1]: https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84 <https://forum.riot-os.org/t/survey-how-will-we-communicate-in-the-future-mailing-lists-forum/84> [2]: https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46 <https://forum.riot-os.org/t/riot-forum-as-a-mailing-list/46> OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Release 2020.10
|And hopefully this time with newlines: Dear RIOTers, We are happy to announce the 25th official release of RIOT: --- * RIOT 2020.10 * --- | |The 2020.10 release includes: - Support for PicoLIBC as standard C library implementation - A new radio abstraction layer for ieee802.15.4 radios - Improvement to the linking of modules - An improved algorithm for generating local unique identifiers - Pagewise addressing support for MTD devices - 23 additional modules supported by Kconfig - Initial rework of the clock modelling on stm32 devices - 5 new boards, 2 new device drivers, 7 packages updated 482 pull requests, composed of 1355 commits, have been merged since the last release, and 84 issues have been solved. 64 people contributed with code in 94 days. 2426 files have been touched with 133358 (+) insertions and 756906 deletions (-). ||You can download the RIOT release from Github by cloning the repository and checkout the release tag [1] or by downloading the tarball [2], and look up the release notes for further details [3]. A big thank you to everybody who contributed! Best regards, Koen Zandberg [1]:https://github.com/RIOT-OS/RIOT/tree/2020.10 [2]:https://github.com/RIOT-OS/RIOT/archive/2020.10.tar.gz [3]:https://github.com/RIOT-OS/RIOT/releases/tag/2020.10| || OpenPGP_0x69568F2BF8114A27.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Release 2020.10
|Dear RIOTers, We are happy to announce the 25th official release of RIOT: --- * RIOT [2020.10] * --- The 2020.10 release includes: - Support for PicoLIBC as standard C library implementation - A new radio abstraction layer for ieee802.15.4 radios - Improvement to the linking of modules - An improved algorithm for generating local unique identifiers - Pagewise addressing support for MTD devices - 23 additional modules supported by Kconfig - Initial rework of the clock modelling on stm32 devices - 5 new boards, 2 new device drivers, 7 packages updated ||482 pull requests, composed of 1355 commits, have been merged since the last release, and 84 issues have been solved. 64 people contributed with code in 94 days. 2426 files have been touched with 133358 (+) insertions and 756906 deletions (-). You can download the RIOT release from Github by cloning the repository and checkout the release tag [1] or by downloading the tarball [2], and look up the release notes for further details [3]. A big thank you to everybody who contributed! Best regards, Koen Zandberg [1]:https://github.com/RIOT-OS/RIOT/tree/2020.10 [2]:https://github.com/RIOT-OS/RIOT/archive/2020.10.tar.gz [3]:https://github.com/RIOT-OS/RIOT/releases/tag/2020.10| || OpenPGP_0x69568F2BF8114A27.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Release 2020.10 - Hard feature freeze now effective
Dear RIOTers, We've created the 2020.10 release branch, so we are now officially in feature freeze. This means from now only bugfixes will be backported to the `2020.10-branch`. If anyone has any bugfixes or documentation improvements that they feel should be part of this release please let me know. New features can still be merged into master during this period. The tracking issue of Release candidate 1 [1] is opened. If you want to help with testing, please put your name against the corresponding item in the linked spreadsheet. Thanks all for the awesome work! Best regards, Koen Zandberg [1] https://github.com/RIOT-OS/Release-Specs/issues/192 signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Release [2020.10] - Soft feature freeze now effective
Dear RIOTers, The soft feature freeze (for high impact PRs) is now effective. As a gentle reminder: the final feature freeze (for all PRs) is 05.10.2020. Whishing you a happy code/polish/review/merge sprint, Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Release [2020.10] - Dates and Feature Requests
(And now with some extra whitespace) Dear RIOTers, The release dates for the upcoming release cycle (2020.10) are fixed as follows: - 23.09.2020 - soft feature freeze, for high impact features - 05.10.2020 - hard feature freeze, for all features - 26.10.2020 - Release date Could you please send your suggestions for features which you would like to see merged during this release cycle. Best regards, and happy hacking! Koen Zandberg On 09-09-2020 14:40, Koen Zandberg wrote: > |Dear RIOTers, The release dates for the upcoming release cycle > (2020.10) are fixed as follows: - 23.09.2020 - soft feature freeze, for > high impact features - 05.10.2020 - hard feature freeze, for all > features - 26.10.2020 - Release date Could you please send your > suggestions for features which you would like to see merged during this > release cycle. Best regards, and happy hacking! Koen Zandberg | > > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Release [2020.10] - Dates and Feature Requests
|Dear RIOTers, The release dates for the upcoming release cycle (2020.10) are fixed as follows: - 23.09.2020 - soft feature freeze, for high impact features - 05.10.2020 - hard feature freeze, for all features - 26.10.2020 - Release date Could you please send your suggestions for features which you would like to see merged during this release cycle. Best regards, and happy hacking! Koen Zandberg | signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT OS port for the icoBoard FPGA board - icoSoC / picorv32 RISC-V platform
Hi Tomas, On 03-09-2020 21:04, Tomas Styblo wrote: > Hi guys, > so far it's only an experiment, but I've started porting RIOT OS to > the icoBoard Lattice FPGA / icoSoC / picorv32 RISC-V softcore CPU > platform. > > The Lattice chip used on the icoBoard is probably the only FPGA device > supported by open source tools. And it will be the first FPGA device > supported by RIOT OS (AFAIK) I think you're right with this. I haven't heard of anybody running RIOT on an FPGA softcore before. Doesn't mean that they don't exist of course :) > > RIOT OS already supports the HiFive E310 RISC-V MCU, but that is a > very different piece of hardware with RISC-V Privileged Architecture > support. Still I've been able to reuse some code chunks. I happen to be working on refactoring the fe310 code to split out the common RISC-V code bits. Mainly to support the gd32vf103 devices from Gigadevice, but any RISC-V MCU should benefit from this. It should at least simplify your porting work in the future. > > So far It's only an experiment (and I'm a newbie at this!), but all > the important features already work, including shell over UART. It is > really fascinating to be able to use a tiny FPGA board this way. (Personally) I think this makes for a great addition to RIOT. Support for a softcore really opens a lot of options for designers. > > If you are interested, you can find the (alpha, experimental!) code at: > > https://github.com/tstyblo/RIOT-icoboard > > It would make no sense trying to merge it into the mainline now, as > the code needs a lot of testing, comments and improvements. But I'd > like to use this opportunity to invite anyone interested in FPGA > devices or in the RISC-V platform to check it out. Looks awesome, thanks for sharing. Is there also a repository with the verilog for the FPGA configuration? Any estimation how many LUT's and other resources it requires from the FPGA? Best regards, Koen Zandberg signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FOSDEM 2020 RIOT BoF
Hi again, We got ourselves a slot at 16:00 today in room H3242, just follow the BoF signs in building H! See you there! Koen On 31/01/2020 15.55, Koen Zandberg wrote: > Hi all, > > For those of us attending FOSDEM this year, I plan to grab a BoF room > time slot to have a small RIOT meet-up. Unfortunately from what I've > heard there won't be a RIOT stand this year again, but we can meet-up > anyway of course. Please let me know if you have any preference for a > time slot. > > I'll announce here and on IRC as soon as I have a time and a room > reserved for us. > > Cheers > Koen > > > > ___ > users mailing list > us...@riot-os.org > https://lists.riot-os.org/mailman/listinfo/users signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] FOSDEM 2020 RIOT BoF
Hi all, For those of us attending FOSDEM this year, I plan to grab a BoF room time slot to have a small RIOT meet-up. Unfortunately from what I've heard there won't be a RIOT stand this year again, but we can meet-up anyway of course. Please let me know if you have any preference for a time slot. I'll announce here and on IRC as soon as I have a time and a room reserved for us. Cheers Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ADC API resolution
Hi all, A month or so back I added ADC peripherals bindings for the MicroPython fork. As this had to be generic across boards I also stumbled over a missing run-time indicator for which resolutions are supported. At that moment I worked around it by iterating over all possible ADC resolutions until a supported resolution was tried. Of course this is a bit suboptimal. I'm very much in favor of some way to determine the available resolutions and min/max resolutions of an ADC. I was thinking of a function such as `adc_res_t adc_res_max(adc_line_t line)` to be able to support different ADC peripherals on a single image. Just my 2 cents on this issue. I'm already glad that this is tackled. Cheers, Koen On 08/01/2020 14.30, Hauke Petersen wrote: > Hi Marian, > > I agree that users are unlikely to produce that garbage when passing > value to the `adc_sample` function directly. More likely those kind of > values are produced in cases where values are deducted > programmatically via (potentially broken) code, or from broken > indirect configuration (nested defines...). The main point is simply > that the compiler does not catch this and we need to handle it somehow > -> which we agree upon as it seems :-) > > So +1 in documenting the preconditions correctly, checking the `line` > and `res` values using assertions and not returning any specific code. > How about we change the API doc to something `@return <0 for any > internal error` or similar, to still allow certain peripherals to > signal an error and mark the result invalid. > > While touching this API, would it make sense to also change the return > type from `int` to `int32_t`? This would allow for 16-bit ADCs on 16- > and 8-bit platforms... Just thinking loud here :-) > > Cheers (and thanks for tackling this!), > Hauke > > On 1/7/20 10:09 AM, Marian Buschsieweke wrote: >> Hi, >> >> thanks for your reply. >> >> On Tue, 7 Jan 2020 09:00:54 +0100 >> Hauke Petersen wrote: >> >>> Hi, >>> >>> keep in mind that just because an enum value is not defined, it does not >>> prevent code like >>> ``` >>> adc_res_t res = 77; >>> adc_init(.., res); >>> ``` >>> Also, calling `adc_init(..., 1234)` is completely fine for the compiler... >> To me, this is a text book example of garbage in, garbage out. I personally >> don't expect someone to use random numbers out of the head of their mind >> instead of the enum constants and expecting things to just somehow magically >> work. >> >> How about we add a precondition statement to the API documentation that only >> values provided via enum constants are valid input for the resolution? >> >> But if we cannot assume a minimum level of common sense being applied to the >> users source code, why not at least use assert()? This way at least >> production >> code doesn't have to pay the overhead of checking for completely insane bugs. >> >> (Don't get me wrong: I personally very much in favor of doing proper error >> handling even at the expense of some overhead. But adding overhead to check >> for >> completely crazy stuff seams not to be a good trade off to me.) >> >>> Hence the two fold approach in the current implementations: each CPU >>> should define only the ADC_RES_X values it actually supports and on top >>> adc_sample() *should* return -1 on unsupported values to catch mishaps >>> as stated above. >> Sadly, neither is it (consistently) implemented like this nor documented this >> way. But if there is an agreement that only the enum constants actually >> supported should be defined, I can open a PR to document this. But let's keep >> the discussion on how to handle it if users call adc_sample() with a >> resolution >> not provided by the enum going for while. >> >> While I'm at it: How should adc_sample() behave if the line parameter is out >> of >> range? This is something that can easily happen, e.g. when compiling code >> written for one board for a different board. Again: I would say a >> precondition >> added to the doc and an assert() would be this best solution here. >> >> I'd also like to add that the API is not safe to be called from IRQ context, >> as >> (at least some) implementations use a mutex to serialize access to the ADC. >> >> (Btw: If we would replace the `ADC_LINE()` macro by a `static inline adc_t >> adc_line(unsinged num)` function, we could use `_Static_assert()` to generate >> compile time errors there as well. For backward compatibility an macro >> ADC_LINE() calling that function could be provided.) >> >>
Re: [riot-devel] USB PID number
Hi Juan, On 2/25/19 3:19 PM, Juan Ignacio Carrano wrote: > Hi all, > > First of all, great work. Now to the VID, PID matter: I don't think we > should get any VID. A single PID may be ok. > > Product numbers are for products. RIOT is not a product. Rather, it is > used to build product (or at least that's wath we hope for). Even if > we obtained an ID it would be irrelevant for everyone except > developers: if you develop a device, you should get your OWN ids, you > cannot reuse your OS vendor's. > > > > I think that having a single PID for "Generic RIOT-powered device" (or > something of the sort) is valuable, especially for development, and > for the CI, and we only really need one, not a whole block. That, and > the fact that we have a more or less large project should be enough > justification to get a PID from pid.codes. Of course, the docs should > clearly state that the PID is for use in RIOT development and should > be changed for actual devices. > > A whole VID would not be useful: what would you do with so many PIDs? I agree with you here. First of all, I also don't see any use for a VID for RIOT-os, but hey maybe somebody else has a use case for a full VID. For me, a hypothetical RIOT-os PID would be used only for development and testing. CI jobs, people wanting to test USB or develop USB devices. As soon as the USB device leaves the building it must have a different VID/PID owned by the developer/company. Having a PID for this is mostly for ease of development, so we don't have to use a random VID/PID with all the consequences. A lot of USB functionality doesn't require a specific VID/PID, but is purely recognized based on the descriptor information. A second PID could be required if we have our own DFU enabled RIOT bootloader. For this I wouldn't mind if it was used for actual products as long as the RIOT bootloader is unmodified. This as in if it claims to be the RIOT-os DFU bootloader, it should behave like the RIOT-os bootloader and be able to flash RIOT-os on the mcu with the RIOT-os DFU tooling. Cheers, Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] USB PID number
Hi all, With the whole USB peripheral PR set slowly starting to take it's final shape, I'd like to get a RIOT-os specific vendor/product code. As Dylan suggested[1] we can try to get a free vid/pid combination at the pid.codes[2]. This with the assumption that a full vendor space for $5.000 is both too much and too expensive for RIOT-os. I'm strongly against making up/stealing a combination, even if it is for a short while as this not how USB VID/PID's should work(tm). My question is if anydbody has a better solution for the vid/pid problem? If not wether anybody minds if I go ahead and fill out the necessary info to request a PID from the pid.codes collection. Cheers, Koen P.S. For those interested, the progress so far: PR'd: - Generic USB peripheral interface (#9830) - USB peripheral driver for the atsamr devices (#10915) - Preliminary USB peripheral stack (#10916) In a branch somewhere: - Simple USB auto init code - USB CDC ACM with STDIO support (https://github.com/bergzand/RIOT/tree/pr/usb/cdcacm/examples/usbus_minimal) Not yet in a branch/very WIP but somewhat functional: - USB peripheral driver for the nrf52840 - USB CDC ECM with netdev support [1]: https://github.com/RIOT-OS/RIOT/pull/9830#issuecomment-428096556 [2]: http://pid.codes/howto/ signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT-os meet-up at FOSDEM
Hi all, We have a BoF room slot reserved for us: Sunday 13:00 - 14:00 Location: H.3242 Hope to see you there! Cheers, Koen On 1/29/19 1:30 PM, Koen wrote: > Hi all, > > As I will be visiting FOSDEM again this year, I was wondering if there > are more people from the RIOT-os community attending. From what I've > read, there won't be a RIOT-os stand this year, but if there is some > interest for a small meet-up anyway, I can try to get us a timeslot in > one of the BoF rooms. > > Please let me know if you would like to meet up at FOSDEM and whether > you have a strong preference for either saturday or sunday for the meet-up. > > Cheers, > Koen > > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] General configuration Task Force
Hi, Sounds fun, count me in! Koen On 07/09/2018 10:09 AM, Jose wrote: > Dear maintainers, > > > Last Friday we had an offline discussion with some RIOT people about > he lack of a mechanism to configure Kernel parameters as well as > application specific configurations (private keys, timer values, etc). > Although RIOT is configurable via CFLAGS, there's no way to (easily) > expose all configurations and tweak RIOT in a centralized manner. As > shown, other OS are using several strategies in order to accomplish > this (KConfig, header files, etc). > > > I want to propose a "Kernel and Application specific configuration" > Task Force to address these issues. What are your feelings about this? > Anyone (besides me) is interested to work in this topic? > > > Cheers, > > José > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Easing maintainer burden
Hi all,
At FOSDEM I attended a talk about how Easybuild simplified their
contribution process[1] (recording and slides available). The short
story is that they have added functionality to their tooling to
integrate with Github to simplify some of the repetitive tasks for
contributors and maintainers. I think some of their ideas can be adapted
to RIOT, mostly the points about easing maintainer burden.
1. Have Murdock comment on PR's on (some) build failures. The goal here
is to give the contributor a nudge that the build failed. Currently an
inexperienced contributor might miss the small red cross indicating
build failure. Having Murdock comment on the PR about the build failure
and maybe even with a short explanation why the build probably failed
could increase contributor responsiveness while removing the need to
have maintainers poke the contributor and having to explain why the
build failed.
2. Automated test uploading and reporting. The idea here is to have a
script that executes a test and uploads the result to a gist and attach
it with a comment to a PR/issue. This would ease test failure/success
reporting. This way we can provide a default template to provide all
relevant information (toolchain versions, build log, test output etc.).
For a contributor it should be easier to report test failure for issues,
while for maintainers it becomes easier to report test success/failures
to reviewed PRs.
3. Documentation about the directory tree. This is about having
documentation about what can be found where in the directory structure.
Mostly to prevent new contributors from having to search around in the
directory tree. Most parts of the directory tree is quite obvious, but I
think it can help the inexperienced developer to have some guide for
this. Not sure whether this already exists though.
4. Skeleton drivers: In my opinion it should be as easy as possible to
add simple sensor drivers to RIOT. If a template-like skeleton dummy
driver is added which can simply be copied and filled in for a new
sensor, the contribution threshold could be lowered. Mind that this is
aimed at the simple I2C/SPI drivers which can be implemented with not
much more than init and get functions (something like the jc42 sensor
driver).
A lot more menial tasks of reviewing can be reduced of course, for
example, a scripts to check out a PR in a different directory, and as
Kaspar already proposed, a script to create backport PRs[2].
What I would propose is having some script, a riot.{sh,py} to handle the
maintainer automation together with point number 2. Point 4 could
relative simple be added as a driver with tests. Number 1 probably
requires Murdock to be extended, but could be valuable to have. Number 3
would have to be added to the Doxygen together with a link in the readme.
Regards,
Koen
[1]: https://fosdem.org/2018/schedule/event/contributor_automation/
[2]: https://github.com/RIOT-OS/RIOT/issues/8523
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Plans for switching over to a new network infrastructure in GNRC
Hi, As #7925 was merged yesterday, there is now a nightly build with the gnrc_netif code merged. From this I present you the build size differences <https://riot-graphs.snt.utwente.nl/dashboard/db/full-grid-diff-boards-vertical?orgId=1=1511743027554=1511869511369=examples%2Fdefault=examples%2Fgcoap=examples%2Fgnrc_border_router=examples%2Fgnrc_minimal=examples%2Fgnrc_networking=tests%2Fgnrc_udp=arduino-mega2560=cc2538dk=native=nucleo-f401=pic32-wifire=samr21-xpro=text> between today (with gnrc_netif) and yesterday (before the merge). Absolute numbers on a single application on a single board can be found by pressing the relevant diff. Selection of the tests, boards and metric (bss, data and text) is at the top of the page. Some remarks: These are the diffs between the previous and the current build size, not absolute numbers. Furthermore, this is a comparison between nightlies, not from merge to merge, so all merges from yesterday are included in this diff. Cheers, Koen On 11/01/2017 04:26 PM, Martine Lenders wrote: > Hi, > > FYI there is a re-integration PR > now: https://github.com/RIOT-OS/RIOT/pull/7925 > > Cheers, > Martine > > 2017-10-27 17:56 GMT+02:00 Martine Lenders <m.lend...@fu-berlin.de > <mailto:m.lend...@fu-berlin.de>>: > > Hi all, > > after the release is before the release, so let's use the drive to > continue the good work. > > Some of you might have noticed, that we are currently working on a > big switch-over for GNRC-internal APIs, so if you are not involved > in any direct GNRC programming or need access to the network > interfaces this won't most likely only affect you a little bit > (the calls how to get an interface ID will change -- actually > simplify ;-)) to not at all. > > This is quite a massive step, since basically most of the files > that are doing operations on, or related to network interfaces > (i.e. IPv6, 6LoWPAN, MAC and routing protocols) need to be > touched. In addition we decided to integrate this network > interface layer directly with the new, shiny and fixed neighbor > discovery which saves us a lot of integration work into old stuff, > but doesn't make things easier. Some of that work is already done > and in master, but most of it will take some time to adapt. > > This is why we (the RIOT maintainers) decided to go a slightly > different route than usual: we made a feature branch where all the > integration work (and testing) for the new components will happen > [1] and made a 1-2 week plan to get this branch re-merged into > master as fast as possible. In that time this feature branch exist > merging new changes to GNRC into master is highly discouraged to > not risk merge conflicts in the gnrc_netif2_integration/master > branch. We will notify you again when this embargo is lifted. > > So what changes after all this is done (I call the new interface > API gnrc_netif2 here, but in the final result it will be called > just gnrc_netif): > > * Network interfaces: > - Simplification of GNRC's network interface architecture: > currently there are 4 APIs (gnrc_netdev, gnrc_netif, > gnrc_ipv6_netif, and gnrc_sixlowpan_netif) that represent network > interfaces in some kind or form. This makes things complicated if > you need e.g. in NDP information that is both device dependent > (e.g. link-layer address) and IPv6 dependent (e.g. IPv6 address). > This is why gnrc_netif2 merges all these APIs into one single API. > - Tighter integration into GNRC's principles: For most device > related options interfaces worked like any other GNRC module and > used NETAPI, but when it came to other stuff, like IPv6 addresses > or 6LoWPAN configuration, other APIs were used. With gnrc_netif2 > all options can be set via NETAPI. > - Better thread synchronization: apart from the the fact that > GNRC-externally the options are now set over NETOPT (i.e. in the > thread context of the interface) we also use recursive mutexes > GNRC-internally now to better synchronize the access to the > interface. In the previous implementation normal mutexes were used > (requiring some dangerous unlocking in the middle of an operation) > or no mutexes were used at all. > - Easier to extend: If you want to provide a new MAC protocol > to GNRC you don't have to copy all the thread-handler stuff > anymore. Just implement the operations provided in > `gnrc_netif2_ops_t` and let gnrc_netif2 do the rest ;-). > * new neighbor discovery: > - In comparison to the old neighbor discovery the new was > designed more thoughtfully so it easier to m
Re: [riot-devel] [riot-maintainer] Monthly meetings for organisation purposes
Hi, I'll try to participate in the meeting as well. Koen On 11/04/2017 01:39 PM, Martine Lenders wrote: > Hi Paco, > > I'm in as well. > > Cheers, > Martine > > 2017-11-04 1:03 GMT+01:00 Thomas Eichinger <tho...@riot-os.org > <mailto:tho...@riot-os.org>>: > > Hi Paco, > > Thanks for the initiative! > > I will try to tune in. > > Without wanting to start a tools discussion, I had very good > experiences with larger groups using zoom.us <http://zoom.us>. > > Best, Thomas > > On Nov 3, 2017, at 4:29 PM, Francisco Javier Acosta Padilla > <francisco.aco...@inria.fr <mailto:francisco.aco...@inria.fr>> wrote: > >> Hi again! >> >> A kind reminder to let us now who’s willing to attend the meeting >> on Monday, November 6th at 17:00 CET (UTC +1). >> >> I don’t have an agenda yet but if we can establish it before it >> would speed up the meeting. So far I propose: >> >> 1. Sort the most urgent bugs-issues by priority >> 2. Assign (more/new) people to the bugs-issues >> 3. Mark the related issues/PRs to be solved as “in progress” >> >> The goal is to have the selected issues solved before the next >> meeting, if it happens before, be free to assign new ones and >> move them to the “in progress” column. >> >> Please don’t hesitate to propose your ideas for the topics of the >> meeting! >> >> Cheers! >> >> -- >> Francisco Javier Acosta Padilla >> Research Engineer at INRIA Saclay >> INFINE Team >> >> On 1 November 2017 at 12:25:51, Martine Lenders >> (m...@martine-lenders.eu <mailto:m...@martine-lenders.eu>) wrote: >> >>> Hi Cenk, >>> >>> 2017-11-01 11:05 GMT+01:00 Cenk Gündoğan <list-r...@cgundogan.de >>> <mailto:list-r...@cgundogan.de>>: >>> >>> > > On 17-10-31 18:03:01, Francisco Javier Acosta Padilla wrote: >>> > > […] >>> > > > P.S: @Martine, can you set up the next Hack >>> meeting? Thanks >>> > > >>> > >>> > Anything different to do than the usual ad-hoc placecam >>> set-up? >>> > >>> >>> Jup, provide a working mic for the FU's PlaceCam laptop this >>> time (: >>> >>> >>> We had... the problem was that the machine we ran placecam on >>> was so slow and old that ALSA wasn't able to stream that audio >>> including video ^^ (that's definitely a problem we need to solve >>> until next week). >>> >>> Cheers, >>> Martine >>> ___ >>> Maintainer mailing list >>> maintai...@riot-os.org <mailto:maintai...@riot-os.org> >>> https://lists.riot-os.org/mailman/listinfo/maintainer >>> <https://lists.riot-os.org/mailman/listinfo/maintainer> >> ___ >> Maintainer mailing list >> maintai...@riot-os.org <mailto:maintai...@riot-os.org> >> https://lists.riot-os.org/mailman/listinfo/maintainer >> <https://lists.riot-os.org/mailman/listinfo/maintainer> > > ___ > Maintainer mailing list > maintai...@riot-os.org <mailto:maintai...@riot-os.org> > https://lists.riot-os.org/mailman/listinfo/maintainer > <https://lists.riot-os.org/mailman/listinfo/maintainer> > > > > > ___ > Maintainer mailing list > maintai...@riot-os.org > https://lists.riot-os.org/mailman/listinfo/maintainer signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RPL DAO target concat from fib
Hey Rahul, Unfortunately I don't have time right now to read and comment on your email in depth :( About the ETX metrics for RPL, please have a look at #6873 and #7450. I want to take a better look at your ideas and proposal in the weekend. Regards, Koen Zandberg #6873: https://github.com/RIOT-OS/RIOT/pull/6873 #7450: https://github.com/RIOT-OS/RIOT/pull/7450 On 10/19/2017 07:46 AM, Rahul Jadhav wrote: > Thanks Cenk for giving a clear picture. Some comments inline... > In general, I feel this is important to be handled, since even in > small network this would result in DAO fragmentation and will impact > its performance. > > Also there are some other points i wanted to understand/clarify: > 1. Currently RIOT does not handle L2 ACK for determining whether L2 > send was successful or not. This feedback is not used at RPL/6lo > layer. Scenario: A node receives a DIO from parent and sends a DAO. > But lets say this DAO could not reach the parent. In this case L2 ACK > would have failed and the child node could have handled it to switch > parent. Even if K bit is set in the DAO, and if DAO-ACK is not > received, the child node wont come to know since there is no > state/timer maintained to handle this. Essentially this will lead to > child node believing that it is connected to the network but the > downstream path is never actually established. > 2. RIOT does not handle L2 retry-count feedback to maintain RPL metric > (for e.g. ETX). > Pls correct if i m wrong. > > Thanks, > Rahul > > On 19 October 2017 at 01:00, Cenk Gündoğan <list-r...@cgundogan.de > <mailto:list-r...@cgundogan.de>> wrote: > > Hey Rahul, > > you are correct. The current RPL DAO building routine does not take > into account the MTU size, which is IMO the appropriate approach, > because on that level (ICMPv6) there is usually no knowledge about the > link-layer in use. > > > [RJ] True. > > > If I understand you correctly, then you basically > want to move the fragmentation from the 6lowpan layer up to the > ICMPv6/RPL layer (and only for DAOs). > > > [RJ] Thats exactly what I had in mind. > > > I think in one of the older > iterations of our RPL implementation we once had a functionality to > limit the number of Target Options in the DAO to a specific number > (configurable on compile-time). > > > [RJ] This would have been a real nice feature. Supporting target > aggregation in DAO without depending on 6lo frag. In the future, > proposing/implementing prefix eliding (the way 6loRH does for SRH or > by simply using 6lo CID) between target containers and standardising > it would make sense ! Considering that DAO consumes the most amount of > RPL control traffic, i feel this can be fairly important. > > But with the addition of a proper > 6lowpan fragmentation, we dropped that functionality. > > > [RJ] 6lo frag is not a good option to use and should be avoided as far > as possible. > > > > I may take a look at it during the weekend. If I remember correctly, > then we used to have a further parameter to the "send_DAO" > function that > tracked the number of already sent Target Options. Further calls to > "send_DAO" would then add the next Target Options. If such > functionality > is needed (@bergzand, @BytesGalore, @smlng any comments on this?) then > we should aim to come up with an unintrusive approach to activate / > deactivate such a behaviour with compile flags. > > > [RJ] Wouldn't a simple compile-time flag such as > DAO_TARGET_CONCAT_NUM=X be sufficient, where X could be 0 (no concat, > send only 1 target container which will be node self IP addr), -1(for > full concat, current implementation), and anything else which means > non-self target container count. The other way to define such a flag > would be DAO_TARGET_CONCAT_SZ=Ybytes ... which defines number of bytes > instead of target count. > > > > Cheers, > Cenk Gündoğan > > On 17-10-19 00:00:34, Rahul Jadhav wrote: > > Hello RIOT team, > > > > While experimenting with RIOT i found the RPL module implementation > > behaviour which sort of stops my network from building up. > > > > Scenario: > > If i have a RIOT 6lr node and it has an FIB with, let's say, 10 > active > > entries, then when the 6lr next sends DAO, it concatenates > multiple target > > containers (from multiple FIB entries) in the same DAO message. This > > results in a packet size crossing link MTU limit (127 in my > case) and for > > my case i do not have 6lo fr
Re: [riot-devel] Graphing build sizes
Hi Kaspar, Back to the mailing list with this one :) We could also move this discussion to a github issue if we're generating too much mailing list traffic with this. On 10/14/2017 11:02 PM, Kaspar Schleiser wrote: > Hi Koen, > > seems like I accidentally replied off list. ;) > > On 10/14/2017 10:51 PM, Koen Zandberg wrote: >> I might have underestimated the amount of data slightly when I started >> this. Currently the CI is building 13.900 test. Triple that for the >> actual number of time series stored. I don't think that there's an >> application optimized for this many series. > Yup, that's a lot of data... Do you think influxdb/grafana can handle > this for only the merged PRs? Yes, the raw data is not a problem. The main problem here is visualisation. Grafana has no issues with displaying a large number of graphs, but at around 200 queries for a single page things start to slow down quite a bit for me. I currently only hit this when displaying a large number of different time series, but storing them in the database is not an issue. Influxdata considers more than 250.000 writes/s with a million unique series "high load" [1]. >> Although I like being able to see the differences in size a set of >> merged PR's generate, I agree that visualizing changes from unmerged >> PR's is one of the more useful features we can get out of this. The data >> isn't hard to generate (diff current master against the PR build). I >> have to think a bit more on how visualization of this is best done while >> keeping it useful and not too processor intensive. > Probably a plain text list, sorted by change (in percent or absolute) > would totally suit our needs, for any open PR. > > Something like: >text data bss total > examples/hello-world samr21-xpro +124b +0b +456b +570b > examples/hello-world iotlab-m3 +120b +0b +456b +566b > > CI needs to warn on any increase (with an additional yellow build result > in github that points to that list). I'm probably just thinking too complicated (or fancy) here, this should do for starters. Koen [1]: https://docs.influxdata.com/influxdb/v1.3/guides/hardware_sizing/#general-hardware-guidelines-for-a-single-node signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Graphing build sizes
Hey, On 10/13/2017 01:28 PM, Hauke Petersen wrote: > Hej, > > On 13.10.2017 13:19, Kaspar Schleiser wrote: >> Hi, >> >> On 10/13/2017 09:53 AM, Hauke Petersen wrote: >>> Thinking out loud: would it make sense to do some data aggregation for >>> more generic views? On first thought I would imagine something like >>> average ROM/RAM size over all application/examples over all platforms. >> Yes! The data should already be there (in the parsed sizes.json). Maybe >> an "all" selector for both application and board would do it? >> >>> I also have an idea for code size diff visualization, that I have in my >>> mind for quite a while: how about we draw a (huge) table, using all >>> available platforms as columns and all available applications as rows. >>> Each cell would then be colored: [...] >>> >>> What do you think about this idea, and how would you assess the >>> doability? >> Well, that table would be *huge* (~100 * 150 cells). We could make a >> bitmap with mouse-over. > This is what I head in mind, talking about something like 5x5 pixes > per cell (or similar) - the term table was more coined as a HTML table > would be the natural construct to build this... I'm going to see if this is already possible via a plugin or if I can build something. I was thinking of building a sizes diff between the start time and the stop time and then color code. This way it should be possible to diff between a single PR, but also over a whole release. One feature that approximates this a bit is a carpet map. These are already available for Grafana and are to data over time, so either all boards or all tests over time. I'll put up a few dashboards to get a feel for these. Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Graphing build sizes
Hi, On 10/12/2017 03:32 PM, Kaspar Schleiser wrote: > Hi Koen, > > (your mail's quoting arrived a little garbled, I'll try my best to fix) Whoops > See [1]. > > Probably a simple http(s) request using wget would do it? I started working on rewriting the script to a microservice. I should have this working in a few days after enough refactoring. >> [1] http://docs.grafana.org/reference/annotations/ > [2] pretty much shows our use-case. ;) Got this one working with PR urls. I want to modify them a bit and see if I can fit the PR title in the description, but I think the general idea works very nice. Koen signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Graphing build sizes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, On 10/12/2017 11:19 AM, Kaspar Schleiser wrote: > Hey Koen, > > On 10/11/2017 04:59 PM, Koen Zandberg wrote: >> For now I want > to keep it up to date by running my script as a cron >> every night approximately after the nightly build. > > If we'd build the in-between HEAD commits, would your script pick them up? If that means I can grab the JSON files based on the merge commit hashes, it shouldn't be that much work to integrate. At that point it might be easier to integrate this work into the CI to trigger it after such a build. >> The dashboard is now a simple Grafana templated dashboard where a test >> >> and a board can be selected. I'd like to expand this by creating a >> dashboard for every test or for every board. The most difficult thing >> for now is to present the huge amount of data in a clear and concise >> way. Input on this and the overview in general is most welcome. > > Is it possible to put the commit hash into each step? If I move my mouse > over a graph, each point shows a pop-up with the timestamp. It would be > very useful to see which commit that belongs too. Maybe even with a link > to the PR page on github? The best way to add this to the dashboards might be to use annotations[1]. I would have to try if it is possible to embed a link in those. I'm not sure if annotation are the best way to show this information, but I don't have a better way at this moment on how to integrate this in Grafana. Koen [1] http://docs.grafana.org/reference/annotations/ -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEM1a0jNDzUUT3pcy6CJWok+bSmFsFAlnfZ/QSHGtvZW5AYmVy Z3phbmQubmV0AAoJEAiVqJPm0phbHSIQAIVIqQfoOKwUzkohe/NdLT2IXjL7iBOk m1N6J2HnKx5DZF1Ye8BhhwcjFcu9qF9GDNNPcxOvuv/uqtvXtrxu7FtjmdY0trk2 DqWcS7tFmtqP0ePY5xOPE11QEdoNJ0P0Nji0En4mB6egi4qFgdyc3CL9B5Vh4D6I qwMwTYPRIprx9rmWZEyEuqVWAmW3FdnPrv2LlCEx+DiZnWoVGbN4EJ4WRy8Nd3XD WiLvKaQgpfm7GBgVjIqx30jBpbW7x9UnqcpL0DGuGx+GT5G/6FN/GLwSd/PERy/5 JZuXyKErXptqEcJop/HOBXsiiU9xSNzBxS3pBRix0qvD9mPnwqU65uQMfAoxlsOT RS4e/1ymPGbN6qsC7UYryVAUwf7w+RTGndnSQW6ig/FuDTesqpkPsWSblm+Czz2t TGcjasykT7UuMT3i+W+DHsA/O7CbSaABG80E+RnzhCzXR7vbR35Yh+Zo9hbN4L1B WWnHl/DdMDMyf2WVzIEj+/J0gnswwtfPG4JIt7LE4tJ6Szbn/PG6Q94Wm/VQnrfm 3+s0yc6I1HRd7vK4QSGO37J8IcNvgRL2+jXUeV7MvO6zqw1Ptcu6gdavzUcSdniP lJLWAMUt93isOI/NFpz+cdoosJJ78CyZUi6bXRJzS74kdc6RmhFRodNVAnHIJRIM 94zzYXdAUAdH =/Phv -END PGP SIGNATURE- ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Graphing build sizes
Hello, One of the issues from the CI discussion at the RIOT summit was the tracking and graphing of the nightly build sizes. After some instructions from Kaspar for getting the JSON files I got something working here: https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1 For now I want to keep it up to date by running my script as a cron every night approximately after the nightly build. The source code of the script that parses and pushes the values to the database can be found at my github [1]. The dashboard is now a simple Grafana templated dashboard where a test and a board can be selected. I'd like to expand this by creating a dashboard for every test or for every board. The most difficult thing for now is to present the huge amount of data in a clear and concise way. Input on this and the overview in general is most welcome. Koen [1]: https://github.com/bergzand/RIOT-graphs signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Mailserver issues
Hello, On 08/11/2017 03:49 PM, Stefan Schmidt wrote: > Hello. > > On 08/11/2017 02:03 PM, Oleg Hahm wrote: >> Hey Adam! >> >> Thanks for the pointer. That's definitely something we should consider. >> >> Cheers, >> Oleg >> >> On Fri, Aug 11, 2017 at 04:52:05AM -0700, Adam Hunt wrote: >>> I was going to suggest that you might talk to the Oregon State >>> University Open Source Lab (http://osuosl.org). OSUOSL offers free >>> hosting, email, VMs, colocation, FTP, backup, etc. (both managed and >>> unmanaged) to open source projects. I can't speak to what type of >>> computing power they offer but I know they've been working to stand up >>> an OpenStack cluster they may be able to help out with CI or in other >>> ways. > > They also offer to host a server of your own. We do that for the > Enlightenment project for several years now. Their connectivity and > general admin service has worked very well for us. > > We have a beefy server there hosting our own tons of git repos, web > services, downloads, CI, etc. I don't think there is any bandwidth > limitation or such. All in all a really nice service from them to the > open source communities. > > If it is something interesting for RIOT I have no idea but if you are > looking for something in that regard it is surely worth talking to them. > > regards > Stefan Schmidt To offer an alternative, I can offer the services of Studenten Net Twente[1]. Studenten Net Twente is a student associations of the University of Twente aimed at providing IT services. We have a history of supporting open source projects by offering FTP space and/or colocation services for free. As we use RIOT-os for an internal project, we'd love to return something to the project. If a host for CI or other services is needed, I can see if I can get a virtual machine or some real hardware available for RIOT-os infrastructure. Regards, Koen Zandberg 1. http://www.snt.utwente.nl/en/index.php ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi, On 06/27/2017 09:42 AM, Peter Kietzmann wrote: > Hi Koen, > > thanks for your explanations! Are you aware of the FIT IoT-lab testbed? > > https://www.iot-lab.info/ > > This should give you access to several hundred iotlab-m3 nodes which are > equipped with an at86rf231. There is also one site with some tens of > samr21-xpros, equipped with an at86rf233. You just made my day, I thought they only had nodes with the at86rf231 > Would be great if you keep me/us informed about your results :-). I should have some slides with results this friday. Regards, Koen > > Best > Peter > > On 26.06.2017 12:36, Koen wrote: >> Hi, >> >> For now this is all quite proof of concept. I haven't had the time to >> measure the actual power saving. >> >> There are still a few problems that limit the actual power saving. The >> way I've implemented it now, only transmit power is limited. Before a >> transmission, the radio power is configured, and almost immediately >> after, the transmit power is set to full power again. This way L2 ACK >> frames are always send at full power and the power scale algorithms of >> nodes don't affect each other. Furthermore, if I have to believe the >> datasheets, the radio's seem to also consume comparable current when in >> RX-mode. For now, until I've confirmed the actual power draw of the >> radio, I think the most benefits are in the reduced transmission range >> and thus reduced interference between nodes. >> >> The other limitation is that my implementation depends on the radio >> reporting the frame retries. At least the mrf24j40 and the at86rf233 >> support this. I don't know about the kw2xrf. The other variants of the >> at86rf2xx don't seem to support reporting the frame retries, they only >> report whether at least an ACK was received or not. >> >> I don't have any plans of repeated tests in network topologies at the >> moment, mostly because I don't have a large enough network at my >> disposal. I'm still trying to get at least repeatable results from my >> small setup, but random interference makes this difficult. Any proposals >> for this are welcome. I'd love to have some larger tests on node >> interaction here. In the future I'd like to try to have RPL minimize >> power consumption as a route metric.> >> The actual power scaling algorithms I've implemented are based on TCP >> congestion control. TCP congestion control also has the goal of >> approaching a limit where loss occurs when the limit is passed. Two >> algorithm are implemented: A "Reno" style additive increase, >> multiplicative decrease and a "Cubic" approach style function. As soon >> as I have some results where I can actually compare both algorithm I'll >> share them here. >> >> One of the other ideas for algorithms I've had so far was a PID kind of >> control loop where a predefined ETX value is used as a setpoint. This >> way a configurable amount of loss versus power saving might be achieved. >> If somebody has a different proposal for an algorithm, I'd like to know. >> I'm currently trying to use only ETX or other already known values >> instead of a negotiating algorithm to keep the implementation compatible >> with different nodes and/or operating systems. >> >> Regards, >> Koen >> >> On 06/23/2017 09:03 AM, Peter Kietzmann wrote: >>> Hi Koen, >>> >>> awesome! IMO this is interesting work and I'd like to push this forward, >>> at least to use it myself at some point in time, though I can't promise >>> an in-depth review so soon -> let's start polishing "later". >>> >>> Did you already start measurements of the actual consumption saving of a >>> node? Do you plan to evaluate your approach in different network >>> topologies? >>> >>> Cheers >>> Peter >>> >>> On 22.06.2017 22:00, Koen Zandberg wrote: >>>> Hello, >>>> >>>> For a small research project as a part of my study, I did some research >>>> on the effectiveness of dynamic radio output scaling. The general idea >>>> is that to save power, the radio has to transmit at only the power >>>> required to reach the destination. For the research I wanted to build a >>>> practical setup instead of a simulation as one of the research goals. >>>> >>>> The setup I've build works by estimating the minimum required powered >>>> and using layer 2 acks (or the lack thereof) as feedback. At this point >>>> I have a mostly working power scaling pro
Re: [riot-devel] Dynamic radio power scaling in RIOT
Hi, For now this is all quite proof of concept. I haven't had the time to measure the actual power saving. There are still a few problems that limit the actual power saving. The way I've implemented it now, only transmit power is limited. Before a transmission, the radio power is configured, and almost immediately after, the transmit power is set to full power again. This way L2 ACK frames are always send at full power and the power scale algorithms of nodes don't affect each other. Furthermore, if I have to believe the datasheets, the radio's seem to also consume comparable current when in RX-mode. For now, until I've confirmed the actual power draw of the radio, I think the most benefits are in the reduced transmission range and thus reduced interference between nodes. The other limitation is that my implementation depends on the radio reporting the frame retries. At least the mrf24j40 and the at86rf233 support this. I don't know about the kw2xrf. The other variants of the at86rf2xx don't seem to support reporting the frame retries, they only report whether at least an ACK was received or not. I don't have any plans of repeated tests in network topologies at the moment, mostly because I don't have a large enough network at my disposal. I'm still trying to get at least repeatable results from my small setup, but random interference makes this difficult. Any proposals for this are welcome. I'd love to have some larger tests on node interaction here. In the future I'd like to try to have RPL minimize power consumption as a route metric. The actual power scaling algorithms I've implemented are based on TCP congestion control. TCP congestion control also has the goal of approaching a limit where loss occurs when the limit is passed. Two algorithm are implemented: A "Reno" style additive increase, multiplicative decrease and a "Cubic" approach style function. As soon as I have some results where I can actually compare both algorithm I'll share them here. One of the other ideas for algorithms I've had so far was a PID kind of control loop where a predefined ETX value is used as a setpoint. This way a configurable amount of loss versus power saving might be achieved. If somebody has a different proposal for an algorithm, I'd like to know. I'm currently trying to use only ETX or other already known values instead of a negotiating algorithm to keep the implementation compatible with different nodes and/or operating systems. Regards, Koen On 06/23/2017 09:03 AM, Peter Kietzmann wrote: > Hi Koen, > > awesome! IMO this is interesting work and I'd like to push this forward, > at least to use it myself at some point in time, though I can't promise > an in-depth review so soon -> let's start polishing "later". > > Did you already start measurements of the actual consumption saving of a > node? Do you plan to evaluate your approach in different network > topologies? > > Cheers > Peter > > On 22.06.2017 22:00, Koen Zandberg wrote: >> Hello, >> >> For a small research project as a part of my study, I did some research >> on the effectiveness of dynamic radio output scaling. The general idea >> is that to save power, the radio has to transmit at only the power >> required to reach the destination. For the research I wanted to build a >> practical setup instead of a simulation as one of the research goals. >> >> The setup I've build works by estimating the minimum required powered >> and using layer 2 acks (or the lack thereof) as feedback. At this point >> I have a mostly working power scaling proof of concept implemented in >> RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg >> which is a measurement of a number of packets. The blue dots is an ETX >> estimation measured based on the feedback from the radio module. The Red >> line is the power configured for that packet. As visible, power is >> scaled down until a stable level is reached. Power keeps oscillating >> around this level until a lot of interference is noticed, then the power >> sweeps back up. >> >> The merit of this whole idea is that it should both save the node power, >> but when implemented correctly also improve the total throughput of the >> network. This last point because nodes transmit with less power, thus >> causing less interference with nodes further away. >> >> If there is interest in having this feature merged in mainline RIOT-os, >> I'm willing to work on this to make sure that the code quality is as >> required. The code can be viewed and tracked at >> https://github.com/bergzand/RIOT/tree/mwn2 >> >> Regards, >> Koen >> >> ___ >> 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
[riot-devel] Dynamic radio power scaling in RIOT
Hello, For a small research project as a part of my study, I did some research on the effectiveness of dynamic radio output scaling. The general idea is that to save power, the radio has to transmit at only the power required to reach the destination. For the research I wanted to build a practical setup instead of a simulation as one of the research goals. The setup I've build works by estimating the minimum required powered and using layer 2 acks (or the lack thereof) as feedback. At this point I have a mostly working power scaling proof of concept implemented in RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg which is a measurement of a number of packets. The blue dots is an ETX estimation measured based on the feedback from the radio module. The Red line is the power configured for that packet. As visible, power is scaled down until a stable level is reached. Power keeps oscillating around this level until a lot of interference is noticed, then the power sweeps back up. The merit of this whole idea is that it should both save the node power, but when implemented correctly also improve the total throughput of the network. This last point because nodes transmit with less power, thus causing less interference with nodes further away. If there is interest in having this feature merged in mainline RIOT-os, I'm willing to work on this to make sure that the code quality is as required. The code can be viewed and tracked at https://github.com/bergzand/RIOT/tree/mwn2 Regards, Koen ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Implementation ideas for rpl ETXOF/MRHOF
Hello, I'm looking into RPL objective functions for RIOT. My main goal is to extend RIOT-os such that RPL can be used in a practical wireless ad-hoc network. For now we constructed a temporary setup with a border router and up to four nodes. The problem we ran into with our initial setup is that the parent selection of RIOT only uses the rank. If a node only barely receives a DIO frame from the border router, it will switch the parent to the border router while a lower ranked node is a better choice in terms of link quality or ETX. My current goal is to implement ETXOF[1] or/and MRHOF[2] as an objective function for RIOT. I realize that this is not an easy task. This way I hope to have a node decide that an incidentally received DIO frame is not the cause of a switch to a worse parent. Now to implement this I've looked into tracking ETX values within RIOT. How exactly ETX values are calculated I'm still trying to figure out. The first assumption I've made is that the 802.15.4 transceiver used has link layer acks enabled and reports RSSI/LQI and retransmission values. I'm currently looking along the lines of making an initial ETX estimation based on the reported RSSI and LQI. This value can then be adjusted with the retransmission statistics. In RIOT I was thinking to make a separate array of structs with L2-address and statistics. This table can then be maintained in the gnrc ieee802154 code. The table doesn't have to be that large, maybe equal to the ncache table, but I would have to test how large the table should have. For now I think it doesn't take a lot of code to update entries within table. I haven't thought about what to do if the table is full and a new entry is needed. The RPL functions can then query the table for the required statistics. My first idea was to add a statistics part into the neighbor cache table, but this looked like a bad idea after some research. The main reason is that a L2-address can occur multiple times in the ncache table. Now to summarize my questions: - How would you calculate ETX assuming the provided RSSI/LQI and retransmission values? - Is a separate table with L2 statistics the right way(tm) to do this? - Any ideas what to do with entry expiration? Any comments/questions and remarks about this idea? Your feedback is appreciated :) Best regards, Koen [1] https://tools.ietf.org/html/draft-gnawali-roll-etxof-01 [2] https://tools.ietf.org/html/rfc6719 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] CoAP observe support
Hi Ken, Sorry for the slow response. Time limitations are also an issue for me. I'm going to look at the code in the next few weeks when I have time. Besides the work for coap observe, what would be the priority to work on? Koen On 01/10/2017 12:31 PM, Ken Bannister wrote: > > Hi Koen, > > Thanks for your interest! I am working actively on Observe support for > gcoap/nanocoap. I don't see a technical difficulty -- the biggest > issue for me is time to work on it. :-/ My first goal is server-side > support. I plan to create a WIP PR within a week or two, so at least > there will be a place for discussions. You'll see a new branch in my > repository before then, and I'm happy to discuss at any time. > > If you are generally interested in contributing to CoAP within RIOT, > both nanocoap and gcoap could use some help. There are a couple of > open PRs for work on nanocoap. Certainly it would benefit from more > documentation and unit tests, which are a great way to get into the > code. I also maintain a wiki about gcoap [1], and also have written up > some issues as 'notes to self' [2] but would be happy for someone to > move them to official RIOT issues. gcoap also needs full-on > confirmable messaging support, which actually is a requirement for > Observe. > > Ken > > [1] https://github.com/kb2ma/RIOT/wiki/gcoap-Status > [2] https://github.com/kb2ma/RIOT/issues > > > On 01/10/2017 04:56 AM, Koen Zandberg wrote: >> Hello, >> >> I was looking for a CoAP implementation to use with RIOT. Having looked >> at both microcoap and nanocoap (gcoap), as far as I could tell both lack >> observe support. Are there difficulties with implementing this? If there >> are no blocking issues with it, I might be willing to spent some time >> trying to get it working. >> >> Koen. >> >> >> >> >> ___ >> 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 signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
