04-27 Work flow analysis

There were no major problems today. First I will discuss a more or less resolved issue. In the last section of this article I analyse what workflow patterns have led to issues so far and how I have to change in order to make my work more effective.

Small Issue

Path loss model input parameter uncertainties

The client side does not provide the backend all the necessary information to calculate distances. The log distance path loss model needs to know the TX power in dBm to find the power lost in over distance. Currently I only supply the RX power level. Furthermore, the RSSI is technically speaking a relative value that manufacturers use to indicate signal strength of their wireless product. I was uncertain what the unit of the RSSI values was (dBm is necessary) and whether I was saving relative RSSI or absolute RSSI.

Espressif API reference

I dug around the rather excellent ESP32 API documentation online. In the BLE Client library I located a FreeRTOS binary semaphore snippet illustrated down below.

	m_semaphoreRssiCmplEvt.take("getRssi");

	esp_err_t rc = ::esp_ble_gap_read_rssi(*getPeerAddress().getNative());

	return rssiValue = m_semaphoreRssiCmplEvt.wait("getRssi");
}

It matches the esp_ble_gap_cb_param_t::read_rssi_cmpl instance member of the BLE Gap event handler and returns the RSSI in dBm. The possible range is from -127 to 20. I am using the right values in that case.

Espressif Systems also provides a datasheet with the hardware specifications of the RF antenna.

Workflow review

Problems

I wasted a lot of time resolving issues in throwaway code. In March 29's article about my intended workflow I declared that I would work towards the final product in small steps. Yet for the last week I have been working on code that I intended to replace entirely. I was not working on the final product.

How to promote effectiveness of work

I should make my feature branches on GitLab smaller. There shouldnt be more than 10 commits to them, because otherwise it is very likely that there are changes to different topics in the codebase. As a result, the changes are less effective at resolving an issue and tend to fail tests. Consider the failed feature branch feature/webservices-and-models vs the feature/register-discovered-servers-on-startup branch. Both intend to do the same thing, but in the former I attempted to make webservices and models for servers, clients and measurements. The branch is ineffective because it wasn't clear on creation what the precise intended purpose of the changes were. The second branch already in the name says exactly what is does and makes it easier for me to quickly implement the necessary changes.

A large proportion of my time is wasted while building the code and writing it to the ESP32. With web development I developed the bad habit of changing something small to the code and then quickly checking what it does by running the script. The problem with this approach is manifold. With C++ and embedded systems, it is very inefficient to develop by trying out algorithms. The software has to be highly optimized so that the underpowered hardware can handle it. This is not achieved by writing code and seeing at runtime if it works. The second problem is that code written blindly is not deliberate. It often lacks a concise intention which leads to the build including changes that are not necessarily involved in resolving a branch's issues.

It is much more effective to architect code by prototyping not in the code itself but inside a sequence diagram. Consider my decision to base my measurement uploading on a scanner callback. It was a prototype to see if I could upload live RSSI values. Being a prototype, I knew that it would not be fully functional. Yet I still spent all of last week prototyping a proof on concept that I could have just as well done a sequence diagram. The result would have been the same. A sequence diagram forces me to think things through and look at things as a bigger picture. The difference is that it takes a sequence diagram an hour to make, yet a scanner class with callbacks and webservices will consume a whole week's time.