Difference between revisions of "Configuration"
(→Configuration delivery and application) |
(→Mortality detection) |
||
(60 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | {{DISPLAYTITLE:CONFIGURATION}} | + | {{DISPLAYTITLE: CONFIGURATION}} |
− | == | + | ==Overview & Basic Concepts== |
+ | <br> | ||
+ | : Users with admin rights (device owners/admins) can access the configuration from the lists and profiles using cogwheel icons. | ||
+ | : Note the configuration functionality is available for Anitra devices only. | ||
+ | :[[File:config_lists_profiles.JPG|900px]] | ||
− | |||
− | |||
− | |||
− | * | + | : User configuration screen is structured into three main areas |
+ | :* Data collection settings | ||
+ | :* Communication schedules | ||
+ | :* Other settings | ||
+ | :[[File:config_sections.JPG|900px]] | ||
− | + | : Note many more advanced settings are possibly available to adjust device behavior upon request/need (device maintenance, troubleshooting, firmware upgrades, custom configuration/behavior - such as GPS accuracy, etc) | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | : Any changes made are visualized by blue and red symbols close to the modified setting and in the top right corner of each modified section | |
− | + | :* symbols ("pen", "clock" and "check") show the status of each configuration (edited (=blue "pen") >> pending (=red "clock") >> confirmed (=green "check")) | |
− | + | : [[File:config_submitted_modified.JPG|400px]] | |
− | |||
− | |||
− | == | + | : New modifications (not yet submitted) are highlighted by blue color |
− | * | + | :* these modifications can be reverted to saved values simply by closing the config screen or by clicking on the blue "pen" (for a particular parameter or on the section level) |
− | + | :* in order to submit the modified parameters, click the "Send" button below | |
− | + | : [[File:config_send_discard(send).JPG|400px]] | |
− | ** | + | |
− | * | + | |
− | *** | + | : Submitted values are highlighted by red color |
− | *** | + | :* >> all the blue "pen" icons change to red "clock" icons indicating the value is waiting for the device to apply it |
− | *** | + | :* note the configuration changes apply whenever the tag connects to communicate/send data |
− | ** | + | |
− | *** | + | |
− | ** | + | : Until the values are confirmed by the device the pending changes can be modified or canceled |
− | *** | + | :* by clicking on the particular "clock" icon - for a particular parameter or on the section level |
− | *** " | + | :* by clicking on the "Discard all pending changes" button below - for canceling all |
− | **** | + | : [[File:config_send_discard(discard).JPG|400px]] |
− | *** | + | |
− | **** | + | |
− | + | : Once the pending parameters are received, accepted, and confirmed successfully by the device the status is changed from red "clock" to green "check" | |
− | * | + | :* note by default the configuration is sent and delivered to the device via GPRS data |
− | * for | + | :* as a supplementary delivery channel SMS can be used ("Send by SMS" button) |
+ | : [[File:config_send_discard(resendSMS).JPG|400px]] | ||
+ | |||
+ | |||
+ | : Using SMS might help to deliver configuration mainly in certain areas with poor GPRS data coverage however please note using SMS has certain limitations | ||
+ | :* SMS delivery is not a guaranteed channel (if not delivered SMS disappears from the network in a couple of hours) - this might cause inconsistency in device configuration temporarily | ||
+ | :* just a small subset of the full configuration scope can be fit into one single SMS (therefore the "Sent by SMS" button is only available till the modifications made fit into one SMS message) | ||
+ | :* also note additional charges might be applied when using SMS excessively | ||
+ | |||
+ | == Configuration areas / Device features == | ||
+ | <br> | ||
+ | : The configuration screen shows only | ||
+ | |||
+ | :* the settings relevant to a particular hardware model, firmware version, etc. are available | ||
+ | :* the options relevant to the context of previous selections are available (unrelated or conflicting options are hidden) | ||
+ | |||
+ | |||
+ | === Data collection settings === | ||
+ | <br> | ||
+ | : Left-side "Data collection" section concentrates all the controls related to data sampling | ||
+ | |||
+ | : [[File:config_data_collection.jpg|900px.JPG]] | ||
+ | |||
+ | |||
+ | ==== Scheduled GPS/sensor sampling ==== | ||
+ | <br> | ||
+ | : Defines type and structure of data triggered by the scheduler and the actual schedules | ||
+ | |||
+ | : Data scheduler offers two distinct modes | ||
+ | :* defined as separate cycles or day and night | ||
+ | :* defined as an interval (ignoring both human clock and day and night transitions) | ||
+ | |||
+ | |||
+ | |||
+ | ===== Different day & night cycles (night saving) ===== | ||
+ | <br> | ||
+ | : Day/night and night/day transition is configured by sun angles (either typing in the angle form or comfortably using the slider below day/night graphic) | ||
+ | |||
+ | : [[File:config_schedule_night_angles.JPG|700px]] | ||
+ | |||
+ | |||
+ | : Measurement intervals within each daypart use | ||
+ | |||
+ | |||
+ | :* '''"human time"''' (UTC clock) - intervals synchronized around defined UTC time (by default around UTC midnight) | ||
+ | |||
+ | : [[File:config_schedule_night_human.JPG|700px]] | ||
+ | |||
+ | |||
+ | :* '''"solar time"''' (i.e the local solar time for actual GPS position) | ||
+ | |||
+ | |||
+ | :: By default, the sampling interval is restarted with each day/night and night/day transition (i.e. the first position is collected with the day/night transition) | ||
+ | |||
+ | :: [[File:config_schedule_night_solar_start.JPG|700px]] | ||
+ | |||
+ | |||
+ | :: Alternatively, the interval can be synchronized '''around solar midnight/noon''' (positions are evenly distributed around solar noon/midnight) | ||
+ | |||
+ | :: [[File:config_schedule_night_solar_midnight.JPG|700px]] | ||
+ | |||
+ | |||
+ | ===== Schedules defined as Interval ===== | ||
+ | <br> | ||
+ | : Useful in situations when different day and night interval is not needed or when intensive energy saving needs to be achieved (data sampling within many hours or even days). A floating interval unrelated to the human UTC clock | ||
+ | |||
+ | : [[File:Config_schedule_interval.JPG|600px]] | ||
+ | |||
+ | ===== GPS/data measurements vs GPS/data bursts ===== | ||
+ | <br> | ||
+ | : The scheduler can trigger both - single GPS/data measurements and/or GPS/data bursts. In default, single measurements are triggered. | ||
+ | |||
+ | : When the burst launching is activated, an additional configuration section is displayed to specify burst behavior | ||
+ | |||
+ | : [[File:config_schedule_burst.JPG|700px]] | ||
+ | |||
+ | |||
+ | : Note the following about measurements and bursts: | ||
+ | |||
+ | |||
+ | : '''GPS/data measurement''' | ||
+ | |||
+ | :* Is a single planned (or activity-triggered) measurement event saving data from available/active sensors | ||
+ | |||
+ | :* The full dataset structure contains GPS data (latitude, longitude, altitude, direction, speed, and GNSS quality metrics), solar and battery voltage/percent, 3ax-sensors data (accelerometer, magnetometer, gyroscope), temperature. barometric pressure, and some more value-added calculated measures) | ||
+ | |||
+ | :* For sake of energy saving some measurements might be scheduled to run without activating the GNSS module and without waiting for GPS fix - i.e. '''interlacing''' GPS records with a sensor only records in data delivered into the database | ||
+ | |||
+ | ::: By default, GPS is turned on for every measurement: | ||
+ | ::: [[File:config_data_GPS_always.JPG|600px]] | ||
+ | ::: GPS interlacing can be configured here (1 GPS position + 4 non GPS records taken): | ||
+ | ::: [[File:config_data_GPS_each5.JPG|600px]] | ||
+ | ::: GPS can be turned off completely like this | ||
+ | ::: [[File:config_data_GPS_off.JPG|600px]] | ||
+ | ::: Note these settings are ignored when mortality is detected. | ||
+ | |||
+ | |||
+ | : '''GPS/data burst''' | ||
+ | |||
+ | :* a time-limited (by "burst length") continuous series of measurements at a defined sampling rate/interval (even down to 50Hz = 50 records/second) | ||
+ | |||
+ | :* while running bursts the device is switched to data and energy-intensive mode - a minimum battery level restriction should be maintained at a safe level | ||
+ | |||
+ | :* each of the sensor types used has a different "maximum resolution" - therefore in the case of running fast burst, we distinguish between | ||
+ | :** '''"slow" data''' (GPS data, temperature, battery voltage, or barometric pressure) - these are only present in one-second data or slower and | ||
+ | :** '''"fast" data''' (accelerometer, magnetometer, gyroscope) which can be sampled at a much higher frequency (e.g. up to 50hz) and saved in every record (e.g 50x per second) | ||
+ | |||
+ | :* for sake of energy-saving the busts can be also run without activating GNSS and storing GPS data at all. | ||
+ | :: [[File:config_burst_GNSSoff.JPG|700px]] | ||
+ | |||
+ | :* for limiting data volume generated by fast bursts '''"acc only" mode''' is available (only accelerometer data are stored - not magnetometer and gyroscope data) | ||
+ | :: [[File:config_burst_acconly.JPG|700px]] | ||
+ | |||
+ | :* Starting of the GNSS module and acquiring GPS position typically lasts a couple of seconds - the following options allow adjusting the burst start behavior the way needed | ||
+ | : [[File:config_data_burst_wait.JPG|500px]] | ||
+ | : [[File:config_data_burst_wait_off.JPG|500px]] | ||
+ | |||
+ | |||
+ | ==== Activity triggered data collection ==== | ||
+ | <br> | ||
+ | : Range of triggers that can activate/wake up of the device when a certain activity event is detected by the hardware sensors | ||
+ | : [[File:config_activity_triggers.JPG|800px]] | ||
+ | |||
+ | |||
+ | : Currently implemented triggers | ||
+ | |||
+ | |||
+ | :* "wake up from accelerometer" - based on sudden movement - e.g. can be used to detect take off / landing | ||
+ | :* "wake up from altimeter" - based on height change in meters | ||
+ | |||
+ | |||
+ | : Upon activation, the selected trigger can launch either a single measurement or burst | ||
+ | : In case of using triggers for burst an additional burst configuration screen is opened (similar to bursts triggered by schedule) | ||
+ | |||
+ | : [[File:config_activity_triggers_burst.JPG|800px]] | ||
+ | |||
+ | ==== Speed triggered continuous GPS sampling ==== | ||
+ | <br> | ||
+ | : A special functionality ensuring continuous GPS sampling till the object moves | ||
+ | |||
+ | : The speed threshold, GPS sampling rate, and battery threshold are adjustable | ||
+ | |||
+ | : [[File:config_speed_trigger.JPG|800px]] | ||
+ | |||
+ | : If used in combination with well-configured activity triggers it can allow full movement coverage of tracked animals! | ||
+ | |||
+ | ==== Mortality detection ==== | ||
+ | <br> | ||
+ | : Dedicated Anitra proprietary algorithm based on accelerometer and gyroscope evaluation. Comparing to the older version the new version is much more sensitive and accurate. | ||
+ | |||
+ | : When enabled, the mortality status is continuously evaluated and logged (note the device consumes additional energy). | ||
+ | |||
+ | : As soon as the status changes to "mortality detected" or vice versa (i.e. from "mortality" to "alive") the device automaticaly runs additional measurement (GPS+data) and stores this additional record into memory. | ||
+ | |||
+ | : Config parameter "run extra comm session.." proactively launches extra communication and notify of the mortality event immediately. | ||
+ | |||
+ | : Actual mortality state (in mortality/not in mortality) is stored in each dataset and usable for calibration for particular species or even individual/deployment. | ||
+ | |||
+ | : Note the default configuration options are adjusted to detect while the tag is deployed as a backpack (best tested for raptors) | ||
+ | |||
+ | : Calibration parameters are detection interval, number of confirmation cycles before the mortality warning is raised, and detection sensitivity | ||
+ | |||
+ | :[[File:config_mortality.JPG|800px]] | ||
+ | |||
+ | ==== Geofencing ==== | ||
+ | : ''(for the complete information about geofencing see detailed [[geofencing| geofencing configuration guide ]]'') | ||
+ | <br> | ||
+ | :Modifies standard device behavior based on the geographic location | ||
+ | |||
+ | : Specifics of Anitra geofencing | ||
+ | :* tailored for very advanced geofencing tasks on top of POI databases with even many thousands of items (e.g. database of past poisoning places, wind turbines, dangerous power pylons, etc) | ||
+ | :* a dynamic geofence synchronization (when moving the tag synchronizes 100 closest geofence instances) | ||
+ | :* geofences defined by circular (or possibly even cylindrical) zones | ||
+ | :** working with circles allows resolving conflicts for overlapping geofences (as the closest, the smallest) | ||
+ | :** altitude definition enables 3D geofencing (when higher it is considered as outside of geofence) | ||
+ | |||
+ | : Geofences are created and managed in the Geofence dialog listing all the device geofences and showing them on the map | ||
+ | :[[File:GF_map_definition.JPG|900px]] | ||
+ | |||
+ | : A modified geofence behavior is defined in the Geofence behavior screen. A subset of configuration parameters can be overridden within the geofence | ||
+ | :* day/night data collection interval | ||
+ | :* activity and speed triggering | ||
+ | :* radio buoy activation | ||
+ | :* communication while entering/leaving the geofence | ||
+ | :[[File:GF_behavior.JPG|900px]] | ||
+ | |||
+ | : ''(for the complete information about geofencing see detailed[[geofencing| geofencing configuration guide ]])'' | ||
+ | |||
+ | === Communication schedules === | ||
+ | |||
+ | : Right-side "Communication plans" section concentrates all the controls related to communications schedules/data delivery | ||
+ | : [[File:config_comm_schedules.jpg|600px.JPG]] | ||
+ | |||
+ | : Anitra devices offer a very wide range of communication setups to match best any particular field situation. Users can combine the following options in order to achieve desired behavior and data delivery timing | ||
+ | |||
+ | :* Communication defined by intervals | ||
+ | :* Communication defined by fixed UTC timeslots | ||
+ | :* Communication based on number of records collected | ||
+ | :* One-time communication UTC timeslots | ||
+ | :* Additional options | ||
+ | |||
+ | ==== Communication defined by intervals ==== | ||
+ | : This communication plan allows programming the tag to sent data regularly within defined cycles/intervals. The plans can be set up | ||
+ | |||
+ | :* synchronized to human clock | ||
+ | :** the interval is repeated within 24 hours and restarted at a defined sync time | ||
+ | :** because of that only intervals matching 24 hours are allowed here (i.e. intervals of 1,2,3,4,6,12 hours) | ||
+ | : [[File:config_comm_interval_synced.JPG|400px]] | ||
+ | |||
+ | :* or floating (not synchronized to the clock) | ||
+ | :** the interval is repeated independently of human clock hours | ||
+ | :** the cycle is restarted with the applied change of the cycle (or when the device is completely discharged) | ||
+ | :** any hours intervals are allowed in this case (i.e. 1,2,3,4,5,6,7 hours) which might result in different communication times from one day to another | ||
+ | : [[File:config_comm_interval_nosync.JPG|400px]] | ||
+ | |||
+ | : Note this schedule can not be completely turned off as it also acts as an "emergency" schedule (i.e. in case of accidentally turning off all other plans) | ||
+ | : Even when turned off by a user the schedule is still triggered every 648 hours (27 days) | ||
+ | : [[File:config_comm_interval_default.JPG|400px]] | ||
+ | |||
+ | |||
+ | ==== Communication defined by fixed UTC timeslots ==== | ||
+ | : This functionality offers up to four "fixed" time slots | ||
+ | :* fixed to a particular UTC day hour | ||
+ | :* and run every X days defined per slot | ||
+ | : [[File:config_fixedtime.JPG|400px]] | ||
+ | |||
+ | |||
+ | ==== Communication based on number of records collected ==== | ||
+ | : Communication is relaunched whenever a defined number of records is collected by the tag | ||
+ | : This setting might be particularly beneficial in case of the use of dynamic, unpredictable, or data-intensive sampling modes (such as data/burst triggered by activity or speed triggers) | ||
+ | : [[File:config_comm_datatrigger.JPG|400px]] | ||
+ | |||
+ | |||
+ | ==== One-time communication UTC timeslots ==== | ||
+ | : In this case, the tag enforces GPS position taking before running communication | ||
+ | : A typical use case is planning the one-time session at the time of the planned field check (e.i. the tag delivers a fresh GPS position) | ||
+ | : Allows parallel scheduling of up to four one-time communication sessions defined at a particular UTC date/time | ||
+ | : [[File:config_comm_onetime.JPG|400px]] | ||
+ | |||
+ | |||
+ | ==== Other communication-triggering events ==== | ||
+ | : Note the communication can also be triggered in some other situations | ||
+ | |||
+ | :* device notifies its state in Power-off / Storage mode | ||
+ | : [[File:config_comm_poweroff.JPG|400px]] | ||
+ | |||
+ | :* mortality detection functionality can be configured to sent data when mortality is reliably confirmed | ||
+ | : [[File:config_comm_mortality.JPG|400px]] | ||
+ | |||
+ | :* POI/geofencing can also be configured to trigger communication (when entering POI) | ||
+ | |||
+ | :* Finally a special SM communication session is trigger when regular data schedules fail cor certain number of days | ||
+ | : [[File:config_comm_emergencySMS.JPG|400px]] | ||
+ | |||
+ | |||
+ | : Taking into account above mentioned various communication sources the predictability of the next communication session is limited | ||
+ | : The "Next schedule" prediction only factors schedules planned to UTC clock | ||
+ | : [[File:config_comm_prediction.JPG|400px]] | ||
+ | |||
+ | |||
+ | === Other user settings === | ||
+ | |||
+ | : Bottom-right section concentrates all the remaining user controls (Communication Channels preference, Storage mode configuration, appended radio buoy or release trigger control, etc) | ||
+ | : [[File:config_other_settings.jpg|700px.JPG]] | ||
+ | |||
+ | |||
+ | === Storage mode === | ||
+ | * allows bringing the device to low energy consumption mode | ||
+ | * the device is powered off most of the time and only wakes up at 00:00 UTC in a specified day interval to send tag status (one dataset - GPS, battery level, etc.) | ||
+ | * the communication interval can be set between 1 and 32 days | ||
+ | * using storage mode is useful for long-distance transport and for storing undeployed devices longer time (e.g. when solar charging or GPS signal is unavailable longterm) | ||
+ | [[File:config_poweroff.JPG|500px]] | ||
+ | |||
+ | |||
+ | == Advanced Concepts== | ||
+ | |||
+ | === Configuration Presets === | ||
+ | : ''(for the complete information about Presets see detailed [[presets| guide to configuration presets]]'') | ||
+ | <br> | ||
+ | : This functionality allows saving current device configuration (combination of parameters) into general "Configuration preset" | ||
+ | |||
+ | : * it can be later applied again at the same device or elsewhere | ||
+ | : * it only stores configuration which is universal (not unique to a particular device – e.g. mobile phone number or individual calibration values are not stored) | ||
+ | : * full or just a subset of configuration can be saved as a preset. Eg. you can save communication settings into one preset and data collection setting into another preset and geofence settings into the third one. | ||
+ | : * application the preset later on modifies only values or sections treated by the preset. You can thus apply more independent presets step by step in a sequence | ||
+ | |||
+ | |||
+ | : '''Preset creation:''' | ||
+ | |||
+ | :* use the „Save as preset“ button in the config screen | ||
+ | :* name the preset | ||
+ | :* review the contents | ||
+ | :* save when all done<br>[[File:Presets_Save_as_Preset.jpg|700px]] | ||
+ | |||
+ | |||
+ | : '''Using preset / Load existing preset''' | ||
+ | |||
+ | :* use the „Load preset“ button | ||
+ | :* look up the preset | ||
+ | :** using "Find preset" | ||
+ | :** chosing from "My presets" | ||
+ | :* highlight and review the contents | ||
+ | :* load values back to the device config screen | ||
+ | :* review if preset applied correctly | ||
+ | :* submit modified configuration & activate geofences created<br><br>[[File:Presets_Apply_preset.jpg|600px]] | ||
+ | |||
+ | : ''(for the complete information about Presets see detailed [[presets| guide to configuration presets]]'') |
Latest revision as of 10:36, 6 July 2023
Contents
- 1 Overview & Basic Concepts
- 2 Configuration areas / Device features
- 3 Advanced Concepts
Overview & Basic Concepts
- Users with admin rights (device owners/admins) can access the configuration from the lists and profiles using cogwheel icons.
- Note the configuration functionality is available for Anitra devices only.
- User configuration screen is structured into three main areas
- Data collection settings
- Communication schedules
- Other settings
- Note many more advanced settings are possibly available to adjust device behavior upon request/need (device maintenance, troubleshooting, firmware upgrades, custom configuration/behavior - such as GPS accuracy, etc)
- Any changes made are visualized by blue and red symbols close to the modified setting and in the top right corner of each modified section
- symbols ("pen", "clock" and "check") show the status of each configuration (edited (=blue "pen") >> pending (=red "clock") >> confirmed (=green "check"))
- New modifications (not yet submitted) are highlighted by blue color
- these modifications can be reverted to saved values simply by closing the config screen or by clicking on the blue "pen" (for a particular parameter or on the section level)
- in order to submit the modified parameters, click the "Send" button below
- Submitted values are highlighted by red color
- >> all the blue "pen" icons change to red "clock" icons indicating the value is waiting for the device to apply it
- note the configuration changes apply whenever the tag connects to communicate/send data
- Until the values are confirmed by the device the pending changes can be modified or canceled
- by clicking on the particular "clock" icon - for a particular parameter or on the section level
- by clicking on the "Discard all pending changes" button below - for canceling all
- Once the pending parameters are received, accepted, and confirmed successfully by the device the status is changed from red "clock" to green "check"
- note by default the configuration is sent and delivered to the device via GPRS data
- as a supplementary delivery channel SMS can be used ("Send by SMS" button)
- Using SMS might help to deliver configuration mainly in certain areas with poor GPRS data coverage however please note using SMS has certain limitations
- SMS delivery is not a guaranteed channel (if not delivered SMS disappears from the network in a couple of hours) - this might cause inconsistency in device configuration temporarily
- just a small subset of the full configuration scope can be fit into one single SMS (therefore the "Sent by SMS" button is only available till the modifications made fit into one SMS message)
- also note additional charges might be applied when using SMS excessively
Configuration areas / Device features
- The configuration screen shows only
- the settings relevant to a particular hardware model, firmware version, etc. are available
- the options relevant to the context of previous selections are available (unrelated or conflicting options are hidden)
Data collection settings
- Left-side "Data collection" section concentrates all the controls related to data sampling
Scheduled GPS/sensor sampling
- Defines type and structure of data triggered by the scheduler and the actual schedules
- Data scheduler offers two distinct modes
- defined as separate cycles or day and night
- defined as an interval (ignoring both human clock and day and night transitions)
Different day & night cycles (night saving)
- Day/night and night/day transition is configured by sun angles (either typing in the angle form or comfortably using the slider below day/night graphic)
- Measurement intervals within each daypart use
- "human time" (UTC clock) - intervals synchronized around defined UTC time (by default around UTC midnight)
- "solar time" (i.e the local solar time for actual GPS position)
- By default, the sampling interval is restarted with each day/night and night/day transition (i.e. the first position is collected with the day/night transition)
- Alternatively, the interval can be synchronized around solar midnight/noon (positions are evenly distributed around solar noon/midnight)
Schedules defined as Interval
- Useful in situations when different day and night interval is not needed or when intensive energy saving needs to be achieved (data sampling within many hours or even days). A floating interval unrelated to the human UTC clock
GPS/data measurements vs GPS/data bursts
- The scheduler can trigger both - single GPS/data measurements and/or GPS/data bursts. In default, single measurements are triggered.
- When the burst launching is activated, an additional configuration section is displayed to specify burst behavior
- Note the following about measurements and bursts:
- GPS/data measurement
- Is a single planned (or activity-triggered) measurement event saving data from available/active sensors
- The full dataset structure contains GPS data (latitude, longitude, altitude, direction, speed, and GNSS quality metrics), solar and battery voltage/percent, 3ax-sensors data (accelerometer, magnetometer, gyroscope), temperature. barometric pressure, and some more value-added calculated measures)
- For sake of energy saving some measurements might be scheduled to run without activating the GNSS module and without waiting for GPS fix - i.e. interlacing GPS records with a sensor only records in data delivered into the database
- GPS/data burst
- a time-limited (by "burst length") continuous series of measurements at a defined sampling rate/interval (even down to 50Hz = 50 records/second)
- while running bursts the device is switched to data and energy-intensive mode - a minimum battery level restriction should be maintained at a safe level
- each of the sensor types used has a different "maximum resolution" - therefore in the case of running fast burst, we distinguish between
- "slow" data (GPS data, temperature, battery voltage, or barometric pressure) - these are only present in one-second data or slower and
- "fast" data (accelerometer, magnetometer, gyroscope) which can be sampled at a much higher frequency (e.g. up to 50hz) and saved in every record (e.g 50x per second)
- each of the sensor types used has a different "maximum resolution" - therefore in the case of running fast burst, we distinguish between
- for sake of energy-saving the busts can be also run without activating GNSS and storing GPS data at all.
- for limiting data volume generated by fast bursts "acc only" mode is available (only accelerometer data are stored - not magnetometer and gyroscope data)
- Starting of the GNSS module and acquiring GPS position typically lasts a couple of seconds - the following options allow adjusting the burst start behavior the way needed
Activity triggered data collection
- Range of triggers that can activate/wake up of the device when a certain activity event is detected by the hardware sensors
- Currently implemented triggers
- "wake up from accelerometer" - based on sudden movement - e.g. can be used to detect take off / landing
- "wake up from altimeter" - based on height change in meters
- Upon activation, the selected trigger can launch either a single measurement or burst
- In case of using triggers for burst an additional burst configuration screen is opened (similar to bursts triggered by schedule)
Speed triggered continuous GPS sampling
- A special functionality ensuring continuous GPS sampling till the object moves
- The speed threshold, GPS sampling rate, and battery threshold are adjustable
- If used in combination with well-configured activity triggers it can allow full movement coverage of tracked animals!
Mortality detection
- Dedicated Anitra proprietary algorithm based on accelerometer and gyroscope evaluation. Comparing to the older version the new version is much more sensitive and accurate.
- When enabled, the mortality status is continuously evaluated and logged (note the device consumes additional energy).
- As soon as the status changes to "mortality detected" or vice versa (i.e. from "mortality" to "alive") the device automaticaly runs additional measurement (GPS+data) and stores this additional record into memory.
- Config parameter "run extra comm session.." proactively launches extra communication and notify of the mortality event immediately.
- Actual mortality state (in mortality/not in mortality) is stored in each dataset and usable for calibration for particular species or even individual/deployment.
- Note the default configuration options are adjusted to detect while the tag is deployed as a backpack (best tested for raptors)
- Calibration parameters are detection interval, number of confirmation cycles before the mortality warning is raised, and detection sensitivity
Geofencing
- (for the complete information about geofencing see detailed geofencing configuration guide )
- Modifies standard device behavior based on the geographic location
- Specifics of Anitra geofencing
- tailored for very advanced geofencing tasks on top of POI databases with even many thousands of items (e.g. database of past poisoning places, wind turbines, dangerous power pylons, etc)
- a dynamic geofence synchronization (when moving the tag synchronizes 100 closest geofence instances)
- geofences defined by circular (or possibly even cylindrical) zones
- working with circles allows resolving conflicts for overlapping geofences (as the closest, the smallest)
- altitude definition enables 3D geofencing (when higher it is considered as outside of geofence)
- Geofences are created and managed in the Geofence dialog listing all the device geofences and showing them on the map
- A modified geofence behavior is defined in the Geofence behavior screen. A subset of configuration parameters can be overridden within the geofence
- day/night data collection interval
- activity and speed triggering
- radio buoy activation
- communication while entering/leaving the geofence
- (for the complete information about geofencing see detailed geofencing configuration guide )
Communication schedules
- Right-side "Communication plans" section concentrates all the controls related to communications schedules/data delivery
- Anitra devices offer a very wide range of communication setups to match best any particular field situation. Users can combine the following options in order to achieve desired behavior and data delivery timing
- Communication defined by intervals
- Communication defined by fixed UTC timeslots
- Communication based on number of records collected
- One-time communication UTC timeslots
- Additional options
Communication defined by intervals
- This communication plan allows programming the tag to sent data regularly within defined cycles/intervals. The plans can be set up
- synchronized to human clock
- the interval is repeated within 24 hours and restarted at a defined sync time
- because of that only intervals matching 24 hours are allowed here (i.e. intervals of 1,2,3,4,6,12 hours)
- synchronized to human clock
- or floating (not synchronized to the clock)
- the interval is repeated independently of human clock hours
- the cycle is restarted with the applied change of the cycle (or when the device is completely discharged)
- any hours intervals are allowed in this case (i.e. 1,2,3,4,5,6,7 hours) which might result in different communication times from one day to another
- or floating (not synchronized to the clock)
- Note this schedule can not be completely turned off as it also acts as an "emergency" schedule (i.e. in case of accidentally turning off all other plans)
- Even when turned off by a user the schedule is still triggered every 648 hours (27 days)
Communication defined by fixed UTC timeslots
- This functionality offers up to four "fixed" time slots
- fixed to a particular UTC day hour
- and run every X days defined per slot
Communication based on number of records collected
- Communication is relaunched whenever a defined number of records is collected by the tag
- This setting might be particularly beneficial in case of the use of dynamic, unpredictable, or data-intensive sampling modes (such as data/burst triggered by activity or speed triggers)
One-time communication UTC timeslots
- In this case, the tag enforces GPS position taking before running communication
- A typical use case is planning the one-time session at the time of the planned field check (e.i. the tag delivers a fresh GPS position)
- Allows parallel scheduling of up to four one-time communication sessions defined at a particular UTC date/time
Other communication-triggering events
- Note the communication can also be triggered in some other situations
- mortality detection functionality can be configured to sent data when mortality is reliably confirmed
- POI/geofencing can also be configured to trigger communication (when entering POI)
- Finally a special SM communication session is trigger when regular data schedules fail cor certain number of days
- Taking into account above mentioned various communication sources the predictability of the next communication session is limited
- The "Next schedule" prediction only factors schedules planned to UTC clock
Other user settings
- Bottom-right section concentrates all the remaining user controls (Communication Channels preference, Storage mode configuration, appended radio buoy or release trigger control, etc)
Storage mode
- allows bringing the device to low energy consumption mode
- the device is powered off most of the time and only wakes up at 00:00 UTC in a specified day interval to send tag status (one dataset - GPS, battery level, etc.)
- the communication interval can be set between 1 and 32 days
- using storage mode is useful for long-distance transport and for storing undeployed devices longer time (e.g. when solar charging or GPS signal is unavailable longterm)
Advanced Concepts
Configuration Presets
- (for the complete information about Presets see detailed guide to configuration presets)
- This functionality allows saving current device configuration (combination of parameters) into general "Configuration preset"
- * it can be later applied again at the same device or elsewhere
- * it only stores configuration which is universal (not unique to a particular device – e.g. mobile phone number or individual calibration values are not stored)
- * full or just a subset of configuration can be saved as a preset. Eg. you can save communication settings into one preset and data collection setting into another preset and geofence settings into the third one.
- * application the preset later on modifies only values or sections treated by the preset. You can thus apply more independent presets step by step in a sequence
- Preset creation:
- Using preset / Load existing preset
- (for the complete information about Presets see detailed guide to configuration presets)