3.0 Introduction

image.png

  • There are literally thousands of different types, with a vast array of capabilities, costs and features, so this raises questions, such as:
    • Which micro controller/ microcomputer should we use?
    • How do we get them to talk to the Internet and “Cloud”?
    • What’s the difference between a microcontroller and microcomputer？

  • We will be able to:

    • Select a microcontroller based on a set of requirements;
    • Specify and select communication protocols dependent on a set of requirements;
    • Understand microcontroller to mircrocontroller communication;
    • Understand microcontroller to computer/Cloud communication;
    • Differentiate between Fog, Edge and Cloud processing;

      3.1 Microcontrollers and microprocessors

  • Almost all electronics equipment contains either a microcontroller or microprocessor.

  • Most IoT systems utilise microcontroller units (MCUs) to collect data and transfer it to the processing units through the Internet.
    • They are relatively simple, as MCUs do not require an operating system to function and are easy to interface with external coponents such as sensors.
    • A MCU is usually sufficient to provide processing power and functionlity in most IoT systems, thus making them economically viable for IoT applications.
    • Due to their simplicity, MCUs are less vulnerable to security attacks

  • A microprocessor is a micro version of our computers, hence the name “microprocessor”.

    • We can see that generally, if an application requires a form of Operating System, a microprocessor is normally used.
    • A good example is our smartphones, which often use ARM microprocessors.

      Microcontrollers VS Microprocessors

  • The main differentces between a microprocessor and a microcontroller are:

    • A microcontroller is “all in one”: the processor, RAM, and IO are all on the one chip -as such, you cannot(for instanc) increase the amount of RAM available or the number of IO ports. The controlling bus is internal and not available to the board designer.
      • Central Processing Unit(or CPU)
      • System Clock
        • It is derived from an Oscillator
      • Memory
      • Peripherals
    • A microprocessor generally does not have on-chip RAM, ROM, and few GPIO pins. It usually uses its pins as a bus to interface with RAM, ROM, serial prots, digital and analogue IO, etc. As such, it is expandable at the board level.

image.png

3.2 Selecting a microplatform

Mircrocontroller or microprocessor?

  • The first choice you need to make when designing an IoT solution is obviously whether to use a microcontroller or microprocessor. In many cases this simply comes down to asking the question: “Do I need an Operating System”
    • When they are used, operating systems for IoT hardware are often categoriesd into two groups: end devices an gateways
      • End devices, or nodes, are often small and low power(both in energy and processing)
      • Gateways often control communication to the Cloud, or handle signicficant processing themselves

  • There are a sort of key aspects to consider when selecting a micro.

    • Power consumption
      • Most IoT devices will be placed in the field running on a small battery. We would like the devices to run for weeks, days or even years on a single battery.
    • Connectivity options
      • For example: Bluetooth, LoRa, 802.11 Choosing the IoT connectivity comes with its own set of choices, dependent mostly on power and range required
    • Development boards and kits
      • Many IoT development boards are prototyping solutions that feature low-power processors and support various programming environments such as C, Python, Scratch, etc. These platforms are generally used to collect sensor data using firmware and transfer it to an on-site or cloud-based server.
      • There are more powerful hardware prototyping platforms based on microcomputers, such as the Raspberry Pi and BeagleBoard. Such microcontrollers are enhanced with multiple core processors, may run an operating system, and support multiple types of peripherals.

        How to choose?

  • What we choose will depend on :

    • The requirements of your project, and
    • Your test results

  • Utillisng off-the-shelf components can speed up the development process.

    High-level capabilities

  • We can characterise IoT devices in terms of these hight-level capabilities, includng:

    • Power management
    • Sensors and actuators
    • Processing capability
    • Connectivity

      Power manangement

  • Several aspects impact a device’s power requirements, including:

    • the clock rate of the CPU
    • number of processor cores
    • included peripherals(USB, Bluetooth, Ethernet ports)
    • processor load
    • supply voltage levels

image.png

Sensors and actuator

  • As we have seen, sensor and actuators are the way our IoT solutions interact with the world.

  • Sensors

    • In order to make use of the information detected by sensors, it is necessary to convert these measurements into digital readings.
      • Data Acuisition is the process of measuring real-world conditions and converting these measurements into digital readings at fixed-time intervals (the data sample rate).
    • We also need to apply some forms of signal contitioning to filter usable data from the signals (i.e. remove noise) and scale raw sensor readings.
    • Data is often read by analogue-to-digital converters and actuators controlled by digital to analogue converters (motors)
    • When selecting a micro for our prototype system, the resolution of the sensor and the required accuracy of our solution must be considered.
      • The resolution of a sensor represents the samllest amount of change that the sensor can reliably read, and is related to the size of the numeric value that is used to represent raw sensor readings.
    • In practical systems, sensors are affected by electrical noise, which usually requires us to build in a higher resolution than the minimum illustrated here.

      Actuators

  • Output devices or actuators convert an electrical signal to a physical action.

  • When designing a system, we need to consider the prots necessary to drive these devices.

    Processing capability

  • There are two main approaches to how, and more importantly, where we process our data:

    • Transmit the data to other devices, gateway devices, or cloud services or apps for aggregation and analysis.
    • Process the data locally in the IoT device(or perhaps on the gateway device).
  • The “Cloud” based solution is to transmit possibly large volumes of data ot a cloud server or data center for analysis.
  • The “Edge” approach involves performing data analysis at the edges of a network whre the data is captred, rather than in a centralised or Cloud location.
    • Processing data at the Edge provides an opportunity to aggregate and filter the data as it is collected, with only the most salient data being transmitted to the cloud.
    • Processing data at the Edge has the advantage of reducing the required network bandwidth at the cost of requiring a significantly more powerful processor within the IoT device.
  • The amount of memory that is available, and the specifications of the processor, determine the rate at which data can be processed by teh device. The capacity of the non-valatile flash memory, used to store data until it can be transmitted, determines how much data can be stored on the device.

  • Devices performing Edge processing will require substantially more processing capabilities than devices that perform only basic data processing, like validating, scaling, or data conversion.

    Connectivity

  • Our microcontroller needs to talk to our sensors and actuators and also connect to the Internet, either directly or via a gateway/concenrator.

  • Solutions may use:

    • Wireless links, e.g. 802.11WiFi, Bluetooth, Low Power Wide Area Network(LPWAN), LoRa and SigFox;
      • has the flexibility of being mobile, however, power consumption, restricted range and low data rates and throughput are a limitation with these technologies.
    • Wired links, e.g. SPI, I2C, Ethernet, RS232.
      • overcome some of the limitations of wireless, in particular the data rates and power efficiency, but can require significat infrastructure to be installed.
      • are well suited ot stationary devices such as samrt housing and industrial manufacturing lines.

        Prototyping boards

  • There are a growing range of off-the-shelf prototyping kits now available, many specifically designed for IoT developement.

  • Many of these microcontrollers and microcomputer are designed around System-on-a-Chip(SoC) ICs.
  • SoCs bundle a number of capabilities onto a single chip, including
    • data processing
    • storage
    • networking
  • https://www.ubergizmo.com/what-is/system-on-a-chip/

  • For example:

    • Arduino Uno
    • Raspberry Pi

      Microcontroller and MicroComputer development boards

  • Microcontroller development boards contain a processor, random access memory(RAM), and electrically erasable programmable read-obly memory(EEPROM) for storing the custom programs that run on the microcontroller.

    • Development boards are PCBs (printed circuit boards) with additional circuitry to support the microcontroller, to make it more convenient to prototype with and program the chip.

image.png

  • MicroComputer development boards in most cases they are much more powerful with a faster CPU, greater RAM, and a variety of I/O devices, such as USB, Ethernet, WiFi, and HDMI for screens, built-in than Microcontroller.

image.png

  • Be aware that these devices tend to have limited GPIO, often do not include ADCs or DACs, and consume significantly more power.

    Do I need an Operating System?

  • If your application requires less than 16 kilobytes of RAM or Flash(usually an 8 or 16 bit micro) and can be implemented in a single loop, an operating system is probably not necessary. However, with the ever-reducing costs of hardware, even simple application are now including an OS.

  • Things to consider when choosing an embedded OS

    • Memory Footprint
    • Security
    • Modularity/Compatibility
    • Support and Reliablility

      Programming and selecting a “language”

  • Arduinos have great libraries and support for the C language.

  • Raspberry Pi are well suited to python(but as they run Linx, they support many languages)

  • ….

    3.3 Sensor communication

    Asynchronous serial commncation

  • In asynchronous serial communication, transmitter and receiver manually agree on the data rate, and each manage the timing independently with no common clock.

  • The data rate for the transmitter seding pulses is the same as data rate for the receiver listening for the pulses.
    • data rate
    • voltage level corresponding to 1 bit or 0 bit
    • signal voltage level interpretation; whether high voltage=1 and low voltage=0, or high voltage=0 and low voltage=1, for inverted signals.
  • Asynchronous communication is suitable for connecting microcontrollers that can manage the time signal independently of each other, using their internal clock.
  • The two most popular asynchronous serial communications are RS-232 and USB

image.png

Synchronous serial communication

image.png

  • In synchronous serial communication, a clocking system manages the synchronisation between the transmitter and receiver. The clock is either embedded as part of the data frame, or a separate clock wire manages the timing during transmission.
  • All devices i nthe communication line share the same clock data, and with every clock pulse one bit moves inteh line; therefore the clocking system directs devices regarding when to listen to the coming bits and when to discard them.
  • This type of communication is sed for simpler devices with noe internal clock crystal and few memory registers.
  • The two most common synchronous serial ocmmunications are Inter-Intergrated Circuit(I2C) and Serial Peripheral Interface(SPI)

image.png

  • According to the distinctions between I2C and SPI, it may be concluded that:

    • I2C is more suitable when there is a large number of peripherals and a high data rate is not required;
    • SPI is a good option for applications that require low power and high speed.

      3.4 Connecting up the system

      Packet Tracer: Connecting sensors and micro-platforms

      3.5 System communication

      Overview of how sensor data travles from device the Cloud.

      https://readwrite.com/2015/10/13/sensor-data-device-to-cloud/

      Sensor to Cloud commnication protocols

  • Ehernet

image.png

  • Wireless

image.png

WIreless communication introduction

image.png

  • From smallest ot largest networks, there are:

    • Personal Area Network(PAN) and Wireless Sensor NetWork(WSN);
    • Wireless Local Area Network (WLAN)
    • Wireless WIde Area Network(WWAN)

      PAN and Wireless Sensor Network (WSN)

  • Bluetooth | Name | Bluetooth | | —- | —- | | Standard protocol is based on | IEEE802.15.1 | | Designed for |
    - Wireless ad-hoc connectivity that operates in 2.4 GHz ISM
    - With low power consumption
    - M2M (can be used for microcontroller to microcontroller communication)
    | | Connection range | short range, 1-100 metres | | Data rate | 1Mbit/s | | Example | Wearable sensors transmitting data to a smart phone |

  • 6LoWPAN | Name | 6LoWPAN | | —- | —- | | Standard protocol is based on | IEEE802.15.4 | | Designed for |
    - Extends the use of Internet Protocol for low power devices with limited processing capabilities in a Personal Area Network (PAN)
    - M2M (can be used for microcontroller to microcontroller communication)
    | | Connection range | 10s (tens) of metres | | Data rate | maximum data rate of 250kbps | | Example | smart meters in a small network |

Wireless Local Area Network (WLAN)

  • WiFi | Name | WiFi | | —- | —- | | Standard protocol is based on | IEEE802.11 | | Designed for |
    - Extend the Ethernet communication for wireless devices in Local Area Network (LAN)
    - Operates in 2.4GHz (ISM band) or 5GHz (U-NII band)
    | | Connection range | different coverage area depending on building structure or geographical area | | Data rate | 54Mbps – 600Mbps | | Example | IEEE802.11 has two operation modes: Ad-Hoc and Infrastructure.
    In Ad-Hoc mode, devices are directly connected to each other; and in Infrastructure mode, wireless clients (Stations, STA) are connected through the Access Points (AP), forming a Basic Service Set (BSS). The BSSs are associated together via a wired Distributed System (DS) to form Extended Service Set (ESS). |

WIreless Wide Area Network (WWAN)

  • The Mobile network evolution starting with 1G, and progressing to 2G, 3G and 4G as the lastest technology.

image.png

  • GPRS | Name | General Packet Radio Services (GPRS) or 2.5G | | —- | —- | | Standard protocol is based on | a packet switching data transmission standard | | Designed for |
    - Mobile network and an extension to GSM (Global System for Mobile Communications)
    | | Connection range | Kilometres (depends on terrain) | | Data rate | 64 -114 Kbps |
  • LTE(Long Term Evolution)
    • LTE is based on Universal Mobile Telecommunication System(UMTS) and GSM network technologies. It is a 3G cellular network system that support high data transmission rate for multimedia applications. | Name | LTE | | —- | —- | | Standard protocol is based on | 3G cellular network system | | Designed for |
      - To increase the data rates available in 3G network technologies, Long Term Evolution (LTE) is designed as a series of 4G standards
      - LTE architecture eliminates the need for RNC (Radio Network Controller) and uses Evolved Node B (eNB) that adds control and management functionalities to each base station
      | | Connection range | Kilometres (depends on terrain) | | Data rate | 150Mbps (LTE-A with 1Gbps and LTE-A pro with 3Gbps) |

LPWAN (Low Power WIde Area Network)

  • LoRa | Name | LoRa | | —- | —- | | Standard protocol is based on | Chirp spread spectrum (CSS) radio modulation technology | | Designed for |
    - For low power and low cost receivers in IoT environment
    - Security in LoRaWAN is handled through network and application layers to make it a rather secure protocol
    | | Connection range | Kilometres (greater than cellular) | | Data rate | 0.3-50 Kbps |
  • Sigfox | Name | Sigfox | | —- | —- | | Standard protocol is based on | Ultra Narrow Band (UNB) ISM radio band | | Designed for |
    - Uses Ultra Narrow Band (UNB) to transmit information between low power devices operating at 868 MHz frequency band, that divides the spectrum into 400 of 100 Hz channels
    | | Connection range | 30-50 km for rural areas, and 3-10 km for urban areas | | Data rate | 100bps, with a limit of 140 messages per day for each end device |
  • Weightless | Name | Weightless | | —- | —- | | Standard protocol is based on | 3 Weightless standards | | Designed for |
    - Uses the low frequencies unused spectrum band with high propagation signal and low output power
    | | Connection range | 2-10k – see below | | Data rate | Depends on standard - see below (200bps – 10Mbps) |

https://www.slideshare.net/DuncanPurves/low-power-wireless-technologies-and-standards-for-the-internet-of-things

3.6 Cloud, Fog, and Edge processing