Olimex Nano Amount of Serial connections

Started by WimV, April 16, 2018, 01:34:51 AM

Previous topic - Next topic


I'm trying to set up serial communications with the serial monitor, an Olimex mod-gps module and the Olimex Nano GSM-module.

Now, I have used the Serial.Begin and Serial1.Begin to connect to the serial monitor and GPS-module respectively. I have tried to use a Serial2 connection, but it seems that the Nano doesn't support that.
Is there any way to create a softwareserial connection on 2 other pins like there is on Arduino with the SoftwareSerial library? And if so, how does it work and on which pins? Or does the Nano only support 2 serial connections and do I need to look for another microprocessor to establish multiple serial connections?

This is my code for setting up the serial connections, but I still need a third connection for the gprs. 

#include <TinyGPS++.h>

#define GPS Serial1
#define BAUDRATE 9600
TinyGPSPlus gps;

void setup() {

  pinMode (8, OUTPUT);
  digitalWrite (8, LOW);;
  while (!Serial);


Hello WimV!

Yes, Nano supports only 2 Serial connections: Serial (through USB); Serial1 (through the UEXT pins).

You can use software serial and there are examples from the Arduino itself to see how it works. Go to "File --> Examples --> SoftwareSerial --> SoftwareSerialExample":

  Software serial multple serial test

Receives from the hardware serial, sends to software serial.
Receives from software serial, sends to hardware serial.

The circuit:
* RX is digital pin 10 (connect to TX of other device)
* TX is digital pin 11 (connect to RX of other device)

Not all pins on the Mega and Mega 2560 support change interrupts,
so only the following can be used for RX:
10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69

Not all pins on the Leonardo and Micro support change interrupts,
so only the following can be used for RX:
8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).

created back in the mists of time
modified 25 May 2012
by Tom Igoe
based on Mikal Hart's example

This example code is in the public domain.

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup() {
  // Open serial communications and wait for port to open:
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only

  Serial.println("Goodnight moon!");

  // set the data rate for the SoftwareSerial port
  mySerial.println("Hello, world?");

void loop() { // run over and over
  if (mySerial.available()) {
  if (Serial.available()) {

Try it and see if this will solve your problem.

Stan, Olimex
May the Source be with You!


Thanks, I may try that out later since I presume it requires some external wiring to the module to connect the TX and RX pins of the GSM module to the right softwareserial pins.

Short sketch of my project: What I'm trying to do is to get data from the GPS, process that data to a usable JSON-string on the Nano and then wirelessly upload that JSON-string to a server using the GPRS of the GSM module. Then I use a webapp to get that data from the server and display the location of the GPS on a Google Maps map.

For the moment I have figured out another solution to my Serial problem (which probably isn't the best):
When the UEXT isn't powered, I can use the Serial1 connection on the pins that lead to the GSM module allowing me to communicate to the module. So I make sure that the UEXT pins are powered off by setting pin 8 to a HIGH output. Then I execute all the commands I need for my GPRS setup and close the Serial1 communication.
When the UEXT is powered, the Serial1 connection also works on the UEXT pins. So I power the UEXT by putting pin 8 to LOW output and then open the Serial1 connection again to communicate with my GPS module. Then I read out all the data I need for my application and close the connection to my GPS module and power off the UEXT.
In the third step, I reopen the communication to the GSM module and execute the necessary commands to upload the gathered data to the server I want to have the data on.

I do realise that this could lead to potential problems like having to wait for the GPS to reconnect to the satellites everytime it is powered off and on again so that's something I'll have to either live with or I'll have to revert to the solution with the softwareserial pins, which probably is the best solution in the long run.