Sort of my point with sending to many devices. The bluetooth standard requires that you stop talking to one device, go through the handshaking procedure with the next device, send the information to that device, then disconnect from it before moving to the next one. the process of connecting and disconnecting actually takes much more processing power/time than the information needed to run the engines. When you mix in an audio stream it won't hurt that one stream to break data flow for a couple hundred microseconds to send out data to the engines, but to put it in perspective the amount of data that needs to be send for a mid-grade quality audio stream is 20 times the total capacity of the TMCC/Legacy system if it sent as much data as it possibly could. You can sneak a few train commands in there with little trouble. The problem comes in when you account for the overhead of the bluetooth protocol its self. By the time connections can be opened and closed, you get a practical limit of about 7 devices that can operate without one of them interfering with any of the others. You could probably force about twice that many to work if they don't need much bandwidth.
|
|
