That's a really good question and part of it is that this shit is super hard and takes forever and it's totally binary: it works or it doesn't and you spend a lot of time in the "doesn't" and that is soul-crushing for anyone. So there's that barrier to cross, haha. But I think you're asking more about what decisions as we designed/planned our mesh network topology has enabled us to do this.... and I think it's because we started by focusing on an MVP and then became philosophically attached to that MVP in the long-term for different reasons beyond just being a practical place to start.
What that meant for us is we decided to focus specifically on burst data. As a result our hardware can be lighter/smaller/less expensive and our networking protocols can scale to do things that other mesh projects have failed at.
For goTenna/goTenna Mesh, not doing real-time high-bandwidth media transmissions is a feature not a bug. Plus, focusing on packetized burst data transmissions doesn't preclude us from even sending a whole Netflix show over goTenna if we wanted to, because you could technically send a video over in lots of small packets and reconstruct it at the other end. Everything, after all, are 1's and 0's. (BTW with our SDK you can do that if you'd like! We're still gonna be focused on text & GPS in our own apps for now - for both goTenna v1 and goTenna Mesh).
Because we didn't have the choice of working on beautiful licensed spectrum used by limited users and less subject to regulations by government. We always had to by definition design goTenna (and now goTenna Mesh) to work on public spectrum which is a scarce and shared resource with potentially unlimited users and regulations that we have to fit into.
TL;DR: Focusing on burst data has been a really great way of scaling our technology from the first intelligent protocols that power v1 (which we call Aspen Prime) and goTenna Mesh (Aspen Grove).
Also perseverance. And naivete probably helped too because it's easier to get into something difficult when you have no clue how hard it's gonna be. We've learned a lot along the way since our first working prototypes in early 2013.
(Sorry if I sound barely coherent right now; I haven't slept in a few days leading up to goTenna Mesh launch!)
What that meant for us is we decided to focus specifically on burst data. As a result our hardware can be lighter/smaller/less expensive and our networking protocols can scale to do things that other mesh projects have failed at.
For goTenna/goTenna Mesh, not doing real-time high-bandwidth media transmissions is a feature not a bug. Plus, focusing on packetized burst data transmissions doesn't preclude us from even sending a whole Netflix show over goTenna if we wanted to, because you could technically send a video over in lots of small packets and reconstruct it at the other end. Everything, after all, are 1's and 0's. (BTW with our SDK you can do that if you'd like! We're still gonna be focused on text & GPS in our own apps for now - for both goTenna v1 and goTenna Mesh).
Because we didn't have the choice of working on beautiful licensed spectrum used by limited users and less subject to regulations by government. We always had to by definition design goTenna (and now goTenna Mesh) to work on public spectrum which is a scarce and shared resource with potentially unlimited users and regulations that we have to fit into.
TL;DR: Focusing on burst data has been a really great way of scaling our technology from the first intelligent protocols that power v1 (which we call Aspen Prime) and goTenna Mesh (Aspen Grove).
Also perseverance. And naivete probably helped too because it's easier to get into something difficult when you have no clue how hard it's gonna be. We've learned a lot along the way since our first working prototypes in early 2013.
(Sorry if I sound barely coherent right now; I haven't slept in a few days leading up to goTenna Mesh launch!)