Symbiobites
#31 Perspective
It’s notoriously difficult to imagine our works, which we are so intimately familiar with, through the eyes of a third party. Instinctively we’ll put far too much emphasis onto little details that might seem important to us, but are insignificant to our audience.
One reason is that, whilst it’s intellectually and emotionally easy to point out a minor bug or to tinker with design, dealing with external feedback can be much harder.
Getting your product out to the actual end-users can help keep that crucial perspective!
#30 2.4 GHz Tracking
There are three main methods for localising an object using 2.4 GHz radio in use today. All involve fixed nodes (‘anchors’) and the nodes to be tracked (‘tags’).
The simplest is by measuring the signal strength of a transmission from the anchors to the tag or vice versa. The signal being measured could be a reflection, attenuated by obstacles or the direct signal, which makes this approach the least accurate. Positioning within 3-5m is typical for indoor deployments with a couple of anchors per room.
More precise positioning can be done by measuring the Angle of Arrival pioneered by Quuppa and now included in the Bluetooth specification as of version 5.1. With AoA we can get measurements that are extremely precise, at the expense of more complicated hardware and commissioning.
Finally, though not strictly a 2.4 GHz technology but deployed to great success by RedLore, a supplemental Ultra Wide Band radio measures the Time of Flight of messages for similarly precise measurements as with AoA.
All of these approaches have applications to which they are best suited. Book a free consultation with us to learn more!
#29 Expectations vs Reality
The reasons for missing goals fall in two categories: Poor performance or unrealistic expectations.
IoT projects typically push the state of the art in some ways. Perhaps the technology might be proven, but the value might not be. This why it’s particularly easy to have unrealistic expectations.
You should expect that your first version might not deliver the value you envision. You should expect that there will be learnings in the field, even if they seem obvious in hindsight. You should expect that there are risks that might materialise.
If you are able to set realistic expectations from the start and learn early on in your project, your chances of success increase significantly!
#28 AI and Coding
There is some excitement about the likes of ChatGPT and its ability to write or analyse code and for good reason: An AI writing code as autonomously would have been hard for many of us to imagine even a year ago.
But there is a fundamental limitation: A big software project is full of thousands of little decisions and interactions, typically made by a human. Those decisions might be made based on anticipation of the behaviour of the user. They might have a social context. They might need to be in line with the vision of the company. Some decisions might lead to issues if they contradict other design aspects of the system.
Fully specifying literally everything would be near impossible and really, it is all these little decisions that are the hard part of making software, not the act of transforming them into executable code.
If natural language becomes the programming language that’s turned into code by ChatGPT, then we are not tackling what actually makes software difficult. What it would take is for the AI to be able to write the specification itself.
#27 Productivity vs Systems
Agile management approaches such as Scrum are fantastic. And if followed properly the results can be more than the sum of its parts.
But then following those practices to the letter is not always possible. Some developers or product owners won’t enjoy following a strict set of rules. And in that case it might be better to find another way of working.
One of the most important parts of agile projects is regular review and reflection, to make sure that the team can always improve. This is in contrast to traditional management, where there would have been a thorough plan from the beginning.
In that review it makes sense to consider whether you’re following a system just for the sake of it and whether it’s completely aligned with your team’s productivity.
#26 Wirepas 5G
Our friends at Wirepas have been hard at work on a version of their excellent mesh network that operates in the 1.9 Ghz band, which was once commonly used for telephone handsets. Their proposal has become part of the ITU 5G standard, despite not being a cellular network like the one most people associate with ‘5G’.
In practice this will bring a largely increased radio range over 2.4 GHz mesh, which will allow powerful mesh networks to be deployed in applications that might previously have been the domain of technologies such as LoRa or Sigfox – with long range, but far more limited capabilities.
At the same time 2.4 GHz mesh is here to stay and will remain the top choice for applications in which long range is not required or where lower device cost is favoured. The future is exciting – but so is the present!
#25 Outsource Your Engineering
You might not know how to hire the right engineers for your project. You might not be passionate about the things it takes to keep an engineering team excited. It might not be core to your business or suit your skillset.
Partnering with companies like Symbiotech in building your project allows you to focus on what you do best and eliminates a major source of risk.
#24 Mismatched Expectations
When building any kind of novel IoT or software project, chances are that reality won’t precisely match our expectations.
Tools to clarify and align only go so far: detailed mockups may look great, but it is only when seeing the actual solution in practice that we might realise that we would like things to work quite differently.
The real solution is to build flexibility into the process and expect to learn throughout.
#23 Ecosystem
The wider ecosystem of a technology might not be the first thing that you consider, but it can become a crucial aspect to your success.
What if a manufacturer of a component ceases to exist? Will there be others to supply that part?
What if you suddenly need a new sensor, a plugin or an integrated tool? Will that be something that you can buy off the shelf or a development project from scratch?
And then there is the longevity of the ecosystem. In the world of IoT, ecosystems can come and go fast. The commitment of the ecosystem participants matters.
We’ve been in the game for a while. Reach out if you to us if this has peaked your interest!
#22 Software Uncertainties
Once the software is written, it’s possible to copy and distribute it infinitely at virtually no cost. A consequence of that is that software that is being developed tends to be ‘new’ in some sense – unlike for example most residential housing, where one construction project is much like the next.
Novelty introduces uncertainties. Over the past decades the software world has gravitated towards Agile project management approaches, to manage, rather than eliminate, those uncertainties.
Eliminating all uncertainties simply isn’t possible. Experience in the domain helps a lot to mitigate some key risks. That experience and agile management is what we offer to our customers.
#21 Transmitting is Cheaper than Receiving
An invisible fact of radio communications, but one that impacts the design of all of the devices that we use is that receiving data is typically a lot more power hungry than transmitting it. This is in large parts because devices often need to keep their receiver turned on for much longer than the actual message they want to receive, because they don’t know ahead of time exactly when it is going to arrive.
This is why there are (transmit-only) beacons that have a battery life of years. These get received by phones that have big batteries, but only with an expected battery life of days at best.
This is why your Bluetooth headphones will periodically advertise their presence and only listen for connection requests for an extremely brief interval thereafter, putting the onus of the expensive Bluetooth ‘scan’ (i.e. listening continuously for several seconds) on the device that wants to connect to them.
This is also why most mesh networks don’t lend themselves to battery powered infrastructure. Bluetooth Mesh and Zigbee can have battery powered end-devices, so long as they don’t route traffic as part of the mesh. Wirepas is the only technology that has a mode optimised for battery-powered infrastructure.
#20 Bandwidth Requirements
Ethernet and WiFi for the intents and purposes of almost all IoT are infinitely capable.
Bluetooth can stream audio but is not suitable for video or other large data transfer.
2.4 Ghz mesh networks such as Wirepas, Bluetooth Mesh and Zigbee can support massive networks, where each device typically sends small amounts of data every few minutes or so.
Sigfox and LoRa send data much less frequently than that and dictate that the payloads must be very small.
There are exceptions to the above but by and large these are the orders of magnitude that these technologies operate in. In practice though many IoT applications are not very bandwidth intensive. The choice then comes down to factors such as reliability, battery life, scalability and available hardware.
#19 LoRa vs Mesh
LoRa and 2.4 GHz Mesh are very different beasts and suitable for different applications.
LoRa shines in sparse networks where its long range can let a gateway cover vast areas. Mesh on the other hand can offer much greater bandwidth and more predictable latencies, but imposes restrictions on the placement of devices. Both technologies scale well, but in ways that can be counterintuitive at times.
If you’re wondering about the difference, then we’d love to hear for you and discuss the relative merits for your application.
Also, if you want to continue reading on the topic, we have already written an extensive blog post on how to combine LoRaWAN with Wireless Mesh.
#18 Brooke’s Law
An old but still often true statement about software timelines: Adding manpower to a project that is already late makes it later. Of course reality is more complex than that, but it’s worth taking a moment to think about that sentence.
The nature of software projects is such that tasks can not always be neatly divided and it takes significant time and effort to be onboarded onto a project. Good software design practices and documentation can only go so far.
The solution? Where possible cut down the scope to build a valuable release faster and start with capable resources to begin with. If it’s not looking like you’ll be hitting the target, then adjust early on in the project.
#17 Insightful Data
It might seem a tad theoretical to think about the difference between data and insight, but it’s an important distinction in the world of IoT. Plenty of sensors produce plenty of data, but is this data telling us something that we don’t already know, and that we’re actually interested in?
A receptionist might see that the air quality in a meeting room is poor at a point in time. A facilities manager might see that a building was sparsely occupied on a given day.
Going from data to insight means anticipating the needs of the consumer of the data, and presenting it in such a way that the insight becomes accessible without deep analysis – which most consumers are not willing to do. And unless that insight is actionable, [there is still little that will be done with it] → it still serves little purpose.
#16 Less is More
Most software projects aim to release a minimum viable product (MVP), or a similar concept. We often see MVP specifications that are extremely complex, almost matching the vision of the ultimate product.
The mistake here is thinking in terms of absolute importance. If we ask ourselves ‘is this important’, the answer is often ‘yes’.
A better approach is to rank features in terms of their relative importance. Then go through the list asking yourself ’if I was given the choice to either release the product now or wait another two months to deliver the additional feature, which would I choose?’.
Complexity and risk don’t increase linearly with the number of things you want your MVP to do. This is easy to neglect when planning. A simple MVP is the best remedy.
#15 Bandwith is Overrated
Bandwidth is often the first point of comparison when looking at different local-area IoT technologies, even when the comparison is done by the very people who developed the technologies themselves. It’s a bit like comparing the horsepower on two different sports cars.
But similar to the unlikelihood that you chose your last car purely on horsepower, or even gave it much consideration at all – it’s rarely the most important point about a networking technology.
How does it scale? How easy will it be to install? How can I maintain it for the coming five years? These questions are much more nuanced, but they are the ones that make and break systems.
#14 Prove your Concepts
It’s a commonly recognised challenge to fully specify software before it has been at least partially developed.
Software is complex, and our ability to imagine how it will feel to use this software is limited.
The exceptions to this are if we’re building a system that’s either very simple or very similar to one we’ve used before. But IoT projects are rarely in those exception categories.
This is why an early PoC is so important: so you can see your ideas in action, learn from them and adjust the plan accordingly.
#13 Silos
The world of IoT is fragmented. Devices use different radio (or other) technologies and speak different protocols to different ecosystems.
Then there are a number of software platforms aiming to overcome this by integrating ecosystems with each other. But note that a lot of ecosystems and tools make unstated assumptions about IoT.
Here is one of the most common assumptions: The device is a ~$100+ unit that connects to the internet. It’s easy to spot this one from the pricing: If the platform is costing multiple dollars per device per month, it’s clearly not intended for low-cost devices sending data infrequently.
And there lies the challenge: Who is to claim they have a comprehensive overview over ‘IoT’ and all the verticals it might serve? Who can really understand the needs of the end-users, without narrowing down who those users might be?
Convergence is certainly worth striving for, but it needs to be a slow and organic process. Don’t be fooled by those claiming to have solved it.
#12 firmware in C++
Almost all firmware is written in C and even the mere idea of anything else can spark a heated debate. Here are some things we believe to be true:
– It’s just as crucial for firmware as for any other code to follow good coding practices, such as clear control flow and no duplication of code
– It’s possible to write good code in both C and C++
– C++ offers features on top of C that encourage writing good code, if used correctly
– C++ also offers features that are very rarely appropriate in firmware (the ‘new’ operator, exceptions, standard libraries…)
– Many people writing firmware today don’t have a lot of experience with C++ and so many of the benefits might go unused
We’ve written firmware in C++ and have been very happy with the results. Would you consider it for your next project?
#11 Designed for Success
The tragedy of the commons is often told as the story of public farmland on which farmers let their cows graze until the land becomes depleted and ultimately destroyed.
A similar situation can happen with a radio spectrum or network.
Fortunately Bluetooth Low Energy was developed based on ‘Designed for Success’ principles. It shows incredible foresight, when pioneering a technology one can only hope will be adopted, to consider its ability to function in a football stadium filled with tens of thousands of those devices. But luckily they did.
We’ve seen Bluetooth Mesh and Wirepas work flawlessly in massive networks, at packed trade fairs, in underground mines, industrial buildings, cargo ships and factories.
Is your system designed for success?
#10 INTERNET THINGS
To us the ‘Internet’ in IoT is about the networking between (lat: inter) devices. They may be connected to the internet or they may not be. Either way it’s IoT.
Otherwise, wouldn’t it have to be called the ‘Internet Things’?
#9 Hiring Talent
In any software project, tasks and risks fall into one of three categories:In the classic read ‘Rapid Development’, author Steve McConnell talks about the needs of software developers, comparing them with the needs of their managers that are so often projected onto their developers.
What do you think it is that developers value the most?
Achievement and opportunity for growth rank as the top two motivators. Responsibility, which ranks the highest for managers, is regarded much lower for developers.
If you are looking for top developers then this is important: do you offer an environment in which developers can feel a strong sense of achievement, growth and opportunity to rise to technical challenges?
If not – as is the case for a lot of companies not traditionally developing software – then perhaps you should consider working with a partner like Symbiotech who specialises in building this kind of dynamic environment.
‘Known knowns’ are where you know about the task and you know how to do them. ‘Known unknowns’ are where you anticipate that there will be a risk. These two are almost always dutifully included in any project planning, and all risks are accounted for. But they are rarely what makes projects late or cost more than anticipated.
‘Unknown unknowns’ are those things that are not even on our radar when we’re planning a project. And for anything beyond trivial tasks, they are certain to be there. Unless an IoT project is simply a copy of something that already exists, it will be full of unknown unknowns.
#8 On the Importance of Commissioning
When we dream up IoT systems, we tend to picture them in operation, reporting data, giving insights. We think of hardware that needs to be developed and dashboards that need designing. This often neglects a crucial part of any IoT system: the set-up or ‘commissioning’.
Traditional wired systems often require experts to commission them, both initially and during maintenance. This cost often gets swept under the carpet, but in fact it is the very item that can turn an investment into a bad one. Wireless IoT can revolutionise commissioning by making it simple and cost-effective, but only if simple commissioning is treated as a priority from day one. Don’t let it be an afterthought!
#7 Unknown Unknowns
In any software project, tasks and risks fall into one of three categories:
‘Known knowns’ are where you know about the task and you know how to do them. ‘Known unknowns’ are where you anticipate that there will be a risk. These two are almost always dutifully included in any project planning, and all risks are accounted for. But they are rarely what makes projects late or cost more than anticipated.
‘Unknown unknowns’ are those things that are not even on our radar when we’re planning a project. And for anything beyond trivial tasks, they are certain to be there. Unless an IoT project is simply a copy of something that already exists, it will be full of unknown unknowns.
Sure, it’s possible through planning and applying past experience to reduce the amount of unknown unknowns in a project. But that doesn’t change the fact that they will be there. Good project management does not eliminate unknown unknowns, but employs agile practices to manage them.
#6 Bluetooth and Wifi for IoT
To a lot of people ‘IoT’ is synonymous with having more devices connected using WiFi networks. Others might think of Bluetooth. That makes sense because those are the technologies that we are the most familiar with.
For large scale smart buildings or industrial IoT, though, both technologies struggle to meet typical scalability needs because they simply weren’t designed for it.
Technologies like Wirepas or Bluetooth Mesh can create massive networks on inexpensive, even battery powered devices.
#5 How long do IoT Projects take?
…of course depends on many factors.
But since we’ve been in the business of building Smart Building and Industrial IoT solutions for a while, we can tell you what’s typical:
2-6 months for a prototype that is suitable for piloting the technology and testing assumptions
6-12 months for an MVP that can be tested with the first customers
1-3 years for a product that has matured through feedback
#4 Low Energy Mesh
One of the best features in Wirepas is running devices in Low Energy Mode. It allows devices powered by coin cell batteries to last for years. It allows a complete IoT network to be installed in a building without laying a single power cable.
It’s allowed our partner Intrex to deploy a comprehensive system in dozens of senior living communities across the US, all without having to do as much as engage an electrical contractor.
To our knowledge there is no other technology out there that could have accomplished this.
#3 The Nature of Security
Frequently security gets reduced down to simple technical solutions, cryptography being the most common. If data is encrypted in transit and at rest, then surely it is secure, right?
Unfortunately the answer is not a simple ‘yes’. For example looking at most web applications, the only place that is typically accessible to the outside world is the application server. The application server needs to access the database in unencrypted form to serve requests. If the application server gets compromised, and it’ll be the first place that an attacker will try to break, then it won’t matter if the database is encrypted or not.
Or how about this: The database is encrypted, but there are several developers with access to it. An attacker is just one weak password or one phishing email away from full access. The encryption itself will almost never be the thing that lets the security of the system down.
Undeniably security is a hard problem, which is why we see data leaks even at the largest of organisations. The only way we can build secure solutions is by understanding that the challenge is at a systems level.
#2 Bluetooth Mesh Models
We’ve had the fantastic opportunity to work alongside Szymon Slupik, Piotr Winiarczyk and their team. They are arguable the two leading figures in the Bluetooth Mesh standard. What they have achieved and the vision they have is inspiring.
When we get asked about Bluetooth Mesh, the questions are often around the capabilities of the network. But this is only a small part of the story. Even more work has gone into meticulously defining models that define the interactions between different classes of devices.
It’s exciting to see more and more products make use of this facility!
#1 Integration First
A lot of the time we work with device manufacturers to make their devices smart. It might only seem natural to start by building a dashboard that manages those devices and shows their data.
But if the value that you provide is the devices you make, do you really need to own your own IoT platform? And are your customers going to want to use it over a system they are already using.
Focussing on integrations can get you to market much faster and might meet your customers’ needs much better!