Bluetooth remote control from PC sample code?

[linusa]

What are the actual line(s) I want to replace "mysteryFunctionToSendItToTheSerialPortOnThePC" with?

Has already been posted, check the tutorial here https://sourceforge.net/apps/phpbb/mind ... ?f=3&t=181 and the other link at the bottom of that thread.

[kschaffer]

Ok, using BluetoothWrite() on the brick. It sends an encapsulated message of:

Byte: Data payload length
Byte: Unknown (always 0, is this the BT address, which would always be 0 as received by the PC? If so, why send it?)
N Data bytes

The data bytes are terminated by a C-string '\0' null character, which makes sense as we created a fake string of binary data with FlattenVar(my struct). Zeros embedded before the null terminator don't affect anything internally to the brick, fortunately, and I just use the length when unpacking it on the PC.



In practice, I'm limiting my full suite of sensor readings (in a struct) to 10/s. With no limiting, it will try to pump through 27/s, but that's apparently too much for the BT serial link as they begin getting stacked up. A 30s run causes my parsing, PC-side, to continue parsing for about 8s after the end, indicating a buffer unfilling.


I don't know if that's the limit for this particular BT connection, or because my PC is limited. I doubt the latter since docs say using a port speed is irrelevant, and I don't set it anyway.




Next step: Checking if I can send the "Direct Commands" the other way over the BT link to drive the motors and stuff, or if I have to receive it in my program and forward commands to the motors directly. Is that little firmware listening layer still there even though I am running a program directly on the brick?


Question: ctrl-f find on the BricxCC UI (in source code) seems to have trouble finding things sometimes, especially if it's a blued-out keyword. E.g. searching for "flatten", hoping to find "FlattenVar" where I've used it fails -- nothing found. Is this a known issue? I do not have sensitive search set, and it "gets better" sometimes anyway. Yes, I put the cursor back at the front of the file in case it's stuck at the end for some reason and doesn't wrap.

[kschaffer]

BluetoothStatus is returning -35. This is not 0, 32, or 64, the three COMM status values. As the help for BluetoothStatus() unhelpfully says it returns the Bluetooth status, with no pointers to possible return values, any ideas?


0 NO_ERR
32 STAT_COMM_PENDING
64 STAT_MSG_EMPTY_MAILBOX


I'm having a devil of a time even finding any other error constants, much less knowing whether they're part of an expanded set such that BluetoothStatus might return them.

[linusa]

Ok, using BluetoothWrite() on the brick.

Never used that. Looks like you're bypassing the outgoing mailbox message queue this way? Sorry, can't help you with this method, it's not the way listed in those tutorials. You seem to get it to work ok though, so that's at least proof of concept.

Is that little firmware listening layer still there even though I am running a program directly on the brick?

Yes, it is. Depending on where you "inject" your serial packets. Usually you should send mailbox messages (MessageWrite direct command) to the NXT, and the firmware handles parsing those messages (and sorting them into mailboxes) for you.

You can definitely use all direct commands while RXE programs are running at the same time (also says so in the tutorials).

[linusa]

BluetoothStatus is returning -35. This is not 0, 32, or 64, the three COMM status values. As the help for BluetoothStatus() unhelpfully says it returns the Bluetooth status, with no pointers to possible return values, any ideas?

Maybe you have a "signed vs unsigned" integer / byte problem?

Check the LEGO Bluetooth SDK, as well as the NXC header files, if nothing else helps.

[afanofosc]

See line 496 here:

http://bricxcc.svn.sourceforge.net/view ... iew=markup

John Hansen

[ricardocrl]

Hi kschaffer,

Are you using the fantom drivers, provided by LEGO? If not, I would encourage you to use them. They facilitate a lot the communication between a PC and an NXT. You can use classes and methods that take care of most the things you want to do. You can check here all the info:
- http://cache.lego.com/upload/contentTem ... CBB206.zip

There is a Communication Protocol implemented by LEGO to handle communications over BT and USB that we have to respect. If you use the fantom drivers API, you don't need to worry about the communication protocol, because the drivers work it out for you. With this, I mean that if you use an appropriate method from this API to send a string to the NXT, from the host PC, you don't need to know what to fill in the first bytes (length, command type, command, etc); instead you just need to send the string.

Moreover, if you don't have problems with the ~58 bytes limitation of the mailing boxes I strongly recommend you to use that system. On the NXT you will just use something like MessageRead(...) and no further processing to the received data will be needed; and a correspondent API function from the PC, for writing to one of the NXT's mailbox.

Anyway, it's always worth to take a look at the NXT communication protocol:
- http://cache.lego.com/upload/contentTem ... A8B567.zip
On that .zip, you can also find the list of "Direct Commands". This commands are still part of the communication protocol, that somehow are handled by the firmware to process them.
Actually, MESSAGEWRITE is a direct command to send messages to the mailboxes. On your PC you will have something like: sendDirectCommand(...,{MESSAGEWRITE|YOUR_MESSAGE},...). Yes, to work with mailboxes, you'll need to read these documents.

I think that this is a better solution than "writing to files", like you are doing. Otherwise you will always have to process the messages to send/receive to fulfil the LEGO communication protocol, on both sides.
Even doing this (writing and reading directly from the BT buffer), you can do it through the fantom API functions.


Well, I am far from an expert on this. Someone, correct me please if I said something wrong. I hope I helped.

Cheers,
Ricardo