MADAR III Data Probe – Under the Covers

In my last post I described the MADAR project and the effort to create a worldwide network of sensor nodes to detect UFOs. This post is for the techies who might be more interested in what’s actually going on under the covers with the device itself.

Support the Project

Before I jump in, a few thoughts about my effort to dissect the MADAR probe.

First, it’s a closed project, and I do respect that the director made the decision not to share the hardware or software specifications. A fair amount was probably invested in the engineering and I can understand the desire to preserve any IP.

Second, there’s a mention on the MADAR site that the technology is patented, so fair warning to anyone who wants to recreate one of these devices on their own. The reality is that even if someone managed to build one, a significant part of the project’s value is in having a distributed network of sensors across the globe. In my opinion, it’s just easier to support the project and join the network versus trying to reinvent the wheel.

Now that the PSA is out of the way, let’s jump into the hardware.

MADAR III Probe – The Hardware

Central to the project is the MADAR III Probe. Under the covers, it’s a small single board computer bundled with a tiny 3-axis magnetometer and mounted in a 3-D printed case. When you order the device, you’re asked for location information and it’s mailed to you preconfigured. You just plug it into an ethernet port and it starts to collect EM readings and sends to a server in a central location.

When I opened the case I was surprised to find a Raspberry Pi. It looked to be a 3 Model B+ (which I later confirmed with a cat of /proc/cpuinfo.)

Mounted on the Pi is a daughter board that connects directly to the 40 pin GPIO header. Soldered on the board appears to be 1 or possibly 2 sensors, a relay and a push button switch.

The website documentation is light on the sensor details and the chips themselves are a bit of a mystery because the stamped manufacturing IDs aren’t visible. I’m fairly certain that one is a tiny 3-axis magnetometer because of the data collected. From some additional digging (which I’ll explain later) my guess is that it’s either a QST or Honeywell sensor.

I’m assuming that the second chip is some type of barometric pressure sensor as there’s a mention on the site that this data is available as well.

I’m unaware of any single sensor that can do both, and given that both chips have a similar form-factor, I’m speculating that the second might be a combination 7-axis gyroscope with an integrated altimeter similar to this one. This is a total guess though because although barometric pressure is mentioned, it doesn’t appear to be one of the data points that’s actually exported from the device.

MADAR III Daughter Board – Front
MADAR III Daughter Board – Back

The relay provides a way to wire up an optional external device that can provide an audible alert if the magnetometer detects a field change above the typical background threshold (I.e. Alert! Aliens are overhead!). Your queue to run outside to see if something’s up.

The push button switch presumably just resets the relay to silence the alarm.

Given that the sensors were a bit opaque my next step was to try to logon to the device itself to get for more info.

MADAR III Probe – The Software

Did I mention there’s no login provided? First step was to gain shell access to the device itself. Luckily with physical access to the Pi SD card, it’s relatively straight forward to boot into single user mode and create a login.

Once logged in I discovered a controlling script (compiled in C) named madar_node along with supporting files under the /home/pi user directory. The script is configured to run continually with a second watchdog script called watch.sh that makes sure it’s always running.

The madar_node script takes readings from the magnetometer every minute and sends the data to a central server for reporting. Here are the fields that are collected:

FieldDescription
Node IdX digit unique node ID
Event Typestatus, alert, alertStat, alertStart, alertEnd
Compass (Degrees)Compass heading (0-359)
mGamagnetic field milliGauss
Avg. Ambient mGaAvg Ambient milliGauss
ThresholdmGa threshold for alert status. (I’m not sure how this is calculated, but individual nodes appear to have different values.)
Accel/PressureUnsure of this one. Many magnetometers have a builtin accelerometer, but the pressure is a mystery. The value collected from my node appears to be acceleration only.
DateYYYY-MM-DD
Time%H:%M:%S

Collected sensor data is sent to a server IP that’s referenced in a madar.conf file in the /home/pi directory. The same output is also sent to statusLog.txt in this format:

status,174,0.00,203.48,1.00,2021-10-17,22:00:18,578.41
ack

The script operates in the following way:

  1. Every minute data is collected and the mGa value is compared to the threshold.
  2. If the threshold is not breached, a “status” event is written to the log with the collected sensor values.
  3. If the threshold is breached, the script goes into overdrive. An “alertStart” event is written to the log, 3 additional “alert” events are written immediately to the log, and then data is collected every second for 3 minutes as an “alertStat” event.
  4. After 3 minutes an “End Fastscan” messages is written to the log and then normal one minute data collection resumes.

The madar_node script appears to be a compiled C program. This makes it difficult to get any additional info on how the sensor data is actually collected and calculated. However, using a binary editor I was able to get some additional info from some print statements.

I found a comment within a function that determines whether a QST or Honeywell chip is present. This provided an additional clue to what the sensor might be. For Honeywell, my guess is a HMC5883L 3-Axis digital compass.

Historical data collected by all the nodes are publicly available on the MADAR site. Unfortunately, the reporting is limited in that you can only view the data in a table. There’s no export option or ability to create graphs or charts. To get around this I have my own custom setup (using Splunk) so that I can export the data locally and do my own analysis.

Magnetometers and UFOs

You might be wondering what my thoughts are about the validity of using a magnetometer for UFO detection. I discussed this at length in my previous post, but I thought I’d add some additional color here.

First, for such a small form factor the magnetometer is MUCH more sensitive than I would have imagined. Placing the device anywhere near other electronic equipment greatly impacts the readings. Also, I noticed that just opening a draw of tools 3′ away from the device was enough to send the monitoring script into an alert state.

I ultimately mounted my device on a small shelf in the rafters of my garage to eliminate as much EM noise as possible. This is easily 20′ away from the nearest electronic device and there is very little variability in the electromagnetic field at this location.

Overall, my biggest concern with the project design is the proximity of the sensor to the Raspberry Pi itself. I wouldn’t be surprised that under certain circumstances that the Pi could generate an EM field that would influence the sensor.

Concerns aside, I’ve been collecting data long enough now that I’ve become comfortable with the range of readings and the consistency. This is why when an anomaly does happen it’s a bit of a head scratcher. This is an example of one a few months ago. Like mentioned in my earlier post, I have my very own WOW signal.

I’ve seen many misunderstandings on social media about what this device does and how it operates. With this post and the last, I’ve tried to make the case that there’s merit to this project and hopefully more people will join as a result.

If you liked this content make sure to share on social media!

Please follow and like us:

Leave a Comment