The Yabby Edge LoRaWAN provides a number of configurable parameters, to allow its behavior to be tailored to specific applications. Factors affecting the configuration you might choose include:

• How many messages per day your network will allow
• How often you intend to change the batteries, and the type of batteries in use
• How detailed a bread-crumb trail you require, or the required time between updates
• How good the GNSS/WiFi reception is in your installation

How The Yabby Edge LoRaWAN Connects 

OTAA

By default, the Yabby Edge LoRaWAN connects to a local LoRaWAN network using Over The Air Activation. Each device is provisioned with:

• A read-only DevEUI - a 16 digit code uniquely identifying the device (printed on the label)
• A configurable JoinEUI /AppEUI - a 16 digit code identifying the server the device is registered with 
• A configurable NwkKey (1.1) / AppKey (1.0) - a 32 digit code that authenticates the device to the network server
• A configurable AppKey (1.1) - a 32 digit code that authenticates the device to the application server
  • The default JoinEUI is 70-B3-D5-70-50-00-00-09
  • Each device is provisioned with a random default NwkKey and AppKey (1.1) 
• A configurable Region and optional Channel Mask
  • The channel mask is used in the US915 and AU915 regions, to set the network frequencies
  • Other regions don't need the channel mask, as all their networks use the same OTAA frequencies

Once the region has been configured, the Yabby Edge LoRaWAN will attempt to join local networks by transmitting join requests. Any network that hears the join requests and has knowledge of the device's DevEUI, JoinEUI and keys, will allow it to join the network and transmit data.

By default, the Yabby Edge LoRaWAN will attempt to rejoin a LoRaWAN 1.0 network if it sees no downlinks for over a week. This ensures continued operation in the event of a network losing the keys (for instance, if the device is mistakenly deleted). On a LoRaWAN 1.1 network, it sends a rejoin request once a week, even in the presence of downlink traffic, to allow roaming.

ABP

The Yabby Edge LoRaWAN can also be configured to connect using Activation By Personalization. When using ABP, each device must be configured with some additional numbers:

• A configurable DevAddr - an 8 digit code identifying the device to the network
• 32 digit session keys FNwkSIntKey (also known as NwkSKey)and AppSKey,on LoRaWAN 1.0
• 32 digit session keys FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey, on LoRaWAN 1.1

ABP allows a LoRaWAN device to connect without exchanging the usual join request and join response, which can save on downlink bandwidth, and allow the device to work when downlink reception is difficult. However, in LoRaWAN 1.0, the ABP mechanism is somewhat problematic. It either suffers from a lack of security (if you configure your device to reset it's uplink frame counts when it resets), or difficulty with configuration (if you don't reset the frame counts, and are in a region requiring dynamic channel configuration). These issues are fixed in the LoRaWAN 1.1 specification, but since the fix negates the chief advantage of ABP by requiring some downlink traffic, we recommend OTAA.

How The Yabby Edge LoRaWAN Locates

The Yabby Edge LoRaWAN uses an accelerometer to detect movement, allowing it to decide when an asset is in-trip, and when it is stationary. Each time a status update is scheduled, the device will attempt a location scan, then transmit the results to the Location Engine. You can configure it to transmit a status update:

• Periodically (ie. 24-hour heartbeat)
• At configured times of the day
• At the start of a trip
• During the trip
• At the end of the trip
• During after-hours trips
• When the 'Inactivity Indicator' status changes

How The Yabby Edge LoRaWAN Uses Airtime

LoRaWAN devices can transmit at various data rates, usually denoted DR0, DR1, DR2, and so forth. The lowest data rate (DR0) takes the longest to transmit, but has the longest range. As the data rate goes up, the range goes down a bit, and the transmission time goes down a lot. Yabby Edge LoRaWANs can be configured to use a particular data rate, or a range of data rates (ie. DR2-DR4). Lower data rates will have the longest range, but also use the most battery power and airtime. When configured to use a range of data rates, the device spends an equal amount of airtime using each data rate. There is also optional Adaptive Data Rate support, which allows the network server to intelligently control the data rate.

There are several factors limiting the maximum transmission rate of a Yabby Edge LoRaWAN:

• Radio regulations may limit the transmission time
  • In Europe the law limits you to 36 seconds of transmit time per hour on most frequencies
  • Whereas in Australia there is no legal limit
• Networks may limit the transmission time, to prevent congestion
  • The Things Network for instance limits you to 30 seconds of transmit time per day
  • At DR0, this gives you 20 messages with 100% range
  • At DR1, this gives you 36 messages with 75% range
  • At DR2, this gives you 80 messages with 50% range
  • At DR3, this gives you 145 messages with 37% range
  • At DR4, this gives you 265 messages with 28% range
  • At DR5, this gives you 486 messages with 21% range
  • In America, data rates are all two increments higher, so DR0 corresponds to DR2 in the above list
• Networks may limit the number of messages, for billing purposes
  • Your network might require you to pay more for higher throughput
• Battery life may prove to be a limiting factor
  • A Yabby Edge LoRaWAN can only send around 10 thousand WiFi scans at DR0 on one set of batteries
  • Using a higher data rate will use less battery per transmission, but doesn't change the battery use of the GNSS/WiFi scanning
  • Battery required for a transmission at DR0 is roughly 0.1 mAh, compared to a GNSS/WiFi scan of 0.015 mAh.
  • GNSS scans typically take 2 to 3 transmissions to send, while WiFi scans take only 1 to 2 transmissions.

The radio regulations are automatically enforced by inserting delays between messages where required. It is up to the user to configure their Yabby Edge LoRaWAN with a low enough transmission rate to meet network and battery life requirements.

How The Yabby Edge LoRaWAN Sends Large Messages

The Yabby Edge LoRaWAN scans for WiFi MAC addresses and GNSS satellite timing, which are then sent to the cloud to be resolved into a location. This allows indoor scanning, and significantly reduces the battery used for GNSS, but results in relatively large uplink sizes. Typically, 7 WiFi MAC addresses will fit into a single 51 bytes uplink, and 12 GNSS satellites will fit into two 51 byte uplinks. The fragmented message is sent over LoRaWAN ports 101-116, reassembled by the Location Engine cloud server, and then forwarded to the application server as a single uplink (for instance, a position message on port 5). If no fragmentation is required, the message is instead sent as a single uplink on port 5 to begin with.

If WiFi and GNSS are combined, or the maximum packet size is smaller (ie. 11 bytes in some regions), each location update message might be spread across several uplinks. If each message is being sent in 5 uplinks, and each uplink has a 3% chance of being lost, the chance of losing at least one part of the message goes up to nearly 15%. To prevent this, additional uplinks are sent containing forward error correction. For instance, 6 uplinks could be sent instead of 5, in anticipation of one being lost. If any 5 out of the 6 are received, the message is successfully decoded. By default, the extra uplinks usually reduce the chance of losing the message to lower than the chance of losing a single uplink. The level of uplink loss tolerance can be tuned by changing parameters in the Uplink Fragmentation section, detailed below. 

Relationship with the Location Engine

In order to resolve WiFi scans into physical positions, a constantly updated database of WiFi access points must be consulted. Likewise, the low power GNSS scans produce satellite timing information which needs to be resolved into a position by a cloud server with access to the satellite's orbital information. This alone makes cloud infrastructure a critical part of any Yabby Edge LoRaWAN deployment. But a further consideration is the aiding data required to make the GNSS scans perform well. The device requires a satellite almanac, a coarse position estimate (+-150 km), and a fairly accurate time source (+-30 seconds), to deliver full GNSS performance. Transferring the aiding data and reassembling the fragmented uplinks in a reliable and efficient way is a complex task, requiring extensive software development.

For this reason, all of the cloud services required (position lookups, aiding, and message decoding) are provided by Digital Matter's Location Engine. This greatly simplifies integration, saving many months of software development, and gives you access to bulk discounted WiFi lookup pricing, even in low volume. Device traffic from the network server is forwarded to the Location Engine, which in turn forwards the resolved positions to your integration in a simple JSON formatted HTTP push.

While the portions of the protocol handled by the Location Engine are not secret, implementing them is so complex that we do not provide support for private integrations at this time. However, if you need to operate a Yabby Edge LoRaWAN without a Location Engine integration, you can disable the cloud features to achieve standalone operation by:

• Disabling GNSS aiding (Scanning->GNSS Aiding Mode = Autonomous no Time)
• Disabling uplink fragmentation (Scanning->Uplink Fragmentation = Disabled)
• Ensuring your uplink data rate can carry large messages (Advanced LoRaWAN->Min Data Rate)
• Leaving all Scheduled Uploads and After Hours definitions empty 

When configured this way, the Yabby Edge LoRaWAN will deliver only simple position and battery statistic uplinks, at the expense of greatly reduced GNSS performance. Because GNSS messages use more than 51 bytes, implying a higher data rate, the maximum range for GNSS operation is also reduced. The position uplinks will contain the scanned WiFi MAC addresses and raw GNSS timing information, which can then be resolved with a lookup service from Google, Semtech, or any other provider.

How The Yabby Edge LoRaWAN is Configured

The Yabby Edge LoRaWAN is configurable over-the-air using downlinks. Sites integrating the device can find the complete protocol specification here. Initial configuration of the region and JoinEUI, as well as firmware updates, are performed with a plug-in USB adapter, and a Windows provisioning tool. An adapter can be obtained from your distributor. The adapter plugs into the six pin connector next to the battery holder.

To read the available parameters, open the provisioning tool and plug the DM Link into the device. The provisioning tool will read continuously, and display the existing parameters in the center column. To program new parameters and firmware, enter the desired parameters in the right hand column, and check the Set Parameters checkbox. To update the firmware only, check the Set Firmware checkbox, and leave the Set Parameters checkbox clear.

If you click the DevEUI List button, a list of scanned DevEUIs will pop up. You can hot-plug the adapter into many Yabby Edge LoRaWANs in sequence to populate the list. Each time a device is programmed the parameter list will flash, the DevEUI list will update, and a chime will sound. The list is in CSV format, so it can be imported into a spreadsheet easily.

The top line in the display shows the DevEUI and version string. In the screenshot above, the DevEUI is 0016C001F000AC2A, and the firmware version is 86.2.1.4. (product, hardware revision, major, minor). The configured encryption keys and EUIs can be found in the DevEUI list on the right. Hovering the cursor over a line reveals an action menu ('...') and a help pop-up ('?'), from which you can copy, reset, and inspect parameters and sections. Save and load functions are available in both the File menu and the All Parameters action menu.

Configuration Options

 There are many settings, but only a handful require customization. These are highlighted below.

General

Heartbeat Tx (0-7620 mins):

The maximum time between status updates. Setting to 1.00:00 results in at least one status update per day. If movement causes additional updates, the next heartbeat update is scheduled for 24 hours after the last movement update. The default is 24 hours.

In Trip Tx (0-7620 s):

The time between status updates when in-trip. Set to zero to disable these updates entirely. Note that in Europe, radio regulations will prevent the effective time between transmissions from dropping lower than about 140 seconds when using the lowest data rate. The default is 10 minutes, to improve the response time when testing, but a more conservative value on the order of an hour makes more sense in terms of battery life.

+ After Hours:

The time between status updates when in-trip, and after-hours. This allows you to specify different detail levels outside of normal working hours. You can use it to save battery by not tracking non-business trips, or to provide detailed tracking in the event of theft. Set to zero to disable in-trip fixes when after-hours. The default is 10 minutes.

Trip End Timeout (0-2550 s):

The time required before a trip ends, if no movement is detected. Set to zero to disable trip tracking entirely, which saves a small amount of power by disabling the accelerometer. You will still get heartbeat fixes with the trip tracking disabled. The default is 5 minutes.

Tx On Start:

When set, a status update is scheduled at the start of a trip. The default is true.

+ After Hours:

When set, a status update is scheduled at the start of a trip when the trip is after-hours. You can use this to implement theft alerting. The default is true.

Tx On End:

When set, a status update is scheduled at the end of a trip. This lets you know where the asset is, with one caveat - if the destination is under cover, it may have no GNSS signal, resulting in a transmission, but no position update (it is useful to enable WiFi scanning to mitigate this scenario). The default is true.

+ After Hours:

When set, a status update is scheduled at the end of a trip when the trip is after-hours. The default is true.

Disable Wake Filter:

Disables the additional wakeup filter during work-hours. After a force exceeds the configured threshold and duration, it passes through a fixed filter. This filter prevents trip starts if the forces aren't sustained (frequent and short, or infrequent and long). Disabling it allows trips to start even for momentary forces. The filter is enabled by default.

+ After Hours:

Disables the wakeup filter after hours. The filter is enabled by default. 

Random Tx Delay:

Random wait time before tx, to improve network capacity when very many units move simultaneously. Default is 8 seconds.

Basic LoRaWAN

Region:

This selects the radio frequencies to use according to your country. Please be sure to select the correct region, to maintain compliance with your country's radio regulations. Yabby Edge LoRaWANs leaving the factory are currently pre-configured for either the European 868 MHz band, US915 or AS923 1.0.3, depending on their hardware type. However, this is subject to change, and in the future the region may be left unset. If the region is unset, the device will not transmit until configured. Otherwise, to prevent the device from transmitting before configuration, start the provisioning tool, and plug the cable into the device within 5 seconds of inserting the batteries. The region cannot be reconfigured over the air.

Next to the region you will see the associated LoRaWAN Regional Parameters revision. Currently only AS923, US915 and AU915 have multiple revisions to choose from:

•  In AS923, the 1.0.3 version uses both SF10 and SF9 for join requests, rather than just SF10 in the 1.0.2 version
•  In AS923-1, the latest version of AS923, the 'downlink dwell time' restriction is off by default
•  In AU915, the 1.0.3 version supports the new 'uplink dwell time' restriction, so it joins at SF10 instead of SF12
•  In US915, the 1.0.3 version uses a smarter join channel sequence and allows greater power reductions

Sub-Band / Channel Mask:

In fixed channel regions (US915 and AU915) you can select a sub-band or channel mask, instead of using all 72 channels at startup. Strict compliance with the LoRaWAN standard requires enabling all channels, but if you are confident that your network will not change its operating frequencies, choosing a sub-band speeds up the join process. If you choose a custom channel mask, the hex string you must provide has the lower numbered channels on the right hand side. For instance, 010F in hex is 100001111 in binary, and selects channels 0-3 and 8. On some older network servers, choosing a sub-band might be mandatory to avoid packet loss. The default is 'All'.

Activation:

This chooses between the default (and recommended) Over The Air Activation, and Activation By Personalization. In OTAA, the Yabby Edge LoRaWAN and the network server generate the session encryption keys and device address during a join request / join response exchange. In ABP, you have to generate the encryption keys and device address beforehand, and configure them. When choosing ABP, you also have to choose your LoRaWAN version.

Reset FCnts:

This option is available in ABP 1.0 only, and resets the uplink and downlink frame counts whenever the device is reset. This defeats the encryption entirely, but is required by many networks in LoRaWAN 1.0, so that the network server can detect the device reset and reconfigure the device's channels. It is vital that you pick the setting appropriate to your network, or your device may stop connecting after a reset. If you're not sure, you should probably choose 'Yes'. The default however is 'No', for strict compliance and security.

JoinEUI / AppEUI:

In OTAA, this identifies the server your device is registered with. If you don't set a custom JoinEUI, the default for the Yabby Edge LoRaWAN (70-B3-D5-70-50-00-00-09) will be used. In LoRaWAN 1.1, changing the JoinEUI resets the cryptographic counters used by the join server (RJCnt1, DevNonce and JoinNonce). So if you reset the counters on your join server without changing the JoinEUI there, you can reset them on the device by choosing a temporary JoinEUI, writing it to the device, and then configuring it back again.

NwkKey (1.1) / AppKey (1.0):

In OTAA, this 32 character key authenticates the Yabby Edge LoRaWAN with the network server. If you don't set a custom key, the device will use a unique random key, which was written to it in the factory. This default key can be read from the DevEUI list dialog, or the label on the box. It is not printed on the device's label. This key cannot be reconfigured over the air. Please note that this key was renamed by the LoRaWAN standard in the 1.0 to 1.1 upgrade, in the most confusing way possible. So the label on your device will either read AppKey (with no version number), or NwkKey.

AppKey (1.1):

In OTAA, this 32 character key authenticates the device with the LoRaWAN 1.1 application server. This key isn't needed in LoRaWAN 1.0. If you don't set a custom key, the device will use a unique random key, which was written to it in the factory. This default key can be read from the DevEUI list dialog. If your device is new enough, it will be written on the label on the box. On older devices, only the AppKey (1.0) is on the label.

Device Address:

This 8 character number identifies the device with the network server. It is only applicable to ABP activation.

FNwkSIntKey / SNwkSIntKey / NwkSEncKey / AppSKey:

These are the 32 character ABP session keys. Only the first and last are required in LoRaWAN 1.0. They may be referred to as the Network Session Key (NwkSKey) and Application Session Key (AppSKey) on your network server.

Advanced LoRaWAN

Adaptive Data Rate:

ADR is a server side mechanism for controlling the data rate, to optimize network capacity and battery life. By default, the Yabby Edge LoRaWAN only requests ADR when out-of-trip. When in-trip, it controls its data rate according to the configured range. Once the trip ends, it switches to its lowest configured data rate and maximum power, and begins requesting ADR from the server. Thereafter, the network server will configure it to a lower power mode if appropriate. You may wish to instead force ADR on at all times, in order to control it using a policy on the network server. It is also possible to force it off at all times, but this can lead to issues on older network servers.

Min / Max Data Rate:

These parameters select the minimum and maximum data rates to transmit at, when ADR is not active. A '0' selects DR0, the lowest data rate with the longest range. If you set both parameters to the same value, the device will always use that rate. If you choose a range, the device will alternate between the allowed data rates in such a way as to spread the transmit time evenly. This means it will use the higher data rates more often. Using a range of data rates allows the network to support more devices per gateway, but reduces your guaranteed range to the range of the highest data rate. Using higher data rates may allow you to send more messages per day. Please see the section 'How The Yabby Edge LoRaWAN Uses Airtime' above. The default is DR0-DR2.

Roaming Rejoin Uplink Period / Time Period:

This sets the initial maximum number of uplinks / minutes between Rejoin0 Requests in LoRaWAN 1.1. These requests facilitate roaming, and can be reconfigured by the network server at runtime. The default values are the maximums, effectively disabling these requests until the server asks for them.

Rejoin / Reset Time Period:

By default, the Yabby Edge LoRaWAN rejoins the network one week after the last downlink was received, in case the network server has somehow forgotten the session keys. This period can be extended to up to 255 days, or disabled entirely (0). However, if a device is accidentally deleted on the network server, or the network server suffers a database failure and loses the session keys, the server will be unable to decrypt any device data until it has rejoined. Rejoining weekly generates several extra transmissions, but lowers the time spent out of service in the event of an accident. The exact rejoin behavior depends on the Activation and LoRaWAN version:

• In ABP, the rejoin is equivalent to removing and reinserting the batteries. All protocol state is reset, with the exception of the uplink and downlink counters (unless you have chosen to reset them as well, in LoRaWAN 1.0.) The rejoin is only performed if there have been no downlinks for the configured period. 
• In OTAA 1.0, the rejoin is also equivalent to removing and reinserting the batteries. A regular Join Request will be sent. The rejoin is only performed if there have been no downlinks for the configured period.
• In OTAA 1.1, a Rejoin1 Request is used to rejoin without resetting any protocol state. Please note that older network servers might not support this mechanism. The rejoin request is sent even if downlink traffic was seen.

ADR Ack Limit / Delay:

This parameter controls the number of uplinks between checks that the server can still hear the device when ADR is active. The device starts asking for a response once the Limit is reached, and if no response if heard after Delay attempts, the device switches to a lower data rate. The default values (64 and 32) are very slow. Please consult your network support before choosing more aggressive settings, as they may have policies forbidding lower values. In LoRaWAN 1.1, these values can also be set dynamically by the network server.

Receive / Join Delay:

These setting control the timing between a request and a response on the network. You shouldn't change them from the defaults unless instructed to by your network. The defaults are 1 and 5 seconds respectively.

Repetitions:

This sets the default number of frame repetitions (called NbTrans in the standard). Usually this value is one, until the server requests a higher number. You shouldn't change this value unless you have special requirements (for instance, a transmit-only ABP configuration).

Tx EIRP Limit:

This setting restricts the transmit power to the given value, in dBm EIRP. This allows you to save a small amount of battery on the transmission, and limit the peak current draw from the batteries. Limiting the current may be useful in extreme cold weather (less than -20°), where lithium batteries begin to struggle. A setting of 8 dBm drops the peak current from 120 mA down to 70 mA. Lower values are not recommended. Your network server may require knowledge of the maximum power to correctly operate its ADR algorithm. In this case, be sure to configure the device accordingly on the server. The default is maximum power.

Scanning

Scan Order:

Selects a scanning strategy, from which the data to send is chosen. Default is WiFi + GNSS Fallback. If sufficient WiFi signals are seen, the device will skip the GNSS scan entirely. This is usually what you want, since it indicates you are indoors, and WiFi is more accurate than GNSS when indoors. However, WiFi and GNSS scans use about 6x less energy than LoRaWAN uplinks, so it is also reasonable to scan both signals, and send only the best one.

Send Order:

After position data is scanned, this parameter chooses which components to send. This setting exists to help you limit the size of uplinks, and save battery. If you choose Best signal only, and both WiFi and GNSS were scanned, the device will discard the least promising scan results. Otherwise, it will try to send both, prioritizing the chosen scan. The secondary scan will be discarded if there isn't enough space left in the uplink to send it. Default is GNSS then WiFi, to give you the best chance of resolving a position.

GNSS Aiding Mode:

When Aiding is enabled, GNSS sensitivity increases roughly 14 dB, which is very significant. However, the device must downlink about 20 bytes of aiding data per day. 'Autonomous + Time' disables the almanac aiding, reducing the downlinks. 'Autonomous no Time' further disables the GNSS time aiding. If the device isn't configured with any other time dependent behavior (such as after-hours, scheduled uploads, and uplink fragmentation), it can then avoid requesting real time clock updates, saving battery power. The GNSS solver will then use the uplink reception time as a starting point when solving for the position and time. Default is Aiding Enabled.

GNSS Scan Effort:

Chooses between a best effort, high power scan, and a lower power scan. The default is best effort. The lower power scan uses half as much power in no-signal conditions, but has difficulty finding satellites when the sky view is obstructed.

Filter Short-Lived APs:

Filters out access points that have been on for <2 days. These are usually mobile phone WiFi hotspots. However, after a power outage, all nearby access points will have short uptimes. Default is to send.

Filter Non-Global APs:

Filters out access points with 'local' MAC addresses. These are usually mobile phone WiFi hotspots. Default is to filter.

Filter Guest APs:

Filters out access points with very similar MAC addresses. These are usually duplicate guest access points. Default is to filter.

Fallback Threshold:

Scanning falls back to the secondary method if the first scan results are less promising than this threshold. For GNSS, a threshold of zero means 'just barely resolvable'. For WiFi, a threshold of zero means 'single access point detected'. Since some WiFi data providers require a minimum of two access points, and GNSS is unreliable on the lowest setting, the threshold should generally be larger than zero. The default is 3. 

WiFi Scan Time:

Time to spend scanning each WiFi channel. Access points usually send a beacon every 102 ms, so the minimum scan time is 105 ms. Using a longer scan time improves the chance of detecting access points, but uses more battery. The default is 210 ms/ch.

Max APs to Scan:

Maximum WiFi access points to scan. Since some access points might be far away or non-global (ie. filtered out), it is best to scan more access points than you send. The default is 21.

Min APs to Scan:

The minimum number of access points to send when sending WiFi data. Since some WiFi data providers require at least two access points to perform a lookup, this should usually be two. The default is two.

Max APs to Send:

The maximum number of access points to send when sending WiFi data. Sending more access points increases the chances of the WiFi position lookup succeeding, but each access point increases the uplink size by seven bytes. Since the uplinks are the largest component of the battery usage, and the best access points are sent first, it's better not to send every scanned access point. Seven access points can fit inside a single 51 byte uplink, without fragmentation. Default is 7.

Max Satellites to Send:

Maximum satellites to send. In firmware versions <= 1.4, twelve satellites can fit into two 51 byte uplinks. In firmware versions >= 1.5, twelve satellites will fit together with 3 WiFi access points, or 17 will fit with no WiFi. Default is 12.

Max Bytes to Send:

The maximum bytes to send in a position update payload. This applies to the final update payload, after any fragment reassembly. This gives you more control than the 'Max Satellites' and 'Max APs to Send' parameters, but in most cases it is best left at the maximum value. Default is 282 bytes.

Uplink Fragmentation:

Disabling fragmentation simplifies uplink decoding on the server, but limits the uplink size as a function of the region and data rate. It isn't possible to fit more than a single WiFi access point in an 11 byte packet, and you can only fit the bare minimum satellites in 51 bytes. So uplink fragmentation is essential for lower data rates. Default is 'If Required'.

Accelerometer

Wakeup Threshold (0.031-0.5 G):

This sets the amount of force, in increments of 63 mG, that will wake the accelerometer up. Setting it too high might result in trips being missed. Increase this value if you have a problem with small vibrations setting off spurious trips. The default is 0.094 G.

Wakeup Duration (10-1000 ms):

This is the required time duration of the force that will wake the accelerometer up. Increasing this value will make the accelerometer less sensitive to short, sharp forces, but increases the chances of a trip start being missed. The default is 100 ms.

Sampling Mode:

Low power mode has the longest battery life, but isn't very accurate. The minimum wakeup threshold in Low Power mode is 0.078 G, compared to 0.031 G in High Resolution mode. The default is Low Power.

Sampling Rate:

Higher rates may help to catch shorter events, but use more battery. The lower μA range is for Low Power mode, and the upper for High Resolution. Default is 10Hz / 4-5 μA.

Timezone

Timezone:

This is the timezone used for after-hours calculations. The default is UTC.

DST Shift:

This is the amount of time that the clock shifts during daylight savings time, if applicable. It applies only to the after-hours and scheduled uploads calculations, and will usually be one hour, or zero to disable daylight savings. The default is disabled.

After Hours

Mon / Tue / ... After Hour Start / End:

These parameters allow you to specify which times are after-hours, for the purpose of applying different trip tracking parameters at those times.

Set both the start and end parameters to 00:00 to disable (default).

Set the start to 00:00, and the end to 24:00, to make the entire day after-hours.

Setting a start time to before the end time makes the intervening times after-hours.

Setting the start time to after the end time makes the times between 00:00 and the end time, and between the start time and 24:00, after-hours.

Scheduled Uploads

Scheduled Uploads 1-12:

A heartbeat can be configured, with up to 12 slots, to log a heartbeat at a specific time of the day. This time is set in local time (using the configured timezone and DST) with 7.5 minute intervals. The upload will occur within a variance period of 10 minutes. By default the slots are disabled (00:00:00).

Inactivity Indicator

Inactivity Timeout:

The inactivity indicator is a bit in the Yabby Edge LoRaWAN's location message uplink which shows if the device has stopped moving for a configurable time. This can be used to detect if an asset has been idle for a few weeks, a car has been stopped for a few hours, or if livestock have died. The timeout can be set from 10 minutes to 21h10m, in 10 minute increments, or from 1 day to 63 days 12 hours, in 12 hour increments. A value of 0 disables inactivity indication. The default is disabled.

+ Tx On Set:

This chooses what action to take when the inactivity indicator bit becomes set. You can choose one of:

• Do nothing - the bit will upload when the next heartbeat is sent (default)
• Transmit once, assuming the network connection is ready (join has been successful)
• Keep retrying (with backoff) until the network connection is ready, then transmit once

The current firmware only supports unconfirmed uplinks, even when retrying.

+ Tx On Clear:

This chooses what action to take when the inactivity indicator bit becomes clear, and is configured as above.

+ Inactivity Heartbeat (0-7620 mins) :

The time between status updates when the Inactivity indicator is active . Setting to 1.00:00 results in at least one status update per day. The default is disabled (0). If this heartbeat is enabled, it will override the general configuration heartbeat above if a shorter heartbeat time is set.

Battery Statistics

Uplink Period:

Time between stats uplinks, +-12%. Zero disables. Default is 4 days.

Battery Capacity:

Battery capacity used in network server (DevStatusReq) battery reports and self discharge calculations. Zero disables. Default is 1100 mAh.

Self Discharge:

Battery self discharge, typically 1-3% per year, depending strongly on temperature. Default is 3.0% per year.

Battery Chemistry:

Please note that alkaline batteries are not officially supported, and should be de-rated 50% in the battery capacity parameter, with a corresponding 100% increase in the self discharge. Alkaline batteries are notoriously unreliable, and can't maintain maximum transmit power for long, so please use lithium wherever possible. Default is 1.5v lithium. 

Uplink Fragmentation

Minimum Uplinks:

Minimum uplinks to send in a position update. Default is 1. This results in most WiFi-only scans being sent in a single uplink. If you want some redundancy for these, you can increase it to 2.

Maximum Uplink Size:

Maximum size of individual uplinks in a position update message. Default is 222 bytes. Usually the uplink size is already limited by the current datarate (typically to 51 or 115 bytes). This parameter can be used to apply a further limit for test purposes, or to work around packet size limits in faulty network servers.

Loss Tolerance:

Uplink packet loss to tolerate when fragmenting. Default is 20%. This leads to a two uplink message (such as a typical GPS scan with 51 byte uplinks) being expanded to 3 uplinks. This message would be successfully decoded if 2 out of the 3 uplinks were received.

Almanac Management

The settings in this section are for fine tuning some very technical details of the almanac download protocol. Most users won't need to touch them. You should generally only modify them if advised to by customer support.

Download After:

Minimum almanac age before a new download begins. Default is 21 days.

+ Randomization:

Random component of download threshold. Default is 14 days, leading to a new download every 3 to 5 weeks.

Request Period:

Nominal time between almanac requests. This sets a lower bound on the download speed, as at least one chunk of almanac will be requested every time the period expires. However, if there is ongoing LoRaWAN traffic (due to heartbeats or trip tracking), the download will piggyback on that traffic, and complete faster. Downloads will also proceed much faster in the first 24 hours after battery insertion. Default is 12 hours.

Retry Time:

Base time between almanac request retries. After waiting one Request Period, making a request, and getting no response, the device will wait at least one Retry Time or the configured number of Retry Frames before retrying.If it continues to get no response, it increases the retry time. Default is 1 hour.

Retry Frames:

Downlink opportunities between almanac request retries. If an almanac request gets no response, there is a time limit (the Retry Time above) before retrying the request. However, if there is a lot of incidental LoRaWAN traffic between requests (in other words, many opportunities for the server to send a response), but no response is seen, the device retries sooner. Default is 3 downlinks.

Connection Check:

Time between failsafe connection checks. These checks verify the device's connection to the almanac server, and allow the protocol to recover in the event of corrupted server state. Zero disables. Default is 28 days.

Time Request Period:

Base time between aiding requests. The default 6 days maintains the accurate time required for aided GNSS scans. If you aren't using aided scans, but are using fragmented uplinks, after hours, or scheduled uplinks, which require a coarse time, you can increase the period. Decreasing the period is not recommended.

Max Time Retries:

Time requests back off when out of coverage. Increasing this gives more aggressive retries initially. However, the long term average is always 6 request per period. Default is 14 per period.

Downlink MTU

Because the maximum size of a LoRaWAN downlink can change with both the uplink spreading factor, and the settings sent by the network server, the almanac server needs to calculate the maximum size dynamically. If the almanac server and the network server disagree on this calculation (for instance because the network server is using an older LoRaWAN standard), almanac downlinks could stall. This section allows you to work around any issues with your network server by reducing the calculated downlink size. In normal installations, this won't be necessary.

Reduction (scale):

Percentage to reduce the maximum downlink sizes. Default is 0%.

Reduction (offset):

Bytes to further reduce the scaled maximum downlink sizes. Default is 0 bytes.

Limit:

Maximum downlink size, applied after reductions. Zero disables. Default is 0.