I believe most of the people have the same idea in mind when they think of “a developer working” (will avoid describing it). My cause though, it is a little bit particular. I am a developer at R3 Communications, a pioneering company in real-time wireless communications technology. We solve one of the most challenging problems in wireless communications of our current era: turn the highly unstable, unpredictable and unreliable wireless channel into the appropriate one for time-critical applications. What we believe is unsolvable by definition, turns to have a solution. Talking about engineering?
The possibility to be part of a company that is growing at the same rate as the market’s interest is unique. It is outstanding to see how a small startup from Berlin that is solving such a particular and challenging problem is finding its room in such a big topic as the Industrie 4.0, one of the most significant revolutions of our era. This interest from the industry in our technology. EchoRing comes along with, of course, huge demand, which makes it very exciting. In contrast, it is highly sophisticated to cope with heterogeneous use cases that come with this demand. Each company comes to the market with a proprietary solution with unique features, which requires individual handling. And this is a big challenge for the whole team.
Our development team covers all the areas of a company that works implementing a MAC Layer wireless communications protocol: from user space programming, write Linux driver, develop algorithms, develop network protocols, analyse embedded hardware, etc. My precise job here is to develop the driver in the operating systems Linux to bridge the gap between, on the one hand, the user application and the complex Linux networking system and, on the other hand, the multiple hardware platforms that run with EchoRing. To that aim, a wide variety of skills is required. First, knowing the hardware in and out is crucial. This is unfortunately way more complex than it sounds. Typically, each platform comes with a unique specification, which is not always well documented. Second, based on the knowledge on the platform, the development of the driver can begin. The life cycle of the development goes through multiple steps, including planning, designing, implementing (i.e. writing code), testing, optimising the performance and maintaining. In general, the unique challenges here come from the fact that the drivers are tightly coupled with the hardware and the operating systems. Primarily, the driver also needs to implement unique features required by the networking protocol EchoRing. Above all, to achieve the low latency requirements of some use cases we target, one of my main tasks is to optimise the performance of the driver to reduce the latency, measured as the time any packets traverse the whole networking stack.
Perhaps I am getting too much into detail… Let’s keep the rest for my next blog post! But I believe that my point is clear: there is no time for boredom at R3!