Limits of Search and Rescue

Limits of Search and Rescue

Last year I lost a remote control plane that had a 1080p video camera onboard. The loss was largely due to not following flight procedures. It was the result of a combination of factors that could have been avoided. Once I realized that the plane was no longer responding to controls, it was too late. All I could do was watch as it slipped behind objects on the horizon.

Searching for the plane was out of the question due to the distance it could have traveled and my limited access to the surrounding area. My greatest concern was where it might land and the trouble that could cause. It was unnerving to think of all the possibilities. As a result, I decided not to fly again until I fully understood what happened and how I could avoid this in the future.

There are plenty of resources covering the safe and responsible operation of model aircraft. One that I found after this incident was a book by Jim Mohan titled “RC Ground School”. It covered most, if not all of the items that would have prevented the loss.

If I had done all that I could do, could another loss occur from some other unforeseen circumstance? That’s difficult to answer and I would have to assume it could. So it stood to reason that the aircraft should have some kind of beacon so it could be found. When I thought of how this could be done, the idea of using the AI Thinker ESP32 Camera module came to mind.

It’s a low cost, light weight, low energy microcontroller that has on board WiFi and BLE. I had already purchased some a year before for another project that was scrapped for a better solution. It didn’t take long for me to find this example of BLE and its use in an Easter Egg Hunt.

The setup consisted of similar items that would apply to my project. There was a beacon that would periodically broadcast a wireless message and a device that would detect it and provide some kind of locating indication.

I also purchased a commercial BLE beacon that was typically suited for that purpose. In addition, there are phone apps that will provide signal strength indication of BLE beacons. I did some field tests with my phone and the commercial BLE beacon to get an idea of the process. However, the commercial BLE beacon was too large and heavy to be useful on my aircraft. I also noticed that it had a limited range.

So I went about coding the ESP32 modules, the first being the beacon, and the second being the locator. The locator incorporated a GPS module. The idea was that a pre-defined beacon phrase would be filtered out from any other BLE beacons. I was surprised from my earlier field tests the number of broadcasting devices in the environment. By filtering out the others, the locator would only trigger when my BLE beacon was in range. This would trigger the ESP32 module to store both the BLE signal strength and the GPS reading where it was detected. It would do this over and over so I could develop a heat map from all of the readings and thus locate the beacon.

When I finally did field tests of this setup, I quickly realized that it would not be viable. The range of the beacon presented the first part of the problem. The second part of the problem was the latency of the locator. The locator spent several seconds making readings and that gap in time could lead to missing the target when I was surveying an area.

Here is a demonstration of a beacon in varied shades of red squares surrounded by green squares indicating where the locator was when it made its readings. As far as the locator is concerned, there is no sign of the beacon.

This made covering a large area in a limited amount of time unlikely for success. It required a tight and slow scan, something that would be a challenge and that would increase the risk of another aircraft becoming lost. This gave me some understanding to the challenges facing those involved in search and rescue.

Comments are closed.