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
