# 09-24 Calibration Scheme
While checking the amount of daily SARS-CoV-2 patients on the BAG's website, I came across a technical paper about how the threshold values for SwissCovid were adjusted. It (unsurprisingly) turns out that researchers at the EPFL had been having issues with finding the correct parameters for signal attenuation. There was a reference to google's Exposure Notification documentation, which is the primary API used to gauge the difference between devices. It contains lots of helpful information about how to calibrate devices and what the pitfalls of distance estimation using BLE are. I had already made lots of the insights myself, but they had specified their own calibration scheme that can be applied to a certain degree to my situation as well.
# Google's EN API Calibration Tips:
# Environment requirements
- If an RF anechoic chamber isn’t available, then we recommend testing outdoors in a dry environment, far away from objects (buildings, cars, trees, heavy vegetation, and so on).
Testing in a situation with very low signal multipath fading and shadowing is a good way to get a sort of negative control for the experiment. It would be interesting to see if it is more reliable outdoors.
- Stand a few meters away from the test setup while the calibrations are running. To ensure a consistent reading, stand in the same position each time so that the impact of your body is identical between tests.
This is something worth considering, since I generally stood right next to the device stand. I did this because I wanted to reduce the time induced by having to walk back and forth when repositioning the device on the grid. It makes sense that this is probably not the best practice.
- Set up the two tripods holding the DUT and reference device 1 meter apart, with the devices 1.5 meters from the ground.
This is very similar to my test setup with the purpose built stands. They devices rest at a height of roughly 1.2 meters.
# Device Setup
- Make sure the reference device and the DUTs have no cases, no attached wires, and nothing else attached that might affect RF performance.
The cases I made intentionally do not cover the antennae and are necessary to mount the Raspberry Pis. But I have some pretty beefy metal coolers stuck to the CPU's that can interfere with signals. There are also wires in the way that power the fans. Maybe I need to remove these.
# Experimental Setup
Test for expected behavior with different radio modes (airplane, Bluetooth [BT] off, BT on, and so on). Test for concurrent Wi-Fi/BT radio use (such as music playback). To reduce the amount of traffic on the antennae in single device schemes, I should send the data stream to the server running on localhost. It does not make sense to send them somewhere for processing and risk signal interference if the Raspberry Pi can do it by itself. In multiclient setups I still have to rely on sending data between servers.
# Takeaways
Generally speaking I have to rigorously test the software in the coming few weeks with all kinds of different configurations. I think it makes sense to test for different room setups (length, width, location, indoor, outdoor, multidevice, chaging orientations, concurrent wifi) to get a feel for where the system works best. It will also let me know how to improve the output. Yesterday's work on plotting the positions on a floor plan makes it easy to visualize the results.
The only thing standing between me testing many different setups is a way to do it easily: I feel like the calibration script is slowing me down considerably. It is a very slow process to move around a measuring tape and the devices at different intervals and I wish it were faster. The test stand is very unstable when the center of gravity is so high due to the raspberry pis. I have to stand next to it and hold it so it doesn't fall down and always move it manually to the next spot. It would be nice if I could put the stand on rolls and pull it with a string or something. The next thing I will do is make a better stand for the Raspberry Pi's.