Subject:
|
RE: Bluetooth Comm Problem
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Wed, 14 Feb 2007 03:52:18 GMT
|
Reply-To:
|
<DICKSWAN@SBCGLOBALavoidspam.NET>
|
Viewed:
|
14358 times
|
| |
|
|
The NXT-G firmware implementation for mailbox messaging is extremely
funky. I don't think your code is working properly for this
implementation.
You need to be continuously calling "ReadMessage" and only check for "a
message was found" error code. Any other error code is meaningless.
There doesn't appear to be any return code that indicates a recent "read
message" request has received a reply.
It appears that "ReadMessage" returns the following error codes.
"NO_ERR" is returned when it found a message. It immediately returns the
message and this status without looking at the transmission state of the
BT channel.
"STAT_COMM_PENDING" is returned when there was no message and the BT
transmission state was initially idle. In this case it sent the "read
message" request over the BT channel. This error code is only returned
once for the call to "ReadMessage" where the poll request was actually
initiated.
"STAT_MSG_EMPTY_MAILBOX" is returned when there was no message queued
and the BT transmission state was not idle. This error code will be
returned immediately after the poll request was launched but the reply
was not yet received.
For mailbox messaging to work the user application program has to be
continuously calling "ReadMessage" function. It is this function call
that provides execution time to the mailbox "polling" system.
To quickly check that above is a correct representation, change your
code to only exit the "read mailbox message" loop after it has seen
either a valid mailbox message or two "STAT_COM_PENDING" return codes.
I'm surprised that this confusing behavior hasn't been previously
reported. I guess it probably means that there haven't been many users
writing code for mailbox messaging in a text based language.
Being curious, I looked inside the source code for the NXT-G "Message
Read" block. [Source code for many NXT-G blocks is available with the
LabView tool kit for building blocks]. It has the following algorithm.
1. Do a "ReadMessage" and check the return code.
2. If the return code was not "STAT_COM_PENDING" then finish the block
right away.
3. If return code was "STAT_COM_PENDING" then loop for 200 milliseconds
performing "ReadMessage" within the loop. Exit the loop if the return
code was not "STAT_MSG_EMPTY_MAILBOX".
|
|
Message has 2 Replies:
 | | Re: Bluetooth Comm Problem
|
| Dick, Thanks for the research and all of the valuable information! It's Valentine's Day, so my wife won't allow me the time to try it tonight, but I'll try your suggestions tomorrow and see how it works. By the way, I actually saw a response come (...) (18 years ago, 15-Feb-07, to lugnet.robotics.nxt)
| | | Re: Bluetooth Comm Problem
|
| Dick, Thanks! I tried it out tonight and got consistent messages from the PC. You were correct about having to continually do message reads until I get something. I didn't have to do the wait for a second STAT_COMM_PENDING (32) or the 200 ms wait. I (...) (18 years ago, 16-Feb-07, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | Re: Bluetooth Comm Problem
|
| (...) I was a little confused about how I was supposed to determine when the message had been received. I wasn't sure whether the ReceiveMessage should be called multiple times or not. Here is my code: // Connection = 1, Queue = 0 (...) (18 years ago, 13-Feb-07, to lugnet.robotics.nxt)
|
8 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
