Interfacing GSM sim900 with atmega16.

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right now I am trying a simple code of calling by GSM sim900 using atmega16
MY SETUP:Rx and Tx pins of atmega board are connected to Tx and Rx of my GSM modem and also to my uart bridge which i connect to my PC(done by splitting the Rx and Tx pins)-This was done so i could know whether my AT commands were given to modem or not
 

OBSERVATION;

AT commands appeared as i wanted in terminal(X-CTU I have Used) that means they were actually given to modem also(since i splitte the wires).But no call was made.However when i myself entered the AT commands During the same process I was succesful
 

MY code:

#define F_CPU 12000000UL
#include <util/delay.h>
#include <avr/interrupt.h>
#define BAUD 38400                                //setting up baud rate
#define bd (int)(F_CPU/16/BAUD-1)          //value of UDRR to be set
#include <avr/io.h>

void command(char*a)                   //function to send a string using pointers
{
  int i;
  for(i=0;a[i]!='\0';i++)
  {
    while(!(UCSRA&(1<<UDRE)));
    UDR=a[i];
    _delay_ms(100);
  }
}

flush ISR (USART_RXC_vect)        //flushing any type of echoes obtained
{
  char recdata;
  recdata=UDR;
}

int main(void)
{
  sei();
  UBRRH=(bd>>8);
  UBRRL=bd;
  UCSRB|=1<<RXEN|1<<TXEN|1<<RXCIE;
  UCSRC|=1<<URSEL|1<<UCSZ0|1<<UCSZ1;
  _delay_ms(2000);
  command("AT\r");
  _delay_ms(2000);
  command("AT\r");
  _delay_ms(2000);
  command("ATD+919933988118;\r");
  _delay_ms(20000);
  command("ATH\r");

  while(1)
    {

    }
}

Can any one please help me why my atmega is unable to do so or is there any problem in my code?

yo mechatronix

Last Edited: Mon. Mar 9, 2015 - 11:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does the code even compile? "flush" is not a recognised keyword in C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually i have made it as a function named as flush...that is only for flushing the echoes obtained from gsm module

 

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but:

flush ISR (USART_RXC_vect)        //flushing any type of echoes obtained
{

is not valid syntax for the avr-gcc compiler. You don't get to name the ISR() functions - they have fixed names. In this case USART_RXC_vect which in turn translates to something like __vector_12 or whatever. You cannot just add the word "flush" as you have done there.

 

When I try to compile your code I get:

error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’

on the line that uses "flush".

 

So if you cannot even compile this code how do you know whether it might work or not?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would also question your "splitting" of the comm lines to two different places with out them causing a problem for one or both.

Can you show a schematic for your split cabling?  

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

shubh-agrawal wrote:
However when i myself entered the AT commands During the same process I was succesful

And what do you think is the key difference between you manually typing commands, and a microcontroller sending commands under program control...?

 

All AT commands give responses. They do this for a reason - use them!!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Leave this funtion aside as i had commented it out in my code.That was just to ignore the Responses OK obtained after AT comands.Prefer disabling of RXEN.I will only transmit (enable only TXEN),the AT commands.You can see my doubt that i could see on terminal that my AT commands were send to modem but call wasnt recieved by me.However when i manually tried it ,it worked though?
Is it necessary to take into account the Ok responses obtained from modem or my method of transmitting them is wrong.Please send me code that u seggest me to follow.

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

shubh-agrawal wrote:
Is it necessary to take into account the Ok responses obtained from modem

Yes! That is the modem's indication to you that it is ready for another command - ignore it at your peril!

 

And what happens if the response is not "OK"..?

 

Quote:
or my method of transmitting them is wrong.

Your method is like driving a car with your eyes shut, and just hoping that you turn the wheel at the correct time - and that there's no other cars in the way!!

 

surprise

 

Again, see: http://www.keil.com/forum/21658/

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried out your solution.In my code I have put on a while loop that if my response is OK<cr> then only send the next At command.But also for debugging purpose i have set my Led ports high if it does not come out of the loop.And alas ,my leds are always on for which i understood that i am never getting an OK response.But when I am sending them manually, I am gettting the responses OK.

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before connecting the AVR to the SIM900 I would connect the AVR to your PC (just as you have dome previously with the SIM900). Then try to make the AVR send and receive data you can see in the PC terminal program. Only when this works - which proves that the AVR is configured correctly and running at the right speed would I then drop the PC from the picture and connect AVR direct to SIM900. At the moment you have no way to tell if the two are even talking at the same speed. You may well be sending ATZ, ATE1 or whatever to the modem but if the speed is wrong the modem won't be receiving it and it will never say "OK" or anything else.

 

If you don't have an easy way to connect your AVR to the PC at the very least set up a simple test where the AVR just sits in a loop sending out the character 'U' with 8-N-1 framing over and over again. That will produce a constant 10101010101010... signal on the TXD pin. Then use a device such as a 'scope, logic analyser or frequency meter to measure that signal and make sure the bit width is the correct value for the baud rate you are trying to use. At 38400 (is that really what the SIM900 defaults to?) the bit width is 26us.

 

BTW 12MHz is an "odd" crystal to be using - you sure it is 12MHz?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes ,I am sure my crystal is 12Mhz.And I have set default the baud rate of my moden to 38400.Using a another AT command through putty.I am pretty sure that I am alright with my speed parameters.

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

shubh-agrawal wrote:
I have put on a while loop that if my response is OK<cr>

It won't be.

 

It will be at least <cr><lf>OK<cr><lf>

 

Do you have echo enabled...?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Done with that .still the same problem...

 

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes perhaps,because in terminal of XCTU i do get echo of each and every charachter that I send....Hoe can they be disabled?

 

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A simple search of the AT Commands documentation for the word "echo" should answer that...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had run the same algo of code over arduino mega wherein I never checked for reponse and always relied over delay functions.And it worked,...then why not in atmega?

yo mechatronix

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like I said, it's like driving a car with your eyes shut, and just hoping that you turn the wheel at the correct time - and that there's no other cars in the way!!

 

Sometimes, you will get lucky; maybe many times - but, sooner or later, your luck will run out.

 

That time has come!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even I m facing the same problem. So someone plz post a solution for this

Lolly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it is the same problem then, clearly, all the same answers will apply!

 

Have you taken into account all the answers given so far?

 

Where does that leave you?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...