mDot Sensornode Firmware Ready to use


Where do I set the LORA_MODE ?
We would like to work with LORA_MODE_1
Posting the complete stanza here would be of great help...

Thank you

Also just as a note: Though you have added information about OTAA on the LoRa page ..
the 'Actual Stage of the software says'
"Actual Stage of the Firmware
LoRa Activation
At the moment only ABP is supported. Implementation of OTAA is planned"
And in bullet 2, Page:Configuring LoRa Connection
it says "At the moment only ABP is supported."


Your are right I have to update the other wiki pages.

To use Lora_Mode_1 please refer to Application Mode Wiki. Basically you just have to make sure that setLoRaMode() inside the specific switch case of Application::build() has LORA_MODE_1 as its input parameter for the Application Mode that you are using.


@Halfbrain Working on getting your program working and so as you suggested I will follow your instructions EXACTLY.

To that end I have:
Conduit Setup to poly packet forward to TTN

So I would like to start by getting ONE of these working.
I will choose MBM280 to start

That would be APPLICATION_MODE_3

I have your program setup as follows:
#include "Application.h"
#include "ApplicationConfig.h"
#include "UARTTunnel.h"

int main() {

Application application;

while (true) {

return 0;

ApplicationConfig.cpp has LORA_MODE_1
Then in in LoRaConfig.cpp - Only change is LORA_SUBBAND_2 as that is what has always worked for my TTN setup
case LORA_MODE_1:
and lastly
static uint8_t LORA_APP_EUI[] = { 0x08, 0x09, 0x00, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
static uint8_t LORA_APP_KEY[] = { 0x21, 0x12, 0x20, 0xC3, 0x97, 0x70, 0x8D, 0x5E, 0x64, 0x20, 0x0E, 0x9C, 0xFC, 0x6C, 0x3F, 0xCF };
static uint8_t LORA_DEVICE_EUI[] = { 0x36, 0xBF, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00 };

Which should match this TTN OTAA setup:

Also commented out s1143
void Application::configureSensors(){
// si1143->init(config->getSI1143_MODE());
When I run this I get two incorrect behaviors:

a) In the COM Window (serial to STLink Virtual COM Port) I see this upon startup..
The node does NOT join the network as evidenced by:
the message in above picture 'Device is Not Activated' (as well as the keys have not been generated
b) and the text is wrapped.. (I am connected 9600)

What do I have misconfigured..

Thank you for your assistance...



First of all the good news: Your configuration looks correctly.

The Issue with Putty is about Linefeeds. I usually use hTerm for my Serial Connection. There you can specify at wich sign it has to make a newline. Couldn't find that option in Putty.

I've found out that the problem probably is the joinNetwork() method of Multitechs mdot library.
Somehow it hangs forever in that method.

If you comment out the following Section:

while ((ret = dot->joinNetwork()) != mDot::MDOT_OK) {
    debugSerial->printf("failed to join network %d:%s\n", ret, mDot::getReturnCodeString(ret).c_str());
    // in the 868 (EU) frequency band, we need to wait until another channel is available before transmitting again
    osDelay(std::max((uint32_t)1000, (uint32_t)dot->getNextTxMs()));

inside LoRa::joinNetwork() the program continous.

Strange thing is that I don't have this issue in Attolic True Studio where I usually program the code before I upload it to the mbed Compiler.

So the bad news: I'dont know how to fix the problem at the moment but I will try to fix it somehow. I can't tell you how long it will take me to solve that.

Did you also try older Versions of the Firmware using ABP and having the same problems?



Good news: I've fixed the Bug :tada:.

Problem was that I've been using different mbed-rtos and mbed librarys inside my Attolic Project. It seems as if libmdot of Multitech doens't like the newest Versions of them. So I changed them to the old Versions I also use in my Attolic Project.

I've also tested APPLICATION_MODE_3 for your. My compiled project from mbed compiler runs perfectly.

Please update to my newest Version of the Firmware and test it and let me know if it works. And thanks for the info about the bug.:+1:


@Halfbrain I downloaded your newest version into a new program (so I would not get confused about revisions, merging etc), updated the LoRaConfig.cpp and made certain other config options were in place..

We are getting closer... however now get this error: "failed to join network -4:Join Error"
setting network name
setting network password
setting App EUI
setting App Key
setting frequency sub band
setting TX spreading factor
enabling ACKs
setting join mode
saving config
joining network
failed to join network -4:Join Error

I updated:
LoRaConfig.cpp to match our TTN Application
See here:
static uint8_t LORA_APP_EUI[] = { 0x09, 0x09, 0x00, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
static uint8_t LORA_APP_KEY[] = { 0x8E, 0x3B, 0x55, 0x80, 0xBD, 0x1C, 0xDA, 0xC9, 0xF4, 0x4F, 0x62, 0x17, 0xF4, 0x4F, 0xE5, 0x95 };
static uint8_t LORA_DEVICE_EUI[] = { 0x36, 0xBF, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00 };
compared to:

Seems set correctly.....

What does this point to "failed to join network -4:Join Error" ?


I think I might know what your problem is.

Change the order of the Bytes. In my Dashboard theres msb written not lsb and it really looks like your order is different to mine because the second last of DEV EUI for example is 0x80. In the Dev EUI of my mdot 0x80 is the second byte.

So change the order of all bytes strings. Last one will be first one second last one will be second and so on.

For example
APP EUI will be: 0x70,0xB3,0xD5,0x7E,0xD0,0x00,0x09, 0x09

Let me know if that helped you.


@Halfbrain Brilliant that did the 'trick' for joining OTAA.. (I had made a copying error earlier .. this entry is correct)

I have annotated my code to include notes regarding the specific TTN Screen, Field Name and Data Format ie " " msb from 'Dev Address' of Devive type 'OTAA' " see below:
static uint8_t LORA_APP_EUI[] = { 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x00, 0x09, 0x08 };// msb from 'App EUI' of Devive type 'OTAA'
static uint8_t LORA_APP_KEY[] = { 0xCF, 0x3F, 0x6C, 0xFC, 0x9C, 0x0E, 0x20, 0x64, 0x5E, 0x8D, 0x70, 0x97, 0xC3, 0x20, 0x12, 0x21 };// msb from 'App Key' of Devive type 'OTAA'
static uint8_t LORA_DEVICE_EUI[] = { 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0xBF, 0x36 };// msb from 'Dev EUI' of Devive type 'OTAA'

You may choose to add this to your code for the clarity... You do WONDERFUL work! Congratulations!


@halfbrain ok so now we have the BME280 connected and all seems to be working..

I am getting this off my MQTT client:
and I can see the "payload" changing .. thats a good sign

a) How can I see in the COM window the VALUES of Temperture/Pressure/Humidity? (later I will need to do some calculations on these values)
b) Can you tell me what values are in the 'payload'? and how I would 'unpack it'?

Thank you kindly in advance!



Output in hTerm should be something like this for APPLICATION_MODE_3

Message scheme is always the same. there is first an ID followed by its Value. like for example for the temperature
B1:26.24, which stands for 26.24°C The Id for each type of value is different. Please refer to main.h where all id's are defined.

Maybe you have to add a payload function in your dashboard.
Mine is something like this which should get me a string with only the ascii values. But it's just for test purpose. Not really beautiful code. Just copied something from the web.

function (bytes) {
// Decoder
// Here can decode the payload into json.
// bytes is of type Buffer.

var hex = bytes.toString();//force conversion
var char = '';
var str = "";
for (var i = 0; i < hex.length; i += 2){
char += String.fromCharCode(parseInt(hex.substr(i, 2),16));


var text = hex.replace(/\u[\dA-F]{4}/gi,
function (match) {
return String.fromCharCode(parseInt(match.replace(/\u/g, ''), 16));

// todo: return an object
return {
payload: text,

If you find one that can make a real String out of the Payload let me know.


@Halfbrain Got it going.. see here:

MAX44009 Working Niceeeeeeeeeeeeeeee..........................
MPU9250 Acceleration, Tesla and Gyroscope Working Niceeeeeeeeeeeeeeeeee...............

BME280 .. Not responding ..
I have BME280 wired the same way as the other two working sensors
However maybe I have a mistake due to naming .. see here the
Arafruit BME280 has VIN | 3Vo | GND | SCK | SDO | SDI | CS

In your documentation you show and I have substituted
BME280 (wiki)<==> mDot <==> BME280 (substitute pins)
SDA <==> PC_9 <==> SDI
SCL <==> PA_8 <==> SCK

Notice SDA and SCL are not on the module
(you might want to update the Installation of the Sensors page of your wiki)

Here is a picture of my wiring:

I wanted to show you the wiring to 'eliminate or change it' .. then to focus on firmware to get this sensor going.. ..

I am using Custom Case:
It uses BME_MODE_1 as seen below:
case BME280_MODE_1:
I have also tried BME280_MODE_0 and BME280_MODE_9 with the SAME results....

What do you think I have 'remiss'? Let me know . .thank you ...


Nice to see the other Sensors working.

BME280 will also work soon :wink:

I guess I know the problem. I checked the datasheet

On Page 31:

The 7-bit device address is 111011x. The 6 MSB bits are fixed. The last bit is changeable by
SDO value and can be changed during operation. Connecting SDO to GND results in slave
address 1110110 (0x76); connection it to VDDIO results in slave address 1110111 (0x77), which
is the same as BMP280’s I²C address. The SDO pin cannot be left floating; if left floating, the
I²C address will be undefined.
The I²C interface uses the following pins:
 SCK: serial clock (SCL)
 SDI: data (SDA)
SDO: Slave address LSB (GND = ‘0’, VDDIO = ‘1’)

This means for you connect SDO to GND because my Firmware uses 0x76 as BME280 Address.


@Halfbrain I added GND to SDO and ..... ......
The values B1/B2/B3 are unchanging.... .. See here:

I have two of these BME280's they both behave the same way.

Hmmmmmm.... What are your thoughts about this...


did you also try connecting it to 3.3V, Could be a mistake in the datasheet...

We didn't use adafruits BME280 because we made our own PCB but our Layout says that we also connected SDO to GND.

Do you have an Oscilloscope where you could check the signals on the I2C Bus? If so I would recommend you to check if BME280 is alive and returns ACK's to the mDot if it is sending something to the BME280 via I2C


@Halfbrain Our BME280 is connected to 3.3V, see here:

I have two of these and they both behave exactly the same way
I do not have an Osciloscope
Do you have access to an Arafruit BME280 (I thought you might as this is the specific item in your writeup)?
If not ... Can you readily get one?
If not .. Where do you live? If need be I could send you one.....

What do you think we should do?

Let me know... Thank you


funny guys at Adafruit :joy:

take a look at assembly page

their assembly page says:

I2C Logic pins:
SCK - this is also the I2C clock pin, connect to your microcontrollers I2C clock line.
SDI - this is also the I2C data pin, connect to your microcontrollers I2C data line.
Leave the other pins disconnected

as you see their BME280.h at git

they use 0x77 as their Sensoradress not 0x76 like my Firmware does.

They probably already connected SDO to 3.3V internally on their circuit.

Solution for you:

  • Let SDO unconnected
  • Change
    BME280_SENSOR_ADDRESS of bme280 inside BME280.h of my firmware from 0b11101100 (0x76) to 0b11101110 (0x77)

Let me know if this helped you.


@Halfbrain Sorry to say 'no change'
Removed the SDO line to GND
Change the BME280_SENSOR_ADDRESS to 0b11101110
see here:
#define BME280_SENSOR_ADDRESS 0b11101110 /**< Sensor address */
#define BME280_SENSOR_ID 0xD0 /**< ID of BMP280 */
#define BME280_SENSOR_RESET 0xE0 /**< Reset sensor */
#define BME280_SENSOR_CTRL_HUM 0xF2 /**< */
#define BME280_SENSOR_STATUS 0xF3 /**< */
#define BME280_SENSOR_CTRL_MEAS 0xF4 /**< */
#define BME280_SENSOR_CONFIG 0xF5 /**< */+++++
and BME280 still unresponsive. See here:

What to do next?



But the values looking somehow possible....

Do you have a link to your project on mBed. I would test it with my Hardware if you want.


@halfbrain Here you go .. I published a fork and here is the URL:

Let me know what you find...


Your project works on my Hardware. I only changed address back to 0x76 as my Firmware(Sensor) uses this one.

Has to be a Hardware problem. I have to think about that. At the moment in my opinion it should work if u use 0x77 for BME280 Address. But you showed me values in your screenshot that seem somehow possible but don't change from time to time which would mean that the sensor doesn't get new values in his registers.