Hi all, > The problem with that is that it requires unicast communication between > the nodes, which usually doesn't happen between random nodes. > The problem was also that the at86rf231 radio didn't have hardware > retransmission reporting, so I tried a couple of other metrics. > (Now this could of course be solved in software if the driver was ported > to the new 802154 sub-MAC)
FYI, I'm already porting this radio to the Radio HAL. In fact, this was the first radio that ran the Radio HAL and SubMAC, but it's in a very hacky state. I plan to get it in a consistent state soon-ish. Cheers, José On 20/11/30 02:58PM, Benjamin Valentin wrote: > On Mon, 30 Nov 2020 09:36:06 +0100 > Robert Hartung <hart...@ibr.cs.tu-bs.de> wrote: > > > Thanks Benjamin, > > > > as far as I understand RPL MRHOF [0] uses ETX, which is the expected > > transmission count, i.e. how many transmissions do you need to > > transmit a packet as successful, which can be based on ACKs purely > > (if you have unicast communication). > > At least back in the Contiki days, the metric wasn't based on LQI at > > all [1]. > > The problem with that is that it requires unicast communication between > the nodes, which usually doesn't happen between random nodes. > The problem was also that the at86rf231 radio didn't have hardware > retransmission reporting, so I tried a couple of other metrics. > (Now this could of course be solved in software if the driver was ported > to the new 802154 sub-MAC) > > > In addition to the LQI definition. There is no guarantee that the LQI > > values span over the full range of 0 - 256 and not even evenly spaced. > > We had big troubles when using LQI from different radios. A colleague > > published the results partially in [2]. > > Thank you, I'll take a look! > > > I didn't find mrhof for RPL [3] - you said that you found the LQI to > > work best? > > MRHOF for RPL was never merged. There was a PR by Koen a few years ago > that I tried to revive earlier this year. [0,1] > This only contains ETX, but I have a local integration branch where I > implemented other metrics. > I will update the RPL PR once the required neighbourhood statistics [2] > are in. > > But it seems that there isn't much interest in RPL to begin with, so > maybe that's a dead end. Zephyr dropped their RPL implementation [3] as > nobody wanted to maintain it [4]. > > > Have you tried in heterogeneous networks with different radio > > transceivers and how it behaves? > > I only tried with the at86rf231 on the testbed. > > Best, > Benjamin > > [0] https://github.com/RIOT-OS/RIOT/pull/7450 > [1] https://github.com/RIOT-OS/RIOT/pull/14623 > [2] https://github.com/RIOT-OS/RIOT/pull/14448 > [3] https://github.com/zephyrproject-rtos/zephyr/pull/12407 > [4] https://github.com/zephyrproject-rtos/zephyr/pull/10679 > _______________________________________________ > users mailing list > users@riot-os.org > https://lists.riot-os.org/mailman/listinfo/users
signature.asc
Description: PGP signature
_______________________________________________ users mailing list users@riot-os.org https://lists.riot-os.org/mailman/listinfo/users
