CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

SIM 808 GPS INFO - RETRIEVING DATA

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
rudy



Joined: 27 Apr 2008
Posts: 168

View user's profile Send private message Send e-mail MSN Messenger

SIM 808 GPS INFO - RETRIEVING DATA
PostPosted: Tue Jun 07, 2022 12:55 pm     Reply with quote

Hi there,

I am working with a SM808 GSM and GPS module, and I pick latitude and longitude data in the RS232 buffer, these values need to be converted from degrees and decimal minutes to decimal degrees, so, I take out the degrees and mount the decimals in other to divide them by 60 and obtain the desired result. I have to do this twice, once for the latitude and another for longitude. I ask if there is another “smarter” way to do that!
In this example, the latitude is = 25.41169, so I pick 25 and mount 24701446. The 24701446 divides by 60 = 41169, resulting in 25.41169.
Code:

void GET_GPS()
   {
   printf("AT+CGPSINF=0\r\n");
   delay_ms(500);
   LATITUDE[0]=25; //((GSM_BFR[0X0E]-48)*10)+((GSM_BFR[0X0F])-48);
   LATITUDE[1]=24; //((GSM_BFR[0X10]-48)*10)+((GSM_BFR[0X11])-48);
   LATITUDE[2]=70; //((GSM_BFR[0X13]-48)*10)+((GSM_BFR[0X14])-48);
   LATITUDE[3]=14; //((GSM_BFR[0X15]-48)*10)+((GSM_BFR[0X16])-48);
   LATITUDE[4]=46; //((GSM_BFR[0X17]-48)*10)+((GSM_BFR[0X18])-48);
   LTE=(float)LATITUDE[1]*1000000+(float)LATITUDE[2]*10000+(float)LATITUDE[3]*100+(float)LATITUDE[4];
   LTE=LTE/60;
   }

Regards;
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jun 07, 2022 2:14 pm     Reply with quote

Never worked with them, but... can you reprogram the GPS to send you the data (Lat and LONG) in the format YOU want ??
rudy



Joined: 27 Apr 2008
Posts: 168

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Tue Jun 07, 2022 2:16 pm     Reply with quote

Unfortunately no! The only think I got from it is the speed in KM/h, because the default unit is knots.

The standard units format from all SIM line is DDmm.mmm.

Regards!
PrinceNai



Joined: 31 Oct 2016
Posts: 480
Location: Montenegro

View user's profile Send private message

PostPosted: Tue Jun 07, 2022 6:05 pm     Reply with quote

Quote:

In this example, the latitude is = 25.41169, so I pick 25 and mount 24701446. The 24701446 divides by 60 = 41169, resulting in 25.41169


What are you trying to to convert? What does "mount" mean? No disrespect, just asking. Where did those 24701446 came from? What was the string from GPS and how should the result look like? In your example the end result is the same as the input.
Ttelmah



Joined: 11 Mar 2010
Posts: 19549

View user's profile Send private message

PostPosted: Wed Jun 08, 2022 1:54 am     Reply with quote

One tiny thing.
It is generally faster and smaller to multiply rather than divide. So the code
for val=source/60, will be larger and slower, than val=source*0.01666666.
Might be worth declaring a define for this, perhaps 'OVER60", and trying
multiplying instead of dividing. It may well save some space and time.

#define OVER60 (0.01666667)

val=source*OVER60;

Now the saving is greatest on the more basic PIC's (16,18), which don't
have a hardware divide instruction, and almost disappears on the DsPIC's.

On the PIC18, the multiplication is about 4* faster than the division.
On a basic test the multiplication code is 100 bytes smaller on a PIC18.
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jun 08, 2022 4:43 am     Reply with quote

Hmm, any chance he could use 'integer math' instead of the 'nasty' floating point ? If so, it should be a LOT faster.......
rudy



Joined: 27 Apr 2008
Posts: 168

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Wed Jun 08, 2022 5:31 am     Reply with quote

Hum.... That's fine for me. In fact, I always try the best and shortest ways to do the job. The processor is 18F2550, and it is running very well, but I do really get suspicious when I fell that I am not doing the best way it can....

Ttelmah wrote:
One tiny thing.
It is generally faster and smaller to multiply rather than divide. So the code
for val=source/60, will be larger and slower, than val=source*0.01666666.
Might be worth declaring a define for this, perhaps 'OVER60", and trying
multiplying instead of dividing. It may well save some space and time.

#define OVER60 (0.01666667)

val=source*OVER60;

Now the saving is greatest on the more basic PIC's (16,18), which don't
have a hardware divide instruction, and almost disappears on the DsPIC's.

On the PIC18, the multiplication is about 4* faster than the division.
On a basic test the multiplication code is 100 bytes smaller on a PIC18.
rudy



Joined: 27 Apr 2008
Posts: 168

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Wed Jun 08, 2022 5:34 am     Reply with quote

That's a good point temtronic, but I don't know how to do it. I tried with int32 variable, but it seem to not work well, really don't know why.

I love to test if you help me....Using float because in debugger, it works very well.

temtronic wrote:
hmm, any chance he could use 'integer math' instead of the 'nasty' floating point ? If so ,it should be a LOT faster.......
rudy



Joined: 27 Apr 2008
Posts: 168

View user's profile Send private message Send e-mail MSN Messenger

PostPosted: Wed Jun 08, 2022 7:30 am     Reply with quote

It worked flawless with int32... I think it is ok now! Besides it could be much more easily if the GPS send already in decimals degrees, it is ok. Now start decoding the speed, but this shall be easier because the units is km/h with the sentence "AT+CGPSINF=64\r\n".

Thank you all!

Code:
void GET_GPS()
   {
   GSM_LCK=1;
   int i;
   printf("AT+CGPSINF=0\r\n");
   delay_ms(500);
   LATITUDE[0]=((GSM_BFR[0X0E]-48)*10)+((GSM_BFR[0X0F])-48);
   LATITUDE[1]=((GSM_BFR[0X10]-48)*10)+((GSM_BFR[0X11])-48);
   LATITUDE[2]=((GSM_BFR[0X13]-48)*10)+((GSM_BFR[0X14])-48);
   LATITUDE[3]=((GSM_BFR[0X15]-48)*10)+((GSM_BFR[0X16])-48);
   LATITUDE[4]=((GSM_BFR[0X17]-48)*10)+((GSM_BFR[0X18])-48);
   LONGITUDE[0]=((GSM_BFR[0X1A]-48)*10)+((GSM_BFR[0X1B])-48);
   LONGITUDE[1]=((GSM_BFR[0X1C]-48)*10)+((GSM_BFR[0X1D])-48);
   LONGITUDE[2]=((GSM_BFR[0X1F]-48)*10)+((GSM_BFR[0X20])-48);
   LONGITUDE[3]=((GSM_BFR[0X21]-48)*10)+((GSM_BFR[0X22])-48);
   LONGITUDE[4]=((GSM_BFR[0X23]-48)*10)+((GSM_BFR[0X24])-48);
   LTE=(int32)LATITUDE[1]*1000000+(int32)LATITUDE[2]*10000+(int32)LATITUDE[3]*100+(int32)LATITUDE[4];
   LTE=LTE/60;
   sprintf(GSM_BFR, "<%lu>", LTE);
   LATITUDE[1]=((GSM_BFR[1]-48)*10)+(GSM_BFR[2]-48);
   LATITUDE[2]=((GSM_BFR[3]-48)*10)+(GSM_BFR[4]-48);
   LATITUDE[3]=((GSM_BFR[5]-48)*10)+(GSM_BFR[6]-48);
   LATITUDE[4]=0X00;
   LTE=(int32)LONGITUDE[1]*1000000+(int32)LONGITUDE[2]*10000+(int32)LONGITUDE[3]*100+(int32)LONGITUDE[4];
   LTE=LTE/60;
   sprintf(GSM_BFR, "<%lu>", LTE);   
   LONGITUDE[1]=((GSM_BFR[1]-48)*10)+(GSM_BFR[2]-48);
   LONGITUDE[2]=((GSM_BFR[3]-48)*10)+(GSM_BFR[4]-48);
   LONGITUDE[3]=((GSM_BFR[5]-48)*10)+(GSM_BFR[6]-48);
   LONGITUDE[4]=0X00;
   //SPEED IN KM/H   
//   printf("AT+CGPSINF=64\r\n");
//   +CGPSINF: 64,94.66,T,,M,0.000,N,0.000,K,A
   BFR_CNT=0;
   GSM_LCK=0;   
   GSM_GET_GPS=0;
   }
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group