The very first batch of Flic we created cannot be firmware updated. Unfortunately this means that they are not future proof and cannot be used with much of the new functionality we are providing. That sucks.
The First Batch is the most important batch
Shortcut Labs is the first company we (ok, most of us) ever ran and Flic is our first product. We are a young startup with young employees and management, without any real experience in creating connected hardware products. Even though Flic is “just a button”, creating it has been far more challenging than we could have imagined.
The crowdfunding campaign we ran for Flic became one of the most successful in the Nordics. Thousands of people supported us just the first days of the campaign, believing in the idea and believing in us to make it happen. They put their real money at stake, at high risk.
These are the people that believe in technology, that are proud to support startups and that tell their friends about it. They spread the word and people listen when they talk. They are the seeds in grass root financing.
Yet these people, the early adopters, are the ones that we and many other crowd funding projects manage to disappoint, over and over again. This is because they are the ones who suffer most from delays and because they are the ones that will receive the first batch.
Component cost googling
When trying to launch a hardware product for the first time, you need to do early cost estimates. It starts with component cost and an estimation of the price of each component. In the later stages of the design cycle you can quote factories about volume prices and delivery times for all the finalized components required to get a far more accurate cost estimate. But way before that you may do as we did, google component costs. Try to avoid that and more importantly: don’t trust it.
We calculated the maximum acceptable cost for manufacturing Flic, knowing that we had to stay under that figure to make a viable business out of the product. We googled component prices and got a basic understanding.
Memory, as it turned out, is one of the most expensive components in our design as the component size needed to be minimal to fit our vey compact PCB.
From googling we quickly understood that doubling the memory capacity doubles the price.
We knew the memory size was needed for the firmware and some space for optimizations. With that memory space we could update all the most important parameters such as connection time intervals and power saving algorithms, while still leaving some space available for the Flic buttons to remember which phones they are allowed to connect to. But to update the entire firmware from scratch, we would need to double the memory space.
Our lead engineer was clear: if we don’t get the larger memory we can’t completely update the product.
But why would we ever need to completely refresh the firmware? The core functionality was well tested, bug free and all optimization parameters could still be updated. The functionality is so simple, just send a single event to a known host when you get clicked! Plus, we did not anticipate, nor did we promise, that Flic would get more core functionality over time (integrations on the App side, e.g. Actions, we would still be able to update).
Doubling the memory would double that components price based on our google research, which would add around $4 USD to the total retail price.
The technology was supposed to be future proof
Flic makes use of Bluetooth Low Energy, which is an integral part of Bluetooth 4.0. When the idea of Flic was first conceived in 2012, this technology practically only existed on paper. Two years later as we were finalizing the design, Bluetooth Low Energy was built in to every new smartphone and tablet on the market.
Google Android 6.0 Marshmallow is the first OS to implement Bluetooth 4.1. Differences from Bluetooth 4.0 are minimal.
The Marshmallow release was perfectly timed with the First Batch being shipped out.
In BT 4.0 a few bits in the pairing setup were reserved for future use. These parameters were supposed to be ignored since they could end up being used in future protocol specifications. In the core Bluetooth stack implementation in the chip, a code licensed by a third party provider, these ignored bits were not parsed correctly.
They were not ignored, they were null.
While that ridiculously small difference made no impact before, it suddenly caused all pairing attempts between new Android devices and Flic to fail. We noticed this as our first batch was just sent out. We asked our backers to not upgrade to Android 6.0 until we worked out a solution.
We also asked if anyone knew someone on the Android team who could help us out. Just a couple of hours later, we were introduced to the right guy at Google (the power of our community!) who helped us out and patched Android for Flic, basically whitelisting the Bluetooth MAC range of that batch. In Android 6.0.1 and future revisions, that First Batch still works.
How could we not have noticed before, in beta versions of Android 6? Mysteriously, the MAC range used by the development boards from our chip provider were already white listed in Android. No one knows why.
A quick reaction
From our side, the patch to fix the error was simple and we immediately patched future versions of Flic from the factory. The First Batch were not malfunctioning thanks to our friends at Google. But we also came to think about something.
Did we ever really check the actual price of that double memory component that would allow us to update the firmware of new Flics?
Turns out a double memory size is not equal to double cost. Quite the opposite, the price difference is only marginal when quoted by professionals. We quickly bought tens of thousands of the bigger memory, sold our current stock of the smaller memory and wrote the code to be able to update Flic over the air. Just to be on the safe side, if anything like this would happen again.
Unchallenged early assumptions
The false assumption that double memory equals double price caused a lot of trouble, not only for us but for our most important customers. It was also, in retrospect, stupid of us to not believe that full software updates would be necessary when dealing with a brand new technology.
We had another unfortunate early assumption that today really affects that important Fist Batch. We “knew from the beginning” that we would not be able to start Siri on iOS with Flic. Apple did not allow that kind of functionality using the custom Bluetooth profile and App connection that we had to create to make Flic what it is.
Turns out they changed that a while ago and that Flic, with a firmware upgrade, could implement new Bluetooth profiles with a (very!) clever code switching algorithm that our brilliant engineers invented. As of our Flic App 2.0 release earlier this week, Siri and many new functionalities that we assumed would be impossible are now possible.
But not if your Flic is from the First Batch with the smaller memory chip.
Thank you for reading, I hope you enjoyed a bit of insight to our challenges. If you are part of our First Batch, please find a kind offer for new Flics in your email inbox.
Joacim
