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. Would be great if you keep me/us informed about your results :-). 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 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 > -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
