user37223: I have a LoRa Click Module and Adafruit Ultimate GPS which both use Serial Communication.
I wish to just check the initial tests with all the components in on the Serial Console. Hence I have declared :

SoftwareSerial GPSSerial(10,11);
SoftwareSerial LoRaSerial(5,6);

Apparently when I declare them and upload the code on the board I do not obtain any information.
observations

However when I comment out the LoRaSerial declaration I obtain the GPS coordinates.
When I set the SoftwareSerial LoRaSerial(10,11) I retrieve the information.
I thought 5,6 pins won't be the right choice and hence went on the set SoftwareSerial(8,9) but I retreive no information.

inference
Nano cannot take into consideration more than 1 SoftwareSerial Component. However the Official Documentation states that all Digital pins can be used for Software Serial.
Is it too much for a Nano to have overall 3 Serial ports (including Serial itself)?
sketch
#include <SoftwareSerial.h>
#include <TheThingsNetwork.h>

SoftwareSerial GPSSerial(10, 11); //RX , TX
SoftwareSerial LoRaSerial(8,9); // RX, TX (tried with 5,6 too)    
#define freqPlan TTN_FP_EU868


 TheThingsNetwork ttn(LoRaSerial, Serial, freqPlan);
void setup() {
  Serial.begin(115200);
  GPSSerial.begin(9600);
  LoRaSerial.begin(57600);
}
void loop() {
  delay(2000);
  while (GPSSerial.available()) {
    char c = GPSSerial.read();
    Serial.write(c);
  }
  delay(2000);
  while (LoRaSerial.available()) {
    ttn.showStatus();
  }
  delay(2000);
}


user4143: You cannot use two SoftwareSerial instances at the same time - or not for receiving anyway.
SoftwareSerial is a "last resort" system - only to be used if there is absolutely no other option. And then you need to be aware of certain information and rules:

Only one device can listen at any time, switchable using the SoftwareSerial::listen() method
When a byte is being received nothing else can happen - it takes over the entire CPU for the duration of reception
When a byte is being transmitted nothing else can happen - it takes over the entire CPU for the duration of transmission
There is a minimum required time between successive bytes when receiving that causes problems at higher baud rates

These limitations mean that, when using multiple devices, you have to know before hand which device will be sending you data so you can be ready to receive it. It also means that SoftwareSerial is effectively half duplex - it only really works properly when you are either only receiving, only transmitting, or using a "call-response" scenario like sending "AT" commands and looking for a response afterwards.
So the general recommendation is: use hardware UARTs whenever possible (and if you don't have enough, then consider using a different, more suitable, board with multiple UARTs), and if you must use SoftwareSerial then limit yourself to only one instance of it.
As a last resort you can always use multiple boards and connect them using a different system, such as I2C.

37223: <p>I have a <a href="https://learn.mikroe.com/lora-rf-click-solution-for-iot-developers/" rel="nofollow noreferrer">LoRa Click</a> Module and <a href="https://www.adafruit.com/product/746" rel="nofollow noreferrer">Adafruit Ultimate GPS</a> which both use Serial Communication.</p>

<p>I wish to just check the initial tests with all the components in on the Serial Console. Hence I have declared :</p>

<ul>
<li><code>SoftwareSerial GPSSerial(10,11);</code></li>
<li><code>SoftwareSerial LoRaSerial(5,6);</code></li>
</ul>

<p>Apparently when I declare them and upload the code on the board I do not obtain any information.</p>

<h3>observations</h3>

<ol>
<li><p>However when I comment out the <code>LoRaSerial</code> declaration I obtain the GPS coordinates.</p></li>
<li><p>When I set the <code>SoftwareSerial LoRaSerial(10,11)</code> I retrieve the information.</p></li>
<li><p>I thought <code>5,6</code> pins won't be the right choice and hence went on the set <code>SoftwareSerial(8,9)</code> but I retreive no information.</p></li>
</ol>

<h3>inference</h3>

<p>Nano cannot take into consideration more than 1 SoftwareSerial Component. However the Official Documentation states that all Digital pins can be used for Software Serial.</p>

<p>Is it too much for a Nano to have overall <strong>3</strong> Serial ports (including <code>Serial</code> itself)?</p>

<h3>sketch</h3>

<pre><code>#include &lt;SoftwareSerial.h&gt;
#include &lt;TheThingsNetwork.h&gt;

SoftwareSerial GPSSerial(10, 11); //RX , TX
SoftwareSerial LoRaSerial(8,9); // RX, TX (tried with 5,6 too)    
#define freqPlan TTN_FP_EU868


 TheThingsNetwork ttn(LoRaSerial, Serial, freqPlan);
void setup() {
  Serial.begin(115200);
  GPSSerial.begin(9600);
  LoRaSerial.begin(57600);
}
void loop() {
  delay(2000);
  while (GPSSerial.available()) {
    char c = GPSSerial.read();
    Serial.write(c);
  }
  delay(2000);
  while (LoRaSerial.available()) {
    ttn.showStatus();
  }
  delay(2000);
}
</code></pre>
 4143: <p>You cannot use two SoftwareSerial instances at the same time - or not for receiving anyway.</p>

<p>SoftwareSerial is a "last resort" system - only to be used if there is absolutely no other option. And then you need to be aware of certain information and rules:</p>

<ul>
<li>Only one device can <em>listen</em> at any time, switchable using the <code>SoftwareSerial::listen()</code> method</li>
<li>When a byte is being received nothing else can happen - it takes over the entire CPU for the duration of reception</li>
<li>When a byte is being transmitted nothing else can happen - it takes over the entire CPU for the duration of transmission</li>
<li>There is a minimum required time between successive bytes when receiving that causes problems at higher baud rates</li>
</ul>

<p>These limitations mean that, when using multiple devices, you have to know before hand which device will be sending you data so you can be ready to receive it. It also means that SoftwareSerial is effectively half duplex - it only really works properly when you are either only receiving, only transmitting, or using a "call-response" scenario like sending "AT" commands and looking for a response afterwards.</p>

<p>So the general recommendation is: use hardware UARTs whenever possible (and if you don't have enough, then consider using a different, more suitable, board with multiple UARTs), and if you <em>must</em> use SoftwareSerial then limit yourself to only <em>one</em> instance of it.</p>

<p>As a last resort you can always use multiple boards and connect them using a different system, such as I2C.</p>
