Sample "Pop-Up" from Node 06

The MADAR-III DataProbe has a board 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. Of particular interest here in this discussion is StdDev. But first things first.

That is the node number assigned by the server and is the permanent number for that particular device at that location.

This describes the current status of the device.  Status is "routine" or normal background for all the sensors. Alert is self-explanatory. On the spreadsheet the status can also be AlertStart, AlertEnd.

This 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 in 3 axes.  Most hand-held units use only 1.
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 whole number of 1.0.

So as to the discrepancies between our sensor readings and a dedicated hand-held they probably will be due to any one or all the reasons noted above. The readings shouldn't be too different however but that may depend on where they hold the hand-held and it's orientation since it only reads one axis.  Our software takes the 3 axis readings and runs them though an algorithm recommended by the sensor manufacturer to get a single mGa reading.

Note 3 is an important one as our sensor does not have to be as accurate as a hand-held to work as intended.  These sensors were meant to function as a compass and as long as the 3 axies were matched at the factory they can tell you direction just fine.  A compass function is more dependent on field polarity than field strength so a super accurate strength reading is not as important for it's normal advertised use.

We submit that a super accurate reading is not needed for the sensor to function as a MADAR device since we are simply looking for a deviation from normal whatever the normal is.  Of course we want NORMAL to be as low as possible to pull out small disturbances. This, however, will depend very much on where operators choose to setup their nodes.  Also, the devices only need to lay flat if an accurate compass reading is desired.  The mGa reading can be calculated at any angle so long as the angle does not change.  We only generate whole numbers because the sensor is only accurate to 2.0 mGa.

Formerly (and many times during discussions) trigger may be referred to as "limits" settings. We set devices at 30 before shipping so that we can tweak them once they are online at the right coordinates. 40-60 is actually too high and 10-20 could be too low. If a device is working properly and triggers too often, the settings are probably too low. If three months pass with no AlertStarts the settings may be too high. It's up to ourTech Support to help the Ops obtain maximum sensitivity.

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 too 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 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.

This number is NOT the version of the MADAR-III DataProbe device, but the version of the software currently ON the device. The 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: 2018-11-17 15.29.20 is 9:29 AM 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 partcipation in either Project MADAR or Projec t 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: