MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Turtle_Sense/Division_of_labor",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "5": {
                "pageid": 5,
                "ns": 0,
                "title": "Turtle Sense",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": ";Using high tech sensors and cell phone networks to protect sea turtle hatchlings\n[[File:HIOC turtle sense logo.jpg|right]]\n\n==Background==\n[[File:Hawaii turtle 2.JPG|400px|right]]\nSea turtles have existed for 100 million years, but in the last century, the impacts of man through accidental capture in fishing nets, habitat destruction, pollution, and plastics in the ocean have significantly reduced populations by as much as 95%.   Six of the seven species nest in the warmer beaches of the US, and all of these are protected by the Endangered Species Act of 1973.  Although volunteer groups and park personnel can identify egg-laying sites almost immediately, the hatching date (when they emerge onto the beach) cannot be predicted\u2014it will happen sometime in a six-week period beginning 50 days after the eggs are laid.  All 100 to 150 of the sea turtle hatchlings in a nest usually appear simultaneously (mostly at night) on some unpredictable date during that six-week period.  The hatchlings \u201cboil\u201d out of the sand and begin a dash to the ocean, one of the most touching sights in nature.\n\nBeginning at 50 days after the eggs are laid, the National Park Service (NPS) at the Cape Hatteras National Seashore fences off a lane from the nest to the ocean and forbids other access to that lane until either the hatchlings appear or the 100 days has elapsed.  This long protection period creates conflicts with other uses for beach access, such as fishing and vehicular movement for recreation and safety.  Conflicts are inevitable, often leading to lawsuits.\n\n== Project Objective==\n[[File:Baby sea turtles make their way toward the water.jpg|thumb|400px|left|This project is developing technology to help protect sea turtle hatchlings at their first crisis:  emerging from the egg and making it to the ocean.  Hatching happens on an unpredictable day sometime during a six-week window beginning 50 days after the eggs are laid.  Predicting the hatching date to within a few days is the goal of this project.]]\nThe goal of the project is to develop simple, inexpensive technology for determining when a \"boil\" will occur with as much accuracy and reliability as possible.  The current design employs a sensor that measures egg motion either as the embryos agitate in the egg or as the sea turtle hatchlings begin to pip out of the eggs or both. The results, perhaps including modeling, will hopefully be able to predict hatching dates (arrival on the beach) to a reliable one-to-three-day window, a significant improvement over the current six-week window.  Developing a reliable technology for predicting hatching will allow the NPS to create a new protocol for protecting the nests, thus freeing up access to the beaches for a significantly longer time.\n\nThere are several possible beneficial side effects of the technology:\n* The technology can be used to help develop ecotourism around the hatching of sea turtles. Once people (especially young people) experience the hatching of these creatures, they may be much more likely to think positively about the welfare of sea turtles in the future.\n* If local people can develop an income around this ecotourism activity, they may be less averse to the obstructions to beach vehicles and foot traffic. \n* The technology might be useful for scientists studying sea turtles and might be adaptable for the study of other egg-laying species.\n\nAll the designs and software code will be published on this website and will be available for use worldwide.  All data created by the system will be made available to researchers worldwide.\n\n== History ==\nThe device began with an idea from Eric Kaplan, founder of a company that develops Bluetooth wireless technology test equipment.  Kaplan sold his company to his employees and later founded the Hatteras Island Ocean Center (www.hioceancenter.org), a nonprofit, 501(c)(3) ecology education center on Hatteras Island in North Carolina.  Kaplan saw the need for this technology and approached his childhood friend Tom Zimmerman, an IBM Research\u2013Almaden (San Jose, CA) electrical engineer for assistance.  Zimmerman designed the sensor package in 2013 as a public service commitment from IBM.  Tom recruited his college buddy, Samuel Wantman a retired software designer, and they worked on developing the first phase of the design with support from IBM and from the National Park Service.  Britta Muiznieks, a biologist with the NPS has been coordinating the Park's involvement.  The first phase of the project was a very quick and inexpensive hack of cell phones with a simple custom circuit board to test the viability of the project.  The devices were tried in a few nests in 2013, but unfortunately it was too late in the season to get any data from viable nests.  Even so, there was enough learned to make everyone involved in the project believe that there was the potential to make the technology work.\n\nWantman took over management of the project in 2014, as Zimmerman had to return to other commitments at IBM.  Additional volunteers were recruited, including David Hermeyer a retired electrical engineer and Charles Wade a retired IBM Research manager.  Phase Two of the project involves developing a more robust custom sensor embedded in a plastic sphere the same size and shape as a turtle egg, with industry standard technology for transmitting data over cell phone networks.  Installation has begun on multiple sensors that the NPS is funding for field testing in 2014.  The project inspired Samuel Wantman to start Nerdswithoutborders.net to help organize the project, recruit volunteers, and inspire other projects.  All of the Turtle Sense project members, with the exception of the NPS employees, donate their time.  The Hatteras Island Ocean Center is the sponsoring non-profit institution that administers receipt and disbursement of funds for materials and other expenses.\n\n==Phase One (2013 Turtle Season)==\n[[file:PingPongSensor.jpg|right|thumb|300px|A ping-pong ball sensor assembly placed in a sea turtle nest (field tests 2013).  The cable coming from the sensor leads to the communications tower for the cell phone connection.]]\nPhase One was a proof-of-concept field test undertaken during the 2013 turtle season.  A motion-and-temperature sensor (Analog Devices ADLX362, 3-Axil, Digital Output MEMS accelerometer), soldered to a Sparkfun \u201cbreakout board,\u201d was soldered to a CAT5 cable.  The board was sealed in a Ping-Pong ball by filling it with \u201caquarium safe\u201d silicone caulk. The Ping-Pong ball, about the size and shape of the sea turtle eggs, was placed in the sea turtle nest by National Park Service (NPS) rangers. The other end of the cable attached to the \"egg\" assembly was electrically connected to a hacked cell phone that was programmed with a very small, low-powered TI MSP430 microprocessor.  The phone sent out text messages with the motion and temperature data every two hours.  The cell phone was protected from the elements by a communications tower made from 4\" PVC pipe and pipe fittings.   \n\nTurtle eggshells are thick and leathery, so the hatchlings need considerable effort to emerge from the egg.  After leaving the egg, the hatchlings remain in the nest for two-to-four days before exiting (usually) as a group onto the beach.  All the resulting motions should activate the accelerometer sensor and thus provide data to the phone network.  Though the first device had its problems, field tests done at Hatteras in October 2013 were positive. The signal from the sensor close to a single hatchling was eight times larger than the background signal, giving hope for more extensive tests planned for 2014.\n\n==Phase Two Description==\n''See also: [[Turtle Sense/Phase Two]]\n\nPlanning for Phase Two began during the implementation of Phase One.  Samuel Wantman and David Hermeyer began working on the design for a more robust solution in the Fall of 2013.  Units were installed by the NPS starting in June of 2014.  About a dozen nests were monitored and predictions were made as to when the hatchlings would emerge.\n\nSeveral problems were identified during Phase One that we tried to address in Phase Two:\n*The sensors had reliability problems communicating with the cell phones because of the long distance between the sensor and the microprocessor in the communications unit.  This is being addressed in two ways.  The sensor was mounted on a very small (1 inch by 1 inch) circuit board inside the \"egg\" that goes in the nest.  The board also contains a microprocessor and a RS485 transceiver that allows reliable communication over very long cable lengths.\n[[file:PhaseTwoCommBoard.jpg|left|400px|thumb|The 2014 communications assembly contains the circuit board, power supply, a microprocessor, an M2M cell phone board and RS485 transceiver.  Inset is a quarter for size reference.]]\n*The cell phone, having been designed with a human interface, was often unpredictable.  Occasionally messages would pop up prompting a human reply (like a notification that the phone was charging).  This made programming the device difficult because of all of the possible messages and the timing of their appearance are not predictable.  At one point, the devices stopped working because the cellular service provider required all its users to upload new operating software.  An appropriate user response was not possible in field-installed pre-programmed units.  Because of this problem, we adopted industry standard M2M (Machine to Machine) methods of sending data over a cellular network.\n*Text messages and disposable cell phones were not a cost-effective way to send large amounts of data.  Phase Two uses FTP protocols with devices and data plans that have much less expensive data charges.\n*Hacked cell phones would be difficult to mass produce, so the new design uses off-the-shelf, plug-in cell phone boards and custom circuitry that can be mass produced.\n*Phase One used single-use D cell alkaline batteries.  Phase Two uses rechargeable NiMH AA batteries and achieves longer battery life, as the package is carefully designed for low energy needs.  \n*Most of the turtle-specific calculations are now done in the microprocessor embedded with the sensor in the \"egg.\"  The communication system is designed so that it can be modified for other sensors. \n*The silicone filling the ping-pong balls that housed the sensors in Phase One never cured.  For Phase Two, we made a casting of a ping-pong ball (which is the same size and shape as a turtle egg), and used it to cast solid polyurethane \"eggs\" around the sensor circuit boards.  The polyurethane is fully set in less than a day, does not out-gas, and is very hard and durable.\n\n== Phase Two results==\n[[File:2015 - NH003 (7-28 final) sensor AA0006.png|250px|thumb|In 2015 we started to automate the graphing of data, and used the graphs to successfully predict emergence of hatchlings]]\n===2014 season===\n:''For more detail, see:\n* [http://media.turtlesense.org/2014_Turtle_Sense_final_report.pdf  National Park Service -- Turtle Sense 2014 final report]\n* [[Turtle Sense / Project logs]]\n\n===2015 season===\nWe successfully monitored nests at the Cape Hatteras National Seashore.\n\nFor graphs of the nests that were monitored see:  [[Turtle Sense / 2015 Season Results]]\n\n==Phase Three Description==\n''See also: [[Turtle Sense/Phase Three]]\n===Phase Three Goals===\nWork on phase three began after the end of the 2014 season.  The goals of Phase Three are:\n*To refine our hardware so that it is easier and cheaper to manufacture, more reliable, and easier to maintain.\n*Extend the firmware so that it has better error handling, can be updated in the field, and offers more features and usable data.\n*Create a working, somewhat complete website which does the following: automates the process of predicting hatching, reports predation events and over-washes; generates alerts for users; centralizes necessary data entry; and, allows open access of data for researchers and wildlife managers.\n*Test the equipment and features in several different environments.\n*Attend conferences to publicize our work and find additional organizations to team up with, and find additional volunteers to assist the project.\n*Create a plan to get the technology included in protocols that are acceptable to the US Fish and Wildlife service.\n\nMost of the technical work to make this happen will be done during 2015. The phase two equipment will be used until the phase three equipment is ready.\n\n==Phase Three Progress==\nWork is underway modifying the Turtle Sense hardware and software.\n===Hardware===\n* A moisture detector is being added to the smart sensor \"egg\".\n* The power supply of the unit is changing from 8 AA rechargeable batteries that just last for a season to a solar cell that will charge 3 AAA batteries.  Preliminary tests indicate that this will be cheaper to produce, and last for many years -- as long as the life of the batteries -- before needing servicing.  Initial testing is very positive.  There is enough light on a very overcast day to keep the units running, and even without any light the units will continue running for several weeks.\n* Connections between the comm unit and the sensors will be made with coax cable.  This will allow the connections to be modified and repaired in the field, greatly reduce the expense and time involved in creating the devices, and allow multiple sensors to be connected to the same comm unit.  Power and two way communication will all use the same wire.\n* Expansion ports will be added for USB/SD support, Bluetooth and other wireless capabilities, and auxiliary connections for controlling and interfacing with other field equipment.\n* Since the batteries will not need annual servicing, the comm units will only have one sealed chamber instead of two.  This will simplify the construction and installation of the devices\n* Upgraded microprocessors will expand available memory from 16K to 64K while lowering power usage.\n\n===Software===\n* Expanded memory provides space for better error handling, increased data storage, and user code.\n* A protocol will be developed for interfacing with multiple sensors\n* Tools and libraries will be help others customize the hardware and software for other applications\n\n==Data==\n:''See also: [[Turtle Sense raw data]]''\n[[File:Screenshot 2014-07-03 01.jpg|thumb|right|400px|Data from the first report of the 2014 season]]\nThe Turtle Sense units constantly monitor and analyze motion to create a profile of its magnitude over time.  The motion detector measures the change in acceleration (or \"jolt\") multiple times per second.  The magnitude is squared and summed.  After six minutes, the results are stored in a record along with a temperature and orientation reading, and the process starts over.  The sum that results is roughly the total energy recorded in the nest during the period.  This process allows us to compress several thousand readings into approximately 32 bytes of information.  We lose but we suspect that those details are not important.  The 240 records created each day give us a very good idea of what is happening in the nest.  Once 40 days have passed, we restart the process of summing every minute to get more detailed data.\n\nThere has been some research that indicates that before emerging from the nest in a \"boil,\" turtles that have hatched congregate underground near the top of the nest.  It is thought that this motion stimulates the hatching of the turtles that haven't yet emerged.  Our sensors, situated at the top of the nest, were able to record some noticeable disturbances several days before the turtles boil.  We were able to see these disturbances in the data in almost all of the nests that we monitored in the 2014 season and were able to predict the date of the boil within a window of a few days.\n\nPredictions from the data in 2014 were made by human observation of graphed data.  We will be generating algorithms to predict hatching from our data and refining them to come up with a reliable automated process for predicting hatching a few days in advance.\n\n==Funding and Impact==\n[[File:NH007-Post Hurr Arthur-exclosure (2) cropped small.jpg|thumb|left|300px|A few days after the first units of Phase Two were installed, Hurricane Arthur hit. The units reported regularly before and after the storm without any problems. This picture was taken the day after the storm. Notice how all the text was sandblasted off the sign in the forefront. Cape Hatteras Lighthouse is just behind the dune.]]\nThe National Park Service has been funding the project since it began.  Labor is being provided by NerdsWithoutBorder.net     volunteers.  Additional support has come from:\n* [http://ibm.com IBM -- grants]\n* [http://www.janus-rc.com/ Janus Remote Communications -- a generous discount on their M2M plug-in boards]\n* [http://www.screamingcircuits.com/ Screaming Circuits -- a donation of the labor toward the production of circuit prototypes]\n* [http://www.telit.com Telit -- publicity]\n* [http://www.fte.com Frontline Test Equipment, Inc. -- a donation of communications testing equipment]\n* [http://www.corun.com/ent  Hunan Corun New Energy Co.,LTD -- a donation of rechargeable NiMH batteries]\n\nWe are seeking funding and volunteers to expand the program. \n\nSuccess in this project would provide widespread, international advantages.  As noted above, the stress could be lessened between the protection agencies and the fishing industry, recreational users, and tourism advocates, all of whom desire more beach access. More effective international protection will be available, since the protection resources can be concentrated close to the hatch date instead of being stretched over six weeks. With a tighter hatching schedule, the public would have the opportunity to observe the hatchlings heading for the sea, an observation available only randomly now.  This would improve the public support of the turtles. NPS will use the hatch dates in on-site announcements and information centers, and the Hatteras Island Ocean Center will disseminate the information in their programs.  Much of the research on sea turtle eggs and hatchlings in the world could benefit from more accurate predictions of the hatch date.  For example, studies that require capturing hatchlings for research could be done with much greater efficiency. Also, the sensor/cell network could be adapted for measurements of other species, including birds.  Given its modest cost and energy efficiency (long battery life), it may have other uses in environmental studies. All the design information will be available to the public on the wiki http://nerdswithoutborders.net. If the project is successful equipment will be made available at cost or perhaps below cost if sponsors come forward.\n\n[[Image:Britta2013.jpg|right|300px|thumb|Britta Muiznieks, a wildlife biologist at the NPS Cape Hatteras Seashore in NC with a protected turtle nest. The 4\" PVC pipe assembly tower was used in the 2013 testing. A smaller 3\" structure holds the 2014 package because the electronics are smaller and AA rechargeable batteries have replaced D cells. Vandal-proofing is one aspect of the design. Britta does the field research for the NPS.]]\n\n==Press==\n===Radio===\n*NPR's Here & Now:\n**[http://hereandnow.wbur.org/2014/08/25/turtles-outer-banks Part One (Aug 2014)]\n**[http://hereandnow.wbur.org/2014/11/04/sea-turtles-sensors Part Two (Nov 2014)]\n\n===Print===\n* [http://hamptonroads.com/2014/08/plan-hatched-could-help-keep-beaches-open Article at PilotOnline.com (Virginia-Pilot) (August 2014)]\n* [http://islandfreepress.org/2014Archives/08.21.2014-ItMakesTurtleSenseGivingCellPhonesToTurtles.html Article in Island Free Press(Aug 2014)]\n* [http://outerbanksvoice.com/2013/08/29/high-tech-could-help-predict-sea-turtle-hatches/ Article in Outer Banks Voice (August 2013)]\n* [http://outerbanksvoice.com/2014/08/10/small-ocean-center-incorporates-an-expansive-natural-theater/ Another mention at the Outer Banks Voice]\n===Web===\n* [http://www.engadget.com/2014/11/13/north-carolina-sea-turtles/?ncid=rss_truncated Engadget.com]\n* [http://spectrum.ieee.org/tech-talk/geek-life/hands-on/technologists-hatch-turtle-sense-system-with-ecology-and-economy-in-mind Tech-talk at IEEE Spectrum]\n* [http://www.psychologytoday.com/blog/the-green-mind/201409/sensing-turtles Article at PsychologyToday.com]\n* [http://hackaday.com/page/8/ Blog at hackaday.com]\n* [http://www.nextgov.com/emerging-tech/2014/08/remote-sensors-mean-more-sea-turtles-fewer-beach-closures-hatteras/90545/ Article at nextgov.com (August 2014)]\n* [http://online.wsj.com/article/PR-CO-20140515-910765.html Telit press release in the Wall Street Journal (May 2014)]\n* [http://www.iotworld.com/author.asp?section_id=3153&doc_id=563269 Blog at iotworld.com]\n\n==Links==\n*[http://www.hioceancenter.org/ Hatteras Island Ocean Center website]\n*[http://hackaday.io/project/2264-Turtle-Sense Entry for the Hackaday Prize at hackaday.io]\n*[https://www.youtube.com/watch?v=b_bWmOsYJz4 Video about the project at YouTube]\n*[[Turtle Sense/People]] -- People involved in this project. \n\n==Contact us==\nIf you would like to help with this project, make suggestions, or offer a critique, please email: admin@nerdswithoutborders.net.\n\nThank You!"
                    }
                ]
            },
            "34": {
                "pageid": 34,
                "ns": 0,
                "title": "Turtle Sense/Database design",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "*''field_name (data example) notes''\n==Table definitions==\n===Table: EVENTS===\nThis is the key table for all the events in the database. One record is created for each report.  One record is created for each registration log, even though they are currently added to two files (sensor logs, and event logs)\n*Event_ID: a sequential unique number to index the events\n*Event_type: (R=report, S=sensor registration, C=communications start,  P=prediction, B=boil, D=disconnect)\n*Event_date_time:\n*Org_ID: key field of the ORGANIZATIONS table\n*Parameter_change (Yes or No)\n*Parameters_ID: The parameters set in the event -- set on-line in the future\n*Nest_ID: sequentially numbered key index of NESTS\n*Report_ID: sequentially numbered key index of REPORTS\n*Sensor ID: sequentially numbered key index of SENSORS\n*Comm_ID: the comm unit that created the report\n*Reset (Yes or No)\n*Shutdown (Yes or No)\n*Battery_level: As reported, coverted from hex\n*Percent_capacity:(0-100) Looked up from BATTERY_LEVELS\n\n===Table: REPORTS===\nThis table contains the header information of each report.\n*Report_ID: sequentially numbered key index\n*Event_ ID: a sequential numbered key index of EVENTS\n*File_name (eg. 2014-06-20_AA0014_r-005-03) can be used to determine nest record.  Starts with registration date, and then the sensor\n*Days_active: calendar days since the sensor was recorded.  001 is the day of recording, 002 is the next day, etc...\n*Report_number: the number of the report issued for this nest, on this day\n*Start_date_time: time of last report, roughly the start time of data collection\n*Secs_per_record: Converted from Hex, number of seconds as reported that data was collected for each record\n*Number_of_records: Converted from Hex, number of records as reported\n*Average_magnitude: The average of the Magnitude field of all the RECORDS in this report\n*Highest_maximum: The highest maximum bin reported in any of the RECORDS in this report\n*Lowest_maximum: The lowest maximum bin reported in any of the RECORDS in this report\n*Highest_energy: The highest energy calculated in any of the RECORDS in this report\n*Lowest_energy: The lowest energy calculated in any of the RECORDS in this report\n*Average_temperature: The average of the converted Temperature field of all the RECORDS in this report\n*Highest_temperature: The highest temperature reported in any of the RECORDS in this report\n*Lowest_temperature: The lowest temperature reported in any of the RECORDS in this report\n*Parameters_ID: The parameters used to generate the data -- will be set on-line in the future\n\n===Table: NESTS===\nEach unique nest is identified by the date a sensor was installed, and the serial number of the sensor.  The registration device stores this information in the sensor, and every report sent from that sensor will start with the unique identifier\n*Nest_ID: a unique sequential number to index to the nest (This is the database ID and not the organization's ID)\n*Long_nest_ID: (eg. 2014-06-20_AA0014) Also the beginning of the file name of reports.  This uniquely identifies a nest \n*Org_ID: The ID of the organization managing the nest.\n*Org_nest_ID: The nest ID used by the managing organization.\n*Reg_date_time: The date is also the first term in the file name  (see the Long_nest_ID field above)\n*Days_when_reg: (0) The number of days after the eggs were laid before registration (normally zero -- manually adjusted for reporting and prediction if later)\n*Sensor_ID: the second term in the file name (see the Long_nest_ID field above)\n*Reg_comm_ID:  The comm unit used to register the nest\n*Event_ID: The event that registered this nest\n*Nest_longitude (eg.12226.3671W) dddmm.mmmm  GPS data from sensor registration\n*Nest_latitude\t(eg. 3746.3183N) ddmm.mmmm\n*Active: Yes or No -- whether the nest is still being monitored\n*Current_Parameters_ID: The id of the parameters currently in use\n*Turtle_Activity_level: the current level of turtle activity in the nest (this will be calculated)\n*Crab_Activity_level: the current level of crab activity in the nest (this will be calculated)\n*Boil_date_predicted: predicted date and time of hatching\n*Boil_date_actual: observed date and time of hatching\n*Prediction_method: Method used to predict hatching\n\n=== Table: RECORDS===\nEach report has multiple records. \n*Record_ID:sequentially numbered index -- all records in the table\n*Report_ID: the index to the report that had this record\n*Event_ID: The event that created this record (this field is redundant Report_ID-->Reports:Event_ID)\n*Nest_ID :the index to the nest that generated this data (This field is redundant  Report_ID-->REPORTS:Nest_ID)\n*Parameters_ID: The parameters used to generate the data (This field  is redundant  Report_ID-->REPORTS:Parameters_ID)\n*Record_number:the number of the record in this report\n*Date_time: the time calculated from the time reported in Report_ID-->REPORTS:Start_date_time plus Record_number multiplied by Report_ID-->Secs_per_record\n*Temperature_hex: Celsius, hex reading 0100 per 10 degrees C\n*Temperature: Hex reading converted (converted to decimal and then divided by 25.6)\nThese x,y and z hex readings are the static readings of the motion sensor. They are the vector of force acting on the meter, so should average 1G\n*X: static x reading converted from hex\n*Y: static y reading converted from hex\n*Z: static z reading converted from hex\n*Magnitude:  This is the x, y and z readings converted to a magnitude (x^2 + y^2 +z^2)^1/2\n*Readings:The total number of sensor readings taken in this record\n*Maximum: The highest bin reading in the record\nBin_A through Bin_J are the top 10 hex bin readings for the record.  Bin J is the number of Maximum bin readings taken, and then everything below it counts down to zero. If the maximum is 0A or less, then bin_A to bin_J corresponds to bin_01 to bin_10\n*Bin_A \n*Bin_B  \n*Bin_C \n*Bin_D\n*Bin_E\n*Bin_F\n*Bin_G\n*Bin_H\n*Bin_I\n*Bin_J\n*Bin_01 The hex bin readings above can be converted to decimal, and put in the appropriate bins here.\n*Bin_02\n*Bin_03\n*Bin_04\n*Bin_05\n*Bin_06\n*Bin_07\n*Bin_08\n*Bin_09\n*Bin_10\n*Bin_11\n*Bin_12\n*Bin_13\n*Bin_14\n*Bin_15\n*Bin_16\n*Bin_17\n*Bin_18\n*Bin_19\n*Bin_20\n*Bin_21\n*Bin_22\n*Bin_23\n*Bin_24\n*Bin_25\n*Missing: This is the number of bins that are below the lowest bin reported, when Maximum is greater than 0A\n*Energy: The average energy level. This is calculated by integrating all the readings and then dividing by the number of readings\n*Max_jerk:  The Maximum bin level converted to a G force\n\n===Table: PARAMETERS===\n*Parameter_ID: sequentially numbered key index\n*THRESH_ACT (2 byte integer) ADXL sensor threshold (not used)\n*THRESH_INACT (2 byte integer) ADXL sensor threshold (not used)\n*TIME_INACT (2 byte integer) ADXL sensor threshold (not used)\n*MAXRUN (4 byte long) The maximum number of seconds allowed for any record\n*SLOWBIN (2 byte integer) The number of seconds for each record on days before the nests are active\n*BINSEC (2 byte integer) The number of seconds for each record on days when the nests are active\n\t\t\nthe following are all one byte fields\n*THRESH_ACT_L\n*THRESH_ACT_H\n*TIME_ACT\n*THRESH_INACT_L\n*THRESH_INACT_H\n*TIME_INACT_L\n*TIME_INACT_H\t\n*ACT_INACT_CTL\n*FIFO_CONTRO\n*FIFO_SAMPLES\t\n*INTMAP1\n*INTMAP2\n*FILTER_CTL\n*POWER_CTL\t\t\n*SLEEP_INTERVALS\t\t\n*READ_SPEED\n*SLOWBIN_LO\n*SLOWBIN_HI\t\n*MAXRUN1\n*MAXRUN2\n*MAXRUN3\n*MAXRUN4H\n*MAX_RECORDS_LO\n*MAX_RECORDS_HI\n*CALIBRATE_TEMP\t\n*REPORT_HEADINGS\n*BINSEC_LO\n*BINSEC_HI\t\t\n*SLOW_DAYS\n*SLOWBIN_LO\n*SLOWBIN_HI\t\n*SPARE_1\n*SPARE_2\n*SPARE_3\n*SPARE_4\n*SPARE_5\n*SPARE_6\n*SPARE_7\n*SPARE_8\n*SPARE_9\n\n===Table: BATTERY_LEVELS===\n*Level: the ADC reading of the battery voltage converted from Hex\n*NiMH_12v_capacity: the level converted to per cent of battery capacity remaining for 8 AA NiMH Eneloop batteries\n*NiMH_9v_capacity: the level converted to per cent of battery capacity remaining for a9 V NiMH Tenergy battery\n\n===Table: SENSORS===\n*Sensor_ID\n*Org_ID: The owner of the sensor\n*Software_version\n*Date_manufactured\n*Hardware_version\n*Software_version\n*In_use (Yes or No)\n*Date_in_use\n*Last_date_in use\n*Nest_ID\n*Calibration_on (Yes or No)\n*Temperature_offset (two byte signed)\n*Temperature_ratio (two byte signed)\n\n===Table: COMMUNICATORS===\n*Comm_ ID\n*Org_ID: The owner of the communicator\n*Software_version\n*Date_manufactured\n*Hardware_version\n*Software_version\n*Type (C= communication tower, H=Hand-held)\n*Battery (which field to use in BATTERY_LEVELS to translate the battery reading)\n*In_use (Yes or No)\n*Date_in_use\n*Last_date_in use\n*Nest_ID\n\n===Table: ORGANIZATIONS===\n*Org_ID: Unique key field for each organization\n*sub_domain: (nps)\n*sub_directory: (caha) multiple sub-organizations could share a subdomain.  In this case Cape Hateras National seashore might share a subdomaine with the rest of the  National Park Service \n*Name: Full name of the organization\n*Date_active: Date organization began collecting data\n*Active: (Yes or No)\n*Date_inactive: Date stopped collecting data\n*Contact_name:\n*Contact_title:\n*Contact_phone:\n*Contact_email:\n*Admin_password:\n\n===Table: USERS===\n*User_ID:\n*Org_ID:\n*Name:\n*Date_active:\n*Active: (Yes or No)\n*Date_inactive: \n*Title:\n*Phone:\n*Email:\n*Sms:\n*Password:\n*Temp_password:\n*Email_verification (Yes or No)\n*Reg_alerts: (N-not requested, R-requested, A-approved, S-denied)\n*Reg_alert_format: (E - Email, S - SMS, B - Both)\n*Edit_rights (U = User Alerts, D = Database edits, A= Admin -- for approving reg_alerts and database editing rights, B= Bureaucrat -- all rights)\n\n===Table: NEST_ALERTS===\n''Note: This depends upon USER rights (U= All users, D = Database access (researcher), A = Administrator of organization, B = Bureaucrat or System-wide access)''\n*Org_ID\n*All_nests: (Yes or No) whether all nests for this organization will generate an alert ''(U,D,A,B)''\n*Nest_ID: If All_nests is no, the specific nest that is being monitored\n*User_ID:  The person monitoring the nest\n*All_updates: (Yes or No)  whether alerts are sent regularly updating the status of the nest for all events ''(D,A,B)''\n*Hatching: (Yes or No)  whether alerts are sent only when hatching is imminent ''(U,D,A,B)''\n*Problems: (Yes or No)  whether alerts are sent when nests are disturbed, sensors are disconnected, power is reset or low batteries cause a shutdown. ''(A,B''\n*Parameters: (Yes or No)  whether alerts are sent when parameters are changed ''(A,B)''\n*High_motion: (Yes or No)  whether alerts are sent when motion above a threshold is detected ''(D,A,B)''\n*Low_motion: (Yes or No)  whether alerts are sent when motion below a threshold is detected ''(D,A,B)''\n*High_temp: (Yes or No)  whether alerts are sent when temperature above a threshold is detected ''(D,A,B)''\n*Low_temp: (Yes or No)  whether alerts are sent when temperature below a threshold is detected ''(D,A,B)''\n*Motion_high_thresh:  The high motion threshold for triggering an alert ''(D,A,B)''\n*Motion_high_thresh:  The low motion threshold for triggering an alert ''(D,A,B)''\n*Temp_high_thresh:  The high temperature threshold for triggering an alert ''(D,A,B)''\n*Temp_low_thresh:  The high temperature threshold for triggering an alert ''(D,A,B)''\n*Hatching_alert_format: (E - Email, S - SMS, B - Both) ''(U, D,A,B)''\n*Problem_alert_format: (E - Email, S - SMS, B - Both) ''(A,B)''\n*Param_alert_format: (E - Email, S - SMS, B - Both) ''(A,B)''\n*Thresh_alert_format: (E - Email, S - SMS, B - Both) for all alerts based on thresholds ''(D,A,B)''\n\n==Data parsing==\nReports and logs are generated and stored at nps.turtlesense.org.   The parsing routine can generate many fields directly from a log or report. Some need to be calculated.  Once the reports and logs are processed they can be archived.\n\nHere is an example of a registration event:\n REGISTRATION EVENT Date/Time: 2014/06/23, 16:11:29\n Sensor ID#: AA0007 \n Registration Communicator ID#: H-AA0005\n Nest GPS Location: 3746.3048N, 12226.3747W\n Battery level: 0230\n\nParsing this data will create new a new record in NESTS:\n*Nest_ID (the next sequential number to index to the nest) \n*Long_nest_ID (2014-06-23_AA0007)  This uniquely identifies a nest \n*Reg_date_time (2014/06/23, 16:11:29)\n*Sensor_ID (AA0007) the second term in the file name (see the field above)\n*Reg_comm_ID (H-AA0005) The comm unit used to register the nest\n*Nest_longitude (12226.3747W) dddmm.mmmm  GPS data from sensor registration\n*Nest_latitude\t(3746.3048N) ddmm.mmmm\n*Active (Y)\n\nA new record is also created in EVENTS:\n*Event_ID: (the next sequential unique number to index the event)\n*Event_type:S\n*Parameter_change:N\n*Nest_ID: (The ID of the record in NESTS created above)\n*Event_date_time: 2014/06/23, 16:11:29\n*Sensor ID: AA0007\n*Comm_ID: H-AA0005\n*Battery_level: 0560 (Converted from Hexadecimal)\n*Percent_capacity:99  (Looked up from 560-->BATTERY_LEVELS:Percent_capacity)\n\nRecords are also created in SENSORS and COMMUNICATORS if the IDs are not found.\n\nHere is an example of a report:\n\n Report: 2014-06-20_AA0013_r-006-03.txt\n Sensor ID#: AA0013\n Installed: 2014-06-20\n Comm ID#: C-AA0002\n Days active & report #: 006-03\n Nest location: 3746.3898N,12226.3516W\n Start date/time: 2014/06/25,01:05:12\n Report date/time: 2014/06/25,07:05:15\n Secs per rec: 0168\n # of recs: 003C\n Battery level: 023A\n \n Rec#,Temp,   X,   Y,   Z, Cnt, Max,Bins: (Low) to (High)\n 0000,0231,0398,FDF4,FF03,8F93,000C,0743,0ECF,294B,2D07,134F,032A,008A,001F,0012,0003\n 0001,0233,0399,FDF3,FF03,8F93,0011,029D,00D0,0064,0035,0020,001A,0008,0001,0000,0001\n 0002,0231,0399,FDF3,FF07,8F8D,000C,0DC4,102C,2BCA,2D10,08AF,00C1,0033,001C,0005,0001\n 0003,0234,0393,FDEF,FF01,8F8D,0012,0036,0010,000B,0010,000D,000D,0002,0003,0004,0001\n etc...\n\nA new record is created in EVENTS:\n*Event_ID: (the next sequential unique number to index the event)\n*Event_type:R\n*Parameter_change: (This depends upon whether there is a message at the end of the report)\n*Parameters_ID  (The parameters set in the event  -- parameter updating will happen on-line in the future)\n*Nest_ID: 2014-06-20_AA0013-->NESTS:Nest_ID\n*Report_ID (the report ID created -- see below)\n*Event_date_time: 2014/06/25,07:05:15\n*Sensor ID:  AA0013\n*Comm_ID: C-AA0002\n*Reset (This depends upon whether there is a message at the end of the report)\n*Shutdown (This depends upon whether there is a message at the end of the report)\n*Battery_level (0549) As reported\n*Percent_capacity: 99\n\nA new record is also created in REPORTS:\n\n*File_name: 2014-06-20_AA0013_r-006-03\n*Days_active: 006 \n*Report_number: 03\n*Event_ ID (the ID set in EVENTS above) \n*Start_date_time: 2014/06/25,01:05:12\n*Secs_per_record: 0060 (converted from Hexadecimal)\n*Number_of_records: 0240 (converted from Hexadecimal)\n*Parameters_ID (The parameters set in the event  -- parameter updating will happen on-line in the future)\n\n Rec#,Temp,   X,   Y,   Z, Cnt, Max,Bins: (Low) to (High)\n 0000,0231,0398,FDF4,FF03,8F93,000C,0743,0ECF,294B,2D07,134F,032A,008A,001F,0012,0003\n 0001,0233,0399,FDF3,FF03,8F93,0011,029D,00D0,0064,0035,0020,001A,0008,0001,0000,0001\n 0002,0231,0399,FDF3,FF07,8F8D,000C,0DC4,102C,2BCA,2D10,08AF,00C1,0033,001C,0005,0001\n 0003,0234,0393,FDEF,FF01,8F8D,0012,0036,0010,000B,0010,000D,000D,0002,0003,0004,0001\n etc...\n\nEach line creates a new record in the RECORDS table.  Here's how a line is parsed (using the third line as an example):\n 0002,0231,0399,FDF3,FF07,8F8D,000C,0DC4,102C,2BCA,2D10,08AF,00C1,0033,001C,0005,0001\n\n*Record_ID (the next sequentially numbered index)\n*Report_ID (the index to the report that had this record set above)\n*Nest_ID (the index to the nest that generated this data (This field is redundant  Report_ID-->REPORTS:Nest_ID)\n*Parameters_ID (The parameters used to generate the data. Parameter updating will happen on-line in the future)\n*Record_number: (00002) Rec# converted from Hexadecimal\n*Date_time: (2014/06/25,01:17:12) the starting time of the record calculated from the time reported in Report_ID-->REPORTS:Start_date_time plus Record_number multiplied by Report_ID-->Secs_per_record)\n*Temperature_hex: (0231)\n*Temperature: (22.0) Hex reading converted to decimal and then divided by 25.6, rounded to .1 degrees\n*X: (921) 0399 Hex converted to decimal\n*Y: (-525) FDF3 Hex (signed) converted to decimal\n*Z: (-249) FF07 Hex (signed) converted to decimal\n*Magnitude: (1089)   This is the x, y and z hex readings converted to decimal and then combined to calculate the magnitude (x^2 + y^2 +z^2)^1/2\n*Readings: (36749) The total number of readings taken in this record converted\n*Maximum (12) The highest bid reading in the record\n*Bin_A (0DC4) These are the top 10 hex bin readings for the record.  Bin J is the number \n*Bin_B (102C) of Maximum bin readings taken, and then everything below it counts down to zero.\n*Bin_C (2BCA) If the maximum is 0A or less, then bin_A to bin_J corresponds to bin_01 to bin_10\n*Bin_D (2D10)\n*Bin_E (08AF)\n*Bin_F (00C1)\n*Bin_G (0033)\n*Bin_H (001C)\n*Bin_I (0005)\n*Bin_J (0001)\n*Bin_01 (1919) missing readings are divided equally among the low bins that were not reported\n*Bin_02 (1919) \n*Bin_03 (3524) The hex bin readings from above can be converted to decimal, and put in the appropriate bins -- in this case bin3 to bin12.\n*Bin_04 (4140)\n*Bin_05 (11210)\n*Bin_06 (11536)\n*Bin_07 (2223)\n*Bin_08 (193)\n*Bin_09 (51)\n*Bin_10 (28)\n*Bin_11 (5)\n*Bin_12 (1)\n*Bin_13 (0) The rest of the bins are zero\n*Bin_14 (0)\n*Bin_15 (0)\n*Bin_16 (0)\n*Bin_17 (0)\n*Bin_18 (0)\n*Bin_19 (0)\n*Bin_20 (0)\n*Bin_21 (0)\n*Bin_22 (0)\n*Bin_23 (0)\n*Bin_24 (0)\n*Bin_25 (0)\n*Missing (3838) This would be the number of bins that are below the lowest bin reported, when Maximum is greater than 0A\n*Energy   This can be computed by integrating all the readings. Each bin value is multiplied by the bin energy level and then added to the energy value.  The bin energy values are adjusted by the average magnitude for an entire report which should correspond to one G.\n*Max_jerk  This can be computed by adjusting the Maximum bin level using the average Magnitude for the report to compute the jerk levels for each bin."
                    }
                ]
            }
        }
    }
}