Bluetooth data value stuck at zero

[hippicurean]

Hi all,

I'm trying to send a simple numerical value from RealTerm (terminal program) to the NXT via Bluetooth. According to Lego's Bluetooth SDK, the Write command follows two bytes that specify the length of the package:
Length bytes: LSB followed by MSB (e.g. 6 bytes: 0x06 0x00)
Byte 0: 0x00 or 0x80 (direct command with or without response)
Byte 1: 0x09 (write command)
Byte 2: Mailbox number, 0-9
Byte 3: Message size (including null termination byte)
Byte 4-N: Message data, where N = Message size + 3 (including null termination byte)

Following the manual's instructions, I've formulated a command sequence to send a "1" to the NXT, i.e. 0x06 0x00 0x00 0x09 0x00 0x02 0x01 0x00.

On the NXT, I have constructed a simple NXT-G program to display the received data. The program is similar to the picture shown in the following URL albeit with a couple of minor differences. The data type is a number instead of a char/text, and a number-to-text block has been added before the display block.
http://www.legoengineering.com/activiti ... eceive.jpg

Unfortunately, the output on the display is always zero regardless of the value transmitted. Treating the received data as a text (instead of a number) produces a blank output. Transferring the display block inside the BT-receive loop doesn't help either. I've placed a sound block right outside the loop to detect breaks, and it does beep every time I send the command sequence. So, it's obvious that the NXT is receiving data. The status byte in the return data package shown on RealTerm is a further confirmation of the fact.

So, why is the value of the received data always zero? Or have I processed it incorrectly? Any help or insight would be really appreciated. Thanks very much.

Cheers
Hippie

[mcsummation]

Which NXT? v1 used fixed point values, v2 uses 32-bit floating point.

[tito-t]

are you sure that v 1.x uses fixed point numbers? I thought they just had integers...?

[mcsummation]

are you sure that v 1.x uses fixed point numbers? I thought they just had integers...?

Let's say they are "non-floating point numbers", because you can have integers represented in floating point.

There have been nomenclature issues for many years about this.

[hassenplug]

I have a couple ideas that you can work on.

First, if the message is read as a string, I believe the value you're sending is the ascii value. Try sending 65 (0x41) and see if you get an "A".

Second, I think when you send an Int, it has to be 4 bytes. So you could try:

0x06 0x00 0x00 0x09 0x00 0x04 0x01 0x00 0x00 0x00

I don't recall if sending an int requires the ending null bit, like sending a string would require.

I'd also try sending different values in the number bits, to see if anything is being received, and incorrectly decoded.

0x06 0x00 0x00 0x09 0x00 0x04 0x01 0x02 0x03 0x04

Hope that helps.

Steve