Quote:
Originally Posted by PhilBot
1) I'd recommend that everyone put a "beep" in the case statement that runs when the NXT Bluetooth VI returns a non-packet status. Specifically when "Message Received" = False. You can quickly determine if you have problem reception-errors. 200ms at 200Hz is pretty noticable.
|
I would suggest a different approach described below.
On the PC side, the game controllers are scanned every 50 milliseconds and their status sent, via Bluetooth, to the NXT. Normally the Bluetooth message (less than 20 bytes) takes less than this time to transmit.
Your message processing "loop" should be running much faster than this. If it is not, then there's likely something seriously wrong in your program!
So what I would suggest instead is that you put a short tone playback in the message received "true" case. Something like 1500 Hz for 65 milliseconds. 65 because it 50 + 15:
- 50 milliseconds scanning rate.
- 15 milliseconds because I think this is Bluetooth's period. Depending on when you send a message it may take up to 15 millisecond to transmit (I think).
If everything is working well, then you'll get a nice constant (and annoying) tone of 1500 cycles. If anything is delayed, then there will be a break in the tone and you can gauge the length of the delay. Note that a new "play tone" will abort the previous tone if it is still in progress.
I have measured and noticed that sometimes a BT transmission can take well over 100 milliseconds. This is readily apparent with the above test.
NOTE for ROBOTC Users:
There's an optional feature in ROBOTC firmware than reduces most of these long duration packets.
ROBOTC has an integrated Controller Station applicaton that already has this audible feedback feature built in. You don't have to do anything in your program. It's enabled by a check box on the PC window. Up to now, it was playing a short blip tone on every 10th message. I just changed it to above. The way it works is it sends the "PlayTone" request to the NXT along with the Game Controller update.