Author Topic: Char[] issues - variable scope or something else? [SOLVED]  (Read 2684 times)

gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Char[] issues - variable scope or something else? [SOLVED]
« on: February 05, 2019, 03:21:06 AM »
Hi All,

Tldr; dtostrf(orgLon, 9,6, lonStr); does not appear to work!?!?!?  The lonStr is not correct when sprintf'ed in another function.

Writing what effectively is a GPS/GSM tracker.  I want to send a data string via HTTP over GSM.  This is using the Ardunio IDE, TinyGPS++ for nmea parsing.  The GPS object is a wrapper to TinyGPS++ with methods to control hardware etc...

I use global variables for some shared data.  The main() and associated functions deal mainly with state.  All the hardware and some other things are created as Objects and their variables are hence hidden.

There is a function to update GPS lat/lon location.
Another function to create the char[] message.

In top of the .ino file I have;

Code: [Select]
double orgLat = 0; // Last recorded Lat
double orgLon = 0; // Last recorded lon
double distance = 10000; // distance moved (default)
char latStr[10]; // lat string
char lonStr[10]; // lon string

Code: [Select]
void checkLocation(void) {

  // update location
  gps.getUpdatedFix(UPDATE_GPS_FIX_TIMEOUT_MSECS, UPDATE_GPS_NUMBER_OF_FIXES);

  distance = gps.distanceMoved(orgLat, orgLon);

  // save present location
  orgLat = gps.getLat();
  orgLon = gps.getLon();

  dtostrf(orgLat, 9,6, latStr);  //first number is length, last is numbers after decimal
  dtostrf(orgLon, 9,6, lonStr);
  dtostrf(distance, 9,2, distanceStr);
  DEBUG("distance: ");
  Serial.println(distanceStr);
}

If it print the latStr and lonStr in this function they are correct.

Code: [Select]
void sendMessage(void) {

  //Get a dateTime String
  sprintf(dateTimeStr, gps.getdateTime());


  //Put the message together
  sprintf(messageStr, "'%s,%sv,%sv,%sc,%s,%s,%s,%dm'", dateTimeStr, lipoStr, vccStr, tempStr, bilgeStr, latStr, lonStr, distanceStr);
  DEBUG("Message is: ");
  DEBUGln(messageStr);

If I print the latStr and lonStr in this function they are incorrect.

However in the messageStr gets populated with garbage.  latStr looks like a Latitude, but is not the most recent, the lonStr is only 3 digits long.  I am near London so Lon is negative - something like -0.45453377

Will post some actual code output later as on the train to work!
« Last Edit: February 07, 2019, 01:00:51 PM by Felix »

gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Re: Char[] issues - variable scope or something else?
« Reply #1 on: February 05, 2019, 01:49:06 PM »
Here is an example output;

checkLocation function output
Code: [Select]
getUpdatedFix: GPS Location: 51.014015,-0.439823, Date/Time: 2019-2-05T18:43:00.00Z, -----lat is:  52.015015lon is:  -0.439823


sendMessage function output
Code: [Select]
-----lat is:  52.015015lon is: .75
Message is: '20190205T18:43:00Z,3.3v,0.1v,20.5c,BILGE:OK, 52.015015,.75,    31.75m'

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Char[] issues - variable scope or something else?
« Reply #2 on: February 05, 2019, 02:36:23 PM »
Let's see... you don't include the declaration for distancestr so we have no idea how the dtostrf() function will behave.
Your sprintf format string for the output of distancestr is "%dm" which is probably not what you want.
And you're sure cutting it close declaring the character buffers to be 10 bytes long even with a size 9 format...
But the really good news is that your bilge is OK!


gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Re: Char[] issues - variable scope or something else?
« Reply #3 on: February 05, 2019, 02:56:57 PM »
Okay ... few issues.  Maybe I should have added I am a newbie at this.

Code: [Select]
char bilgeStr[12];
char latStr[30]; // lat string
char lonStr[30]; // lon string
char distanceStr[6];

distanceStr is fine (I think..)
Changed the sprintf to %s
Changed char buffers to 30.

Still no joy !?!?

Yes, Bilge is OK!  Would be worried it not.

gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Re: Char[] issues - variable scope or something else?
« Reply #4 on: February 05, 2019, 03:07:44 PM »
Okay... 6 is too small so changed;

Code: [Select]
char distanceStr[30];

gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Re: SOLVED - Char[] issues - variable scope or something else?
« Reply #5 on: February 05, 2019, 03:12:22 PM »
Thanks TomWS...

char distanceStr[6];

Was too short and probably over writing the previous declared variable (lonStr) ... which caused the garbage.

Now that's fixed.

You will be pleased to know bilge is still Okay.  And the temp in the house is a nice 20.5C

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Char[] issues - variable scope or something else?
« Reply #6 on: February 05, 2019, 05:27:05 PM »
Okay... 6 is too small so changed;

Code: [Select]
char distanceStr[30];
Your statement:
Code: [Select]
dtostrf(distance, 9,2, distanceStr);
requires distanceStr to be at least 10 bytes long (9 for characters, 1 for string termination).


gregcope

  • Full Member
  • ***
  • Posts: 174
  • Country: gb
Re: SOLVED - Char[] issues - variable scope or something else?
« Reply #7 on: February 06, 2019, 01:42:23 PM »
Yep. Stupid mistake on my part.

Is there a convention on buffer Char arrays?  Just make them huge? Ie 3x bigger and not bother with the RAM impact?

Thanks for your help.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: SOLVED - Char[] issues - variable scope or something else?
« Reply #8 on: February 06, 2019, 02:15:38 PM »
Yep. Stupid mistake on my part.
Simple enough to do, everyone's done it...

Quote
Is there a convention on buffer Char arrays?  Just make them huge? Ie 3x bigger and not bother with the RAM impact?
It's easy enough to make them 'right' sized.   Theoretically 10 characters were just enough for the format specification you had.  I tend to add a bit more because ya never know when you're going to change the format and mess up the memory.  The tricky ones are things like serial input buffers from command lines, etc.  You always think you have enough and then something blows up.  These processors are too memory anemic to waste space, but it is important to right-size.