Coderus Limited

The Challenge

1. Through specialising in embedded solutions and engaging with a wide variety of clients, we have built a strong portfolio of projects. To support the Bowers & Wilkins DB Subwoofers and PX Headphones, Coderus provided Bluetooth LE solutions to allow users of these products the ability to customise them for their needs through a mobile app.
2. In order to provide high-quality applications, a number of challenges had to be overcome. One such challenge that we faced was the varied nature of the products; providing a Bluetooth solution to products that had to ensure compatibility was maintained with a large variety of handsets from multiple manufacturers, comprising different hardware configurations, Bluetooth stack implementations and different OS versions.
3. The team had to ensure the applications were capable of performing stable and reliable firmware updates over a Bluetooth LE connection. This involved the transfer of files over Bluetooth LE from the mobile devices to the audio hardware, checking the validity of the files as they were sent.

The Methodology

1. To aid with the development, the team created a hardware solution that was used to generate mock versions of the DB Subwoofers and PX Headphones, facilitating the development and testing process without being limited by hardware availability. This approach also gave us clear visibility of precisely when and how the app was communicating with the device, which provided us with valuable information that aided development. In addition to our own expertise, we were able to work alongside Cypress and CSR, now purchased by Qualcomm, who provided support with the process of testing and debugging.
2. During the development of these applications, the team used an Agile methodology, ensuring frequent communication with the client and allowing the applications to be iterated upon quickly. Each deliverable was distributed to various teams within Bowers & Wilkins via the testing channels available on the Google Play Store or App Store.
3. The firmware update journey was implemented using the extensive documentation provided by Cypress as well as a reference implementation provided for iOS and Android. This allowed us to verify the firmware integrity as it was being written to the device as well as ensure the process was robust enough to handle any unexpected error that could occur. This complexity included allowing the library to be separated from the application layer for reuse.
4. The open nature of the Android platform means that the application would need to support a wide range of different Bluetooth chipsets. A challenge compounded by the fact the Android Bluetooth stack has received a degree of criticism for being unstable following major changes to replace it in Android 4.3. This meant that thorough testing of the application was required, to ensure robust error handling was put in place. So as to allow the app to automatically recover from any failure that might occur without negatively impacting the user experience. This error handling was implemented in the library layer to ensure that all Bowers and Wilkins products would benefit.

The Challenge

• Land Rover BAR, British Challengers for the 35th America’s Cup, required a pioneering new mobile app that could intuitively show critical information throughout the racing – with no user interaction.
• The boat itself is embedded with hundreds of sensors, providing real-time data that will allow the team to make swift tactical decisions and optimise their time in the water. 
• Data from the sensors is served to the Coderus app, which enables critical data to be read in a user-friendly format from the crew’s water-resistant Android tablets and watches.
• Optimised for challenging race conditions, hardware and battery performance, and crafted to ensure its operation kept pace with events as they unfolded, the Coderus mobile app solution was used through the America’s Cup racing calendar.

The Methodology

• The Land Rover BAR team chose the Android tablet and Android Wear devices to meet the challenging conditions presented. 
• With the rapid and agile development of the app, our sprints of developing and testing were scheduled for a standard two-week duration. Running in the background during testing, Crashlytics Beta allowed us to quickly identify the causes of any crashes or failure and apply solutions for the next release.
• During development, Coderus worked remotely and sustainably across time zones with the Land Rover BAR team, a fantastic example of collaboration between the U.K. and Bermuda.

The Challenge

1. There are many factors that determine who wins and who loses a sailboat race. The ones that are obvious to the casual spectator are speed and manoeuvrability, along with efficiently managing the interactions with other competitors. These are the same kinds of elements that win motorsport races.
2. There is another layer of factors determining the outcome in sailboat racing though – often visible only to the aficionado – and they come from the complexities that motor racing does not have to contend with: 
3. Instead of a reliable, driver-controlled power supply (an engine), the boat’s power source – the wind – varies unpredictably in both speed and direction and relative to both time and position on the racecourse.
4. Instead of a tarmac or gravel track with a clear, optimal ‘racing line’ there is no fixed route around the course, just markers that must be rounded on a particular side, and an optimal route between them that will vary with the wind, current and sea state.
5. The variability of the power source and the lack of constraint on the boat’s course lead to a multitude of questions. Where’s the best wind? How do I get to it? How much confidence do I have in the wind not changing before I get to it? Do I stick with my competitors or back my judgement on a shift in wind direction or speed?
6. The answers to these questions play a big part in winning races and finding the right answer is largely the job of the tactician. The most experienced of these are extremely good at assessing many of the relevant factors; judging the speed of the boat by movement relative to the competition, or judging the wind strength and direction by the effect it has on other boats, on the water, and on trees, smoke or flags on the land. 
7. These judgments are synthesised, and a decision reached – based on experience – on the best tactics. And for much of the long and illustrious history of the Cup – and in smaller boats even today – this was the only way to do it. 
8. The advent of satnav and its integration into a multi-sensor instrument system via powerful onboard computers has been a real game-changer though. The data can now be fed to a screen on the deck and software developed to help assess the tactical options.

The Methodology

1. In the 35th America’s Cup, the team built a bespoke package tailored to the new boat and the racecourse. It had to work very differently to traditional tactical software which had historically been run by a navigator with few other responsibilities.
2. The new ‘tactical app’ had to consider not just the completely different way that it would be used – with almost zero time for the tactician to interact with the screen – but also the fact that the strategic dynamics had fundamentally changed with the introduction of tight boundaries to the racecourse.
3. The task of developing the tactical app was split into two parts, the first of which required intensive sailing maths. The app would rely on a lot of sophisticated calculations to produce all the numbers that would be displayed. These calculations would be done by the team’s in-house software engineers, led by Andy Bryson.
4. The second part of the job was to develop the app to display the data and graphics on the deck screens in the most efficient and effective way possible. This task required a different skill set, obviously, input was needed from the tactician and other sailors, but the team also needed experience in mobile app design. So a partnership was created with Coderus, a software development company based at Adastral Park in Suffolk; one of their specialisms is mobile app solutions.
5. The tactical app went through many iterations in the previous America’s Cup. Tactician and Olympic gold medallist Giles Scott commented at the time: “We were desperate for an app which could act as a virtual seventh crew member and become central to our decision making process during the race, providing Ben (Ainslie) and I with the data that we really need to gain a competitive advantage. We’ve had great support from Coderus through all stages of the development, from design, build and now refinement out on the water.”

The Challenge

The initial development of the project relied on Xcode 10.1 and Swift 3, both of which became obsolete and unsupported by Apple. This dependency created significant barriers to using modern development tools and required cumbersome workarounds.

Additionally, the project had accumulated technical debt, including an excessive number of external dependencies, invasive integrations, and deprecated APIs, complicating further development and maintenance.

The Methodology

A systematic refactor was executed to overcome these challenges:

Documentation: Created a README and CONTRIBUTING guides to provide clear instructions for setting up and contributing to the project.

Dependency Management: Reduced external dependencies from 32 to 13, removed Cocoapods in favour of Swift Package Manager (SPM), and updated necessary dependencies.

Network Layer: Refactored the network layer to remove reliance on Alamofire, abstract request logic, decouple endpoint information, and transition from ObjectMapper to the more modern Codable API.

Notifications: Updated remote notification handling by removing deprecated APIs and ensuring compatibility with modern standards.

The Results

The refactor significantly reduced technical debt by cutting down the number of dependencies and simplifying the integration process, making the project more maintainable. Transitioning to supported versions of Xcode and Swift eliminated the need for workarounds, and meant that the project could be worked on and deployed as this was impossible before. This also enhanced the development environment and improved developer productivity.

The network layer was improved through a new abstraction and the use of Codable resulted in cleaner and more robust network code. The handling of remote notifications was modernised to ensure compatibility with current standards and improve reliability. Additionally, comprehensive documentation was created, providing clear guidelines for future developers and facilitating easier onboarding and contribution to the project.

This refactor not only brought the project up to date with current technologies but also laid a solid foundation for future development and scalability.

The Challenge

Elytone, design and manufacture electronic components and solutions for audio products. They were looking to introduce a new line of subwoofer components to their product range. With the ability to adjust various subwoofer settings over BLE from an iOS or Android companion app.

These subwoofer components and mobile app would serve as the foundation for other audio manufacturers to build their own products. This meant that the communication protocol needed to be extensible so that new commands could be added over time to support future subwoofer models with new capabilities as well as custom commands added for specific hardware manufacturers.

The mobile app was required to support advanced features such as an over-the-air firmware update feature as well as a cutting-edge room correction feature.

The client chose Coderus due to our large amount of experience designing and developing bluetooth applications in the IoT spaces. We were tasked with designing the full solution including producing the UI designs, developing the mobile application and embedded firmware.

The Methodology

The project followed an agile SCRUM methodology with 2 week sprints to ensure a continuous feedback loop between us and the client. The client was involved planning and review sessions throughout the project. At the end of each sprint a new release was made available with the work completed so far.

The UX designers, developers and QA all worked on the same sprint. Helping to ensure that designs were completed and ready for development and QA were aware of what features had been planned into the sprint and when they would be completed.

The QA team verified each new feature as they were developed. This close collaboration between the developers and QA meant we were quickly able to identify and resolve bugs or other issues as early as possible, before code changes were merged into the main codebase. This approach of testing regularly and often meant the application was more robust and had less overall unexpected behaviour when delivering builds to the client.

Because we designed the user interface in-house, this allowed us to work closely with the designers to ensure the app flow worked well with the underlying technical steps required by the hardware, as well as following platform conventions.

Delivering a solution quickly was a requirement from the client, so we utilised the latest Swift and iOS technologies such as SwiftUI to rapidly prototype the user interface, and various library features to get the app off the ground quickly. By targeting a later version of iOS, we utilised newer frameworks such as Swift Charts to create graphs quickly.

The Android app made use of Jetpack Compose the new UI framework from Google to quickly build the screens. Coderus reused a BLE library developed in house to allow BLE interaction with the subwoofer to be quickly developed.

Elytone asked us to work with an audio algorithm supplier who developed the model which worked with the recordings of the subwoofer captured by the mobile app to identify the optimisations which should be applied to the subwoofer. We held a number of workshop sessions to allow us to quickly iterate on the feature to ensure correct behaviour and calibration.

The Results

We delivered in bi-weekly sprints. The app features a pairing flow, a list of the user’s already saved devices, a general settings screen, device volume control, dynamic bass boost, EQ presets, phase control, room correction and firmware updates.

All our BLE logic and RoomEQ logic is in separate libraries so can be developed separately or be reused in other applications.

We saved time by using the latest UI technologies, allowing us to create the app screens and graphs faster.

The Challenge

The Bowers & Wilkins brand’s key focuses are providing customers with products that offer the best music quality as well as battery life. The company sought an app, which would allow users to customise their experience and perform firmware updates, which would ensure that they always had the latest features and improvements. 

The emphasis on high-quality streaming audio meant that any app interaction would need to consume as little power and bandwidth as possible to allow music playback to continue without hiccups – while providing a great user experience and consuming minimal battery.

The application would also be developed in parallel with the hardware, firmware and user experience, so there would be very limited availability of products to develop and test with and there was a high likelihood of change throughout the development life cycle.

The Methodology

Our agile methodology played a vital role in ensuring that the project was kept on track. We continued to share code between both the Android and iOS apps using Google’s Java to Objective-C (J2ObjC). This allowed logic for the device interaction to be written once, providing a standardised way for both mobile apps to interact with the headphones.

Early in the project development when hardware was most limited due to the cost of manufacture, we made use of an in-house project which allows for quickly prototyping and mocking Bluetooth Low Energy (BLE) devices. This allowed us to build and test the app end to end before hardware and firmware were complete, which was invaluable in delivering a quality application in tight timelines.

Because BLE is low power, it can be impractical for transferring data such as firmware files and because great audio quality is key for the user, BLE data would have a lower priority than audio data which could cause app performance problems if not carefully considered. This required us to work very closely with the firmware and hardware teams to optimise connection parameters and the payloads that the app would send and receive.

We structured work into two-week sprints, meaning that there was a release to the client every two weeks. This worked well as it allowed the client to evaluate the designs and implementation frequently and update the user experience as necessary. Jia was our platform of choice to track progress and issues, as well as having weekly calls with the UX and firmware teams to ensure that everyone was aligned and updated across multiple continents.

The Results

Working to a strict deadline in order to coincide with the launch of the headphones, the Coderus team managed to exceed the client’s expectations. Consumer ready applications were developed and deployed to the Apple App Store and Google Play in time for the launch, ensuring consumers could immediately benefit from its use from the moment they got their hands on their newly purchased headphones.

This feat was made possible not only through our close collaboration with the client but due to our ability to produce maintainable and extensible code, allowing us to react quickly to changes in requirements without compromising the quality of the applications. A thorough suite of both automated and manual tests gave us full confidence in the correctness of the applications throughout the whole development lifecycle.

Despite the complexity of the project, we worked to our full capacity and met the deadline, delivering applications which met the client requirements – an iOS and Android mobile app which allowed users to customise the settings on their headphones and perform firmware updates.

Supported by our custom technology and agile approach, the project was completed within our original timelines and we coped very well with the regular changes in the UX design and firmware functionality. Close collaboration and quick feedback cycles with the client made sure that they were up to date on our progress and could design and validate any required changes regularly.

The Challenge

An existing Client called Hybrid Access that we provided a solution for previously, they provide a service where by a router in a home can provide failover of internet via mobile devices. They are located in Ipswich. The problem the client faced was mainly with performance, the bandwidth of the app we provided previously was not reaching the level expected and certain functionality also needed to be added to reduce battery usage and provide more responsive updates of state. The problem we were asked to solve was to parse updated information from the router for data cap, status of the Hybrid link service and messaging to be provided to the user. We were also tasked with the problem of improving the performance of the app, the battery usage was high and the bandwidth of the internet connect was on average a third of what could be achieved via cellular alone. The produce we provide helps the client to achieve their business objectives because they are engaging with ISP across the world that require there service and the app side is how users can interact and get updates on the service provided by their routers. The Client chose to work with Coderus due to our existing relationship and being close to be able to attend their premises on a regular basis to provide a more intimate service.

The Methodology

We worked very closely with the client to improve the performance of the providing, their existing expertise with c level UDP sockets was utilised to provide a more lightweight and performance wary solution. The technologies therefore were primarily focused on the c level UDP sockets (BSD/Berkley) which allowed us to make small tweaks to how the sockets behaved such as ensuring they were not blocking. We also made improvements to the initial API provided in previous work, swapping logic around to make the frequent parsing of data more efficient. Also removing the unnecessary creating of objects or helper classes that would determine the varying kinds of data being provided by the router. we performed much quicker operations to determine flowing traffic and data that requires parsing. We used reduce battery usage by varying the frequency at which messages are broadcast over the UDP sockets to the router. If the device is currently not being utilised for traffic failover then there is less frequent need for updates but if the device is currently active and forwarding traffic then more frequent updates are vital. Quality was of high importance here and where changes were make they were thoroughly tested before provided to the client to test, we worked more closely with the clients hardware, gaining more understanding of how it is configured and was able to start/stop and configure the hybrid agent ourselves where needed to check our changes. we were also then able to monitor and run more thorough tests for a longer period of time and get information from the router to see how the app was interacting to debug problems quicker and more efficiently.

The Results

The result of the project was a far more responsive application for information and status updates from the router. the visual representation in the app for what the router is doing was far more responsive and reliable, always up to date and quickly. There was an exponential improvement to the performance, reaching near close speeds to that of cellular alone. Benchmarks for memory usages, battery usage were also provided throughout the project and the improvements were impressive.

The product we provided was an app that interfaces with a users home router, the user can turn on the service to be able to failover to their cellular connect if their broadband goes down. The service will look at all the mobile devices running the applications on the network, whether iOS or Android and selected one that is most appropriate, with the best speed and reliability. anyone using the network will then have their traffic diverted via the active phone and the cellular connection on that device. The devices can also change at any point and it would seamlessly start channeling traffic via the new device. the app we provided shows a status to the user of whether there phone is being used and notifications of this change if the app is in the background. More importantly the service can also run without the app, running in a background service on the phone to allow traffic forwarding 24/7.