Once installed, try compiling one of the demo programs for Teensy, just to make sure that everything went ok.

Now, we are ready to proceed with actual LoRaMac code. First, Clone the whole package to your system, then add it as new library to your Arduino SDK.

You are almost done ;), just few modifications left…

I will be using defaults with the exception of the DevAddr below.

In the main file, we need to change DevAddr to something unique globally.

static const u4_t DEVADDR = 0x03FF0001 ;

//In this example I used 0x03FFEBB2, you will see it below in the section when we define node manually in gateway's db.

This is equivalent of MAC address associated with your Ethernet port. In production, you will have your own prefix, obtained from IEEE, but for now we can just use anything, as long as it’s not duplicated on your network.

Then, we will adjust Spreading Factor from 11 to 9 to match gateway configuration (as per FCC in North America, Spreading Factor could be between 7 and 10).// Set data rate and transmit power (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF9,14);

Now, you need to use your favoured editor to change the config.h located under arduino libraries (in case of MacOS: /Users/<Your User Name>/Documents/Arduino/libraries/arduino-lmic-v1.5-master/src/lmic to support 915MHz as North American ISM frequency and SX1276 chip for RFM95 HopeRF radio module.#ifndef _lmic_config_h_
#define _lmic_config_h_

// In the original LMIC code, these config values were defined on the
// gcc commandline. Since Arduino does not allow easily modifying the
// compiler commandline, use this file instead. (MK)

Depending if you run gateway or packet forwarder, go to you logs or run mosquitto_sub -t lora/+/up to see incoming packets.

As soon as you run your demo code, you should see something like that:{"chan":7,"cls":0,"codr":"4/5","data":"d29ybGQ=","datr":"SF9BW125","freq":"913.3","lsnr":"-12.8","modu":"LORA","rfch":1,"rssi":-113,"seqn":5,"size":8,"timestamp":"2015-11-18T16:08:51Z","tmst":2397020652}

where “d29ybGQ=” is base64 representation of the word “hi”.

Almost forgot about last cosmetic modification… in order to avoid an extra character at the end of the string, modify// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata), 0);
to // Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(my data)-1, 0);

Enjoy and stay tuned…

Soon, I will share my experience with modules from one of the new LoRa node makers from China.

I will also experiment with LoRa range, explaining ways to get the most from your node…

It is possible for a device to be designed to operate as a DTS, as a FHSS system, or using a combination of these two modulation types.
A hybrid system uses both digital modulation and frequency hopping techniques at the same time on the same carrier. As shown in Section 15.247(f), a hybrid system must comply with the power density standard of 8 dBm in any 3 kHz band when the frequency hopping function is turned off. The transmission also must comply with a 0.4 second / channel maximum dwell time when the hopping function is turned on. There is no requirement for this type of hybrid system to comply with the 500 kHz minimum bandwidth normally associated with a DTS transmission; and, there is no minimum number of hopping channels associated with this type of hybrid system.
As a possible application scenario, consider a system operating with eight 200 kHz channels.
To comply with the requirements for hybrid operation the channel dwell time in frequency hopping mode must not exceed 400 ms in any (400 ms * 8 channels) 3.2 seconds. In addition, the power spectral density shall not exceed +8 dBm in any 3 kHz bandwidth.

It is a good alternative and perhaps, soon we will see plenty of choices for LoRa gateways operating within North American spectrum. The power needs to be limited and capacity is also limited, but still it is an inexpensive way to deploy LoRa network in North America.

In the previous post, I have explained how to configure Multitech Conduit and mDot module to communicate with each other, using private LoRa network mode. Today, we will change it to use public LoRa mode, however we still use just one device to observe incoming packets. We will be running Network Server together with a Gateway on our Conduit.

Let’s change configuration of the LoRa-network-server by editing /var/config/lora/lora-network-server.conf like below:

Now, we will connect to our mDot module, and using AT commands we will change it’s network mode to be a public mode plus we will provide network related information to match our Conduit system. Actually, we will be using the same network information which one would use to connect to The Things Network, in a future post we will show how to use the Packet Forwarder and connect to their Network Server.