SIM800 Serial not working on Nano, works OK on Mega

Hi,

I'm observing a strange serial behaviour between a Mega2560 and Nano.

Circuit is a simple hardware serial connection to a SIM800 GSM module.

Mega - Connection from Serial1 (using pins 18 & 19)
Nano - Connection from Serial (using pins 0 & 1)

Same sketch, except for changing Serial1 to Serial between the two processors. Very simple just sending a few "AT" commands and waiting for the response, to generate an SMS message.

In short, the Mega communicates fine with the SIM800, the Nano sends the data but the data us ignored by the module.

SIM800 is fixed baud at 38400 (thought it might be the auto-baud that was causing the issue).

Using a scope I can see the Nano transmitting, and the data stream looks the same as being sent from the Mega (i.e. timing correct, level the same and signal not inverted).

USB is disconnected when testing (so it's not the shared port issue that's causing the problem).

Anyone any clues as to why the Nano is being ignored?

I have a feeling it's something to do with the SIM800, as I've other systems with serial devices that communicate just fine on both processors.

Jim

Please post your full sketch.

If possible, you should always post code directly in the forum thread as text using code tags:

  • Do an Auto Format (Tools > Auto Format in the Arduino IDE or Ctrl + B in the Arduino Web Editor) on your code. This will make it easier for you to spot bugs and make it easier for us to read.
  • In the Arduino IDE or Arduino Web Editor, click on the window that contains your sketch code.
  • Press “Ctrl + A”. This will select all the text.
  • Press “Ctrl + C”. This will copy the selected text to the clipboard.
  • In a forum reply here, click the “Reply” button.
  • click on the reply field.
  • Click the </> button on the forum toolbar. This will add the forum’s code tags markup to your reply.
  • Press “Ctrl + V”. This will paste the sketch between the code tags.
  • Move the cursor outside of the code tags before you add any additional text to your reply.
  • Repeat the above process if your sketch has multiple tabs.

This will make it easy for anyone to look at it, which will increase the likelihood of you getting help.

If the sketch is longer than the 9000 characters maximum allowed by the forum, then it’s OK to add it as an attachment. After clicking the “Reply” button, you will see an “Attachments and other settings” link that will allow you to make the attachment.

When your code requires a library that’s not included with the Arduino IDE please post a link (using the chain links icon on the forum toolbar to make it clickable) to where you downloaded that library from or if you installed it using Library Manager (Sketch > Include Library > Manage Libraries in the Arduino IDE or Libraries > Library Manager in the Arduino Web Editor) then say so and state the full name of the library.

This is about as simple as it gets.

Test program sends "AT&V" to the SIM800 (command chosen as it returns a lot of data, so I can see activity on the data line using a scope).

When running on the Mega, data is returned, on the Nano, the SIM800 does not respond.

Yes, I have checked TX/RX and no, the USB lead is not connected when using the Nano !!

    // --------------------------------
    //  Mega2560
    // --------------------------------
    Serial1.begin(38400);

    while (!Serial1) {
        ; // wait for serial port to connect
    }

    Serial1.println("AT&V");

    // --------------------------------
    //  Nano
    // --------------------------------
    Serial.begin(38400);

    while (!Serial) {
        ; // wait for serial port to connect
    }

    Serial.println("AT&V");

Mega - Connection from Serial1 (using pins 18 & 19)
Nano - Connection from Serial (using pins 0 & 1)

So on a Mega that is TX(18) -> RX (sim) and RX(19) -> TX(sim)
And on the nano TX(1) -> RX(sim) and RX(0) -> TX(sim)
Just to check, Oh and then i thought.... How are you powering the SIM800 ??

Deva_Rishi:
So on a Mega that is TX(18) -> RX (sim) and RX(19) -> TX(sim)
And on the nano TX(1) -> RX(sim) and RX(0) -> TX(sim)
Just to check, Oh and then i thought.... How are you powering the SIM800 ??

Correct, that's how they are wired.
SIM800 is the SIM800L EVB board, powered at 5v from a regulator, capable of 2A, no ripple/spikes at any time.

I think the issue might be the pullup resistors in the Nano.

The SIM800 does appear to be receiving the data, but the TTL being sent back is only 5.0v/3.8v for 1/0, instead of going close to 0v. Disconnect the RX from the Nano and it's all the way to zero.

Tried a diferent Nano, same result.

Connected to the Mega it's all the way to zero.

Can the pullup be disabled on the serial? Tried pinMode(0, INPUT) but had no effect.

Jim

I have just about the same problem. Trying since a week to connect a sim800l to a nano but its just not returning any answer to the AT command in the serial monitor. At frist I thought I had grilled the module while soldering so I even bougth a new S5 Stack sim800l but here its the same issue.
Usually powersupply seems to be a problem with this module but the module is signalling via the slowly blinking LED that it even logged into the network.
Any advice is much appreciated.

A picture of the board and wiring:

And here the code (it never gets past “Initializing”):

#include <SoftwareSerial.h>

//Create software serial object to communicate with SIM800L

SoftwareSerial mySerial(11, 10); //SIM800L Tx & Rx is connected to Arduino #3 & #2

void setup()

{//Begin serial communication with Arduino and Arduino IDE (Serial Monitor)

Serial.begin(9600);

//Begin serial communication with Arduino and SIM800L

mySerial.begin(9600);

Serial.println("Initializing...");

delay(1000);

mySerial.println("AT"); //Once the handshake test is successful, it will back to OK

updateSerial();

mySerial.println("AT+CSQ"); //Signal quality test, value range is 0-31 , 31 is the best

updateSerial();

mySerial.println("AT+CCID"); //Read SIM information to confirm whether the SIM is plugged

updateSerial();

mySerial.println("AT+CREG?"); //Check whether it has registered in the network

updateSerial();}
void loop()

{updateSerial();}
void updateSerial()

{delay(500);
while (Serial.available())

{mySerial.write(Serial.read());//Forward what Serial received to Software Serial Port}

while(mySerial.available())

{Serial.write(mySerial.read());//Forward what Software Serial received to Serial Port}
}

Whoa...
No ground 0V connection to the modem ??

:astonished: your short comment saved me some more hours of trying. Many thanks, its working now, I can't believe it. I red a lot of posts and youtube videos, that GND connection is not really mentioned explicitly.
I would appreciate very much if someone can quickly explain to my why that ground connection is needed?
My understanding goes that far:

  • The nano board has power from the USB connection
  • The sim800L has power from an external Li-ion cell via GND and VCC
  • The data transfer between sim- modem and nano is happening via the 2 serial connections RX/TX

Why do I need to connect the modem GND to the Nano GND?

Thanks
Jacob

I would appreciate very much if someone can quickly explain to my why that ground connection is needed?

a voltage is just a difference of potential. so when you say a pin is at 5V what you really say it’s 5V above something you defined as GND.

if you have two boards, the GND definition could be different (will be if you are powering them separately) and thus when board 1 sends through Tx a 5V signal or 0V signal to the other board, the 5V could be seen on the other side as 3V for example or 7V (which would burn the pin) and 0V could be seen on the other side as -2V which would also be bad for your arduino.

You don’t want that and you want to make sure they have the same reference hence you join the grounds which levels things out.

All DC voltages... power or signal, are referenced to ‘something’. Just like most car electrical systems are using the chassis as the 0V rail. All the lights, horns etc use the +12V wiring to make things happen.

In the case of most micros, that is a common 0V usually called ground or Vss (substrate).

If those references aren’t tied together (common ground), it’s quite possible the whole module will wobble around between 0 and the signal voltage - hence the chips on the module (which /IS/ referenced to 0V via the power supply) will not recognise those fluctuating signals as ‘anything’ other than noise.

(J-M-L also explains the requirement quite well!)
Somewhere in the [Introductory Tutorials] section I wrote a thread on exactly this phenomenon and requirement. it was prefixed ‘BEGINNERS:’

Great, thank you both for the explanation. I am aware of potential differences and learned from you now that a common GND connections creates an equal level between boards.
I haven't look at all into how signals are transferred via serial connection RX/TX and I guess I need to learn a bit more about this.
So information exchange via serial connection is using patterns of varying electrical signals (Voltage differences?) that is why these can not be interpreted correctly if there isn't a common GND. Is that somehow correct?

Sry maybe you think I am a helpless case but I did some projects with Bluetooth controlled stepper before which worked out well even the Nano and the Stepper controller had seperate power sources (was maybe coincidence that it worked) and were only connected via RX/TX.

So information exchange via serial connection is using patterns of varying electrical signals (Voltage differences?) that is why these can not be interpreted correctly if there isn't a common GND. Is that somehow correct?

from helicopter view (ie it's a bit more complicated) you can see the Serial line (Tx) is asked to transfer a byte - 8 bits. Serial as the name indicates sends stuff one bit at a time (opposed to parallel).

So the hardware looks at each bits of your byte and if it's a 0 it sets the Tx pin at 0V (GND) and if it's a 1 it sets the pin at 5V. it keep the pins at that voltage for some time, that is defined by the baud rate, the number of bits per second you want to transfer. for example at 9600 bauds you would keep the voltage (0V or 5V) during 1/9600 seconds and thus can send 9600 bits per second.

so on the other side the Rx pin is an INPUT and has to check the voltage. Both boards have to agree of course on the baud rate so that they can decide when to read the value (otherwise you would not know how many 1 or 0 you have if you see 5V or 0V for some time).

as you understood, if the boards did not agree on what 5V really is (meaning agree on GND) and if they did not agree on the baud rate then all bets are off

To add to J-M-L’s explanation, you can read about ‘shift registers’... they are the hardware mechanism used to pump ‘parallel’ data out as ‘serial’ and vice-versa... it can be done with ‘bit bashing’ in software if you really need to.

Serial data has the advantage of using ‘a single’ conductor, but is ‘theoretically’ slower than parallel (in practice, fast hardware resolves most of that.

Parallel has the issue that the “multiple’ wires need to be ‘matched’ as the speeds increase - to eliminate ‘skew’ in the data travelling across the parallel conductors.
(rhere are other factors like the slew rate that get in the way too... LVDS helps)

The modern tendency is to go with high speed serial rather than parallel connections unless you can spend the time, and have space for the extra wires.

This really started to gain acceptance around the mid 80s. the time SATA, USB and PS./2 connections first appeared. Before this, we used parallel cables for ‘everything’.
On,y Rs-232, and the like was common, and they were often maxed out at 110, 300, 1200 or 9600 bits per second... now we frequently see multi-megabit or multi-gigabit serial connections !

thanks you both for the explanations and the great level of detail, much better understood now. I don't want to steal the topic from stuckinthemud so case sucessfully closed for me and I leave the chat for his issue. Great forum here,really.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.