# 06-24 IPS Host Case and next steps
Since I haven't encountered any significant problems in the last few days, I have been keeping the journal entries quite short. Today I designed a case that optimizes the signal stability by exposing the antenna in an upright orientation and by raising the host off the ground. Thus, multipath fading and shadowing is reduced as compared to a host placed flat on the ground. A lot of work went into the asthetics of the unibody and physical stability so that the expensive devices do not fall over.
The location of the stand is directly under the center of gravity, so the case can even stand upright without the wooden rod. The RPi is fastened using 3D printed screws so that other people won't have to go to a store to buy M2.5 screws. Furthermore, metal screws interfere with the RF signals. The triangular antenna on the right is exposed by a cutout in the case.
\newpage
{ width=60% }
{ width=60% }
# Problem
The real time correction algorithm is not effective because there is no correlation in the signal strengths picked up by the client or the gateway. I find it hard to believe that the antenna misconfigurations from mass production or multipath fading are causing the RSSI to vary between devices so much. The question I am asking myself is what in my setup is causing the RSSI between devices to be so different even though they were placed 6cm apart during all tests.
# Possible solutions
# Processing on Localhost and 5 GHz Wifi
Running the backend on the local host eliminates network delays completely and keeps the amount of traffic passing through the antenna at a minimum. This reduces signal interference in the 2.4 GHz frequency band, which is the area in which BLE and our home's WIFI operate. Another option that can reduce the interference further is using 5GHZ WIFI for SSH access. Then there should effectively be no traffic on the antenna at BLE frequencies.
# Testing Outdoors
To really be sure that multipath fading and shadowing is not causing the fluctuations, I can test the fluctuations in my yard or in an open area. If the RSSI graphs are congruent in an outdoor environment with hardly any obstacles and reflections, then I will know that shadowing and multipath propagation are causing issues.
# Timestamping and Clock Drift
Perhaps timestamping measurements using NTP time from a server in the LAN is inaccurate. The measurements are not synced up in the backend with their counterparts from the other device. Due to drift, it becomes impossible to link up measurements accurately. I seriously doubt this is because measurements are too far apart. A typical time delta between the measurement timestamps between devices at 40ms advertising intervals is in the low tens of milliseconds. The amount of jitter in the NTP is lower than a millisecond and drift is said to be roughly 100 PPM. That means we are talking about ~8 seconds worth of drift per day. Assuming 100PPM is realistic, this is actually quite significant, since after 30 minutes of runtime the clocks will have drifted by
# Next Steps
The immediate next step is to containerize my backend with something like docker. It is currently a huge pain to set up Apache, Redis, PHP-FPM and Laravel. The prospects of doing this twice for the Raspberry Pi 4 Model Bs and my past positive experiences with automating boring processes suggest that a BLE IPS docker container is a good time investment. It is also easier for people to use my software in future since it will work out of the box as a container and be downloadable from the docker hub.
The client side module will still run on the bare metal server since it needs access to the HCI BLE socket. After putting the software in a docker image, I can test 5Ghz Wifi and localhost configurations. Then I will do some testing in my back yard and in the neighbourhood.
I will also order two RTC to eliminate any issues with clock drift. Expect a lot of entries about testing results in the next few days.