Node Inventory & Updated "Hit" List

Day One is really the first day after a previous week of work on the MADAR Project. Each Monday morning we look at the data on the spreadsheets to accomplish several things:

1) Conduct a weekly inventory of devices running and make necessary adjustment
2) Gather reports of alerts that occurred since the last weekly inventory
3) Update the Project MATCH "Hit List" for MUFON state directors

The first thing we do is run a Node Settings Report. It shows, among other things, each device's limits/trigger settings for the time (week) prior so that false alerts can be minimized without sacrificing the ability of the DataProbe to detect a real anomaly. Then, as the morning proceeds, MADAR Ops are emailed to inform them of any changes in settings were made. As long as a node is not in alert we can make changes on the server and do aremote reboot.

Then, a binder which is kept with one-page printouts of each node's spreadsheets showing each node's AlertStarts. Flipping through these pages filed in numerical order, while looking at the server's spreadsheets online, it can be easily determined if the device is actually running and when the most recent AlertStarts were logged.

Show All

To determine which devices are running we log into the MADAR server and type in the node numbers beginning with Node 01. In the sample above we are looking at Node 100 which is located in the state of Washington. In the Event box in the top line, right, we select "Show All" and the spreadsheet above is displayed. In the upper right is the current Universal Time Code of 2018-09-30 22-01-30, which is Sept 30th, and the local time conversion is 1501 (24-hour clock and 30 secs) or 3:01 PM.

  MFJ-12/24 shows local time & CUT/UTC set with atomic clock.

Using this special clock (which we highly recommend to MADAR Ops and about $25) we look at the UTC to see if it is 22-01. (The sample above shows a time 15:23 from an advertisement, not what we are suggesting).  So if this number is the same as the spreadsheet's top line, the device is running. This is the way we determine which and how many devices are operating in the field.

We have a database on our main computer that lists everything about each node in numeral order.  The key column for this discussion is called "Latest", which is the status, and "running" is one of the status features. "Stopped 8/11" is another which means a device is NOT running and quit sending data on Aug.11. So this information in the form of a Node Report is presented to the software team in our weekly conference calls on Wednesday nights and used in communications with field ops to keep the DataProbes doing what they need to do.

While we are looking at the nodes, the second thing we want to see is when the last alert took place, to see if there were any new AlertStarts since the last inventory a week prior. In the Event box we select Alert Start.


In our example of Node 100 we know that the device had the last AlertStart on 08-11. Since our binder copy shows the same thing we know there have been no new anomalies detected by Node 100.  If there had been a new date on that top line this would tell us there had been a new alert. And if the Op never reported any false alerts it would be considered an actual alert. A copy of the spreadsheet is then printed out and placed in the binder, and the old one is discarded.

CG Form

The alert data is then handwritten-in on a CG Form called Alert & Potential Sighting Correlation Guide. The upper part asks for the Node number, city and state. The Date and UTC (Universal Time Code) are listed and the local time in 24-hour format found on a conversion chart. The CG Forms are set aside untl Day Three. The sample above includes some readings but they are generally not used until a potential sighting correlation is found.

Both links are very helpful in finding a node's local time from UTC.  We are about to set our clocks back so this will be even more useful.

After all the nodes are checked, the CG Forms are used to update the MATCH "hit list" and the Project MATCH Intel Summary, our monthly MADAR report. The "hit list" is then forwarded to the MADAR Team (which includes original members and MADAR Ops) and MUFON's MATCH Supervisor, Rob Swiatek so he can get the data to state directors.

So much for Day One.