1. Home
  2. Projects
  3. Omega2 as a LoRaWAN node

Omega2 as a LoRaWAN node

  • M

    0_1529411145377_logo.png

    This is work in progress!

    Repository:

    This project will be about making the Omega2 a LoRaWAN node.

    LoRa (Long Range) is a radio technology by which extremely long transmission ranges and low power consumption can be achieved at the same time. Depending on the country, it works on license-free bands such as 902-928 MHz (USA), 868MHz (EU) et cetera (complete list).

    The Things Network (TTN) is a open LoRa network that anyone can join and build gateways for to increase its coverage.

    This means that all you have to do is a LoRa radio and a free account. Compared to GSM, LoRa has:

    • no costly SIM card with monthly payments
    • much lower power consumption
    • additional features such as node-to-node communication

    The main usage of LoRa is for small embedded sensors (think: electricity meters, smart city stuff with air quality sensors, temperature sensors, weather stations etc).

    For the Omega2, this might have a usage where power is available, but not internet coverage over WiFi, Ethernet or GSM. Since it's fairly easy to build a LoRa gateway that can be a several kilometers away from the node, but not easy to build a GSM transmission tower, LoRa can be used to transmit data instead.

    The Omega2 is also suitable for being a LoRaWAN gateway. Several projects were already presented here, e.g. with a RAK831 gateway module by @luz.

    With this code, you can connect a LoRa radio such as the SX1276 or SX1272 (or clones such as the HopeRF RFM95) to the Omeag2 and have it send data over LoRa to the The Things Network.

    It actually includes 2 things:

    As of now, I still had some problems with receiving data via the Omega2's native SPI bus. But I also had this chip handy and thought it would be a generally useful addition to have an alternative to the Omega2's SPI interface: A pretty simple I2C to SPI bridge. It features 4 slave selects and transfer rates of about 1 Megabit/s (on the SPI side).

    The wireup is simple:

    • I2C to SPI bridge connected to the Omega2's I2C bus, the bridge's SPI bus to the radio
    • DIO0 and DIO1 (interrupts for radio events) to GPIO pins of the Omega2

    The used radio is a HopeRF RFM95W chip on a simple breakout board.

    This setup successfully transmits data to TTN:

    The repo comes with a command line tool with which data can be sent.

    0_1529412156046_shell.png

    Some things are still in progress like:

    • reception of data has a bug ATM
    • make radios selectable
    • make frequency plan selectable (EU868 ATM)
    • more examples with sensors!

    Things I still have on my bucket list for the Omega2:

    • Implement a 8ch LoRaWAN TTN gateway using 8 single radios
    • release SC18IS602B library seperately
    • build a LED matrix with live FFT of audio data
    • release already built OpenGL 3D code (never had time to write a clean writeup / do code cleanup, from https://community.onion.io/post/16488)
    • other stuff? 😉

    Regards,
    Maximilian

    3
  • M

    0_1529837559659_logo.png

    Welcome back!

    Repositories:

    Considerable progress was made and a demo with AllThingsTalk was added.

    • LoRa reception was fixed (needed LMIC_setClockError()), we can now receive payload
    • send tool is more configurable
      • spreading factor (SF) selectible (SF7 - SF12)
      • OTAA (over-the-air-activation) and ABP (activation-by-personalisation) can be used
      • up/down counters can be set
      • confirmed uplink messages can be sent
      • target FPort can be given
      • US910 and EU868 frequency band versions available
    • sensor demo with DHT11 temperature & humidity sensor added
      • pushes data to TTN, TTN auto-pushes it to AllThingsTalk backend

    Remaining ToDos:

    • make it work with native SPI interface instead of I2C to SPI bridge
      • SPI data reception on the most current firmware seems to be broken at the moment, still investigating, ticket pending

    The tool's usage was updated to:

    Usage: ./lorawan_send --payload PAYLOAD --method METHOD [--dev-adr DEV-ADR] [--nws-key NWS-KEY] 
                     [--apps-key APPS-KEY] [--format FORMAT] [--up-counter UP-COUNTER] [--down-counter DOWN-COUNTER] 
                     [--dev-eui DEV-EUI] [--app-eui APP-EUI] [--app-key APP-KEY] [--spreading-factor SPREADING-FACTOR] 
                     [--fport FPORT] [--confirmed] [--infinite-loop]

    This happily receives downlinks and sends uplink messages to TTN:

    0_1529838961885_confirmed_downlink.png

    For the sensor demo, a DHT11 was chosen. I used a premade program from @h0l0gram: https://github.com/h0l0gram/omega2-checkHumidity.

    The demo program is simple:

    • invoke the above checkHumidity program and parse its output
    • invoke lorawan_send with the encoded data

    Managing sensor data with TTN is really easy because it has so called "payload integrations" available. You can choose an IoT platform and have TTN automatically send data to it. I activated the "AllThingsTalk" integration according to their documentation.

    0_1529839220155_integration.png

    The basic princinple is:

    • register an account with AllThingsTalk
    • create a new "Playground"
    • register a device by adding it via the App-ID (mine: "first-test") and the Device-EUI
    • setup "assets" (captured data types)
      • setup one called "t" (temperature) and one "h" (humidity)

    You have to send the data "CBOR" (Concise Binary Object Representation) encoded to TTN. For example, the data point {"t":24, "h":40} has the following CBOR encoding:

    0_1529839500224_cbor_encoding.png

    The demo program then transmits CBOR encoded humidity and temperature data to TTN

    0_1529839555681_uplink_ttn.png

    And all of it is nicely displayed in the dashboard of AllThingsTalk:

    Devices:

    0_1529839605450_devices.png

    Assets:

    0_1529839617931_assets_overview.png

    Live chart data:

    0_1529839685710_allthingstalk_data.png

    We can also activate "data storage" which will store all sent data up to 30 days. It gives you a nice download button which exports the data to CSV:

    0_1529839726350_datastorage.png

    Which you can then pull into Excel. I let this run overnight and this is the result:

    0_1529839814481_excel_data.png

    Pretty easy, huh? 🙂

    0_1529840861898_IMG_20180624_134454.jpg

    This concludes the project. I showed you a port of LMIC to the Omega2 with which you can send data over LoRaWAN to TTN, a driver for the NXP SC18IS602B I2C to SPI bridge and a demo program and setup which pushes DHT11 sensor data into an IoT backend. You can now send sensor data (and receive data) over LoRa without the need of an internet connection.

    Edit: Fritzing schematics + breadboard view added to repo.

    0_1529857123427_omega_lora_dht11_Steckplatine.png

    2 luz 1 Reply
  • luz

    @Maximilian-Gerhardt Regarding the SPI issue: Have you tried to apply the patch from Bernhard Wörndl-Aichriedler bwa@xdevelop.at I used for my TTN gatway? For SPI communication with the RAK831 it does the trick.

    0 M Lazar Demin 2 Replies
  • M

    @luz It would be weird if I needed that patch because I wrote a MCP3008 SPI ADC driver in January 2018 that reads data (on a lower firmware version, but unmodified) and that worked. Something must have re-broken it on 0b188.. http://community.onion.io/topic/2655/mcp3008-spi-addressing-and-0x00-returned-values/5

    0 Lazar Demin 1 Reply
  • Lazar Demin
    administrators

    @Maximilian-Gerhardt wow, great write-up & great project, as usual!!
    Btw, we have @h0l0gram 's DHT program in our repo as well: https://onion.io/2bt-reading-dht-sensor-data/

    @luz Correct me if I'm wrong, but the patch you linked is more-or-less the same as we use in the Omega2 build system? https://github.com/OnionIoT/source/blob/lede-17.01/target/linux/ramips/patches-4.4/9999-spi-mt7621.patch

    1
  • Lazar Demin
    administrators

    @Maximilian-Gerhardt Took a little bit of time to implement native SPI communication. I've confirmed that bi-directional communication between the Omega and LoRA module is working correctly. Just haven't successfully sent any data to TTN as there are surprisingly few gateways in my area.

    Check it out here: https://github.com/OnionIoT/omega2-lmic-lorawan

    1 M 1 Reply
  • J

    Thanks for all you guys do to constantly keep the Omega development moving forward.

    This is pretty cool. I know this is a bit off topic but if a developer wanted to use python/spi-dev, would the Omega2 be able to correctly read the SX1276 config registers with out any data errors?

    Is this project using hspi or bit-bang spi?

    0
  • M

    @Lazar-Demin Great to see it working. If you need a gateway you can also use a ESP8266 NodeMCU board with another RFM95 module and configure and flash the https://github.com/things4u/ESP-1ch-Gateway-v5.0 firwmare on it, also see http://things4u.github.io/. Needs a little bit of fiddling around with the configuration and pinout; Also be aware that the EUI of the TTN gateway must be the one that the firmware spits out on startup (it's made up of the ESP8266's MAC address and two 0xff in the middle).

    0
i2c 115 spi 77 lora 6 sx1276 1 ttn 1
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.