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 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 >> _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
