VW - Sending and receiving numbers & decimal place

I am trying to get a number with one decimal place xxx.x to be received. I am using an example from Paul S. shown below, however, I receive a number with a zero value in the decimal place - not the actual value. For example, 55.9 will return 55.0 at the receiver; as will 55.3. I can't seem to get the tenths to display a real value.

Can someone guide me?

int flowMPH1 = (int)flowMPH; int flowMPH2 = (int)(flowMPH - flowMPH1)*100.0; // For two decimal points char msg[24]; sprintf(msg, "%i.%i", flowMPH1,flowMPH2);// vw_send((uint8_t *)msg, strlen(msg));

Have you confirmed that flowMPH is correct? Have you confirmed that flowMPH1 and flowMPH2 are correct? Have you confirmed that msg is being created correctly?

The 2nd %i should really be %0.2i, to assure 2 digits in the output, with leading zeros as required (53.09 would appear as 53.9 with your statement).

What is on the receiving end of the virtual wire? What code is on that device to read the value? Perhaps the issue isn't with the sender.

Presumably flowMPH is in a format that supports decimal points. Try creating flowMPH2 in whatever format that flowMPH is in, and then convert to an int(). Add a serial print in there to see that it's really getting created as expected. (or, I guess that's what sprintf does)

why so many characters here: char msg[24];

You only seem to be transmitting maybe 9 bytes out?

flowMPH must be a float otherwise flowMPH2 will always be zero due to the subtraction: flowMPH - flowMPH1.

Can you share your whole sketch? As this gives more insight what is happening.

Add an extra pair () to be sure that the division is done before casting to int. See below: Might help.

int flowMPH1 = (int)flowMPH;
int flowMPH2 = (int)[glow]([/glow](flowMPH - flowMPH1)*100.0[glow])[/glow]; // For two decimal points

char msg[24];
sprintf(msg, "%i.%i", flowMPH1, flowMPH2);//
vw_send((uint8_t *)msg, strlen(msg));

Thank you SOOOOOOOOO much for the replies! YOU ARE ALL CORRECT! The problems were multiple. And one potential one remains.....

  1. As PaulS pointed out, there was the following error in the sprintf statement:

" . . . The 2nd %i should really be %0.2i, to assure 2 digits in the output, with leading zeros as required (53.09 would appear as 53.9 with your statement). . ."

  1. As CrossRoads stated, yes the flowMPH was in the proper form (float) to support decimals; and this was the clue. Flow MPH1 and flow MPH2 are stated as int types - but apparently they must be defined as floats as shown in the snippet below in order to provide the proper output at the receiver end.

  2. As Robtillaart kindly explained, the entire formula needed another set of parentheses so that division is completed prior to casting. DOH! And I will post the final code when I am less ashamed of how it looks right now. I feel like I am building a Frankenstein. At present - there is a lot going on with the project as I measure wind speed using pulse interrupt method, as well as 16 point wind direction, 3 minute and 10 minute average speed, instantaneous (measured at 11.25 degree anemometer rotation interval) peak gust and will be adding wind chill and heat indices next. The project motivation is to re-build an existing high quality wired weather station platform to be wireless at its existing console, and to have the capacity for an additional tiny roaming lcd device to monitor conditions away from the console. Probably not a great starter project for one who has never dabbled in programming, but one that has certainly been very rewarding to watch come true - thanks to your help and that of others here.

  3. Wow! I coulda' had a V8! ( a reference to a silly ad for vegetable juice - that states something that should have otherwise been obvious)!

Potential problem? I have noticed that in a clam condition, and if the anemometer comes to rest at a very very tiny spot in between ON/OFF coded interruptor disk, the output of the photo transistor may fire randomly, resulting in an annoying (non true reading). This condition would be rare, indeed, but possible - so I really would like to eliminate it. Any ideas????

At the point I asked for help (up to a few moments ago), I was completely frustrated - time to walk away - but not nearly ready to quit. That simply will not happen. A common thread here on the forums as well, thankfully.

In any event, thank you all for the great assistance which is why this forum is so powerful. I am humbled by the patience, knowledge and skill of those among us here. I will also do the same when my knowledge surpasses my lack of knowledge - I am further convinced each day that it may be a while! ;)

Working code snippet:

int flowMPH1 = (float)flowMPH; int flowMPH2 = ((float)(flowMPH - flowMPH1))*100.0; // For two decimal points char msg[24];

sprintf(msg, "%i.%0.2i", flowMPH1,flowMPH2);// vw_send((uint8_t *)msg, strlen(msg));

John

John, You could do some software filtering on the random signal. Say, if a value is is suddenly higher than the average of the previous 5, ignore it. Analyze your data and see what makes sense.

Robert (CrossRoads)

 int flowMPH1 = (float)flowMPH;

If flowMPH is a float, as you said it is, the cast here is not necessary. If any explicit cast were used, it would be to cast flowMPH to an int, but that cast is implicitly performed, so no explicit cast is needed.

     int flowMPH2 = ((float)(flowMPH - flowMPH1))*100.0;

Here the cast applies to the output of the subtraction operator when flowMPH - flowMPH1 is performed. If a cast is used at all, it should be applied to the flowMPH1 variable, since the other operand is a float, as is the 100.0. If you have used 100, instead of 100.0, you could have used a cast in front of 100, but adding the .0 makes the value into a float, so no cast is needed.

Again, the only places where casting might be required is to cast flowMPH1 to a float and to cast the whole result to an int. That last cast will be performed implicitly, though.

Robtilaart's additional parens were the real solution, as the real problem was that the subtraction operation was cast to an int before the multiplication was performed.

Of course, removing all the explicit casts would have achieved the same results.