---
# System prepended metadata

title: Questions from Testcases regar

---

#Questions from Quectel regarding Testcases

## Time to data connection

1. In manual mode
    * Usually that means that the deivce was not connected to any network, no cached info on modem side
    * User enables the device via button press
    * 180s timeout
        * For B95
            * We only specify nwscanseq, we don't know actual time allocation of modem for each RAT - eMTC -> GSM -> NB-IoT
2. Automatic mode
    * Device usually remains stationary
        * There are cases where customers mount devices on mobile tanks though (~1%), e.g. on large construction sites
    * Device woke up on it's own via RTC
    * Modem has information about prio connection
    * Might even haven PSM (not for BG95)
    * 120s

### Scanning Mode for NB-IoT
* always restrict bands to bands used by supported PLMNs
    * e.g. if we know that device is in Germany: we enable 8 (Telekom) and 20 (Vodafone)
    * Usually we know that one of those has a rather good connection < -87 dBm
        * Now: we don't know which provider is available at the location without scanning
        * Can we have a quick scan that would only detect a "good connection". We would do that on both bands and if that isn't succesful, we can still do a regular/deep scan
    * We can provide additional EARFCNs
        * We have to check with Vodafone how to get that data

## UDP test cases

1. Send UDP packet CoAP 
    * varying sizes, usually max of MTU (e.g. BG95 we use ~ 1340 bytes)
2. We get response
3. done

1. Send UDP packet CoAP 
2. Timeout <- only after we are registered and have an open PDP context
    * variable backoff
        * Starts with 5s
        * every retry adds 5s
        * up 5 retries
        * after 2nd or 3rd retry we witch IP address
            * We have ~5 IPs saved in flash/hardcoded
        * after 2nd retry we start DNS resolution of coap.oilfox.io
            * We use this IP as well
        * As soon as we get a single response from any server we're good and finished
            
## When packets will be sent
1. In manual mode - triggered by the user
2. In automatic mode - triggerd by RTC e.g. every 4/8/24 hours

## What we currently don't do but might want to in the future
* Sending data do a device that is in PSM
    * This case if to be seen far in the future and not important at the moment
    * e.g. in case someone wants to trigger a measurement from the app 
    * or wants to use the GPS to find a device
* "Offline Measurements" and Change Detection
    * Device wakes up more often than it sends
        * It might compare the data of measurements to find out if there is a change -> Change Detection
        * It accumulates data so we have a finer "data resolution" while not stressing that battery as much as it would do if we send everytime -> this depends on the amount of time required for sending.
            * If we are in PSM mode, and can connect to the network  (signal okay) ~ 2secs
            * Let's assume we start modem connection and measurement process at the same time. (That's what we're doing with BG95)
                * Our current BG95 case
                    * Measurements Process takes ~ 2s (maybe 3s)
                    * Modem connection with good signal strenght ~10s
                        * If we can get the modem connection time down to ~2s - 3s -> I can jsut always send data and don't care about caching data locally. 
                        * Main energy consumption defined by ON time, not what exactly is happening. 
                * What that means for BG772
                    * What is better for the battery lifetime
                        * Waking up the modem everytime we wake up (with and without PSM)
                        * Or only doing an "offline measurement" (which still takes some seconds) and wake up the moment if we now sth changed



# PSM
* 

        
        
        