20181117, updated 20210127

Sample "Pop-Up"

The MADAR-III DataProbe has a proprietary I-board that we created with several sensors. The topic of discussion here concerns the real data shown on the pop-ups and the more detailed spreadsheets.  The pop-up shows the current last minute status, while the spreadsheet shows all the one-minute entries and the 60 times faster one-second entries during an alert.

The MADAR map's normally blue registration dots, when left-clicked, show the node's pop-up data. The sample above is from node 123 at Wichita, Kansas.

This is the node number that we assigned and is the permanent number for that particular device at that location.  Originally we had a few single-digit test nodes but the operational nodes began with the 3-digit ID of 100, which is Mountlake Terrace, Washington on up to 158. The later nodes utilize two-digit ID numbers from 99 backwards.

This is the compass "heading". When someone mounts a MADAR device in a certain location the onboard compass is pointing north but the heading depends on the orientation of the device. This means that orientation or alignment is not necessary and that the heading is their normal for that device. So in this case 174.07 degrees is the normal.

This describes the current status of the device.  The term "status" is "routine" or normal background for all the sensors. Alert is self-explanatory. When the device is on alert the blue dot will turn to red. If the MADAR Map has the "sound-on" box checked there will be an audible beep on the computer.

The 2.25 milligaus reading is a real number that is very important. But first let us describe how the main sensor works compared to a hand-held magnetometer.

1.  Our sensor takes readings with 3 axes.  Most hand-held units use only one axis.
2.  Our sensor reads the earths magnetic field while most hand-held sensors filter this out as you are usually looking for something other that the earths field.
3   Depending on the cost of the hand-held meter, it is probably calibrated much better.  Your meter may read 0.90 or 1.2 but MADAR will show a different number.  Our software takes the 3 axis readings and runs them though an algorithm recommended by the sensor manufacturer to get a single mGa reading.

Formerly (and many times during discussions) this may be described as "trigger" or "limits" settings, but in reality this is a settings we select for the unit's threshold. We set devices at 30 before shipping so that we can tweak them once they are online at the right coordinates. If the device is plagued with excessive "hits" or if the device fails to show any alerts for periods too long, this number may need to be adjusted by our Tech Support. In some cases the device may have to be moved to a new location.

This term would require an extensive explanation, so suffice it to say that if the AA is high it means the local field is problematic and will probably mask any effort to detect a real anomaly. As a rule and with experience it has come to be accepted that a reading in excess of 950 milligaus is too high, and higher readings could even be a fire hazard. In a few cases it was found that the I-board became too close to the RP unit. 

StdDev is as a calibration tool to help find a quiet location.  The higher the deviation the noisier the location. Currently this reading is based on the last 400 mGa data transmissions of the node. This is not ideal and we will be changing that to the average field reading that will be sent back to the server with the new node software. This reading will NOT tell you if you have an abnormally high background reading but it will tell you if it jumps around too much.

Example: Suppose you set a magnet close to the sensor.  The reading will be abnormally high but it will likely be a very stable reading and not jump around very much.  After a few readings the StdDev will settle down to a very low number because the variance in the reading will be low.  This situation would result in a very poor environment for the node because a UAP would probably not trigger the node unless it were VERY close. The down side of this is the StdDev would be very low and the mGa would be very low because the high background would be averaged out. Thus our reason for adding average background reading to the incoming data so one can tell if the background is too high. So we should be shooting for a location that has as low of a background as possible and a StdDev that is also low as possible. This will allow us to set a low trigger level.

Some symptoms have been described in the UFO literature which mimic sudden changes in BMP during UAP events and this sensor allows us to study something that has not been properly set aside on questionnaires.

The location of the Node is precisely set at the exact coordinates from the exact address. For example, Boise, Idaho has two devices but miles part and two different node numbers.

I1.33RBU is NOT the version of the MADAR-III DataProbe device, but the version of the software currently ON the device. All of the hundred-plus devices running today have the new I-board and not the original Q-chip, and are running with the software version 1.33RBU. The upcoming updates from the server should change the version number upon reboot. 

This shows the last reading logged on the pop-up. The date and time is in Universal Time Code and should be current with any of your other devices using that format. For example: In the fall, 2018-11-17 15.29.20 is 9:29 AM CST here at Newburgh, Indiana. If the time is off on the pop-up, refresh your screen. If it is still off, the node has shut down.

Anyone interested in direct participation in either Project MADAR or Project MATCH is  certainly welcome. Please contact me at:

Fran Ridge

Information on MADAR and how to order the MADAR-III DataProbe can be found at: