# 09-02, 09-03 Various Problems

Today I enabled the multiple antennae in software, all measurements from three raspberry pi are pumped into the same measurement pool. There are many problems that stem from this, the details and solutions are described below.

I also added an active flag to the servers table, so that only active servers that are turned on are returned to the trilaterator and inactive servers' measurements are ignored.

I also finished writing some unit tests for the trilateration software and actually caught a pretty big bug in the residual function. I squared a value two times instead of only once, which greatly skews the weight of outliers on the outcome.

The order for the router on ricardo went through for a whopping sum of 3 CHF. Soon I will be the proud owner of a Netgear Dual Band Wirless-N Gigabit router. In thinking that I wouldn't win the bid for such a low price, I bidded on two other ones for 1 CHF each. It is likely that I will win these too.

# Problem 1: Something in API isn't crashing when it should

These are the position estimates when using three clients in order to get three antennae. In the backend the values that are input are averaged with the 5 preceeding and succeeding values, the saved mean is displayed down below in respect to time.

{ width=80% }

{ width=80% }

# Sample source data for graphs

Very irregular values, this is a moving average and there are gigantic jumps between the values.

origin          timestamp       rssi (averaged)
mvavgclient     1599072718761   -67.016851011423
mvavgclient     1599072718689   -50.173211732865
mvavgclient     1599072718678   -50.173211732865
mvavgclient     1599072718643   -61.794791372522
mvavgclient     1599072718603   -67.016851011423
mvavgclient     1599072718594   -67.016851011423
mvavgclient     1599072718562   -54.780729931491
mvavgclient     1599072718555   -57.944555440001
mvavgclient     1599072718553   -54.780729931491
mvavgclient     1599072718551   -43.953989062722
mvavgclient     1599072718540   -43.953989062722
mvavgclient     1599072718489   -61.794791372522
mvavgclient     1599072718476   -57.944555440001
mvavgclient     1599072718472   -54.780729931491
mvavgclient     1599072718459   -43.953989062722

What is weird is that there are these clusters of values with very disparate RSSI. Something was wrong with the PHP api because the rolling averages were wrong. There aren't any logged values for raw client RSSI, which are usually logged before anything else.

 1 getting latest 50 gateway:server:24:6f:28:7a:45:8e  measurements
 2 got 0 measurements //comment: this is okay, there are no gateways active
 3 Sorting by timestamp
 4 getting latest 50 raw:server:24:6f:28:7a:45:8e:client:dc:a6:32:3d:c9:ba:measurements measurements
 5 got 50 measurements
 6 Sorting by timestamp
 7 calculating rolling average rssi of client measurement
 8 getting the index of a measurement with origin: client
 9 position of measurement in pool:  of 50
10 RSSI values found: 5
11 mvavgclient	1599072713606	-54.780729931491

At line 9 we see that the rolling average class could not find any measurement in the array of measurements that was passed to it. Without the index it could not calculate the mean average as a moving average with the correct window size. That is why the output looks so weird in the images above. Weirdly enough the bit of code that manages this passes the unit tests and seemed to work on my laptop. The output there seemed normal.

# Solution and further actions regarding problem 1

There is some digging needed here and the program HAS to crash if the index cannot be found or if anything else was not successfully loaded. I also should trust the unit tests less, because they give me a false sense of security. Perhaps the moving average algorithm should also be moved to the trilaterator. What also might be smart would be to increase the averaging window size in order to reduce the influence of outliers even further.

# Problem 2: Coefficient approximation needs to be improved

I want to start this off with a big disclaimer: This results of this are based on bad data (corrupt due to issues mentioned above) but I figured that this still is a problem regardless of the corrupted data source. The results are posted in

I have to make it easier to calibrate the system. The Y-axis offset is really important in deciding which servers are selected for trilateration. There is a noticable bias in favor of servers with low y-offsets. What also skews the trilateration results is transferring coefficients from one client-server constellation to another. One needs to calibrate the system whenever the hardware changes and work is restarted the next day.

# Solutions that I will implement

# Make calibration walk shorter

I can walk less far, currently it is 5m meters but I think 4 meters is also reasonable. The intervals between stops is also set to 25 cm now but it could also be something like 25 cm for distances under 2 meters and 50 cm afterwards. This reduces the amount of time necessary for a walk.

# More accurate path

The walk should also be routed along a more realistic path, currently I calibrated using some arbitrary line I taped out on the ground. Most likely it is more correct to do it radially from the place of the actual beacon stand into the coordinate grid because the PLM conditions (shadowing, reflections) are definitely different there.

# Calibrate for all antennae

It makes sense to determine the PLM coefficients based on values collected by all active clients (in a multiantenna setup) since the PML might be different based on the client's antenna properties. When doing the calibration walk the data can be collected simultaneously on all active clients and uploaded to the backend with no further software changes required.