Showing posts with label ESP8266 IoT. Show all posts
Showing posts with label ESP8266 IoT. Show all posts

Wednesday, May 18, 2016

About LoRa and LoRaWan

LoRa is based on opened radio-frequency communications, different frequencies are used depend on locations:
  • 430 Mhz – valid for Asia
  • 780 Mhz – valid for China
  • 433 Mhz – valid for Europe
  • 866 Mhz – valid for Europe
  • 915 Mhz – valid for USA
LoRa supports different Data Rates and offer a large radio link budget over 160dB. The power consumption is about 40mA during transmission and 10mA during reception. It allows a wide coverage : about 2.5Km from antenna inside a city and up to 15km in a countryside.
LoRa is based on a Spead Spectrum technology this technology helps to reach long distance over noise boosting up to 10x the distances obtains with classical transmission systems. It also have a good shifting frequency immunity.  LoRa sound to have good results on movement. It uses wide-band linear frequency modulated pulses. Frequency increase or decrease to encode the information.

LoRaWAN Classes, © 2015 LoRa™ Alliance.

LoRaWAN™ is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in regional, national or global network. LoRaWAN target key requirements of internet of things such as secure bi-directional communication, mobility and localization services. This standard will provide seamless interoperability among smart Things without the need of complex local installations and gives back the freedom to the user, developer, businesses enabling the roll out of Internet of Things.
LoRaWAN network architecture is typically laid out in a star-of-stars topology in which gateways is a transparent bridge relaying messages between end-devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways. All end-point communication is generally bi-directional, but also supports operation such as multicast enabling software upgrade over the air or other mass distribution messages to reduce the on air communication time.
Communication between end-devices and gateways is spread out on different frequency channels and data rates. The selection of the data rate is a trade-off between communication range and message duration. Due to the spread spectrum technology, communications with different data rates do not interfere with each other and create a set of "virtual" channels increasing the capacity of the gateway. LoRaWAN data rates range from 0.3 kbps to 50 kbps. To maximize both battery life of the end-devices and overall network capacity, the LoRaWAN network server is managing the data rate and RF output for each end-device individually by means of an adaptive data rate (ADR) scheme.
National wide networks targeting internet of things such as critical infrastructure, confidential personal data or critical functions for the society has a special need for secure communication. This has been solved by several layer of encryption:
  • Unique Network key (EUI64) and ensure security on network level
  • Unique Application key (EUI64) ensure end to end security on application level
  • Device specific key (EUI128)
LoRaWAN has several different classes of end-point devices to address the different needs reflected in the wide range of applications:
  • Bi-directional end-devices (Class A): End-devices of Class A allow for bi-directional communications whereby each end-device's uplink transmission is followed by two short downlink receive windows. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). This Class A operation is the lowest power end-device system for applications that only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink.
  • Bi-directional end-devices with scheduled receive slots (Class B): In addition to the Class A random receive windows, Class B devices open extra receive windows at scheduled times. In order for the End-device to open its receive window at the scheduled time it receives a time synchronized Beacon from the gateway. This allows the server to know when the end-device is listening.
  • Bi-directional end-devices with maximal receive slots (Class C): End-devices of Class C have nearly continuously open receive windows, only closed when transmitting. Class C
[Text from https://www.lora-alliance.org/What-Is-LoRa/Technology]

More details about the protocol can be found in the document.

Tuesday, February 2, 2016

Mqtt broker on ESP8266 #1

[Later edit]. On iotcentral.eu you will find instructions on how to install the ESP8266 MQTT broker on your EPS8266 and how to use the MQTT service provided by iotcentral.eu

First tries on Esp8266 with MQTT broker.

I was able to send and receive up to 1000 messages in few seconds before the heap run out.

Next to do is to optimize the memory usage, use a memory pool allocator, do some profiling to determin the optimum values for memory chunks....a lot of work to do.

Then do the bridging  (bridgind is done and is working fine)  and websockets, if there is any memory left.




And a video with 1000 messages sent from and to my phone using ESP as broker. Don't forget that there are very small messages.



Friday, January 29, 2016

Power issue on ESP double deck module

On this  module power it for development/debugging from your computer USB on the lower board can lead to an very dimmed red LED.

To avoid this issue add power on the upper board also. Looks like RED led consume some power and if you have an low current USB like I have, you will not see the RED led.

Indeed red part of LED is consuming more power and is not as bright as BLUE or GREEN but is fine for development purpose.




Sunday, January 10, 2016

MQTT Broker on ESP32

I've managed to put an MQTT broker on ESP32 (aka ESP31B).

The code is under development and ESP32 at this time is not yet released, but when it will be I'll also have the code complete. There are some problems but let's hope they will be resolved by the Espressif System. 

I will try to see if I can do the same with ESP8266 which is already on the market. 




Friday, November 27, 2015

DHT22 versus BMP180. The winner is ....

For my chronothermostat  project I have evaluated the 5.11USD DHT22 and 2.20 USD BMP180.

I've let them work in parallel for few days and the winner is ..... BMP180.

This is a graph for BMP180.


BMP180



This is a graph for DHT22.
DHT22


As you can see the DHT22 had few unwanted spikes which leads to false triggers.

DHT22 has the advantage of using one pin,  BMP180 is i2c so is using 2 pins, but the temperature has no spikes. 

Both sensors:

  •  are reading the same temperature
  •  both are showing a lower value as my current chronothermostat which is responding more quickly on changing the temperature.

If you know other sensors that are more precise and are more temperature responsive, please let me know.