Tag Archives: ttn

Configuring Multitech MDOT for TTN

I have a Multitech MDOT-BOX for testing. Configuring it for TTN requires the following connection to a computer, after which AT commands can be used to probe and set parameters. The following resets the MDOT to factory defaults and shows the configuration overview.

AT&F
AT&V

Firmware: 		2.0.0
Library : 		0.0.9-14-g4845711
Device ID:		00:80:00:00:00:00:b3:76
Frequency Band:		FB_868
Public Network:		off
Network Address:	00000000
Network ID:		6c:4e:ef:66:f4:79:86:a6
Network ID Passphrase:	MultiTech
Network Key:		1f.33.a1.70.a5.f1.fd.a0.ab.69.7a.ae.2b.95.91.6b
Network Key Passphrase:	MultiTech
Network Session Key:	00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Data Session Key:	00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Network Join Mode:	OTA
Tx Data Rate:		SF_7
Tx Power:		11
Log Level:		6
Maximum Size:		242
Minimum Size:		11
Maximum Power:		20
Minimum Power:		2
Data:			0

After adding a device to application page on the TTN console with OTA activation, the following identifiers/keys are listed on the TTN console page for the device

Device EUI
Application EUI
App Key
Device Address
Network Session Key
App Session Key

From the Multitech documentation: In OTA mode, the device only needs to be configured with a network name (+NI=1,name) and network passphrase (+NK=1,passphrase). The network session key, data session key, and network address are all automatically configured.

With ABP activation, the following identifiers/keys are listed on the TTN console page for the device.

Device EUI
Application EUI
Device Address
Network Session Key
App Session Key

From the Multitech documentation: In Manual mode, there is no join request sent and the device must be manually configured with a network address (+NA), a network session key (+NSK), and a data session key (+DSK). The device must be provisioned with the network server as well.

Mapping between TTN and MDOT keys/identifiers

The Device EUI is hardware dependent and should therefore be copied from the MDOT device to the TTN console. The other keys/identifiers are application dependent and should be copied from the TTN console to the device.

For OTA the following settings need to be updated:

AT+PN=1
AT+NJM=1
AT+NI=0,70B3D57EF000451B
AT+NK=0,5108008928062F42980E42C20AC1E4E1
AT&W

TTN direction MDOT
Device EUI <- Device ID
Application EUI -> Network ID
App Key (only in OTA) -> Network Key

I could not get ABP to work.

TTN direction MDOT
Device EUI <- Device ID
Application EUI -> xxx
App Key (only in OTA) -> xxx
Device Address -> xxx
Network Session Key -> xxx
App Session Key -> xxx

GPS-enabled LoRaWAN temperature sensor

Together with the TTN Nijmegen community we are discussing possible applications of remote sensing nodes in Nijmegen. To get a better view on the TTN coverage in Nijmegen and to get a feel for what works (and what not), we are working on the implementation of some nodes.

The PoC2 TTN gateway will soon be installed by Michiel Nijssen at Maptools in Molenhoek. To help Michiel get started, we agreed that I would give him a fully functional node to play with. Michiel came up with a very concrete idea: it consists of a GPS-enabled temperature sensor that sends the data over LoRaWAN/TTN. Below you can find some details of a very fist implementation.

The node consists of

  • Teensy 3.2 MCU board
  • Dorji LoRa module
  • DS18b20 temperature sensor
  • Ublox NEO-M8N GPS module
  • 4k7 ohm resistor
  • small LED and 200 ohm resistor (not on photo)

I estimate that the material costs amount to 50 euro. It still needs to be soldered in a more sturdy form-factor and a battery and enclosure need to be added.

I created a corresponding application on console.thethingsnetwork.org where I configured the node with APB.

The node is running a sketch (i.e. firmware) that I developed in the Arduino IDE. On the receiving side side I am using a node.js application, which uses MQTT to connect with TTN and to receive the messages. The receiving application also implements a simple web interface that displays the most recently received data. The receiving application is running on a Raspberry Pi in my basement.

The Arduino code for the teensy can be found in my arduino repository on github in the teensy_gps_temp_ttn directory.

The node.js code for the receiving application can be found in its own repository on github.

The web interface can be found on gpstemp.robertoostenveld.nl. Note that I might not keep this particular web application running for very long, so don’t be surprised if the URL stops working. To check that it is displaying live data, you can reload ever 10 seconds or so. The counter should increase, and the numbers might be a bit different.

TTN/LoRa using Dorji DRF1272F module

Teensy connected to DRF1272f

Sofar I have been experimenting with LoRa and TTN using a Multitech MDot board and with a HopeRF RFM95W module connected to a Teensy, but I decided to try something else. Franz, one of the members of the TTN Nijmegen community, started experimenting with node-to-node communication using Dorji DRF1278F 433MHz modules. I’d like to support him in converting to 868MHz, so that he can post data to TTN once a gateway become available in his range.

The Dorji modules are currently among the cheapest LoRa modules available on Ebay. So some weeks ago I ordered a DRF1272F 868MHz module for about $8, which arrived this week.

The first surprise is that it has a 1.27 mm pitch header connector. The module has 13 contacts, but not all are required for the LMIC Arduino library. To make it more easy to handle, I made a custom break-out board that connects the required pins to a 2.54 mm pitch 8-pin header. Soldering the wires at 1.27 mm pitch was quite a challenge; you may want to use a magnifying glass, as those pads are tiny!

DFR1272f module adapter board

Based on the DRF1272F datasheet, the LMIC Arduino library documentation, and the Teensy pinout I connected it as follows:

 DRF1272F  |   Teensy 3.2
--------------------------
 RESET     |   nc
 DIO0      |   2
 DIO1      |   5
 DIO2      |   nc
 DIO3      |   nc
 DIO4      |   nc
 DIO5      |   nc
 3.3V      |   3.3V
 GND       |   GND
 SCK       |   13 - SCK
 MISO      |   12 - DIN 
 MOSI      |   11 - DOUT
 NSS       |   10 - CS

Please note that I did not connect the RESET and the DIO2 pin, which would be needed for FSK.

I used the following snippet of code in my Arduino sketch to specify the pin mapping:

// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 5, 6},
};

On the software side I am using Arduino 1.6.9, the LMIC library and the same sketch that I have been using with the RFM95W module.

I had to change the Semtech radio from SX1276 to SX1272 in the arduino-lmic/src/lmic/config.h:

#define CFG_eu868 1
//#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
//#define CFG_sx1276_radio 1

Following all of this, this node is nicely sending packets to my TTN application.

Bidirectional communication over The Things Network

I have been experimenting today with an RFM95W hooked up to a Teensy and managed to implement full bidirectional communication to/from The Things Network.

The Teensy by default sends the temperature (from a ds18b20) with every transmit. If you press the button, it sends the button press event instead. Furthermore, on every transmit it listens for a message (which can be scheduled downlong through the TTN dashboard), and blinks the led if a message is received.

The Arduino code running on the Teensy can be found here and the server application code running on the Raspberry Pi here.

Still to be done is to extend the server application code with the button (to circumvent the TTN dashboard alltogether) and to come up with an actual application that is smarter than a button and a LED. I am thinking to link both up and downlink to an IFTTT maker channel.

teensy_app2

The Things Network Nijmegen – LoRaWAN module

Next Tuesday we will meet with the core team of the TTN Nijmegen in a small workshop to get things moving. There are some gateways now in Nijmegen (see the coverage map here), so we can and should get started with prototypes and trying to build the local community!

Preparing for next weeks meeting, I ordered a HopeRF RFM95W module at IdeeTron that is compatible with LoRaWAN. Since the hole spacing is 2 mm, making it incompatible with standard headers and a breadboard, I soldered short wires to each of the pads.

RFM95W module

This allows me to plug it into a standard breadboard with a little bit of bending of the “legs”.

RFM95W

Note that – compared to the layout in the data sheet – I soldered it upside-down. This allows me to still read the silk screen labels on each of the connections.