avk

Понял. Не идеально, но все равно юзабильно.

9CXX
Не идеально, но все равно юзабильно.

Из-под Windows - более чем.

А в случае разных переходников USB<->COM причина их неприменимости для кодирования POCSAG не только в стеке драйверов для USB, но и в самом USB-протоколе - вот интересная информация, на которую я наткнулся по ходу дела:

3.8.4 USB Scheduling Delays
Each API call that is used to send data to and from the Aardvark adapter can incur up to 1 ms in delay on the PC host. This is caused by the inherent design of the USB architecture. The operating system will queue any outgoing USB transfer request on the host until the next USB frame period. The frame period is 1 ms. Thus, if the application attempts to execute several transactions in rapid sequence there can be 1-2 ms delay between each transaction plus any additional process scheduling delays introduced by the operating system. The best throughput can be achieved for single transactions that transfer a large number of bytes at a time.

Т.е. получается, что каждая команда на поднятия/опускание DTR'а в случае адаптера USB<->COM может непредсказуемо сдвигаться по времени минимум на одну-две миллисекунды в силу самой логики работы USB, не говоря уже о логике работы кучи драйверов в цепочке.
Т.е. для POCSAG на скорости, например, 1200 bps, когда DTR должен моргать каждые примерно 8.3 мс, это совершенно неприемлемо.

avk

Выруйчайте! Дошли руки до многого, в т.ч. до вашего софта. Напишу на днях репорт про прочее, а теперь про pocsag2sdr.

Команда из консоли (copy/paste):

pocsag2sdr.exe -w \\.\com1 -r1200 -t500 -i cap1 func0 TEST123

Результат:

*** START *** COM port encoder mode
pocsag3sdr has stopped working:

Problem signature:
Problem Event Name: APPCRASH
Application Name: pocsag2sdr.exe
Application Version: 0.0.0.0
Application Timestamp: 56f62fc9
Fault Module Name: pocsag2sdr.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 56f62fc9
Exception Code: c0000094
Exception Offset: 0000328b
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Стучусь в COM1, хочу там 1200 с инверсией. Получатель - RIC 1 без сабов.

Win7 XP1 x86 English + WU + VC_redist.x86.exe. На всякий случай перегружался.

P.S.
Попутно вопрос - какая минимальная поддерживаемая версия ОС?

9CXX
pocsag2sdr.exe -w \\.\com1 -r1200 -t500 -i cap1 func0 TEST123

Сейчас добавлю дополнительные проверки при разборе параметров, а пока вставьте пробелы после -r и -t.

Да, и еще в догонку: я правильно понимаю, что вместо cap1 и func0 стоят просто цифровые значения, а не именно то, что написали вы?

9CXX
Попутно вопрос - какая минимальная поддерживаемая версия ОС?

Windows XP

avk

Да, и еще в догонку: я правильно понимаю, что вместо cap1 и func0 стоят просто цифровые значения, а не именно то, что написали вы?

Нет. Я даю именно свою строку as is. Ничего не меняя. Что не так?

Вот так встает на передачу, но нет манипуляции: pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i cap 1 func0 TEST123

Манипуляцию я жду в линии DTR.

Просто удивило, что после com пробел нельзя, а после остальных - нужно :)

9CXX
Нет. Я даю именно свою строку as is. Ничего не меняя. Что не так?

Правильная строка тогда следующая:

pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123

1. Пробелы после -r и -t критичны.
2. CAP и sub коды нужно указывать просто в цифровом виде, безо всяких лишних и ненужных слов cap и func.

9CXX
Просто удивило, что после com пробел нельзя, а после остальных - нужно :)

Потому что \\.\com1 - это такое хитрое имя файла, которое в ОС Windows предназначено для доступа на самом деле не к файлам, а к драйверам, и лишние пробелы в нем недопустимы.
Лень просто было делать отдельный параметр типа номер COM-порта и потом самому конструировать такое хитрое имя файла.
Вместо этого я приспособил уже существоваший параметр -w для задания имени файла еще как и индикатор режима работы - просто формирование I/Q-файла или же открытие COM-порта и выдача POCSAG'а туда.

avk

И судя по тому, что я вижу, нужна еще инверсия PTT. Сейчас наоборот под мой ключ. В простое станция стоит на передачу. Именно это может быть причиной того, что нет звука. Можно ли сделать переключатель?

P.S.
С COM-портом понял. Это я уже так, придрался. На самом деле несущественно.

9CXX
И судя по тому, что я вижу, нужна еще инверсия PTT. Сейчас наоборот под мой ключ. В простое станция стоит на передачу.

Т.е. получается, что станция у вас встает на передачу сразу при подключении к компьютеру, еще до запуска программы?

avk

nPortNr = atoi(argv[1])
sprintf(port_ptr,"\\\\.\\COM%d",nPortNr);
CreateFile(port_ptr, ....

avk

Т.е. получается, что станция у вас встает на передачу сразу при подключении к компьютеру, еще до запуска программы?

Ну не всегда. Бывает что и так, бывает что и нет. Зависит от состояния ПК, спал/не спал, кто и как до этого ставил шину и т.п. Но обычно все же станция стоит на приеме и ее ничто не беспокоит. Как бы там ни было, в pe310.exe функция PTT не настраивается никак (очень обламывает!), и поэтому я сделал аппаратный преобразователь PTT с инверсией. Встроил в шнур, если конкретно. Моему передатчику нужен TTL low для TX, и поэтому между ПК и передатчиком меня стоит ключ на n-p-n транзисторе. PE дает RTS=high во время TX, и после ключа мы получаем TTL low, что ставит передатчик на передачу.

После запуска pocsag2sdr.exe передатчик ничего не передает, а потом зависает на передачу до бесконечности. Нужно, чтобы ваш EXE сделал RTS=high перед передачей, и RTS=low после того как все передаст. Для такой цели было бы удобно иметь ключ что-то типа -ip (invert PTT). Который просто инвертирует текущую логику работы PTT.

Надеюсь, что не запутал.

P.S.
И еще была опечатка где я жду манипуляцию. Манипуляция мне нужна на линии DTR.

P.P.S.
Заранее благодарен.

9CXX
PE дает high во время TX, и после ключа мы получаем low, что ставит станцию на передачу.

Вообще-то pocsag2sdr работает точно так же.
Потому что противоположный случай - когда передача включается по низкому уровню RTS - будет означать, что станция будет переходить на передачу сразу же при подключении к компьютеру, так как при начальной инициализации порта при запуске компьютера все сигналы находятся в уровне low, что можно легко проверить вольтметром.

Тем не менее я добавил отдельный экспериментальный свитч -x, который меняет логику работы с PTT на противоположную - попробуйте, но думаю, что дело не в этом.

Нужно, чтобы ваш EXE сделал low после того как все передаст.

Именно так у меня и делается. Или вы думаете, что я не обратил бы внимания на красный индицирующий режим передачи светодиод на GM350, с которой тестировал pocsag2sdr? :)

Но, естественно, это произойдет только при нормальной завершении работы программы.

Можно увидеть, что выдается в консоль, желательно с ключом -v?

9CXX
И еще была опечатка где я жду манипуляцию. Манипуляция мне нужна на линии DTR.

Я правильно понял, что PTT у вас заведен на DTR, а данные должны передаваться через RTS?
Тогда ничего удивительного, что ничего не работает, у меня ровно наоборот.

XOR
Спасибо, я немного знаю ANSI C :)

Задача еще была не вводить лишний сущностей типа отдельного свитча выбора режима работы, а приспособить существующий.
Увы, у этого обнаружились побочные эффекты :)

avk

Я правильно понял, что PTT у вас заведен на DTR, а данные должны передаваться через RTS?
Тогда ничего удивительного, что ничего не работает, у меня ровно наоборот.

Нет. У меня так:

RTS - PTT
DTR - Audio TX

С новым exe и новым ключом поведение слегка меняется - появляется короткий, на долю секунду, бип, а потом опять тишина и станция висит на передачу. Без ключа -x все то же самое, но без бипа. Итого, станция не передает, на прием не переходит.

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123
*** START *** COM port encoder mode
*** FINISH *** 1664 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

E:\SOFTWARE-RADIO\POCSAG2SDR>

9CXX
Нет. У меня так:

RTS - PTT
DTR - Audio TX

Качайте на всякий случай с GitHub новый EXE, где -x как раз меняет местами DTR и RTS.

Но вообще-то у меня именно так и было сделано с самого начала - RTS -> PTT, DTR -> Flat TX.

9CXX
pocsag2sdr.exe -w \\.\com1 -r 1200 -t -x 500 -i 1 0 TEST123

У вас ошибка в командной строке - нельзя вставлять -x между другим свитчом и его аргументом.
Правильно будет так: pocsag2sdr.exe -w \\.\com1 -r 1200 -t 500 -i -x 1 0 TEST123
Иначе он просто не будет работать.

avk

Посмотрел все вольтметром.

PE:

Прием: +9 В на 7-ой ноге DB9 (относительно 5-ой).
Передача: -9 В на 7-ой ноге DB9 (относительно 5-ой).

P2SDR, новый exe:

Прием: -9 В на 7-ой ноге DB9 (относительно 5-ой).
Передача: +9 В на 7-ой ноге DB9 (относительно 5-ой).

Если добавлять -x, то в линии начинает твориться что-то невятное, короткие броски напряжения (подозреваю, что данные).

Прошу просто сделать ключ, который инвертирует полярность на 7-ой ноге (RTS - PTT). Должно быть: прием - минус, передача - плюс. Сейчас у вас наоборот! Линии у нас с вами одинаковые и правильные, но нужна обратная полярность.

9CXX
Если добавлять -x, то в линии начинает твориться что-то невятное, короткие броски напряжения в десятки-сотни миллисекунд.

Ничего удивительного - там сыпется POCSAG.

Прошу просто сделать ключ, который инвертирует полярность на 7-ой ноге. Прием - минус, передача - плюс.

Добавлен ключ -y, который меняет полярность сигнала PTT, скачивайте, пробуйте.

9CXX
Посмотрел все вольтметром.

Я тут тоже посмотрел вольтметром свою новую ExpressCard с двумя COM-портами.
Сразу при вставлении на RTS у нее напряжение -5.6 вольта, при открытии порта PuTTY, которая переводит служебные сигналы в high - +5.8В.
Т.е. ведет она себя в этом отношении также, как и другие COM-порты - как аппаратные, так и USB.

Если PE работает так, как пишете вы:

Прием: +9 В на 7-ой ноге DB9 (относительно 5-ой).
Передача: -9 В на 7-ой ноге DB9 (относительно 5-ой).

То это означает, что после загрузки компа с нуля станция сразу перейдет в режим передачи до тех пор, пока не запустится пейджинговый софт и не проинициализирует COM-порт.
Потому что драйверы и USB, и аппаратных COM-портов при загрузке переводят все служебные сигналы в состояние low.
Именно поэтому я и сделал такую логику работы с PTT у себя в программе - чтобы после банальной перезагрузки компа станция не работала на передачу до первой инициализации порта пейджинговым софтом.
Которой (инициализации) может, например, и не произойти долгое время из-за какого-нибудь сбоя в настройках, как самого софта, так и ОС.

Ничего не хочу сказать об авторах PE, но по-моему с их стороны это недоработка, которая может выйти боком пользователям.

avk

Спасибо. Но с ключом -y видимых изменений на порту не просходит никаких, всегда -10 В. Полагаю, что после Tx уровень нужно вернуть уровень на +. PE это делает, ваш EXE - нет. Поэтому я не вижу изменений при добавлении ключа -y. А возможно, что физически уровень ставится еще раз и это будет видно только на осциллографе. Нужно переводить PTT на + по окончанию передачи. Реализуете?

avk

То это означает, что после загрузки компа с нуля станция сразу перейдет в режим передачи до тех пор, пока не запустится пейджинговый софт и не проинициализирует COM-порт.
Потому что драйверы и USB, и аппаратных COM-портов при загрузке переводят все служебные сигналы в состояние low.
Именно поэтому я и сделал такую логику работы с PTT у себя в программе - чтобы после банальной перезагрузки компа станция не работала на передачу до первой инициализации порта пейджинговым софтом.
Которой (инициализации) может, например, и не произойти долгое время из-за какого-нибудь сбоя в настройках, как самого софта, так и ОС.

Ничего не хочу сказать об авторах PE, но по-моему с их стороны это недоработка, которая может выйти боком пользователям

Все верно, так и есть. Автор PE - Клив Купер, очень грамотный разраб. Он же написал линуксовый софт под ягодку, который я тут пару раз упоминал. Не знаю почему он так поступил (может быть разрабатывал под некий коммерческий передачтик, где диспетчерский софт работает круглосуточно), но сейчас станция зависает на передачу при засыпании компьютера (до наступления TOT). Это дико неудобно и опасно для передатчика. Но так уж получилось исторически, что я начал с него и другого под рукой ничего не было и не наблюдается до сих пор. Потом, как определюсь с софтом, постараюсь уйти от этой "обратной логики".

9CXX
Но с ключом -y видимых изменений на порту не просходит никаких, всегда -10 В.

Приведите, пожалуйста, командную строку и выдачу программы с добавленной опцией -v 1

avk

E:\SOFTWARE-RADIO\POCSAG2SDR>pocsag2sdr.exe -w \\.\com1 -y -v 1 -r 1200 -t 500 -i 1 0 TEST123WWW [далее обрезал для краткости]
*** START *** COM port encoder mode
Ticks per second: 3117792
Ticks per bit: 2598
*** FINISH *** 2752 bits have been sent, frequency: 3117792, calculated # of ticks per bit: 2598, average # of ticks per bit: 2598

Про домашний пейджинг на базе радиостанций Motorola:

1. GM300, переделанная и настроенная по инструкции с hackersrussia.ru, работает точно так же, а иногда и чуть уже GM360/GM160 без единой переделки. В связи с этим, искать и переделывать 25 кГц GM300 смысла нет. Проще взять сразу GM340/140, так как их цена сейчас ровна или близка.

2. Картинка, которую я приводил вот тут Пейджинговая связь своими силами. Операторы умерли. - Страница 23 в шаге 5, не верна. На самом деле должен обходиться целиком каскад на ОУ U653, а не просто удаляться ФНЧ на выходе U652B. Текстом действия описаны верно: «удалить резистор R671 и конденсатор C668. Соединить перемычкой 7-ой контакт микросхемы U653 и 10-ый контакт разъема J6». Делать это или нет — решать вам. В GM360/GM160 без к.л. доработок сигнал получается не хуже.

3. У GM300, ровно как и у GM360/GM160 и т.п., при модуляции POCSAG 1200 на Flat TX с COM-порта компьютера имеется смещение спектра от 500 до 1100 Гц в сторону (от начала передачи сначала ползет вправо, потом немного плавает туда-сюда, а потом съезжает ближе к стартовой позиции влево). То есть, сигнал пляшет в стороны в зависимости от того, что летит с COM-порта. Причем, есть зависимость «гулянки» от настроек внешней модуляции — можно попытаться ее несколько уменьшить, но это около что-то 20-30% максимум. Избавиться это этой гулянки нельзя. И это не выбег частоты от нагрузки, прогрева и т.п. — если радиостанцию включать на передачу отдельно, то сигнал гуляет точно так же. Это именно кривизна концепции — влияние целей внешней модуляции на ГУНы радиостанции!

4. Спектр POCSAG с GM300 получается плохой что бы вы не делали! Меандра не получить ни при каких настройках. Сигнал имеет большой выброс и скол, чего не наблюдается у профессиональных фабричных передатчиков. Из этого можно сделать вывод, что внешние недорогие контроллеры вроде Zetron и пресеты для них в GM300 делались нетребовательных мелких потребителей, типа приемного отделения, школы, пожарного депо (малый радиус, сильный сигнал, допускается потеря сообщений). По этой причине коммерческие операторы даже в России (где на всем любят экономить) использовали передатчики стоимостью $20-100k за 1 штуку, а не GM300. Надо понимать, что у них были веские причины переплатить в среднем в 50 (!) раз. И это не только мощность и цикл (усилитель TPL стоит порядка $1000-2000, а 100% цикл можно сделать и на GM300).

5. Проблемы, описанные в п.п. 3 и 4, ведут к тому, что статистика успешных передач сообщений на пейджеры, а также на POС32 (с использованием SDR и VAC) не превышает 70-90% на скорости 1200. На скорости 2400 начинает ад и трэш на большинстве приемных устройств. Переход на 512 может улучать ситуацию, а может и не улучшать, что сильно зависит от модулятора передатчика.

6. Качество передачи (спектр, меандр) зависят от используемого компьютера даже в голом DOS и при использовании аппаратного COM-порта! Это реально ад, но при смене одного компьютера на другой читаемость сообщений может падать с 70-90% до 50%. Или наоборот расти. Но она никогда не ставится 100%. Исправить ситуацию при помощи регулировки уровня сигнала на Flat TX, а также подстроечников VCO REF и VCO MOD внутри GM300, нельзя! Эти подстроечники крутились на протяжении 10 часов - как по спектру, так и по меандру, так и по фактическому приему на пейджеры. Сделать красивый сигнал, действительно близкий к коммерческому передатчику, нереально. Можно сделать похожий спектр, но при этом меандр всегда плохой, а частота пляшет. Сделать меандр и остановить паразитную модуляцию нельзя.

7. Пейджеры в разной степени толерантны к качеству сигнала. Так, самыми капризными у меня являются NEC-21A. NEC 20B и 26B более толерантны. Philips PG2310 также весьма толерантен. Однако, его толерантность приводит к тому, что некоторые alpha-numeric сообщения принимаются им как Tone :( Это проблема качества сигнала, увы.

Итог: Говорить о надежности и целостности передачи/приема сообщений с учетом вышесказанного не приходится. Побаловаться и удивить гостей сойдет, хотя с первого раза может не получится. Но при наличии места и недорогого электричества имеет смысл приобрести фирменный передатчик из закрывшегося пейджингового оператора — благо их продавали много, за сравнительно небольшие деньги и целыми комплектами. С GM300 и другими радиостанциями, предназначенными для голоса и данных, качественного решения не выйдет :(

9CXX
Но с ключом -y видимых изменений на порту не просходит никаких, всегда -10 В. Полагаю, что после Tx уровень нужно вернуть уровень на +. PE это делает, ваш EXE - нет.

Вооружившись вольтметром и вставив задержки перед перед запросом PTT и после его убирания, чтобы вольтметр успевал показать изменения напряжения, могу сказать следующее: с ключом -y работает pocsag2sdr правильно :)
Проблема в том, что после завершения работы программы COM-порт, естественно, закрывается.
И в свою очередь его драйвер, видя это, уже сам принудительно опускает RTS.
Что с точки зрения драйвера логично - раз никто с COM-портом не работает, значит, все служебные сигналы должны быть в low.
Во всяком случае, в Windows 7 это так, как с вероятностью 99% и во всех остальных Windows на базе NT'шного ядра.
Как поменять эту логику и заставить драйвер не опускать RTS после закрытия порта, я, увы, пока не нашел.
Вполне может статься, что никак - как я уже написал, с точки зрения драйвера такое поведение более чем логично.

Кстати, у меня в GM350 можно задать, какой уровень сигнала - высокий или низкий - будет запросом PTT. Может, и у вас в GM300 есть такая возможность? Тогда вам не придется переделывать интерфейс к ней, а просто перепрограммировать саму станцию.

avk

В GM300 среди программируемых I/O нет внешней PTT даже в версии с Expanded LB. Внешнее PTT, пин №3, является аналоговой жестко распаянной цепью :(

9CXX
В GM300 среди программируемых I/O нет внешней PTT даже в версии с Expanded LB. Внешнее PTT, пин №3, является аналоговой жестко распаянной цепью :(

Жаль :( В GM350 этот пин просто один из программируемых, которые через транзисторные ключи идут на входы GPIO в CPU.
Ну а уже CPU может их интерпретировать как хочет.