Greetings

I want to send some float data to the NXT from a java client, but I'm having troubles. I thought it could be done as I was doing int, long and bool data: sending a byte array through bluetooth and rebuilding it in robotc (by means of masks and all that stuff), but it can't be done cause float data type doesn't support bitwise operations.

So my next step is sending a binary file from the PC to the NXT. This file would contain all the floats I want to pass to the NXT. The NXT would recieve this file and use the readFloat function in order to get the values. So, as I understand, the process would go like this (including questions :p)

1 - I create the binary file in java client and send it to the NXT (should I send it as a regular message to a mailbox?)
2 - The NXT recieves it and creates a file using the OpenWrite and WriteByte functions (Is it necessary to create the file? Is there any workaround?)
3 - Once the file is created and filled up with the bytes the NXT received from the PC, use the ReadFloat function in order to get the floats.

At this point, some questions come to my mind:

1 - How sould I write this file? I've seen file examples with some floats written in it and I don't really appreciate the format it's used
2 - Is it necessary to create a file? I've read that using the Flash memory is really slow... maybe I could do something similar using Datalog? By the way... how does datalog work? I couldn't find good documentation for this...
3 - Do you know any workaround to avoid using a file?

Any help would be appreciated

Thank you very much!!!

Are you sure you actually need full floating point values or will fixed point do? For instance, if the values that you need to send are between +/- 32,000 and the number of decimal places to the right of the decimal point is less than 4, then here is a solution using "fixed point".

Say you want to transmit the value: 1234.5678

You would break it up into two integers, one representing the value to the left of the decimal and one representing the value to the right. You might do it like this:

float ValueToTransmit = 1234.5678;

int LeftOfDecimal;
int RightOfDecimal;

LeftOfDecimal = ValueToTransmit; //* Will be truncated to 1234
RightOfDecimal = (ValueToTransmit - LeftOfDecimal) * 10000.0; //* Results in 5678

Then transmit these two integers and reassemble on the other side:

float ValueTransmitted;

ValueTransmitted = ((float) LeftOfDecimal) + (((float) RightOfDecimal) / 10000.0);
//* Results in 1234.5678

You can also make this work for other value ranges, too, as long as you don't need the large dynamic range that floats provide.

cu,
Gary

Really great idea Gary!!!

I didn't think about that...

I don't think I'll need more range (it depends on a general project), but, anyway, do you think it could work using longs instead of ints? (because long range is bigger than int). Or maybe the previous data type conversion will go wrong??

anyway, thank you very much for your solution. I think it's much better than mine

You're welcome!

Sure, longs should work as well as ints in this case, and would provide a range of +/- 2,000,000,000 and 9 digits of precision to the right of the decimal. And if you think about it, you can extend this precision indefinitely by adding more and more bits (just send two longs, four longs, eight longs, etc.). But that's why floats are so great, if you really need a huge dynamic range.

Let me know how it works out!

cu,
Gary

Hi,
A float is represented as: significant digits × base ^ exponent. The base being a constant, so a float is stored in memory as significant and exponent. With a memory copy function, either on the nxt or in java it might be possible to copy both the significant and the exponent to integer variables. These two integers can then be used to recreate the float value using the above formula.

This is how to proceed. You will have to find out the exact bit representation of a float on the nxt. Then memcopy the float to the bt byte array you send over bt. On the pc you collect this as (un)signed integers/bytes according to the bit representation of the float. Then you recalculate the float value.

This way you'll not loose any accuracy at all.

I recently spoke to Dick Swan about floats in ROBOTC. This is what he said:


So there you have it.

- Xander

Interesting idea, Aswin, but in my experience it is not a good idea to make any binary assumptions about floats or for transferring a float between computers. There are too many variables, including big-endian vs. little-endian (i.e. are bytes stored from right to left or from left to right on each processor?), how big is a float really (many compilers treat a float as a double, so you may end up with a 64-bit float, for instance, on one machine and 32-bit on the other), and so on.

Also, floats are cool for easy handling of non-integer values in C, but when's the last time you really used a value of 1,000,000,000,000 or 0.000000000001? So I still think that using "fixed point" rather than "floating point" for transfer between computers is a pretty robust, portable, and simple solution.

cu,
Gary

Gary,

It is indeed not a good idea to make assumptions, that's why I said that you'll have to find out how a float is stored in memory. See Xanders post for this.

But if you really want a simple solution I would just multiply the float value by a large factor (1000 if you wan to preserve 4 decimals) and store the result in a single integer that can be sent. After receiving you divide by the same number to get you original, but truncated, value back. This is a far simpler and quicker solution than the one described above. Also, you'll only need to send a single value. The downside of this solution is that the original value cannot be to large (max 3.2767 when you want to preserve 4 decimals or 32.767 when you only need 3, etc)

In the end, the best solution is the one that fits you and your project.

Nice improvement on the idea, Aswin. And if you use a long (a long is 32 bits on the NXT, isn't it?), you'll actually get a range of approximately +/- 2,000,000,000 to use, or 9+ significant digits - more than enough for most uses.

cu,
Gary

hey , what if the number is 1234.0964?