And I'm out. Mesh networkers really should spend a bit of time re-learning all the lessons from decades of ham radio packet networks.
And I'm out. Mesh networkers really should spend a bit of time re-learning all the lessons from decades of ham radio packet networks.
It sounds like the criticism hints at the hidden node problem. (Briefly: One of the largest problems in wireless networking. A and B can hear each other, B and C can hear each other, but A and C can't. So when C wants to talk to B, how does it know if A is already transmitting and B's receiver is already listening? In large networks this gets hugely important.)
But it sounds like the simulation is already maximally pessimistic about it -- there's no RF attenuation in the drawer, so all the devices occupy the radio channel whenever they're transmitting. So I would imagine that software that works well in this case, would probably also do decently in the real world. (As opposed to software tested on a naively-simplified network of RF cabling and attenuators, which would not model the hidden node problem's complexities very well.)
So, while the real world will surely be more complex than they hint at in their sentence, I think the simulation drawer is also better than you hint at in yours.
There are nuances, of course, and frankly there are RF network simulators they could be using, but I think the presented MAC-filter approach is not terrible.
It is possible to take these issues into consideration, but as you say, that requires a very different infrastructure than what this article is talking about. The way we do it at Thingsquare is to use a software-based simulator where we can both emulate the software on the devices and have full control of the simulated radio medium - if we need it. Sometimes using RF attenuators and/or cabling is useful.
In the end, what it comes down to that each tool has one or more use cases where it shines, but there is no one tool that fits all.