Software Engineer at Motorola Solutions
Created 15.08.2014
I started work for Motorola thanks to a very specific recruitment process introduced by the company in Kraków by that time. Candidates were welcomed to take part in some kind of a written exam, where examinees had to answer as much questions as possible during a given period of time. All these questions were related to areas where I had a strong interest, they were my hobby. As a result of that I passed it well.
HSDPA Project (July 2004 – March 2005)
At first day at work I was assigned to the team that was working on implementation of HSDPA on a new modem Motorola want to provide to their customers in the next release of UMTS into base stations. The office in Kraków at that time was part of Global Software Group, a business inside Motorola responsible for developing software for other businesses. Our customer was a UMTS excellence centre in the United Kingdom.
The whole team was assembled with 13 nearly newcomers, we were all put in a single room due to space constraints in the office building. We have all ourselves in the voice range. That allowed a free flow of knowledge and ideas between us. Thanks to that we were actually very productive. At the beginning, we didn't really know where we head our efforts, as hardware wasn't ready yet, we had to improvise a little bit.
My initial assignment in the team was taking part in development of MAC-hs (high speed data scheduler). That piece of software was intended to be run on Texas Instruments DSP processor. Code was written in C++ (at that time pretty limited subset of C++). Later I took part in development work for other parts of the modem software.
Duties
- Development in C++ for C64x DSP (DSP/BIOS based), simulating, debugging
- Implement high demand message handlers according to the ASN.1 structures
- Studying 3GPP standards and UTRAN architecture
- Development in C for vxWorks, bug fixing, debugging, integration
- Lab testing of HSDPA with signal analysers & user equipment simulators (TM200)
- Performing merges between releases during the integration phase
AXPT (March 2005 – September 2006)
Most of the team previously working on HSDPA including me, has been moved into Pico Base Station project where parts of RRC become integrated into the device in parallel to RLC. Then the product was tested extensively. Team: > 30 people in quickly changing assignments.
Duties
- Development in C for vxWorks, debugging, measuring performance
- Integration of large C code base from another product
- Solving performance problems with message passing between new and old code
- Creating communication tests in ASN.1 and TTCN-3
ISSSE (Aug 2006 – Feb 2008)
After AXPT project failed and was cancelled, as part of huge resource relocation I was moved from BTS department to the Astro department, were software for devices creating infrastructure for trunking radio systems was developed. All that work fits into American standard APCO 25. At the beginning I had a short adventure with MOL (maintenance of the line) team responsible for fixing legacy systems, mainly analog based.
Later I was assigned to the team involved in the development of performance and acceptance tools for the Motorola's Astro simulcast system. In fact, we became solely responsible for that project and we've taken over similar testing tools from the engineering office in Canada. Project managed in SCRUM methodology. Team: 11 people.
Duties
- Development in C++ for vxWorks with adoption of basic STL
- Refactoring old code attempting to be in C++ in fact being C put into classes
- Debugging multiprocessor application running on PowerPC equipped cards
- Co-author of mechanism converting XML into C++ data structures (XSLT, TinyXML)
- Deep analysis of high demanded Ethernet traffic using EtherPeak and Wireshark
- Integrating and testing releases from continuous integration branches (Continuous Integration)
- Creating test and emulation tools in Python
Point-to-Point Wireless (March 2008 – December 2010)
My involvement was project extending features of Point-to-Point non-line-of-sight radio links on 2.5, 5.4 and 5.8 GHz bands. I was responsible for the project which goal was to improve radar pulse detection required by FCC 47 CFR 15.407 and ETSI EN 301 893 standards in the PTP500 product. Involvment includes a lot of testing in the lab using the arbitraty signal generator and the spectrum analyser.
Later I was assigned to fixing bugs and improving the quality of the new version of the software for the PTP300 product. Unfortunately, half year later the corporation decided to sell the whole business that contained the engineering of a whole line of wireless products. People from Kraków as part of internal outsourcing had to be cut off from cooperation with the branch in the UK. At that time BTS business, we were up to that moment part off was being sold to the Nokia Siemens Networks, but earlier plans for 5 of us involved with Othrogon (3 developers, 2 testers) assumed we stay within current project, so formally we were moved already to the business that was going to stay within Motorola Solutions. That's how I avoided becoming employee of Nokia Siemens Networks.
These products are offered now by Cambium Networks (formerly Orthogon Systems, a subsidiary of Motorola).
Team: 3 people in Poland; 6-8 people in UK.
Duties
- Development in C for C64x DSP (DSP/BIOS based) with NDK involved
- Debugging the code, propose fixes and implementing them
- Testing radio and checking compliance with FCC and ETSI rules with signal analysers
- Improving radar pulse detection on FPGA and proving the technology in the lab
- Modifying the memory/register interface between the DSP and the FPGA
- Automating of lab tests by steering GPIB/VXI instruments from Python
January 2011 – April 2012
After cooperation with UK collapsed I joined the Tetra Subscribers department (200 people / 15 to 20 in team), become involved in bug fixing & development of new feature in the software for old and new Tetra terminals. These included embedded development for dedicated system, as well as for Embedded Linux.
Duties
- Development in C for ARM core (Linux based) and DSP core (DSP/BIOS based)
- Preparing unit testable modules written in C compatible with existing code base
- Debugging the code, running simulations, propose fixes and implementing them
- Preparing data structures for configuration storage (matching internal & external format)
- Porting changes between two platforms and integrate releases (large merges)
- Fixing large amount of Klockwork issues and warnings of new GCC or TI’s compiler
- Taking part in initiative to modernize configuration management for multiplatform project