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.


    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.
  3. 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.