fischertechnik community forum

TX Controller in offline mode exchanging Bluetooth messages with a PC

When the TX Controller is running a (C) program in offline mode, it can only exchange Bluetooth messages with another TX controller, but not with a program running on a PC, for example. This is not possible because the TX Controller will not setup a message exchange connection with another device that is not a TX Controller. This has been noted before in this forum: http://forum.ftcommunity.de/viewtopic.p ... 6467#p6513.

I had a need for such solution, as I'm building models that rely on a C program running on a TX to control a model in real time (e.g. handling time sensitive sensor data), but also have a connection to a PC to operate the model, receive data to monitor the model, etc. The only solution so far was to use another TX controller in online mode connected to the PC, exchanging messages with the model's TX controller. But that's wasting a TX as an expensive Bluetooth dongle!

As suggested in the forum post mentioned above, I tried to circumvent this problem using a BT dongle with a modified BT address to let the TX controller think it was talking to another TX Controller. It turns out to be possible, but not necessarily easy to accomplish.

• First you need to get a BT dongle that allows the BT address to be changed. I used this one: http://dx.com/p/37665.
• Then you need to change the BT address itself. I was unable to do it using tools you can find online for Windows. But for Linux there are tools that can do it. I used the BDADDR tool in the BlueZ stack (http://www.bluez.org/). If the BT dongle has an address in the same range as the TX controllers, a TX will think it is talking to another TX controller and happily exchange BT messages.
• That was the hard part. The communication between the TX and the PC is relatively straightforward. They exchange messages in the following format: 0xBE 0xEF <1 byte representing the number of bytes in the following message> <maximum 16 message content bytes> <1 checksum byte>. The checksum is the LSB sum of all bytes in the message including the 0xBEEF and length bytes.
• The master (TX or PC) opens the connection, the slave responds with a messege containing the ASCII representation of the string 'CONN_ACK' (that is, the slave sends: 0xBE EF 08 43 4F 4E 4E 5F 41 43 4B 11). Then either the slave or master can send messages.
• If the PC is the master you can open, read from and write to the COM port associated with the Bluetooth serial connection on the PC. There are plenty of simple libraries to be found online that allow you to do that. If the PC needs to be the slave, you need to listen to, write to and read from the Windows socket.
• When using a BT dongle with a BT address in the TX controller range, you can no longer use it connect to the TX in any other mode, e.g. to download programs to the TX, use RoboPro with the TX etc. Use a USB cable or another PC/BT dongle.

This is working well for me. It's a pitty ft doesn't make it easier to do this, as it can be really useful for advanced model control. Even the good old Robo Interface at least could exchange message over its serial interface. Now we have BT, but no messaging interface, at least not without all these tricks.

Regards,
Willem Evert Nijenhuis.

It will be beautiful to have a PC as message slave node.

With the Robo Interface it was easy to do with the serial communication.
I publish that a long time ago in the forum.
This option opens also a way to connect the Robo interface with a microcontroller (extend it with a webserver or a Wifi interface).

There exist also another old issue, with the Robo Interface it was also possible to have data exchange with the PC in the offline mode:
FtLib 4.4.8 and 4.4.9 GetFtMemoryData and WriteFtMemoryData
These two memory function are not implemented in the FtMscLib.

But now you could implement a readmem yourself, getting 16 bytes at a time

@Ad,
In more details?

A TX C program can read memory locations, e.g. 16 bytes at a time and send them as a BT message. In a more elaborate approach you could implement a kind of RPC scheme. For instance by sending a function code and some parameters and receiving return values.

Maybe I will be a nice suggestion to MSc to implement the same two API function in their FtMscLib. This to be compatible with the FtLib.
And also your BT message suggestion.

Does anyone have working C code for Windows PC as example ( ROBO TX <-> PC by bluetooth ) ?

Thank you.