Difference between revisions of "Configuration"
(→Communication schedules) |
|||
Line 56: | Line 56: | ||
:* the options relevant to the context of previous selections (unrelated or conflicting options are hidden) | :* the options relevant to the context of previous selections (unrelated or conflicting options are hidden) | ||
− | + | :* whereever it make sense alternative data inputs are available to verify user input (e.g. parallel input of s/m/hours or s/ms/Hz) | |
− | + | : [[File:config_hrs_min_sec.JPG|700px]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | [[File:config_hrs_min_sec.JPG| | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 96: | Line 75: | ||
*** 24hours cyclic GPS/sensor frequency setting (day/night ignored) | *** 24hours cyclic GPS/sensor frequency setting (day/night ignored) | ||
*** the cycle starts at the pre-defined hour (UTC) <br>[[File:Config12_dc_human|900px.JPG]] | *** the cycle starts at the pre-defined hour (UTC) <br>[[File:Config12_dc_human|900px.JPG]] | ||
+ | |||
+ | [[File:config_schedule_burst.JPG|600px]] | ||
+ | [[File:config_schedule_interval_notsynced.JPG|600px]] | ||
+ | [[File:config_schedule_interval_synced.JPG|600px]] | ||
+ | [[File:config_schedule_night_angles.JPG|600px]] | ||
+ | [[File:config_schedule_night_human.JPG|600px]] | ||
+ | [[File:config_schedule_night_solar_midnight.JPG|600px]] | ||
+ | [[File:config_schedule_night_solar_start.JPG|600px]] | ||
+ | |||
+ | [[File:config_burst_acconly.JPG|600px]] | ||
+ | [[File:config_burst_GNSSoff.JPG|600px]] | ||
+ | |||
+ | [[File:config_data_burst_wait.JPG|400px]] | ||
+ | [[File:config_data_burst_wait_off.JPG|400px]] | ||
+ | [[File:config_data_GPS_always.JPG|400px]] | ||
+ | [[File:config_data_GPS_each5.JPG|400px]] | ||
+ | [[File:config_data_GPS_off.JPG|400px]] | ||
+ | |||
==== Activity triggered data collection ==== | ==== Activity triggered data collection ==== | ||
Line 103: | Line 100: | ||
* a sensitivity range for each of the algorithms available <br>[[File:Config12_dc_activitytrigger.JPG|900px]] | * a sensitivity range for each of the algorithms available <br>[[File:Config12_dc_activitytrigger.JPG|900px]] | ||
+ | [[File:config_activity_triggers.JPG|600px]] | ||
+ | [[File:config_activity_triggers_burst.JPG|600px]] | ||
− | ==== | + | ==== mortality detection ==== |
− | * a dedicated mortality detection functionality | + | * a dedicated mortality detection functionality (Anitra proprietary algorithm based on accelerometer and gyroscope evaluation) |
− | * | + | * comparing to the older version the new algorithm (2021 version) is much more sensitive and accurate |
− | * species | + | * when the functionality is activated |
+ | ** the mortality status is continuously evaluated (note when activated the functionality consumes some extra energy) | ||
+ | * when the status changes to detected mortality | ||
+ | ** the device can proactively launch communication and notify of the mortality event | ||
+ | ** actual mortality state (in mortality/not in mortality) is stored in each dataset and sent to the server | ||
+ | ** the detection can be thus calibrated for particular species or even deployment/individual | ||
* calibration parameters are | * calibration parameters are | ||
+ | ** the number of confirmation cycles (interval of 30 seconds) before the mortality warning is raised | ||
** the detection sensitivity level | ** the detection sensitivity level | ||
− | |||
− | |||
+ | :[[File:config_mortality.JPG|800px]] | ||
==== Geofencing using POIs ==== | ==== Geofencing using POIs ==== | ||
Line 142: | Line 146: | ||
:* Communication based on number of records collected | :* Communication based on number of records collected | ||
:* One-time communication UTC timeslots | :* One-time communication UTC timeslots | ||
− | + | :* Additional options | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Communication defined by intervals ==== | ==== Communication defined by intervals ==== | ||
Line 170: | Line 168: | ||
==== Communication defined by fixed UTC timeslots ==== | ==== 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]] | ||
Line 180: | Line 181: | ||
==== One-time communication UTC timeslots ==== | ==== One-time communication UTC timeslots ==== | ||
− | |||
: In this case, the tag enforces GPS position taking before running communication | : 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) | : 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]] | : [[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 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 === | === Other user settings === | ||
Line 189: | Line 212: | ||
: Bottom-right section concentrates all the remaining user controls (Communication Channels preference, Storage mode configuration, appended radio buoy or release trigger control etc) | : 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|600px.JPG]] | : [[File:config_other_settings.jpg|600px.JPG]] | ||
+ | |||
=== Storage mode === | === Storage mode === | ||
− | * allows to | + | * 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|400px]] |
Revision as of 18:35, 3 March 2021
Contents
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.
- the options relevant to the context of previous selections (unrelated or conflicting options are hidden)
- whereever it make sense alternative data inputs are available to verify user input (e.g. parallel input of s/m/hours or s/ms/Hz)
Data collection settings
GPS/sensor sampling
- configurable using solar or human time
- "solar time"
- the device synchronizes the data collection to local GPS time based on GPS.
- comfortable day/night transition set up (sun angles above the horizon). Visual control over the settings
- sampling frequency for day/night entered parallel in seconds, minutes or hours
- easy synchronization between various animals
- "human time"
- 24hours cyclic GPS/sensor frequency setting (day/night ignored)
- the cycle starts at the pre-defined hour (UTC)
900px.JPG
- "solar time"
Activity triggered data collection
- checkboxes for two different algorithms detecting movement
- trigger 1: a slot fixed for a generic algorithm detecting movement from the accelerometer
- trigger 2: a slot ready for other customized movement detection algorithm(s). Up to 12 variable algorithms can be implemented on request and assigned to trigger no.2
- a sensitivity range for each of the algorithms available
mortality detection
- a dedicated mortality detection functionality (Anitra proprietary algorithm based on accelerometer and gyroscope evaluation)
- comparing to the older version the new algorithm (2021 version) is much more sensitive and accurate
- when the functionality is activated
- the mortality status is continuously evaluated (note when activated the functionality consumes some extra energy)
- when the status changes to detected mortality
- the device can proactively launch communication and notify of the mortality event
- actual mortality state (in mortality/not in mortality) is stored in each dataset and sent to the server
- the detection can be thus calibrated for particular species or even deployment/individual
- calibration parameters are
- the number of confirmation cycles (interval of 30 seconds) before the mortality warning is raised
- the detection sensitivity level
Geofencing using POIs
- an adjustment of basic data collection cycles based on geographic location
- the definition consists of
- GPS position of the center of POI + radius/range from the center of the circle
- modified day/night data collection interval
- up to 20 static POIs with different configurations can be defined for each device
- flexible mapping to the database of Nests, favorite perches, Pylons, or other POIs
- ready for dynamic POIs synchronization (the tag downloads definition for 20 geographically closest POIs)
GPS/sensor bursts
- switching device to collect the raw GPS/sensor data
- energy and data-intensive mode
- maximum frequency of 250HZ
- data bursts can be triggered with or without GPS fixing
- minimum battery level restriction to trigger the burst
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 time 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
- 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)