Adopting the kibi

Throughout my technological lifetime I followed the convention that 1 kB was equal to 1000 bytes and that 1 KB was equal to 1024 bytes. Similarly, 1 mB was 1 000 000 bytes, and 1 MB was 1 048 576 bytes.

In dial-up Internet days, we surmised that a 56K modem transferred data at a rate of 56 000 bits per second (that is, 56 kbps or 5.6 kBps). Therefore, dividing the nominal modem speed by 10 gave a simple divisor for quickly calculating the download times of files with sizes expressed in kB, that is,

download time in seconds = file size in kB / modem speed in kBps

In reality, however, this was no more than a loose convention adopted by Internet users to express data volumes and bandwidths, and distinguishing between 1000 bytes and 1024 bytes by using kB and KB in writing was very convenient.

I continued with this convention until comments from a heated debate on reddit informed me of the 1999 IEC 60027-2 standard, which introduced the kibi and removed all ambiguity. The MB Confusion blog post explains this standard in a more interesting way than the Wikipedia article.

Trap with `gmtime` and other time functions

From man gmtime:

The gmtime() function converts the calendar time timep to broken-down time representation, expressed in Coordinated Universal Time (UTC). It may return NULL when the year does not fit into an integer. The return value points to a statically allocated struct which might be overwritten by subsequent calls to any of the date and time functions. The gmtime_r() function does the same, but stores the data in a user-supplied struct.

ESP8266: Always call ‘wifi_wps_enable’ before ‘wifi_set_wps_cb’

For WPS to work on the ESP8266 and using the non-OS SDK, be sure to call wifi_wps_enable() before setting the callback function with wifi_set_wps_cb().

For example:

void wps_start()

In the callback itself, call wifi_wps_disable() before wifi_station_connect().

For example:

void wps_callback(int status)

ESP8266: Flash images at more than 115200 bps

If esptool is limited to 115200 bps when flashing your firmware to an ESP8266, you can try to increase the bitrate by following the steps below.

  1. Locate for your installation. On Debian and Ubuntu, this file is located in /usr/share/esptool.
  2. Edit and change the value on the line starting with ESP_ROM_BAUD from 115200 to the maximum of 921600 or your preferred baud rate.

ESP8266: Always call `uart_init` before `gpio_init`

I don’t remember if this information is in the documentation, but having spent a few hours to figure things out, I think it is important to record it here.

For example:

void ICACHE_FLASH_ATTR user_init(void)
     * Always call uart_init() before gpio_init()
    uart_init(BIT_RATE_115200, BIT_RATE_115200);


    os_timer_setfn(&os_timer, &main_on_timer, (void *)NULL);
    os_timer_arm(&os_timer, 50, 1);

Remember, C# does not have an exponent operator

This is a cautionary tale for developers who often switch between programming languages.

Whilst reviewing some logs, I noticed that durations of pauses between API requests were incorrect. They were supposed to double on every subsequent request, starting from a fixed base interval; for example, 5 seconds, 10 seconds, 20 seconds, 40 seconds, and so on. Instead, they were changing unexpectedly: 15 seconds, 30 seconds, 60 seconds, 0 seconds, and so on.

A colleague and I reviewed the following C# code but could not find what was wrong.

int tmp = RetryIntervalInMs * (2 ^ retryCounter);

The incorrect durations puzzled me throughout the day as they were mathematically impossible given the exponential growth algorithm.

Later that evening, when I did some embedded development in C, I suddenly realised what was wrong.

I had used the ^ operator in C#, interpreting it as ‘raised to the power of’ as in some other language — which I cannot even remember now — whereas it was actually an XOR operator. Even two of us reviewing the code together did not spot that mistake.

The fix was to use the Math.Pow(int, int) method, as follows.

int tmp = RetryIntervalInMs * (int)Math.Pow(2, retryCounter);

Avoiding time drift in virtual machines

If you use a virtual machine, you might notice that its system time starts to lag after it has been powered on for a while. To solve this problem, it is useful to run an NTP (Network Time Prococol) client within the VM to have its time synchronised regularly.

On Windows, automatic time synchronisation is enabled by default and uses the server

On a Debian-based Linux distribution, you can install NTP with apt install ntp and start it with sudo systemctl start ntp.

Caveat with AddInitialRequestCultureProvider() in ASP.NET Core

AddInitialRequestCultureProvider() in ASP.NET Core localisation seems to have an undefined behaviour when it is used in both services and application builder configurations to add a custom RequestCultureProvider.

If you want to use a custom RequestCultureProvider to customise how the applicable culture is determined for an incoming HTTP request (for example, by looking up the chosen culture of a user in the database), you must configure the provider in the services collection as described in the section ‘Use a custom provider’.

You must also call IApplicationBuilder.UseRequestLocalization(), but you must not pass any argument to the method. If a RequestLocalizationOptions argument is specified here, it supersedes what is configured in the services collection, and your custom RequestCultureProvider does not work.

Typically, you configure the middleware in the application builder before the services. But in order to emphasise the significance of setting the localisation options only in the services configuration, I have reversed this order on purpose.