Continue to Site

Welcome to

Welcome to our site! is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Data storing problem at server with sim300 and atmega16

Not open for further replies.

sundus abrar

Junior Member level 1
Jan 18, 2010
Reaction score
Trophy points
Activity points
hello every one!

i am using a sim300 module to transfer adc data from atmega16 to a remote server via gprs.i have got the commands right,i have connected to the server with both the atmega16 aswell as through hyperterminal.the server is using C sockets to listen to incoming i am facing 2 problems:

1. data i send from the hyperterminal is getting stored in the database i have enabled at the server but when i send data through MC,it does not update the is being received as i see the data on my server screen but it does not store :S am i missing some type of character that the hyperterminal program automatically adds to store data..?

2. i am sending ADC data with the following approach: an integer variable is assigned the ADC output reading which is inturn updated in a character array.when the array reaches the size 10, it is trigerred to transmit the data to the server. but i donot receive the ADC value at the receiver.instead i receive especial characters on my server screen.the transmit function im using caters for strings,is it a reason why my int vals arent being displayed?

plz if any one has experienced this issue, plz let me know,or if anyone has any kind of idea how to get this fixed..i really really need your help on this one!

ok so iv figured out why the database was not being updated,and i have fixed that too.but the second problem is still there. i know its some ascii to int/char conversion problem but could some one please point me in the right direction?i really need some help with this!

In order to troubleshoot your remaining issue we'll need to see your code.

So please post or upload your code dealing with the ADC and data transmission.

sure!plz take a look at my code.i think there is need for better programming at server end.i have used a 4x4 keypad and a 16x2 lcd too,so that code will be in the middle too.
if you could just interpret what type of data should be received at the server?all i receive is a weird character :s


  • My_Code.txt
    9.5 KB · Views: 38

I downloaded you code and took a quick look.

I'm going to assume you're using winAVR and ATMEGA16.

I do not see any conversion from raw data to ASCII routines.

If you have a ADC value stored in a variable "unsigned char adcvalue" and you send the raw data through the UART without first converting to ASCII characters, you will get gibberish at the other end.

Here's why, an unsigned char can have a value range of 0 to 255, while an ASCII character has the same range, only values between 32 to 126 are used to represent a normal SINGLE character:

Therefore, you must convert your raw data (number) to a string of characters (ASCII) before you send the value through the UART.

Assume you have a adcvalue of 134, this would be converted to a character array msg: msg[0] = '1', msg[1] = '3', msg[2] = '4', msg[3]= '\0'.

The quickest and easiest way to do this conversion, if your compiler has it implemented in it's Standard C Library, is use the sprintf() in stdio.h.

example: sprintf(msg, "%d", adcvalue);

You can build an entire message using sprintf() if you make your message buffer long enough:

char msg[20];
unsigned char adcvalues[10];

// Load adcvalues with 10 adc readings

for(i=0; i<10; i++)
        sprintf(msg, "ADC%d = %d/n", i, adcvalue[i]);
        sendmsg(msg); //send to UART, SMS, etc

Would result in output as such:

ADC0 = 56
ADC1 = 134
ADC2 = 45
ADC3 = 236

Hope the info helps, let me know after adding conversion routines if you're still having problems.

thank you for your response bigdogguru!i was trying this conversion at the server end,i got decimal values but they were way out of range.i will try this before transmission now.i will get back at you with the results!thanks again for your response.

Not open for further replies.

Part and Inventory Search

Welcome to