Oleksandr Lotokhov

Dehancer is a software to make photo/video looking like they are made on film cameras.

My responsibilities are development of Adobe Ae/Pr plugin from scratch, deploy and bugfixing/support.

You can see details on the product page

Switching from embedded systems to Windows programming. Project with cca 1 million lines of code.

Tasks successfully solved:

• Data integrity issues: discovery and fixing. Issues happen in production only, can't be reproducible on test environment. Production servers contain customer's sensitive data, so developers can't have access there. Data integrity issue was actual for cca 5 years and was not fixed even by authors of the SW. Finally discovered and fixed by me.
• Optimization: in many places there were rooms for improvement with drastical effect: time of operation decreased from days or hours to minutes.
• Refactoring: the worst thing for refactoring was hardcoded file path size (600+ places). Till Windows 10 it was OK, after 32000 symbols path was introduced in Windows 10 it became a huge issue. Refactored successfully.
• Dashboard to monitor state of the infrastructure based on ELK stack. Successfully deployed.

Another switching, now to WEB programming. Portal written on Django helping users to manage their backups in the cloud easier.

Although I have good knowledge of Python, Django framework was new for me, but I jumped in quickly. Relatively fresh project - from September 2019.

This device measures RPM of any engine (gas or diesel) with any number of cylinders automatically without any manual settings, using only one audio/vibration magnetic sensor. There are a lot of complex pathented algorithms and real-time signal processing to realize that.

I got the project at support phase, my goal was to investigate and fix the issues discovered during production and in field. For example, device failed to measure RPM on one car while successfully measured all available others. Or the second production run gave half of the devices unable to start. All issues were successfully fixed.

This project was also started from the new HW design, although there was similar project already in portfolio. There was very short timeline for the project, geographically distributed team (Austria, Slovenia, Serbia), five microcontrollers (main one: Atmel UC3A3256 and four smaller ones per each channel: ATMEGA164 and later ATMEGA165) and FPGA for fast sampling of the data. We developed the FW for all microcontrollers and code for FPGA. The customer developed HW and PC SW.

It had different probes support, external calibration and self-calibration, smart power management, self-testing at start-up. Sampled data passed to the PC through USB 2.0 interface.

Later product was extended with configurable signal generator and some other new features. Time pressure increased, the size of the team also increased. Before the deadline we were under big pressure, but the product was delivered on time. It is used over the world now.

Later the new version of the device was developed, some new features were added there, two channels scope was introduced. The code was ported to the new platform smoothly.

We have also developed automatic testing system for the product including probe and signal simulation. The system used for regression testing during development for both versions of the project.

Lessons learned: working under time pressure, team management, conflicts resolving, technical debt processing.

Another project started from scratch: hardware design, my role was FW development from low-level drivers to main business logic and API to the management platform on PC

Lessons learned: safety first. When you are working with battery containing enough energy to kill you or at least make a big fire, safety becomes important.

Two channels scope for automotive use, with support of special sensors like current clamps, pressure, oil temperature etc. Sensors autodetection, auto-level and auto-trigger mode, self-testing, calibration, possibility to update both FW and bootloader – those are the main features of the project.

Team was geographically distributed: Germany, Austria and two cities in Slovenia. We developed bootloader and FW plus PC SW for FW update and calibration. The customer developed HW design and FPGA code.

We were involved in the project from the first revision of HW. At the first step we prepared special revision of FW to test all HW components onboard. After all HW issues were fixed, the main FW was developed. Fast sampling was done by FPGA and sampled picture processing and passing to the PC was made by MC in FW.

The platform was Freescale MCF5235 MC and uCOSII RTOS with TCP/IP stack from Micrium. We developed everything from low-level peripheral drivers to the business logic, captured pictures processing and sending them to PC, selftest functions and calibration.

The project was good learning for distributed team managing. Also sometimes non-trivial troubleshooting was required. One interesting example is the following: on I2C bus we had two devices: cross-switch matrix and EEPROM. The issue was that cross-switch chip reacted on it’s I2C address even if the address was in the middle of data transfer, not at address position. As a result if inside the data block written to EEPROM there was a byte equal to the cross-switch chip I2C address, chip started communication and caused bus collision. After the issue was found it had to be fixed, and it was also nice challenge.

Later we developed the system for automatic testing including probe and signal simulator. The system worked as regression testing system during development and as post-production test system after development was finished.

We delivered the project to the customer and it is still used over the world. We supported it in production and postproduction, although there were almost no errors reported from the end customers.

After changing company from Iskratel to Hermes Softlab and relocating to Slovenia I continued to work on embedded systems/network project: realization of Ethernet OAM on DSLAM.

Till now that project was the best one from organizational point of view. I’ve never communicated directly with the customer during the working. All communication was done through the architect. Tasks were defined very well, reporting was simple and helpful. Team size was relatively small: one architect + one developer for one year.

On the previous job on similar project (DSLAM) we have tried to improve one thing: the device had three different channels of configuration: CLI, DB triggers and the API itself. We had to realize all three configuration procedures separately after any changing or adding new configurable entity. The idea was simple: describe each configurable item once and automatically generate the appropriate code for all configuration procedures. Unfortunately I’ve left the company before we finished that concept. And I was pleasantly surprised when I’ve found almost the same concept already realized in my next product I worked on. They made well-designed C++ framework, where the configurable entities were described in XML with automatic code generation.

In that product the same good concept was used: stable functions were done by specially designed HW chip for the best performance, and features from draft revisions of standards were done by FW for flexibility. The IEEE standard for Ethernet OAM was in draft revision only during product development, but the feature was already requested to be a part of the project.

The main conclusion from that project: communication channels must be organized well and areas of responsibility should be defined. Well written framework could also make things better.