Bluetooth error 224

[mcsummation]

I've got an NXT car controlled by another NXT. Both are programmed in NXC.

Data is sent to the car using 2 Bluetooth mailboxes. The car sends status data back to the controller using 3 mailboxes.

I'm getting "Bluetooth error: 224" on the master (controller) NXT. What causes this?

[afanofosc]

It will be a lot easier to answer this question of you show us your code. Is the 224 coming from the BluetoothStatus API function? 224 == E0 == ERR_COMM_CHAN_NOT_READY.

The firmware source code seems to suggest that this error happens when there is no connection on the specified connection number. It also can be returned when the Bluetooth system is busy trying to complete the last task you asked it to accomplish.

John Hansen

[mcsummation]

The code is a little scattered. However, it's probably coming from the BluetoothStatus. I can force it by turning off the other brick. However, the probable error is "not ready".

How can I determine when a BT function has completed? Do I just sit in a loop until the BTStatus goes to NO_ERR? I thought I had seen a "BT Wait" function, but can't find it now.

I'm using the "btwaitfor" function in protocol.h from http://www.alfonsomartone.itb.it/yepuji.html. (I'm not using any of the other code there and plan to build my own version of whatever code I need. I don't care for his coding style.)

Where are the definitions of the return values for BluetoothStatus?

[afanofosc]

If you'd rather not publish your code you can always send it to me via email but I would encourage you to just post it here. Just zip it up and attach the zip. Without it I can't tell what you are doing wrong but it is certain that you are doing something wrong. What code are you using on the slave to write back to your master? Hopefully just one of the SendResponse* functions. Is that correct?

On the master NXT you can use one of the SendRemote* API functions to write to your slave's mailboxes and use ReceiveRemote* to read data from the slave device.

There should really be no low level Bluetooth code on your slave NXT. It should just use ReceiveRemote* to read the data from a local mailbox and SendResponse* to write a response back to a local mailbox.

The only one of these that involves Bluetooth operations is the SendRemote* family of API functions and, in some cases, the ReceiveRemote* family of API functions when called from a master NXT with at least one slave attached to it.

John Hansen

[mcsummation]

It's not that I don't want to post my code, but it's a mess right now. I've got all sorts of junk in it from my experiments.

With your statement about "Bluetooth system is busy" I think I've got it working. But, the batteries in the controller/master are down and I'm waiting on a batch to get recharged so I can make sure it's working properly and then I'll start eliminating stuff that's not needed.

BTW, is there a "book" that explains NXC/Bluetooth? I feel I'm missing important information right now, like error code values/meanings.

Edit: About what I'm using, it's mostly the send/receive remote/response pairs, along with some "wait on idle" calls (which may not be needed). I'll post more stuff tomorrow (Monday).

Another BTW, the thread about "rotate to target" was instructive and I'm now using that to do the steering in the car. Works much better than what I had.

[mcsummation]

John, just to kind of wrap this up - I had the code in the Slave all working, as I've done that between the NXT (running either NXT-G or NXC) and a PC. When trying to convert my PC (Master) code to NXC, I got confused about how the SendRemoteXXX and ReceiveRemoteXXX functions worked. I went off down a rabbit trail, without knowing it went into a briar patch. Your comment about "BT busy" made me look up and say "How did I get in this tangle?" As I went back and did what you suggested, the code started working better and better.

So, here's a summary of the Slave code:

Code: Select all

// To receive a number from the Master:
until (ReceiveRemoteNumber(mailbox, false, some_long) == NO_ERR)
     Yield();
ReceiveRemoteNumber(mailbox, true, some_long);

// To send a response back to the Master:
SendResponseNumber (mailbox, some_long);

The code running in the Master:

Code: Select all

// To send a number to the Slave:
until (RemoteConnectionIdle(CONNECTION_NUMBER))
     Yield();
SendRemoteNumber(CONNECTION_NUMBER,mailbox, some_long);

// To get a response number from the Slave:
if (NO_ERR == ReceiveRemoteNumber(mailbox, true, some_long))
{
// Your code.
}

What I found is, to make either end of the BT conversation work properly (meaning timely), each "receive" call should be in its own thread.

[afanofosc]

I am a little concerned about your "in its own thread" comment. But you should be okay so long as you pay attention to the status values and act appropriately. It's best to not even try a bluetooth message when the firmware is still busy handling one already so if your code is written so that each thread has its fair chance at sending a bluetooth message and appropriately retries if the BT layer is already busy then you'll probably be fine.

If you only have one slave NXT then using ReceiveRemote* API functions should be okay. But on the master you will need to call this in a loop while it returns something other than NO_ERR. The first time you call this on the master NXT it is guaranteed to return a status code other than NO_ERR since the mailbox will surely be empty. But because the mailbox was empty the firmware will send a MessageRead direct command via Bluetooth to your one and only slave NXT and fill the mailbox with whatever response it gets back from the slave. While that transmission is occurring (which could be several milliseconds) you'll either have to wait or loop with a Yield() and keep calling ReceiveRemote* until you get a NO_ERR result.

John Hansen

[mcsummation]

I believe that's what I'm doing.