Help with "sprintf" formatting for doubles in preparation for JSON

My code is working up until the point where I try to format it for JSON. I’m trying every format I can, but just can’t seem to work out why I can’t get the double values to format properly. Keep in mind that I’m not proficient in C.

If I configure it to out put my variables analogT1 and analogT2, I can get those, but I would rather the computations be done before I send them to the Google spreadsheet.

Values for T1 and T2 should be around 82.99340659340658 and 73.27472527472527. I only need 1 decimal place.

referencing to this guide:
Example: Logging and graphing data from your Spark Core using Google

double temp1 = 0.0;
double temp2 = 0.0;
int pinT1 = A1;
int pinT2 = A2;
char resultstr[64];

void setup()
  // Use serial port for debug print

  // register API variable
  Spark.variable("temp1", &temp1, DOUBLE);
  Spark.variable("temp2", &temp2, DOUBLE);
  Spark.variable("result", &resultstr, STRING);
  pinMode(pinT1, INPUT);
  pinMode(pinT2, INPUT);

void loop()
  int analogT1 = analogRead(pinT1);
  int analogT2 = analogRead(pinT2);
  double voltageT1 = 3.3 * ((double)analogT1 / 4095.0);
  double voltageT2 = 3.3 * ((double)analogT2 / 4095.0);

  temp1 = ((voltageT1 - 0.5) * 100)*1.8 + 32;
  temp2 = ((voltageT2 - 0.5) * 100)*1.8 + 32;

  sprintf(resultstr, "{\"temp1\":%d,\"temp2\":%d}", temp1, temp2);


Try sprintf(buf, "%0.1f", var) and have a read

This is what I get:

“result”: “{“temp1”:,“temp2”:}”,

no values??

with this code:

sprintf(resultstr, "{\"temp1\":%0.1f,\"temp2\":%0.1f}", temp1, temp2);

and this result:

“result”: “”,

with this code:

sprintf(resultstr, "%0.1f", temp1);

Hmm, I’ll have to check again, but it should have worked.

Meanwhile try sprintf(resultstr, "%3.1f", temp1);, meaning at least three places (including decimal seperator) and one decimal place.

BTW: Are you using a Core or a Photon? If you use a Photon, you might like to read this
0.4.3 Firmware Release for Photon/P1

1 Like

I’ve just checked up with our master of bit and bytes and all the hard stuff and I have to row back a bit.

This problem still exists
Issues with converting float to string with sprintf

One half of the equation - the system firmware - has been fixed already, but the user side of it - especially the cloud compile - has not been updated yet.
So you might have to use one of the suggestions given in the above link.

Sorry for the inconvenience :blush:

1 Like

That did not work either. Funny enough, my Spark Core just went solid red last night (which I had been using to this point) and I could not reset it quickly, so this morning (<17hours ago when the update was posted) I got my Photon up and running and this code is on the Photon. I got the rapid lights indicating that the Photon was updating itself, so I would assume I have the recent firmware.

Stupid question? How can I easily check my firmware version without plugging in to a computer?

Ok, I just got your comment after my reply. I’ll just x100 my values and convert to an integer for now.

1 Like

Not a stupid but a valid question and a much anticipated one too :wink:
At the moment you don’t seem to be able to, but it’s on the ToDo list.

If you want to be sure to have 0.4.3 you’d need to flash it, as outlined in the thread above (#13327)
But as said in my previous post, that would only bring you half way to the solution of the problem.

Ok, I cheated this and it’s got me what I need for now:

for my last bit of code I just did this:

  temp1 = 100*(((voltageT1 - 0.5) * 100)*1.8 + 32);
  temp2 = 100*(((voltageT2 - 0.5) * 100)*1.8 + 32);
  int inttemp1 = (int)temp1;
  int inttemp2 = (int)temp2;

  sprintf(resultstr, "{\"temp1\":%d,\"temp2\":%d}", inttemp1, inttemp2);

to get this:

“result”: “{“temp1”:8168,“temp2”:7138}”,

Not elegant, but it works…


@estrauss If you just want to see the numbers during testing while they solve the issue you could do something like this:

sprintf(resultsrt, “{“temp1”:%d.%d “temp2”:%d.%d}”, inttemp1/100, intemp1%100, inttemp2/100,intemp2%100);

although i don’t think that it’s a very good strategy long term. Obviously that just replaces your last line you still need to multiply by 100