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


##### 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)**

.jpg)

### Firmware

#### Simple software and communicatiom flowchart

#### Device Module States Cycle

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

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

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?