Why did we change to asynchronous communication and how?

The previous versions of the program were accessing the TxD pin of the serial port directly by triggering break signal - either through a WIN32 API call, or directly by writing to port of UART (Linux version).

However, the consequences of this were that the program had to be run with administrator (WIN32) or superuser (Linux) priviledges, and even more - in a realtime mode to make sure that it will generate correct signal on the output and will not be preemted by other threads or operating system.

This is necessary because the UART circuit used in PCs doesn't feature synchronous communication (as for example the H8/3292 chip used in RCX does), and so all data bytes sent out from the serial port are automatically preceeded by one start bit, and followed by one or more stopbits.

It turns out that when the port is switched to the highest possible baud rate 115200, the spurious start and stop bits generate so short impulses that the serial IR tower ignores them, or even if the transmission is influenced, the robots do react to the signal. In this way, we use the standard serial communication implemented by hardware in cooperation with the buffers of the operating system. It only remains to see, if it works also for you and your robots. Let us know.