A popular use case for the Guppy is detecting movement and identifying tampering or unauthorized usage.

This article provides some guidelines for Guppy setup to achieve this. The high level points are:

1. Device configuration: disable the wake filter.
2. How to pick up movement: using the "in trip" flag
3. Why is there a delay?

1. Device Configuration

The key settings in the Guppy configuration are found at the bottom of the configuration app.

• Most important: disable the wake filter by choosing True. Optionally do this for +After Hours too. This setting will wake the device and start a trip immediately on movement, rather than looking for sustained movement.
• Choose your wake threshold and count/time. The default is 2/1 shown in the screenshot. 1/0 will be more sensitive. Higher than 2/1 should be used with caution, at the risk of missing wake ups.
• All other settings are up to the user and depend on the exact application. Refer to the config guide.

2. How the device indicates movement

The device will set the trip status flag when it starts moving. Refer to the Guppy Integration Guide. The platform could indicate a tamper when this changes from 0 to 1.

3. Why is there a delay in sending/receiving the uplink?

There could be a few reasons:

1. Is the device picking up the movement? Make sure the wake filter is disabled. And perhaps lower the wake threshold sensitivity.
2. Does the device have duty cycle available to send the message? Remember that the device will obey the laws of the region. Consider this test in the EU region. A tamper was initiated soon after the join succeeded. The device was unable to send the uplink for 35s until the duty cycle freed up.

CON: Tx Maintenance // device is joining
CON: Tx Maintenance succeeded // device joined
CON: Tx / Rx // device sent an uplink
CON: Tx succeeded
Powering down for 897s
Woke (0x417000/0x80)
CON: ACCEL wake // device woke up
CON: Debounce
CON: DecideTx - enter=1 // device has entered a trip and wants to send
CON: Duty cycle sleep: 35s // device must wait 35s for duty cycle to be available
Powering down for 35s
Woke (0x412000/0x4)
CON: Tx / Rx // 35s have passed. Wake and send.
CON: Tx succeeded // sent, but 35s after the event.

1. Things to consider:
   1. The join uses airtime, and will block the sending of other messages for a while. If you are testing, wait for a few minutes after the join before triggering a tamper
   2. Other messages use airtime. If you have just come out of a trip and sent an uplink, there may not be duty cycle available for a sudden start of trip uplink.
   3. Consider using higher data rates to reduce the air time, which will allow the device to send the next message sooner.
2. Network latency: we typically notice a 2 sec delay for a message to work its way through the system to the end application. This is made up of: device wakes up and logs; device sends (on min data rate, this could be up to 1s of Tx time); network hears the message and moves it to the network server; network server dispatches it to the user application; user application acts on the message.