Hi! I'm having problems confirming that RPL is set up properly -
I can ping local addresses from the "middle node" but the border router doesn't seem to make a complete tree and can't see beyond the first node 
I'm using a fairly standard border router example and nanocoap: https://github.com/kmartinez/myRIOT
Am I missing anything to help RPL on the nodes? cheers! Kirk
Hi,
did you check if the DODAG was actually constructed (you can use the `rpl` command for that). The problem you describe sounds like your nodes are just using neighbor discovery to find their neighbors, but that there are no routes configured. If there is no RPL root (with both UHCP and DHCPv6 it should be started however once the BR receives a prefix) you might need to start one manually, using the `rpl root` command.
Best regards, Martine
Can any of the simulated/emulated environments deal with creating a multi-hop network? I know that many people have worked such things, but I don't know how mainstream they are. (I always hated the Cooja approach: good for people writing papers about algorithms, bad for actually getting deployable code)
So, by limiting "radio" propogation by distance, or by creating simulated networks where nodes have multiple interfaces.
Either way, my goal/thoughts is to collaborate on doing a screencast explaining how to set things up, and how to debug them.
Worst case, have to do with with five devices on a table, and maybe some metal walls!
I am only doing physical tests 
You can set the power of the samr radios to a minimum and get hopping across a house.
In my case I have max power and trying to check hopping across a forest (more walking when reflashing is needed!)
OK it seems auto rpl doesn't start - so I have forced it with this in main.c:
gnrc_rpl_init(5);
it turns out I needed less power than -4dBm on the samr30 to get it below -90 RSSI across the house. So I had to also put it in an old metal pc case!
So success in the end - after waiting a couple of minutes nib route switched from 2001:fdfd::ec26:3905:43b7:5a6e/128 via fe80::ec26:3905:43b7:5a6e dev #5 to 2001:fdfd::ec26:3905:43b7:5a6e/128 via fe80::5c1d:e070:a4e1:52 dev #5
showing it was hopping via its strong neighbour. Its ping time went up from 90ms to 240ms as expected.
Now to put them out in the forest again! Cheers Kirk
I am only doing physical tests
You can set the power of the samr radios to a minimum and get hopping across a house.
In my case I have max power and trying to check hopping across a forest (more walking when reflashing is needed!)
but, it's hard to get debug output from across the forest. We need some kind of repeatable simpler test framework to be able to kill bugs.
socket_zep would fit the bill. It encapsulates 802.15.4 frames inside an UDP packet and sends those to a dispatcher. This way radio communication can be simulated on native.
Currently only a dummy dispatcher [0] is implemented which relays all frames to all connected nodes, with no packet loss. But it could be extended to allow modelling more advanced topologies with packet loss between the nodes. This was done before [1] but I don't know if it still works with the current RIOT.
The dispatcher could then also update the link quality field in the ZEP header, so if we get neighbor statistics [2] merged, we could then also test metric based routing.
Best, Benjamin
[0] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/zep_dispatch [1] https://github.com/miri64/zep_mesh [2] https://github.com/RIOT-OS/RIOT/pull/14448
but, it's hard to get debug output from across the forest.
>> We need some kind of repeatable simpler test framework to be able to >> kill bugs.
> socket_zep would fit the bill. > It encapsulates 802.15.4 frames inside an UDP packet and sends those to > a dispatcher. This way radio communication can be simulated on native.
> Currently only a dummy dispatcher [0] is implemented which relays all > frames to all connected nodes, with no packet loss. > But it could be extended to allow modelling more advanced topologies > with packet loss between the nodes. > This was done before [1] but I don't know if it still works with the > current RIOT.
Interesting piece of work.
> The dispatcher could then also update the link quality field in the ZEP > header, so if we get neighbor statistics [2] merged, we could then also > test metric based routing.
> [2] https://github.com/RIOT-OS/RIOT/pull/14448
It seems to need another rebase, but what other objections are there?
It seems that maybe it still has bugs, and maybe it should be split up into maybe two three patches: one to add structure to collect the stats (neighbor.h, netstats_nb_t, etc.)... I'm unclear if there are network driver changes needed too.
[I mean, except that NEIGHBOUR has a EWE, Eh!]
> The dispatcher could then also update the link quality field in > the ZEP header, so if we get neighbor statistics [2] merged, we > could then also test metric based routing.
> [2] https://github.com/RIOT-OS/RIOT/pull/14448
It seems to need another rebase, but what other objections are there?
Not sure, I guess nobody found the time to do a review yet.
It seems that maybe it still has bugs, and maybe it should be split up into maybe two three patches: one to add structure to collect the stats (neighbor.h, netstats_nb_t, etc.)... I'm unclear if there are network driver changes needed too.
Many drivers already report RSSI or LQI and with the new sub-MAC we can always make sure to always get ETX if required. (But some drivers already report that).
I found LQI worked best for RPL (if the radio provides it) as it doesn't require active (unicast) communication between peers.
[I mean, except that NEIGHBOUR has a EWE, Eh!]
Heh, what's that?
Hey,
just my two cents regarding LQI: The LQI is very different for different radios. So be aware of that in heterogeneous networks with different radios!
Best Regards - Robert
It seems that maybe it still has bugs, and maybe it should be split
>> up into maybe two three patches: one to add structure to collect the >> stats (neighbor.h, netstats_nb_t, etc.)... I'm unclear if there are >> network driver changes needed too.
> Many drivers already report RSSI or LQI and with the new sub-MAC we > can always make sure to always get ETX if required. (But some drivers > already report that).
> I found LQI worked best for RPL (if the radio provides it) as it doesn't > require active (unicast) communication between peers.
Yes, true.
>> [I mean, except that NEIGHBOUR has a EWE, Eh!]
> Heh, what's that?
Americans write neighbour as neighbor. No "U", or EWE.
just my two cents regarding LQI: The LQI is very different for different radios. So be aware of that in heterogeneous networks with different radios!
True, the standard (IEEE 805.15.4-2020) only states
The LQI measurement shall be performed for each received packet. The minimum and maximum LQI values (0x00 and 0xff) should be associated with the lowest and highest quality compliant signals detectable by the receiver, and LQI values in between should be uniformly distributed between these two limits. At least eight unique values of LQI shall be used.
However, RPL (MR-HOF) uses hysteresis and by default requires an improvement of 192 on the whole path before it switches.
So as long as LQI can give a rough estimate of link quality, it should be good enough. This is not about estimating distance where some sort of accuracy was required, but just to throw out really bad links.
Best, Benjamin
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].
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].
I didn't find mrhof for RPL [3] - you said that you found the LQI to work best? Have you tried in heterogeneous networks with different radio transceivers and how it behaves?
Best Regards Robert
[0] https://tools.ietf.org/html/rfc6719 [1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-mrhof.c [2] https://ieeexplore.ieee.org/document/8510975 [3] https://github.com/RIOT-OS/RIOT/tree/master/sys/net/gnrc/routing/rpl
Don't you want to move this topic to the forum? I have a hard time following it. I also think it is helpful for other user to find more information about it. https://forum.riot-os.org/
yes thats sensible... I'd really like to understand how to tweak rpl to be happy at low rssi this week so my conference poster is clearer
Can someone add me to the forum please? git hub: kmartinez cheers! Kirk
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] gnrc/rpl: Implement Minimum Rank with Hysteresis Objective Function by benpicco · Pull Request #14623 · RIOT-OS/RIOT · GitHub [2] https://github.com/RIOT-OS/RIOT/pull/14448 [3] net: rpl: Remove the deprecated code by jukkar · Pull Request #12407 · zephyrproject-rtos/zephyr · GitHub [4] Deprecate RPL by rveerama1 · Pull Request #10679 · zephyrproject-rtos/zephyr · GitHub
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é
Hi,
the forum is not public yet, but will be soon. Once it is, this mailing list (and others) will be imported there, so this conversation will not be lost. However, it might be confusing, when it is split ;-).
Best regards, Martine
Oh thanks…
Any idea if low rssi links would stop ppl working?