Getting Arduino Pro Mini + RN2483 + DHT22 to work with SoftwareSerial

End Devices (Nodes)
1

Hi,

i am not able to write a code to send temperature and humidity data from the Arduino Pro Mini via RN2483.
If i use the DHT example from TTN Github the Arduino IDE gives me every time a serial1 error.
I had read, that Serial1 does not work for the pro minis. Now i want to edit this code:

#include <TheThingsNetwork.h>

// First install "DHT sensor library" via the Library Manager
#include <DHT.h>

// Set your AppEUI and AppKey
const char *appEui = "0000000000000000";
const char *appKey = "00000000000000000000000000000000";

#define loraSerial Serial1
#define debugSerial Serial

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan REPLACE_ME

#define DHTPIN 2

//Choose your DHT sensor moddel
//#define DHTTYPE DHT11
//#define DHTTYPE DHT21
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup() {
  loraSerial.begin(57600);
  debugSerial.begin(9600);

  // Wait a maximum of 10s for Serial Monitor
  while (!debugSerial && millis() < 10000);

  debugSerial.println("-- STATUS");
  ttn.showStatus();

  debugSerial.println("-- JOIN");
  ttn.join(appEui, appKey);

  dht.begin();
}

void loop() {
  debugSerial.println("-- LOOP");

  // Read sensor values and multiply by 100 to effictively have 2 decimals
  uint16_t humidity = dht.readHumidity(false) * 100;

  // false: Celsius (default)
  // true: Farenheit
  uint16_t temperature = dht.readTemperature(false) * 100;

  // Split both words (16 bits) into 2 bytes of 8
  byte payload[4];
  payload[0] = highByte(temperature);
  payload[1] = lowByte(temperature);
  payload[2] = highByte(humidity);
  payload[3] = lowByte(humidity);

  debugSerial.print("Temperature: ");
  debugSerial.println(temperature);
  debugSerial.print("Humidity: ");
  debugSerial.println(humidity);

  ttn.sendBytes(payload, sizeof(payload));

  delay(20000);
}

is it done with softwareserial? Thanks!

2

It seems it’s not possible:

And for those using an Arduino Uno: note that despite its name, the TTN Uno is not an Arduino Uno.

3

Great thanks arjanvanb for response,
will work on softSerial, think it will be possible like Swiss made:slight_smile:

4

See There: Minimalistic Arduino/ATtiny SoftwareSerial example code for RN2483 module

5

SoftwareSerial works just fine with an RN2483 and whatever Arduino or ATmega or ATtiny you have. I’ve just finished an application with three serial devices: an SC6Dlite led-display, a MH-Z14A CO2-sensor and an RN2483, all accessed through three distinct SoftwareSerial ports. There is no hardware handshake so you have to be careful when polling if the port is ready, or delivering characters. The catch is, only one may be open at any one time, so each access has the following basic flow:

#include <SoftwareSerial.h>

#define rxpinPort 4
#define txpinPort 5
SoftwareSerial port(rxpinPort, txpinPort);

void setup() {
}  

void loop() {
  port.open(baud rate);
  while (!port) {
    delay(100);
  }
  while (port.available) {
    // get data
  }
  port.write(yourData);
  port.end();
}

Even on an ATtiny85/8 this works, but not at great speeds: the internal clock is not that precise and needs configuring for baud rates greater than 9600. Or use an external crystal. But an RN2483 operates fine at those speeds.

6

more info on this subject

7

The issue with soft serial is you need to be listening when characters arrive, If the arduino is doing anything else for even part of the time a character is transmitted by the sender you will get garbage if anything at all. The RN2483 requires the user to get the response codes to determine what happened so it requires very careful management of the code.
Hardware serial is a lot easier to manage as no data loss should occur.

Are you handling all RN2483 responses in your code? Or do you just send the commands and expect everything went according to plan?

8

I completely parse the possible response-tree that follows the mac commands for the RN2483, i.e. join and tx in order to be able to receive new settings through the downlink. The SoftwareSerial ports do have a 64 byte character buffer, so that even when an Arduino or ATtiny is doing something else while the RN2483 (or any other serial device for that matter) is transmitting, the first 64 bytes are preserved. However, due to the nature of the one-active-port-at-a-time SoftwareSerial library you WILL lose characters if the port is not exclusively opened for that transmitting device. For instance, if I were to do a mac tx cnf 1 1234 to the RN2483, close the SoftwareSerial port, open another SoftwareSerial port and listen to that other device, I would lose the ok and mac_tx_ok that would inevitably come from the RN2483.

My application with three simultaneous SoftwareSerial ports and a regular update to TTN has been stable for two weeks now, with 24x7 use as a CO2 monitor-with-display. You’ll find the SoftwareSerial reference here: https://www.arduino.cc/en/Reference/SoftwareSerial