| |
Any have any experience with communicating over Bluetooth with
'master' connected to more than one NXT? If so, can you share any
performance results? My guess is that it is very slow.
My expectation is that when there is one master NXT and two slave
NXTs, it will take 100s of milliseconds for master to read a message
from slave. I wanted to know if anyone has any hard data to back up
this hypothesis?
Background Data:
================
NXT messaging operates in a polled fashion with the master
sequentially polling each of its three possible slave connections to
see if they have a queued message. The polling is performed in a round
robin fashion.
Polling must be used because of the communications architecture
between the Bluecore module and the ARM CPU in the NXT. The Bluecore
module can have up to three simultaneous connections or streams. There
is a single serial link between the Bluecore and ARM; the ARM tells
Bluecore which of the three channels should be logically connected to
this link. Data on the streams that are not connected is simply
discarded within the Bluecore module.
To prevent lost data, the slave devices should only transmit data over
Bluecore when the master is actually listening to that slave.
The NXT messaging system is built on top of the above. Polling by the
master is used to prevent data loss. This way the "slave" is only
transmitting when the "master" expects and data will not be lost.
In order to step through the different slave connections, the master
needs to send commands to the Bluecore module to reconfigure the
stream that is "active" for communication. This also appears to be a
slow process. It involves the following steps:
1. Toggle a digital I/O pin to switch Bluecore into a mode where data
from the ARM contains Bluecore commands rather than data to be
transmitted.
2. Wait until Bluecore has toggled a second I/O pin indicating that it
has switched modes.
3. Send a message from ARM to Bluecore to switch modes.
4. Wait for a reply message from Bluecore that mode has been switched.
5. Toggle the I/O pin in (1) to switch back to data mode.
6. Wait until Bluecore has toggled (2) back to original value.
Steps 3 and 4 are relatively slow. Measurements with other similar
messages have indicated that Bluecore appears to perform commands on a
50-msec "heartbeat" and steps 3 and 4 are likely to take either 50 or
(more normally) 100 msec.
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
