Проблема чтения виртуального последовательного порта RXTX

Question

Справочная информация: Windows Server 2003 R2, виртуальный последовательный порт Wire Service, созданный с помощью программного обеспечения RealPort, последовательный порт, настроенный как COM5, 9600 бод, 8 бит данных, без битов четности, 1 стоповый бит, без управления потоком, Использование RXTX 2.1-7.

Порт COM5 найден, последовательный порт создан с использованием метода portId.open, а параметры порта и управление потоком настроены так, чтобы соответствовать параметрам драйвера устройства, указанным выше.Я получаю serialPort IntupStream и оборачиваю его в InputStreamReader, чтобы я мог контролировать кодировку ввода.Кодировка по умолчанию, конечно же, Cp1252. Я прочитал, что если вы используете 8 бит данных, кодировка должна быть ISO-8859-1 или Латинской1.и я использую метод InputStreamReader: int c = isr.read ();в цикле while в случае SerialPort.Event.DATA_AVAILABLE Распечатка целого числа c и приведение к символу ((char) c);Проблема заключается в том, что числа и результирующие символы смещены слишком высоко (диапазон от 135 до 250). Все сообщения заканчиваются на «All Rights Reserved.)», А последние символы в каждом сообщении совпадают.Тем не менее, сдвиг не является последовательным от персонажа к персонажу.Перепробовал другие кодировки: UTF8 / UTF-8 сдвигают цифры еще выше.как делает ascii / us-ascii.Cp1252 сдвигает числа в диапазон 130-350, за исключением 3 символов, которые сдвинуты на 65533, 8222 и 8240. Примечание: при использовании InputStreamReader.getEncoding () UTF8 и UTF-8 - это UTF8, а ascii и us-ascii - ASCII.

Могу ли я попробовать другие кодировки?Кто-нибудь еще видел подобные вещи?

Answer 1

Я делаю почти то же самое. 9600 бод, 8N1 (8 бит данных, без контроля четности, 1 стоповый бит), и у нас нет проблем со смещением символов. Мы даже нигде не устанавливаем кодировку.

Наш входной поток имеет тип InputStream и устанавливается с помощью serialPort.getInputStream ();

Попробуйте отступить от InputStreamReader и просто использовать обычный «InputStream». Кодировка должна беречь себя.

Надеюсь, это поможет,

- gMale

Answer 2

Есть два проводных сервисных порта. Одна из них, о которой я писал, оказалась конфликтом между аппаратной конфигурацией устройства TCP-Serial, называемой Digi. Мне удалось устранить проблему на этом порту, изменив настройки последовательного порта COM5 на 9600,7,1,0,0. Сдвиг значений происходил из-за использования 8 битов данных против 7. Это, конечно, означало, что мне пришлось изменить параметры порта в коде, чтобы они соответствовали. Вы правы в том, что считыватель не был необходим, однако он помог мне прийти к решению, наблюдая за изменением смены при кодировании, пока я не понял, что меньшее количество битов данных также будет иметь такой же эффект.

Теперь я ищу магию на втором порту.

Настройки второго порта были 1200,8,1,0,0 с использованием 9600, из-за чего поток был в основном равен 0 с некоторыми 128.