While I wait for some PCBs to arrive for assembly instructions, I thought I should start explaining why and how Microwave Tomography is implemented.

The main motivation behind implementing Microwave Tomography as a method for presence detection was to keep the aesthetics of the "floating button" design. There wasn't a suitable material for PIR, and sonar is too big and too expensive. I wasn't willing to make compromises to the design for some outdated and unreliable tech, so I discovered Microwave Tomography instead.

The concept of Microwave Tomography is simple: water absorbs microwaves. Microwave is around 2.4GHz. Humans are blobs of water. We can detect the presence of moving humans by measuring the disturbance in RSSI between several 2.4GHz transceivers.

The simplest scenario is with two transceivers. One would be constantly broadcasting "token signals", much like iBeacons do, while the other receives. A human passing between the nodes will cause a change in the RSSI on the receiver end. This effectively creates a trip wire.

If there are three nodes, and assuming that only one node can be bursting token signals at any given time, then things get a little complicated. The nodes have to determine which one is the transmitter, which ones are receivers, and how to "cycle" amongst themselves (If there is no cycling then this only creates two sides of the triangle instead of three). This was the biggest problem I had to solve, and I came up with two ways to do it. Both failed to meet my expectations but were monumental in helping me with the design of the successful method, which I will write about next time.

For anyone interested in reading more about Microwave Tomography, there's a patent filed by Xandem in 2011. The exact implementation of measurement is different from mine, obviously. (fun fact: I discovered this patent after I came up with my first method) It does give you more details on the basic concept. Click here to see it.

Before I talk about the failed attempts, I should clarify exactly how the disturbance is measured for the first two methods. Tokens are transmitted at 50ms intervals at 8 tokens per set. The disturbance is measured as the absolute difference in the max and min of the measured RSSI of the 8 tokens. If the disturbance level is greater than 3, then it's considered to be tripped. The reason for the base level to be 3 rather than 0 is to account for the natural noise in steady state. I also had to make sure that only one node was transmitting at any given time, as distance also affects RSSI. Each node is identified by a 16-bit address, ranging from 0x0001 to 0xFFFF (from hereon referred to as "names". The names were randomly generated in excel.

Now, on to the (important!) failures:

Method 1: Sequential Loop Topography

The first thing that had to be determined was the sequence in which the nodes cycled. Without knowing the exact location of each node, this could have been difficult. However, I decided that the location is irrelevant, as they will be arbitrarily placed in 3D space anyway. Because of the random nature of the placement, the burst sequence is numerically sequential (as in, the nodes burst one after another in numerical sequence based on their names), but random in space.

Each node were loaded with the names of the next two nodes after it, and the central control hub was loaded with a start code. The nodes sent their tokens, then sent a start code to the next node. If the next node was lost, then the node would try again with the one after. If that was unsuccessful, then the hub would be notified, and the sequence started all over again. This is what I called the Loop Topography.

The cycle worked perfectly with two nodes. Then I added the third, then problems started showing up. For whatever reason (perhaps the transceiver was too slow), connections were constantly lost, and the loop would break when a person is detected. I abandoned this sequencing method early and moved on to the next one.

Method 2: Sequential Star Topography

The main difference here is that the hub has complete control of sequencing. When a node finishes bursting, instead of sending a start signal to the next node, it instead sends a finish code to the hub, prompting the sequence to continue. This fixed all of the little pesky problems, such as the dropped connections. This led me to discover the main issue which forced me abandon sequential bursting and re-think my approach to tomography - as the number of nodes increased, more movements were missed in the network. The number of misses I had, even with five nodes, were over 30%. This number would only get higher as mode nodes are added. For a network that was designed to contain up to several hundreds of these nodes, this was simply unusable.

These are my failed experiments. In the next Tomography post, I will write more in depth about my new approach, as well as some of the improvements I'm working on.