A lot has been written about our Internet of Things (IoT) powered smart devices, and all the creative use cases for them. Whether it’s for Pharma to Physician communication, time management, combating the spread of COVID-19 or Lab of The Future implementation, our innovative devices are only limited by one’s imagination.
What hasn’t been covered, however, is what makes Swittons devices tick. If you’re like us, you were probably one of those kids that loved to get new gadgets for birthdays and holidays. Not to play with, but to bust open and dissect in order to uncover what made the unlucky gadget do what it was intended to do.
If we’ve just described you, and you are wondering what’s underneath that beautiful, rectangular plastic shell on all our devices, don’t worry… we’ve got you covered. There is no need to buy a few Swittons, just so you can bust them open for a look-see. Simply read on as we share all the secret details about how Swittons devices came to be.
What are Swittons devices made up of?
When we were in the banging stages of our proof of concept, we got our hands on some open-source components. It’s easier to get community support this way, and there are lots of options for customization too.
The initial phase of our hardware selection involved investigating the following features:
- I/O options
- Connectivity options
- Power options
- Choice of MCU
It’s amazing how many different options and configurations there are with these features in mind. We executed several different experimental builds, starting with breadboards and finally working our way to Veroboards. Our manual soldering skills were definitely put to the test.
After many sleepless nights, here is where we landed:
Swittons devices have a total of three buttons and two LEDs (for different indications and status). The three buttons are the core component, as this is what the user will press for triggering an event. In the case of our biometric models, we have an extra I/O feature for the scanning of fingerprints.
The two status LEDs perform the following actions:
- An RGB LED for indicating the status of the device – as in its connectivity.
- A RED LED for charging indication.
Based on the RGB LED, the user will be prompted as to when they need to press the button – which has 3 states.
- Connected to the network (Wi-Fi / GSM)
- Connected to internet
- Connected to P360 server
The charge status LED simply glows when the device is being charged as an indicator.
For biometric devices, we used a few more LEDs for representing whether the user is authenticated or not.
When building IoT devices, one of the greatest challenges is sifting through all the different options available for connectivity. Some of the standard IoT communication protocols are mentioned below.
- NB – IoT
While many options exist, for Swittons devices the choice came down to two main factors.
- Where is the device going to be used?
The first part of this is based on the location; indoor or outdoor, static or mobile. A device will be best suited for Wi-Fi if it’s used indoors and is static, while Wi-Fi isn’t preferred if it’s a mobile device. GSM is well suited for outdoor and mobile connectivity, but with the rise of LTE it’s not a preferred option.
- How much power do we need?
Another important factor we needed to investigate while deciding on the type of network connectivity was power requirements. This is very important, as the networking module consumes most of the power.
In the case of Swittons, we opted for the use of Wi-Fi, GSM and LTE-M. For different versions, different chipsets are used.
Device power options:
Another important factor for us to consider when building our smart devices was power, and how the devices manages it. Being an important link to mission critical workflows, we certainly didn’t want our device running out of power very often. Therefore, we have implemented deep sleep mode in the LTE-M version – which allows the device to run on battery for a period of over 3 years in a single charge.
Microcontroller unit (MCU):
Everything boils down to the microcontroller unit. Selecting the appropriate MCU depends on all the factors mentioned above. The MCU can either be a standalone networking component or a combination of a dedicated MCU with a networking component.
Our specific use case didn’t involve processing at edge level, so we chose the networking component as an MCU. For biometric models an additional layer was added for authentication.
When evaluating communications protocols for our devices, the following features were a must have.
- Low data overhead
- Low bandwidth
- Low power
In the world of IoT, there are dozens of communications protocols to choose from. In the case of Swittons, we selected the Message queue telemetry transport or MQTT protocol. Our primary messaging platform is based on the Azure IoT stack, and we are utilizing an MQTT gateway to handle device to cloud (D2C) communications and cloud to device (C2D) communications.
MQTT is a lightweight protocol and was developed primarily for IoT. It has an extremely low data overhead, as it consumes less bandwidth. It is based on the publisher subscriber architecture, and is highly scalable and consists of multiple layers of authentication and authorization for even processing.
With all the hardware, and a strong, scalable platform for communication in place, the application was the final piece of the puzzle. The application takes care of all the parameters in terms of configuring and monitoring. It involves a series of microservices and API endpoints, which gives users a streamlined, out of the box ready experience. Some of the key features of the application include:
- Device management
- User management
- Campaign management
Swittons as a platform:
In addition to being innovative devices for remote communication, we also wanted Swittons devices to function as their own customizable platforms. This meant we had to leave room for future device options by adding our own proprietary software. This makes Swittons more than just smart devices, it makes them a core piece of digital transformation initiatives.
By combining APIs with our own code, we were able to build a solution that:
- Utilizes advanced analytics and AI.
- Harnesses push/pull data streams.
- Is able to collect data from various sources.
- Integrates seemlesly into the client’s existing systems, as well as other powerful P360 solutions.
After all the necessary research and development was completed, and the final features were in place, Swittons was ready for the world. Our first devices consist of two versions.
- Rectangular shape for non-biometric
- Square shape for biometric
To learn more about Swittons, click below to chat with one of our experts