| field |
comment |
| whole table |
This is the management table for acoustic tags, receivers and related equipment. Typically joins will be made to one of the idcode fields. Joining to the acoustic_data table requires both idcode and codespace1. Important fields used as query filters are tagfamily, interval_min and max, taglocation, invoicedate and owner. All date fields should be converted from type text to date or timestamp. |
| batt_replace_date |
VMT specific though it could work for any receiver. When was the battery replaced? |
| batt_update_date |
When did the new battery life update take place? |
| bin |
Not sure about this field. I think it is related to the code map. |
| chaffing |
Not used much. Would normally be in a programming table. Could be deprecated. |
| codespace1 |
A combination of frequency and space, e.g., A69-1303 or A69-9002. |
| codespace2 |
Codespace for idcode2. |
| codespace3 |
Codespace for idcode3. |
| code_type |
Not sure about this field. Possible duplicate of freqtype. |
| comments |
Any comments about the tag including past locations. |
| dart |
Not used much. Would normally be in a programming table. Could be deprecated. |
| dead_by_date |
Based on invoice date and est_taglife when will the battery likely die? |
| deployed |
Has the tag been deployed? Not used very often. Basically duplicated by deploykey. |
| deploykey |
This should be called eventid. The eventid assigned to the tag if it was deployed. |
| est_batt_update |
Vemco gave us updated battery life estimates for a particular group of tags. We could probably request this service again if necessary. What is the adjusted battery life estimate in days? |
| est_taglife |
The estimated number of days the tag battery will last once the tag is activated. |
| firmware_date |
When was the receiver firmware last updated? |
| freqsync1 |
Not sure about this field. I think it is related to the code map. |
| freqsync2 |
Not sure about this field. I think it is related to the code map. |
| freqsync3 |
Not sure about this field. I think it is related to the code map. |
| freqtype1 |
The submap type for idcode, e.g., S256 or R64K. |
| freqtype2 |
The submap type for idcode2, e.g., S256 or R64K. |
| freqtype3 |
The submap type for idcode3, e.g., S256 or R64K. |
| frequency |
The transmitting frequency of the tag. Either 69 or 81 kHz. |
| idcode |
The primary acoustic transmitting code for a tag. It combines with codespace1 to form a complete identification code for a tag. On older tags this was for identification only. If the tag included environmental sensors then they would be associated with secondary idcodes. On newer tags identification and sensors can be combined. |
| idcode2 |
A secondary transmitting code. Will always be associated with sensor data. It combines with codespace2 to form a complete identification code for a tag. |
| idcode3 |
A secondary transmitting code. Will always be associated with sensor data. It combines with codespace3 to form a complete identification code for a tag. |
| intercept |
The intercept value for converting raw sensor data. |
| intercept2 |
The intercept value for converting raw sensor data. |
| intercept3 |
The intercept value for converting raw sensor data. |
| interval_max |
The maximum timing in seconds at which the tag will transmit. |
| interval_min |
The minimum timing in seconds at which the tag will transmit. |
| invoicedate |
What is the date on the shipping invoice? |
| last_detect_date |
Not used or updated regularly. On what date was the tag last detected? |
| leader |
Not used much. Would normally be in a programming table. Could be deprecated. |
| map_name |
Not used much. What code map is the receiver using? |
| ordernumber |
The order number. |
| owner |
Who owns the tag/receiver? |
| pulse_width |
Not sure about this field. Rarely if ever used. |
| range |
What range of values can the sensor detect. The units depends on the sensor type. |
| range2 |
What range of values can the sensor detect. The units depends on the sensor type. |
| range3 |
What range of values can the sensor detect. The units depends on the sensor type. |
| sensor |
What is the first sensor installed on the tag, e.g., pressure, temperature or accelerometer. |
| sensor2 |
What is the second sensor installed on the tag?. |
| sensor2_transratio |
The transmit ratio for sensor 2. |
| sensor3 |
What is the third sensor installed on the tag?. |
| sensor_transratio |
The transmit ratio for sensor 1. |
| serialnum |
The manufacturer serial number. |
| slope |
The slope value for converting raw sensor data. |
| slope2 |
The slope value for converting raw sensor data. |
| slope3 |
The slope value for converting raw sensor data. |
| submap_id |
Not used much. Not sure about it. |
| tagfamily |
A basic code describing the tag or receiver. |
| taglocation |
What is the current location of the tag/receiver? |
| tkey |
Unique ID serial primary key field. |
| trade_date |
If the tag was traded between owners on what date did the trade take place? |
| trade_owner |
If the tag was traded between owners who is the new owner? |
| trade_tag |
If the tag was traded between owners what tag was it traded for? |
| units |
The units for sensor 1. |
| units2 |
The units for sensor 2. |
| vr4_dataplan |
VR4-Global specific. Basic description of the Iridium data plan - date and approximate length. |
| vr4_dp_activedate |
VR4-Global specific. On what date was Iridium activated for the receiver? |
| vr4_dp_suspenddate |
VR4-Global specific. On what date was Iridium suspended for the receiver? |
| vr4_feed |
Not used consistently. Is the tag included on a VR4-Global notification list? |
| vr4_iridium |
VR4-Global specific. Is Iridium active or suspended for the receiver. If active the receiver will be included in acoustic_vr4plan auto query to update balance_current. |