---
# System prepended metadata

title: Design Spec
tags: [ugs]

---

---
title: 'Design Spec'
disqus: hackmd
tags: ugs
---


Design Spec
===

## Overview

### Requirements

##### Functional Requirements (FRs)

1. Power components (battery life) of the device for at least **6 years**.
    * Provide correct voltage to components.
    * Notify the user that the battery needs replacing.
    * Update interval: 24 hrs 
2. Control components of the device using required interfaces.
    * [x] UART
3. Upload sensor data 
    * liquid gas level
    * battery level 
    * connection signal strength
4. Provide gas level with ±1%FS (full scale) measuring error.
5. Custom gas level threshold alarm 


##### Constraints (Cs)

1. Device must be compact and rugged.
    * For a proof of concept, the device will bigger than a device ready for market.
    * To achieve a small size of a device it will be built using Surface Mount Design components on a PCB. The PCBs will be **2-layer** to keep the cost down.
    * As a reference, the prototype PCB size will be less than **80×50x25 mm**
    * With battery and enclosure, the device can not weigh more than **200g** 
2. Device must use NB-IoT communications to report sensor data.
    * Because the project is to evaluate the performance of NB-IoT enabled gas level detecting device.
3. For cost concern, eSIM (embedded, 6x5 mm) would be applied essentially.

![](https://i.imgur.com/UlNXBVM.png)

##### Design Parameters (DPs)

1. Battery - To provide power to the device. 
    * [x] 18650  lithium-ion rechargeable battery
    * Power regulators - To provide correct voltage to components.
    
    
2. Microcontroller (MCU) - Controller for the device.
    * [x] STM32F030C8T6 (f/w download via SWM or ISP)
    * [AN3155 USART protocol used in the STM32 bootloader](https://www.st.com/resource/en/application_note/cd00264342-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf)
 
3. NB-IoT Modem
    * [x] [WNB303R](https://www.liteon.com/storage/document/template/wnb303r_module_datasheet_hv33%20v05.pdf)

4. Level sensor
    * [x] TNK ultrasonic sensor

#### Communications

#### Security


### Hardware

#### Component Selection

##### NB-IoT Modem and Antenna

##### Microcontroller - MCU

##### Level Sensor 

##### Battery

##### Power Regulators

##### Connectors and brackets

##### Small ICs

#### Battery Monitoring

#### PCB Design

##### Top Board - RF BRD

##### Bottom Board - MCU, Sensor circuit

#### PCB Manufacturing

#### Enclosure

#### Issues

##### MCU Boot

##### SIM Card

##### UART Interface

##### Incorrect Voltage Level

##### Power consumption of WNB303R modem

**PSM (Power-saving Mod)**

![PSM](https://www.avsystem.com/media/iot_energy-09(1).jpg)

### Firmware

#### Simple software and communicatiom flowchart


#### Device Module States Cycle

```mermaid  
graph LR;
    S((Start)) --> A((DeviceOn))
    A --> B((ToDeploy));
    B --> C((SensorChk));
    C --> D((DeepSleep));
    D --> C;
    C --> E((Error));
    C --> F((Alarms));
    F --> F1((LowLevel)); 
    F1 --> D;
    F --> F2((LowBatt))
    F2 --> D
    F --> F3((PoorSignal))
    E --> E1((Level N/A));
    E1 --> B   
    F3 --> B;         
```


#### Block layout of the hardware components ver. 01

```mermaid  
sequenceDiagram  
 participant A as Ultrasonic Sensor  
 participant B as MCU  
 participant C as Communication Module  
 B->>A: 1.UART Echo
 A->>B: 2.TNK_電量_時間  
 NOTE OVER A,B: note: tbu  
 B->>C: 3.UART(Gas Level, Battery, RSSI)  
 C->>B: 4.Ack  
 NOTE OVER B,C: note:
```

#### Block layout of the hardware components ver. 02

```mermaid  
sequenceDiagram
 participant A as Battery Monitoring Circuit  
 participant B as Ultrasonic Sensor  
 participant C as MCU  
 participant D as Communication Module  
 C->>A: 1.Measure the battery voltage 
 A->>C: 2.voltage    
 B->>C: 3.UART Echo  
 C->>B: 4.TNK_Level  
 C->>D: 5.UART request signal strength  
 C->>D: 6.UART send (gas level, battery, RSSI)  
 D->>C: 7.Ack  
 NOTE OVER C,D: note: reliable mechanism 
```

#### MCU, Modem FOTA

### Software Design

{%hackmd /6EOnAe39Qz2HcVlcNcM5Aw %}

## Our approch

Due to NON-IP is not supported by all network operators, if we plan our product solution to international markets, then NB-IoT with CoAP is a better way to go. Whether we then use LwM2M above or our own protocol layer specified is up to us. LwM2M is again a convenient way, because not only the profiles of the telegrams are regulated there, but also the login to the server and the device management.

* UDP protocol is unreliable, but can be avoided by retransmission mechanism or reliable via CoAP.
* CoAP (over DTLS) --- RFC7252/RFC6347 (this is also the protocol LWM2M based on)
* CoAP provides different message types, CON(firmed) messages uses ACK and retransmissions. CoAP is very similar to HTTP offering REST. In advance, it’s very easy to have both coap-client and coap-server on one peer, that makes bidirectional communication working without additional conventions or specifications.
* DTLS 1.2 RFC6347 uses the ip-address to associate the encrption contect. With that, a "(resumption) handshake" is required. IETF DTLS 1.2 Connection Identifiers would solve this without a new (resumption) handshake.
* If a sometimes lost packet is acceptable, then send 3x UDP packets, then go to sleep. We can store sensor data in flash and retry to send it.

### Update Scheduler


## Reference

#### NB-IoT Signal Strength (RSSI) reference values 

| LTE            | NB-IoT         | Signal Strength |
| -------------- | -------------- | --------------- |
| > -65 dBm      | > -60 dBm      | Excellent       |
| -65 to -75 dBm | -60 to -80 dBm | Good            |
| -75 to -85 dBm | -80 to -95 dBm | Fair            |
| -85 to -95 dBm | -95 to -110 dBm| Poor            |
| < -95 dBm      | < -110 dBm     | Disconnect      |


#### NB-IoT vs. LTE-M 

|                   | LTE-M                             | NB-IoT                             |
|-------------------| ----------------------------------| ---------------------------------- |
| Peak Data Rate    | > 384kbps, up to 1Mbps            | <250 kbps                          | 
| Latency           | 50 - 100 ms                       | 1.5 - 10                           |
| Bandwidth         | 1.4 MHz                           | < 200KHz                           |
| Power Consumption | Best at medium to high data rates | Best at very low data rates        |
| Mobility          | Yes                               | No for Cat-NB1, limited for Cat-NB2|



---

in-progress

* IoT Development Stack and its Requirements
* Device Hardware
* Device Software
* Operating system
* OS applications
* Connectivity

```
Some of the Communication Protocols are -
- Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
- Identification (ex: EPC, uCode, IPv6, URIs)
- Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
- Discovery (ex: Physical Web, mDNS, DNS-SD)
- Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
- Device Management (ex: TR-069, OMA-DM)
- Semantic (ex: JSON-LD, Web Thing Model)
- Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)
```

* Data and Analytics

```
Some of the most popular applications are
- Connected Cars
- Connected Health
- Industrial Internet
- Smart City
- Smart Farming
- Smart Grid
- Smart Home
- Smart Retail
- Smart Supply Chain
-Wearables
```

* IoT Hardware Specification
* IoT Product Development Stages
* * Connectivity and data transmission
* Product Hardware Identification
* Vertical M2M Application
* Software and Cloud integration
* IoT-Capable Application(s)
* Roadmap for IOT Development
* Requirements and functionality
* Bringing on partners
* Proof of Concept & Piloting
* Mass production
* Early product testing
* Product development
* Logistics support
* Lifecycle management
* List of IoT Product Development Services
* Design and Engineering
* Hardware and firmware development
* Prototyping
* Manufacturing support
* FAQs on IoT product development stages
* What is IoT Product development architecture?
* What are the highly used sensor types in IoT product development?
* What are the components required to develop IoT Product?
* Things to consider while choosing right IoT Product Development Company?
* Exemplify top IoT Product Development Solution?