Headworx

One of the failures of the widespread silicon - software technology surrounding us is it is very short lived. Ad-hoc reboots, battery replacements, even device replacements are part of our daily lives. Software updates used to be a nightmare too, but thanks to the widespread connectivity they have become less annoying, moving to the background. This is interesting like the continuous improvement in software maintenance and testing has made this task that was so annoying and tedious a much more bearable operation. Something that has become fully automatic, to the point is is almost invisible. None of us can say today which software version is running on their phone or a personal computer. The answer is - probably the latest. So we may say the software problem has taken care of itself, as vendors will continue delivering in the background well-tested upgrades, as long as it is economically feasible for them. And when it becomes not feasible, the device is left on its own. As long as it c...

In automation systems, circuits that have high latency (and high gain) are the most difficult to control. Assuming you're running a closed-loop control algorithm, you apply an input signal and check for changes in the output. If the reaction is instantaneous, it is easy to apply an input that results in a required output. But if the reaction is delayed, it all becomes messy and you must be very careful with manipulating the input. There are many real life examples of such "systems". A simple one involves drinking alcohol. If you only control your input by judging the output, you will overdose very quickly. This is where usually other external inputs, like experience, come in, suggesting slowing down. Many years go I had a car, which was phenomenal on paper and terrible to drive. It had a very powerful turbo-charged engine and an automatic gearbox. The engine had a long turbo-lag and the gearbox did not have any predictive logic, only reacting to the engine output....

Testing the software turns out to be the major cost of product development for us. It is mostly responsible for moving a typical feature from a PoC (Proof of Concept) state to a fully production quality state. Depending on a feature, the PoC is 20% to 10% of the effort. And the PoC works (that is the whole purpose of a PoC). So from the management point of view it is sometimes hard to swallow - the fact that we need to work 5x (or 10x) longer to release the feature. But it is all much more complex in embedded, where you fight for every piece of a resource, such as Flash, RAM, system interrupts, hardware timers etc. Having said that, testing is really one of the outcome of the software revolution. The fact that you actually CAN test. Test repeatedly, test every build, test, test, test... In our infrastructure we run several thousand automated tests on a typical build of what is considered "a firmware for a lightbulb". The tests take a whole night. And the multi-year statis...

Wireless video has been the fail of the decade. Video projectors have always been messy. Back in the times of VGA, a typical conference would not happen without a presenter struggling connecting her/his laptop to the projector. Something was always wrong. Either the connector pin's were bent or the signal was out of sync or too weak, or the resolution could not match or, when everything seemed to be OK, a video clip embedded in PowerPoint was playing only on the computer's screen, leaving a black box on the projected image. HDMI has changed this a bit, albeit not fully. It has been sharing similar issues with resolution, synchronization, signal strength, , and loose connector. Only the pins were not bending, as a HDMI connector has no pins. In the meantime we were promised wireless video would solve all these issues. Unfortunately it still has not... Several technologies arrived in the meantime: UWB, MiraCast, Intel Wireless Display... But none has really prevailed, and a...

We've published  - what I consider very informative - The Myths, Facts, and Futureof Wireless Lighting Control on https://www.bluetooth.com/blog/ . It is quite a read and for those who feel overwhelmed by 2 pages of text, a single word to remember about Bluetooth mesh: MULTICAST I was posting on multicast many times before. It is obvious that this is a fundamental requirement for lighting control. Actually the requirement is low - latency - secure - multicast, which requires blending fire and ice and I believe this is where Bluetooth mesh excels. It does other things very well too - like privacy, openness, interoperability and ease of use . All these advantages are the ingredients needed for a broad market adoption. But from an architectural perspective, I think multicast is where Bluetooth mesh is really different from other potentially competing technologies. Ah... and it is also fully DECENTRALIZED This is the second fundamentally different architectural approach...