05-11 PLM inacurracies

Problem: Signal propagation exponents are inaccurate

The Path loss exponent n of my living room is 2.41514, which I calculated in a documentation post. Inserting the number in my formula gives me very wrong numbers. The sample result below is roughly 3.5 meters instead of 1m. I noticed that the numbers today are a lot lower than yesterday for all servers.

The RSSI is a function of the distance as shown below.

where describes the distance, is the room's signal propagation exponent and is the RSSI at 1m distance.

Thus follows:

which shows that the calculation in backend is computationally inexpensive.

Calc. Result of 50 measurement mean where

[2020-05-11 16:39:20] local.INFO: :::::::::::::::::: Getting distances ::::::::::::::::::
[2020-05-11 16:39:20] local.INFO: $rssi: -61 // mean of 50 measurements
[2020-05-11 16:39:20] local.INFO: $distance: 3.4813615830611

Clearly the calculated is not equal to the actual by a large margin.

Perhaps this is partially bad data since the histogram of the 1 meter measurements as shown in the docs seems very noisy.

Solutions

Take measurements again and get using smallest squares method

I did it before, so maybe I can do it again to obtain new constants. The thing is that I really dislike this because I spent hours taking measurements for all devices at different distances and then importing them as JSON in excel for processing. It is a very cumbersome process that does not make lots of sense to do again if this is something that changes daily.

Calculate the average of RSSI at fixed distances offline

Above I do regression on the average RSSI at given distances in respect to d using the formula below.

From this follows:

This paper suggests that one can take an average of the RSSI at fixed distances instead of taking the least squares approach with regression. To be honest I am not sure what difference it really will make.

Calibration sequence

The environment constants could be approximated dynamically as suggested in this paper. They do it in real time when measurements come in, but I think an 'offline' version would also be okay. As shown in dbdiagram, my database already associates servers with an environment. There I can store values for and which I approximate in a calibration sequence on startup. Assuming that is same for the whole environment (our house is not particularly big), I can more accurately apply the PLM to get input data for the multilateration.

Next steps

The calibration sequence seems the logical choice here, since the database infrastructure already exists (REST API provides CRUD operations for environment values). It seems like a big time saver too, since messing around with JSON in Excel is a pain and took me 4 hours. A second npm script like npm run calibrate can be optionally run to approximate and and save them in MariaDB.