Я не успел добавить это в Ru документацию. Кое где будут огрехи.

В текущей реализации особого смысла в возвращении ошибок от установок таймаута символа нет.
Т.е. таймауты символов можно применять только в режиме Unbuffered. И то , если setTotalReadConstantTimeout(int msecs) ,  msecs = -1 (т.е режим автоматического вычисления общего таймаута пакета данных).
В общем, если оч нужен таймаут - то используйте setTotalReadConstantTimeout - оно установит таймаут не на символ - а на весь читаемый пакет, что ИМХО, более правильно и быстрее будет работать/читать.
Минимальный размер читаемого пакета 256 байт - поэтому минимальный таймаут пакета не может быть ниже чем для 256 байт. (хотя и больше тоже не может быть)
Поэтому если у вас размер передаваемых данных < 256 байт - то ставьте смело или 0 или 1 мс и не заморачивайтесь.
А если > 256 байт - то рассчитайте общий таймаут на 256 байт (с учетом скорости, кол-ва бит данных, стоп-бит и т.п.).

А чтобы не заморачиваться с расчетом - делайте setTotalReadConstantTimeout(-1), а  setCharIntervalTimeout не трогайте вообще. И оно само подберет "оптимальный" таймаут. Т.е. если будете менять скорость и т.п. то не нужно переустанавливать таймауты.

ЗЫ:
Там с таймаутами сейчас полный песец - хотелось универсальности - а получилось хз что.
В общем, не обращайте внимание на ошибки от таймаутов вообще, считайте что оно всегда true!

Ох, juvf, juvf ....

Смотри примеры и найти отличия в *.pro файлах примеров и твоего.
ЗЫ: Неужто так лень разобраться? Или всё нужно разжевывать и в рот класть?

Ну что за чушь... Возьми примеры \test\guiapp , подправь и проверь.

/test/guiapp/mainwidget.cpp

C++ (Qt)
void MainWidget::procSerialDataTransfer(const QByteArray &data)
{
    char buf[4];
    buf[0] = 'a';
    buf[1] = 'b';
    buf[2] = 'c';
    buf[3] = 'd';
 
    if (this->serial && this->serial->isOpen())
        this->serial->write(buf, 4);
}
 

2 juvf, твой код особо не смотрел, наверняка у тебя где-то ошибка, а исправлять твои ошибки не имею желания.

Я специально видоизменил /examples/anymaster так, чтобы он постоянно слал: 03 FC 41 00.

C++ (Qt)
void AnyMaster::transaction()
{
    start(false);
 
    char tx_packet[4];
    tx_packet[0] = 0x03;
    tx_packet[1] = 0xFC;
    tx_packet[2] = 0x41;
    tx_packet[3] = 0x00;
 
    qint64 r = port->write(tx_packet, 4);
    if (r == 4) {
        qDebug() << "Writed: " << r << " bytes";
        if ((port->bytesAvailable() > 0) || port->waitForReadyRead(responseTimeout)) {
            char rx_packet[258];
            r = port->read(rx_packet, 258);
            qDebug() << "Readed: " << r << " bytes";
        }
        else {
            qDebug() << "Response timeout.";
        }
    }
    else qDebug() << "Bytes writed small: " << r;
 
    start(true);
}
 

Далее, видоизменил /examples/reader так, чтобы он принимал пакет и проверял его и при ошибке в принятых байтах - сыпал в консоль предупреждения.

C++ (Qt)
        char rx_packet[4];
        /* 5. Fifth - you can now read / write device, or further modify its settings, etc.
        */
        while (1) {
            if ((port->bytesAvailable() > 0) ||  port->waitForReadyRead(rrto)) {
                qint64 r = port->read(rx_packet, 4);
                if (4 != r)  {
                    qDebug() << "Readed fail: " << r << " bytes";
                }
                else {
                     quint32 val = quint8(rx_packet[3])
                             | (quint8(rx_packet[2]) << 8)
                             | (quint8(rx_packet[1]) << 16)
                             | (quint8(rx_packet[0]) << 24) ;
 
                    if (0x03FC4100 != val) {
                        qDebug() << "Readed fail: bad packet : val = " << quint32(val);
                    }
                    //else { qDebug() << "Ok"; }
                }
            }
            else {
                qDebug() << "Timeout read data in time : " << QTime::currentTime();
            }
        }//while
 

Вот, уже сижу 2 часа и жду, когда же оно мне скажет что принято что-то не то. Так что ищи ошибку(ки) у себя.

Кто-то прикручивал для linux порт rfcomm ? (конект к телефону по Bluetooth)
 

добавил аналогичные (tty) строки для rfcomm в serialdeviceenumerator_p_unix.cpp
 

И удалось завести rfcomm , дело , похоже , в правах доступа на rfcomm.... 

Да,  вроде все работает, enumerator  выводит инфу о rfcomm, примеры тоже работают.
Но чтоб получить доступ к   порту надо бить под рутом! , ето как то можно исправить сделав группу юзеров которым можно юзать порт rfcomm.

Но мне надо потестить более детально, чтоб делать финальные выводы. 

Не подтверждаю "ошибки". У меня работает как часы.
OS: Win7 x32
Шнурок: PL2303
Драйвер:
- поставщик Prolific
- дата разработки 19.11.2009
- версия 3.3.10.140

Всё, добавил в Git.