Headworx

As the Bluetooth mesh networking specifications are now public, we can start dissecting and discussing various building blocks of this - I do not hesitate to say - revolutionary system. There are many novel and unique concepts in mesh, but in my opinion the key asset and differentiator is the packet. It is extremely compact. This compactness contributes to the spectral efficiency (and throughput) of Bluetooth mesh networks. Radio is a shared medium and collisions are one of the key problem to combat (or avoid). The math is simple: a shorter packet means less collisions. But how short can it be? The answer is: up to 29 bytes, as described in the section 3.4.4 of the Mesh Profile specification. Of course you start such design with the basics: compressed binary payload instead of a text representation. Covering a really broad set of use cases (building automation, sensors), 11 bytes for the application payload seems appropriate. 1-2 bytes for an opcode and up to 10 bytes for para...

There has been no event anticipated more than the public launch of Bluetooth Mesh . It all started back in 2013 when Google rolled our Android 4.3 with API level 18 , introducing support for Bluetooth LE. AT that time I knew (almost) nothing about Bluetooth, but I knew IPv6 over 802.15.4 was a pipe dream. IPv6, even with the 6Lo compression has simply been too heavy too fly and 802.15.4 has been too slow to give it a lift. Yes, back in 2012-2013, at Silvair we tried something very similar to what Thread is today, and unfortunately we found this combination incapable of addressing the needs of wireless lighting. Hence looking for a new radio. Google's announcement of support for Bluetooth LE in Android sparked hopes. BLE was already supported by iOS, so with Android on board it seemed like a good candidate to try. It did not fly either. We quickly found out the single-hop range was really limited and the hub-and-spoke topology offered was far from anything usable for our nee...

It is funny how on a daily basis we still keep on applying the common wisdom to the world we aim to change (and are actually succeeding in changing...). Last week my co-founder was shopping for a pair of wireless headphones. Bose has always been his preferred brand and he owns a wired Bose headset. The wired one comes in two variants: Apple and Android. There is a slight difference in how the fwd / rev buttons work on each platform. After finding the wireless (Bluetooth) equivalent, he wanted to make sure he was picking the appropriate variant, so asked the lady behind the counter if they have an appropriate variant. The answer was obvious: "Sir, this is Bluetooth. It works with everything!". I really regret we did not record that answer. It was so obvious to her. Really the way it should be. Yes. The most important thing Bluetooth really succeeded in is interoperability. Not many standards come close...

The common wisdom about startups is they are roller coasters. Especially for investors and founders. I offer to challenge this opinion. A startup is the most secure guarantee of a success. Both on a personal development and an investment front. The reason is a startup is the most effective learning environment you can imagine. Through deep personal involvement and through an extremely broad and complex problems that need to be solved. Running a startup is probably more effective (in terms of a learning curve) than Stanford, MIT, or any other top rated university. You just have to be open to learn. And if you are, there is this continuous supply of knowledge every day, every hour, almost every second. Guaranteed. No other environment creates so many opportunities for creative problem solving, trials, testing hypothesis, and iterating all of that in rapidly spinning cycles. Of course it will not only be smiley and lazy days. There will be a lot of rain and ice. And it will t...

Multicast has always been our fundamental requirement when designing low power wireless networks. It brings enormous efficiency into a system. A single message, such as a sensor reading or a dimmer setting action is sent out in the air and picked up by multiple receivers, which act upon such message. The key problem here is reliability. Usually (and this is a human nature) we want to hear a confirmation. But that can be very costly and slow. Up to a point of not serving the initial purpose at all. Like in a lighting system. A typical ceiling in a commercial building today has dozens of lights. Often more than a hundred. But even with small rooms equipped with as few as 20 lights, multicast is orders of magnitude more reliable, compared to acknowledged unicast traffic. After all it is all very simple. Let's assume a probability of delivering a single message to a destination is 90%. Meaning there is 10% chance the message will not be received (for many reasons: interference,...