1. I'm surprised that TDOA based multilateration works in software when the wave speed is the speed of light! EM moves fast!

2. This module (dw1000) looks expensive! But maybe there's a use that justifies the cost?

3. I don't know anything about this sort of hardware, but any chance you can access the raw waveform and do the delay measurement yourself? This opens new and exciting possibilities...

4. I'm curious what's different between this and every other p2p IoT comm layer that I hear about (LoRa, zigbee, thread...). A compare and contrast would be enlightening.

5. Compliments to OP on the amount, and quality, of text in the code. I (sometimes) write firmware for a living, and the driver in common/dw1000.c (based on only skimming for a few moments) appears Quite Correct. Good firmware drivers should be a C or C++ representation of the datasheet, with no embellishment.

Regarding 3: pretty much, you can get the estimated channel impulse response from the device.

https://www.decawave.com/wp-content/uploads/2018/10/APS006_P...

I am only superficially familiar with the state of these wireless protocols. A lot of both enterprise and OSS-community attention for wireless mesh and IoT seems to be focused around (proprietary, patented) LoRa/LoRaWAN.

Did you consider them, and what made you decide on UWB? What are pros/cons in your opinion for a use-case like Hyperspace?

Traditional LoRaWAN is based on a star topology rather than a mesh (I say traditional as there are P2P and mesh flavors of LoRa now available). OP mentioned wanting to retain network functionality in the event that the network gateway goes down which would rule out LoRa / star network topologies.

Is this something inherent in the protocol making it less suitable for mesh applications or simply convention and lack of implementation? Do the mesh flavors require new hardware?

LoRa gets part of its efficiency from fairly brutal sleeping, to the point where the radio would only get turned on to transmit when sensor data meaningfully changed or some (weeks) timeout comes up to say "yes, I'm still alive".

Also, it's range being longer than normal mobile phone cellular radio allows getting away with sparingly-positioned gateways.

Also it's not truly star, but rather gateways vs. nodes (at least with the popular LoRaWAN stuff). All gateways that pick up a node's transmission will report it to central servers.

I’ve read through the GitHub repo and your message here and was surprised to see this is an 802.15.4 IPv6 mesh yet I see no mention or comparison to Thread - for which this project appears to be heavily influenced by or copy of.

I also have significant knowledge and experience of the current IoT space (specifically focused on the consumer market) and while standardizing these lower layers of the OSI stack is important it will not solve your interoperability concerns. Secure IP based IoT device connectivity is largely a solved problem - the currently _unsolved_ problem blocking interoperability is mass standardization and adoption of an interaction, device, and data model. Zigbee, Z-Wave, HomeKit, Weave, etc. all provide different and unique ways to describe the ontology and capabilities of a “thing” and it is at that layer that mass adoption is needed. Imagine if every PC manufacturer used a different variant of HTTP, REST, and JSON - that is the state of the consumer IoT market today.

The new hot thing in this space is Matter, which does appear to have commitment from the major consumer players for mass adoption. Obviously it is too early to say if this will drive the mass standardization and interoperability you mention, but personally speaking I am very optimistic and excited :)

IMO, when a project starts based on flawed assumptions, it is sure to be short-lived. See, I have nothing against mesh networks or location-based services. I've personally done some things using decawave chips, and I think it's amazing. The point here is that "location doesn't matter" when we're talking about networking. Let's say we have a football team. you have three teammates near the goal, two of the defense guys are right next to the goal, closer to you. And there is the third, an excellent striker, who is a little further from the goal. Who do you kick the ball to? And let's say it's not a good day for your best player and he's tired because he's been partying for three days, would you rather shoot straight for the goal? The point is that all this QOS confusion exists for a good reason, because good routers and network devices have become bad for the most different reasons, and the network must ADAPT to that, and location is a STATIC value, so it doesn't matter. BGP was invented so we could not worry about location. The message gets there, no matter the condition. If you're not connecting to the closest device in the mesh, you already have a problem. This means that despite the power, your mesh router is probably overloaded by some other device, does not like its packets, has been partying for three days, or it's just bugged, so either way it will find the next possible glimpse of the network connection to deliver its message. That made the INTERNET resilient.

I think the OP is using location not as a metric for packet routing or anything else related to the networking aspect, but as an additional piece of information that applications running on the mesh network can make use of.

Even if he is not talking about network, the example he used in github is flawed, of "auto connected devices, based on distance", maybe in US reality, where you have big houses, but ceratinly not in a real world scenario, with thousand of small apartments with everything near. The solution already exists and is not hard. try to register an airtag, or setup a new iphone with the old one and you will se the process is painless, and there is no 3d location involved.

The first example used was "auto configure the device, based on the room". 3D location helps with this, even if the only configuration is automatic labeling of the device, eg. "Kitchen Light 3".