Uploaded August 2018 | Updated September 2026, 2 weeks ago
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 30 of the IOTA tutorial.
In this video series different topics will be explained which will help you to understand IOTA.
It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.
In this video I will demonstrate how to send DHT11 sensor data from an ESP-01S WiFi module to the tangle using MQTT and Masked Authenticated Messaging.
A complete step-by-step guide how to send DHT11 sensor data from an ESP-01S WiFi module to the tangle using MQTT and Masked Authenticated Messaging can be found at:
mobilefish.com/developer/iota/iota_quickguide_esp01s_mam.html
The source code used in the guide can be found at:
github.com/robertlie/dht11-esp01s
ESP-01S (ESP8266) WiFi module specifications:
- Flash memory: 1 MByte
- Max transmission distance: approx. 400 m (direct line of sight)
- Package size: 24.7mm x 14.4mm
- WiFi protocols: 802.11 b/g/n
- Supply voltage: 3.0 to 3.6V
- Operating current (average value): 80 mA
- Comes pre-programmed with an AT command set firmware.
- Operating temperature: -20 deg C to 85 deg C
- Not breadboard friendly
- Number of pins: 8
- Number of GPIO ports: 2 (GPIO0 and GPIO2)
- Not shielded
- One led (blue), will flash when data is transmitted
USB to TTL converter
To upload an Arduino sketch or firmware to the ESP-01S module an USB to TTL Serial converter is needed.
They are also known as USB-TTL converters, USB FTDI converters or FTDI adapters.
FTDI (Future Technology Devices International) is a company who produces the most well-known USB-Serial converter chips.
The USB-TTL converter, converts USB data signals to and from TTL-level serial data.
Serial data is transmitted one bit at a time at a specified data rate (i.e. 9600bps, 115200bps, etc.).
This method of serial communication is sometimes referred to as TTL serial (Transistor-Transistor Logic).
Serial communication at a TTL level will always remain between the limits of 0V and Vcc, which is often 5V or 3.3V.
A logic high ('1') is represented by Vcc, while a logic low ('0') is 0V.
MQTT
MQTT stands for Message Queuing Telemetry Transport and is a publish/subscribe event-driven messaging protocol for constrained Internet of Things devices and low-bandwidth, high-latency or unreliable networks.
MQTT enables messages to be pushed to clients.
The MQTT broker is the central point and is in charge of dispatching all messages between the senders and the rightful receivers.
Each client that publishes a message to the broker, includes a topic into the message.
Each client that wants to receive messages, subscribes to a certain topic and the broker delivers all messages with the matching topic to the client.
The client who publish the data and the client who receives the data don’t have to know each other, they only communicate over the topic.
This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
TCP/IP port 1883 is reserved for use with MQTT.
TCP/IP port 8883 is reserved, for use with MQTT over SSL.
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 30 of the IOTA tutorial.
In this video series different topics will be explained which will help you to understand IOTA.
It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.
In this video I will demonstrate how to send DHT11 sensor data from an ESP-01S WiFi module to the tangle using MQTT and Masked Authenticated Messaging.
A complete step-by-step guide how to send DHT11 sensor data from an ESP-01S WiFi module to the tangle using MQTT and Masked Authenticated Messaging can be found at:
mobilefish.com/developer/iota/iota_quickguide_esp01s_mam.html
The source code used in the guide can be found at:
github.com/robertlie/dht11-esp01s
ESP-01S (ESP8266) WiFi module specifications:
- Flash memory: 1 MByte
- Max transmission distance: approx. 400 m (direct line of sight)
- Package size: 24.7mm x 14.4mm
- WiFi protocols: 802.11 b/g/n
- Supply voltage: 3.0 to 3.6V
- Operating current (average value): 80 mA
- Comes pre-programmed with an AT command set firmware.
- Operating temperature: -20 deg C to 85 deg C
- Not breadboard friendly
- Number of pins: 8
- Number of GPIO ports: 2 (GPIO0 and GPIO2)
- Not shielded
- One led (blue), will flash when data is transmitted
USB to TTL converter
To upload an Arduino sketch or firmware to the ESP-01S module an USB to TTL Serial converter is needed.
They are also known as USB-TTL converters, USB FTDI converters or FTDI adapters.
FTDI (Future Technology Devices International) is a company who produces the most well-known USB-Serial converter chips.
The USB-TTL converter, converts USB data signals to and from TTL-level serial data.
Serial data is transmitted one bit at a time at a specified data rate (i.e. 9600bps, 115200bps, etc.).
This method of serial communication is sometimes referred to as TTL serial (Transistor-Transistor Logic).
Serial communication at a TTL level will always remain between the limits of 0V and Vcc, which is often 5V or 3.3V.
A logic high ('1') is represented by Vcc, while a logic low ('0') is 0V.
MQTT
MQTT stands for Message Queuing Telemetry Transport and is a publish/subscribe event-driven messaging protocol for constrained Internet of Things devices and low-bandwidth, high-latency or unreliable networks.
MQTT enables messages to be pushed to clients.
The MQTT broker is the central point and is in charge of dispatching all messages between the senders and the rightful receivers.
Each client that publishes a message to the broker, includes a topic into the message.
Each client that wants to receive messages, subscribes to a certain topic and the broker delivers all messages with the matching topic to the client.
The client who publish the data and the client who receives the data don’t have to know each other, they only communicate over the topic.
This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
TCP/IP port 1883 is reserved for use with MQTT.
TCP/IP port 8883 is reserved, for use with MQTT over SSL.
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota

![Create self signed certificates with Subject Alternative Names
This video explains how to create a self signed certificate with Subject Alternative Names (SAN).
A certificate with Subject Alternative Names is a single certificate supporting multiple Common Names (CN), for example:
- mobilefish.com
- sand.mobilefish.com
- baidu.com
- china.com
This means this single certificate can be used in multiple URLs:
- https://mobilefish.com
- https://sand.mobilefish.com
- https://baidu.com
- https://china.com
Chrome browsers will issue a warning if your SSL certificate does not specify Subject Alternative Names.
This video assumes that you have installed OpenSSL.
More information how to install and use OpenSSL:https://www.openssl.org
To check if your system has OpenSSL installed, type: openssl version -a
The procedure to create self signed certificates with Subject Alternative names is also documented at:
https://www.mobilefish.com/developer/apache/apache_quickguide_install_macos_sierra.html
Warning: Never use self signed certificates in production environments.
It is okay to use it in development or testing environments.
1. Create a 2048 bit Certificate Authority (CA) private key:
sudo openssl genrsa -out privkey.pem 2048
The CA private key is created: privkey.pem
2. Create a self signed CA certificate:
sudo openssl req -new -x509 -days 3650 -nodes -key privkey.pem -sha256 -out ca.pem
3. Create a 2048 bit Certificate Authority (CA) certificate:
Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:Noord-Holland
Locality Name (eg, city) []:Zaandam
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mobilefish.com CA
The CA certificate is created: ca.pem
4. Create a server configuration file (server.csr.cnf). Example:
https://www.mobilefish.com/download/openssl/sand.mobilefish.csr.cnf.txt
Download and modify the server configuration file according to your situation.
[dn]
C=NL
ST=Zaandam
L=Noord-Holland
O=End Point
OU=Research and development
emailAddress=rd@mobilefish.com
CN = sand.mobilefish.com
5. Create a server Certificate Signing Request (CSR) and server private key.
sudo openssl req -new -nodes -out server.csr -keyout server.key -config server.csr.cnf
The server CSR is created: server.csr
The server private key is created: server.key
6. Create a server extension file (server_v3.ext). Example:
https://www.mobilefish.com/download/openssl/sand.mobilefish_v3.ext.txt
Modify the server extension file according to your situation.
Add Subject Alternative Names:
[alt_names]
DNS.1 = sand.mobilefish.com
DNS.2 = proxy.mobilefish.com
In the sever configuration file (server.csr.cnf) I have used “CN = sand.mobilefish.com.
This common name must be mentioned as one of the Subject Alternative Names.
7. Create the server certificate:
sudo openssl x509 -req -in server.csr -CA ca.pem -CAkey privkey.pem -CAcreateserial -out server.crt -days 3650 -extfile server_v3.ext
The server certificate is created: server.crt
The serial number file is created: ca.srl
Each issued certificate must contain a unique serial number assigned by the CA.
It must be unique for each certificate given by a given CA.
OpenSSL keeps the used serial numbers on a file.
The server certificate (server.crt) and server private key (server.key) are the two files you need to install on your server (Apache web server, proxy server).
Always keep the private keys secure:
- CA private key (privkey.pem)
- Server private key (server.key)
Recap
We have created our own Certificate Authority (root certificate).
But this CA is not trusted by our system.
Next our CA has created a certificate with SAN.
Trusted CA’s such as Comodo and GoDaddy are trusted because their root certificates are already imported in our system.
In YouTube video “Geth supporting SSL using reverse proxy server” I will be using this self signed certificate to setup a reverse proxy server accessible by:
https://proxy.mobilefish.com.
Check out all my other Ethereum related tutorial videos:
https://goo.gl/eNJVXe
Subscribe to my YouTube channel:
https://goo.gl/61NFzK
The presentation used in this video tutorial can be found at:
http://www.mobilefish.com/developer/blockchain/blockchain_quickguide_ethereum_related_tutorials.html
#mobilefish #howto #ethereum Create self signed certificates with Subject Alternative Names](https://i.ytimg.com/vi/qoS4bLmstlk/mqdefault.jpg)
![LoRa/LoRaWAN tutorial 15: Data Rate, Chip Rate, Symbol Rate, Chip Duration and Symbol Duration
If you like this video and want to support me, go this page for my donation Paypal or crypto addresses:
https://www.youtube.com/c/mobilefish/about
This is part 15 of the LoRa/LoRaWAN tutorial.
In this video series different topics will be explained which will help you to understand LoRa/LoRaWAN.
It is recommended to watch each video sequentially as I may refer to certain LoRa/LoRaWAN topics explained earlier.
In this video I will explain how data rate, chip rate, symbol rate, chirp duration and symbol duration are calculated.
The unit of bandwidth (BW) is Hertz (Hz) which is the number of vibrations or wave cycles per second.
This bandwidth is interchangeably with chip rate:
BW = Rc = chip rate (chips/s) [1]
For example: BW=125 kHz
BW = Rc = 125000 chips/s
The Symbol Rate (Rs) is calculated as follow:
Rs (symbols/sec) = BW / 2^SF = Rc / 2^SF [1]
Bandwidth (BW) in Hz
Spreading Factor (SF): 7-12
For example: BW=125 kHz, SF=7
Rs = 125000 / 2^7 = 977 symbols/sec
The chip rate is always higher than the symbol rate: Rc is greater than Rs
To calculate the data rate (DR) or bit rate (Rb):
Rb (bits/sec) = SF x (BW / 2^SF) x (4(4+CR))
Bandwidth (BW) in Hz
Spreading Factor (SF): 7-12
Code Rate (CR): 1-4
For example: SF=7, CR=1
BW=125 kHz, Rb = 7 x (125000 / 2^7) x (4 / (4 + 1)) = 5.5 kbits/s
BW=250 kHz, Rb = 7 x (250000 / 2^7) x (4 / (4 + 1)) = 10.9 kbits/s
BW=500 kHz, Rb = 7 x (500000 / 2^7) x (4 / (4 + 1)) = 21.9 kbits/s
If you increase the bandwidth, the bit rate or data rate is increased.
For example: BW=125 kHz, CR=1
SF=7, Rb = 7 x (125000/2^7 ) x (4/(4+1)) = 5.5 kbits/s
SF=8, Rb = 8 x (125000/2^8 ) x (4/(4+1)) = 3.13 kbits/s
SF=9, Rb = 9 x (125000/2^9 ) x (4/(4+1)) = 1.76 kbits/s
SF=10, Rb = 10 x (125000/2^10) x (4/(4+1)) = 0.98 kbits/s
SF=11, Rb = 11 x (125000/2^11) x (4/(4+1)) = 0.54 kbits/s
SF=12, Rb = 12 x (125000/2^12) x (4/(4+1)) = 0.29 kbits/s
If you increase the Spreading Factor, the bit rate or data rate is decreased.
Because Rc = BW [1], the chip duration is calculated as follow:
Tc (sec) = 1 / BW
Bandwidth (BW) in Hz
For example: BW=125 kHz
Tc = 1 / 125000 = 8 µs
The symbol duration or sweep time is calculated as follow:
Ts(sec) = 2^SF / BW [1]
Bandwidth (BW) in Hz
Spreading Factor (SF): 7-12
For example: SF7
BW=125 kHz, Ts = 2^7 / 125000 = 1.024 ms
BW=250 kHz, Ts = 2^7 / 250000 = 512 µs
BW=500 kHz, Ts = 2^7 / 500000 = 256 µs
If the BW increases, the Symbol duration decreases.
For example: BW=125 kHz
SF=7, Ts = 2^7 / 125000 = 1.024 ms
SF=9, Ts = 2^9 / 125000 = 4.096 ms
SF=12, Ts = 2^12 / 125000 = 32.768 ms
If the SF increases, the Symbol duration increases.
An overview of symbol durations with respect to different Spreading Factors.
If the SF increases by one the symbol duration doubles.
If you increase the SF by 1:
The symbol duration or sweep time doubles compared to the previous SF.
It reduces the bit rate approximately by half compared to the previous SF.
The Time on Air (ToA) (=message transmission time) increases which means the distance increases.
To give you an idea what the Time on Air is for a 10 byte payload and BW=125kHz:
SF7, transmission time = 41 ms
SF12, transmission time = 991 ms
LoRa devices uses a higher spreading factor when the signal is weak or there is lot of interference.
Using a higher spreading factor means a longer Time on Air (ToA).
If an end device is further away from a gateway the signal get weaker and therefore needs a higher spreading factor.
Check out all my other LoRa/LoRaWAN tutorial videos:
https://www.youtube.com/playlist?list=PLmL13yqb6OxdeOi97EvI8QeO8o-PqeQ0g
Subscribe to my YouTube channel:
https://www.youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
https://www.mobilefish.com/developer/lorawan/lorawan_quickguide_tutorial.html
#mobilefish #lora #lorawan LoRa/LoRaWAN tutorial 15: Data Rate, Chip Rate, Symbol Rate, Chip Duration and Symbol Duration](https://i.ytimg.com/vi/r84GMLeiqg8/mqdefault.jpg)







