avk

Да, можно, но может быть ограничение на сам CAP-код - как мы тут недавно обсуждали, многие пейджеры умеют слушать только два слота внутри фрейма.

Ну начиная с третьего заставляют выбирать sub. В NEC 26B точно, остальные не помню.

Sub A/B/C/D - это два function bits, которые идут в кодовом слове за CAP-кодом. A=00, B=01, C=10, D=11.

Что если КАП будет без этих 2 бит? Пейджер, как мне думается, промолчит.

Если в софте нет настроек sub-кодов для какого-то CAP-кода - это означает, что пейджер будет принимать сообщения для всех sub-кодов

Это обычно только для первых двух :(

Наверное, имелось в виду, что можно сделать систему посылки сообщений вообще не завязанной на интернет, чтобы можно было послать sms на сотовый модем, а софт на компе эту sms из модема прочитал бы и автоматом перенаправил бы на пейджер.

Я так и понял. Просто я вижу пейджинговый терминал на ПК. А для других железок все равно придется писать софт. Сотовый модем сам аппаратно ну никак не перенаправит на пейджер. Значит, что на Linux или еще чем-то придется ваять форвардинг с модема в модулятор передатчика. По мне так если уже писать, то писать в настольной среде для ПК - там ограничений по языкам, ресурсам и прочему куда меньше. Да и совместимость будет со всем, и не нужно будет упрашивать автора добавить поддержку бабуино мини, бабуино уно, бабуино зеро 2 и еще целого зоопарка этих платок.

9CXX
Ну начиная с третьего заставляют выбирать sub. В NEC 26B точно, остальные не помню.

В NEC 21A тоже начиная с третьего надо обязательно выбирать sub-код. Для предыдущих двух принимаются сообщения с любым sub-кодом, если это явно не запрещено в RCV Inhibition Set.

Что если КАП будет без этих 2 бит?

Эти два бита есть всегда в любом адресном кодовом слове. Не быть их не может.
И они не являются частью CAP-кода - это просто два отдельных бита.

Может эту тему фрилансерам программерм закинуть? В разумных пределах могу быть финансово в доле. Или мож какое железо поспрашать у знакомых

У меня реализовано с email.на пейджер.работает просто: акаунт на гугле.включен pop.далее mapi и visual basic.все работает.проблема с длинными сообщениями их приходится делить на части и отправлять.

Piratbyru

У меня реализовано с email.на пейджер.работает просто: акаунт на гугле.включен pop.далее mapi и visual basic.все работает.проблема с длинными сообщениями их приходится делить на части и отправлять.

А что энкодером выступает?

avk

В модели 26B самый старший год - 2013 :) Дальше жизни нет. Пришлось на 2005 г. установится.

Кто видел схему пересчета кварца на NEC 21A и Philips 2310 для смены рабочей частоты?

9CXX
В модели 26B самый старший год - 2013 :) Дальше жизни нет.

Проверил сейчас ради интереса Advisor и NEC 21A - по крайней мере 2016 год в них обоих установить можно.
А NEC21A даже правильно при этом показывает день недели :)

avk

21 вообще рулит. Во времена когда были все пейджеры, я себе оставил только его. Очень уж он приятно сделан.

avk

Но в 2310 зато есть 5 RICов, их можно тут же включать/выключать, назначать тип - Personal, Special, Narrowcast. Если я все правильно понимаю, то можно активировать 5 КЭПов и сделать их индивидуальными. И никаких 2-битных расширений.

Ребята, а к кварцам какие требования кроме нужной частоты и габаритов? Есть еще какие-то тонкости, или главное ножками запаяться и чтобы частота была нужной?

Подобрал формулу для NEC и собрал формулы для 3 самых крутых пейджеров в одном месте (действительно для VHF, на других диапазонах может отличаться; NEC UHF точно имеет другую конструкцию):

• Philips 2310: Частота кварца x 3 = Частота приема
• Motorola Advisor: (Частота кварца x 3) + 17,9 = Частота приема
• NEC 21A: (Частота кварца x 2) + 21,4 = Частота приема

avk

Можете проверить формулу? посмотреть какой кварц у вас дает какую частоту приема в NEC 21A? Кварц, который стоит ближе всего к вибромотору рядом со здоровыми залуженными площадками.

Для тех у кого штырь Maxrad и нет оригинального описания выкладываю (график настройки длины штыря) (у кого нет КСВ метра) http://www.radioscanner.ru/uploader/2016/mis-multiband-2-reva.rar
Длинна в дюймах, штырь придётся резать, длинна считается самого штыря от пружины (пружину не считать).
Вот ещё кстати технологические режимы пагеров может кому прегодится : http://www.radioscanner.ru/uploader/2016/texno.rar

9CXX
Формулы все правильные.
У Advisor 17,9 это чистота кварца ПЧ (тот что с тремя ножками) у NEC Компакт и Оптима ПЧ=29,25 (синтезаторный) у остальных NEC ПЧ = 21,4. У Philips вообще всё просто кварца ПЧ нет поэтому просто множитель. Синтезаторные NEC не нуждаются в замене кварца но, после перевода его программно подстраивать всё равно придётся т.к. синтезатор не всегда выходит на нужную частоту приходится подстраивать его подстроичным конденсатором ну и плюс подстройка антенны. Philips 2130 так там вообще всё просто, но без осциллографа и частотомера не обойтись.

9CXX
По мне так если уже писать, то писать в настольной среде для ПК - там ограничений по языкам, ресурсам и прочему куда меньше.

В настольной среде для ПК есть другое существенное ограничение: отстутствие надежных real-time фич как в Windows, так и в Linux (и только, умоляю, не надо кидаться в меня ссылками на разные real-time расширения для Linux'а :) ).
Дело в том, что если писать encoder для того же COM-порта, нужно с высокой степенью точности отслеживать задержки с точностью хотя бы до десятых долей миллисекунды, потому как на передачу одного бита на скорости 1200 bps уходит примерно 0.83 миллисекунды.

Я попытался сделать это под Windows с использованием QPC-таймеров, которые позволяют измерять интервалы времени на уровне микросекунд и меньше (зависит от современности компа и его возможностей).

Взять готовый исполняемый модуль можно здесь: https://github.com/avk-sw/pocsag2sdr/tree/master/bin
Для его работы нужно поставить Visual C++ Redistributable for Visual Studio 2015 Update 1, берется здесь: https://www.microsoft.com/en-us/download/details.aspx?id=49984

Командная строчка будет примерно следующая: pocsag2sdr -w \\.\com<number> <cap> <func_bits> <msg>

func_bits - это то, что в NEC'ах называется sub-кодом у CAP-кода.
По умолчанию программа дергает DTR. Если нужно RTS - для этого нужно добавить в командную строчку свитч -b.
Свитч, который скорее всего пригодится в экспериментах, это -i, включающий инверсию POCSAG-сигнала.

С радиостанциями я его пока не тестировал (сейчас уже спать пойду, завтра попробую с GM350 вместо Zetron'а), а пока результаты его работы с переходниками USB<->RS-232 не очень утешительные.
Например, с переходником на базе чипа FTDI программа не успевает на скорости 1200 (т.е. каждые примерно 0.83 миллисекунды) установить соответствующий сигнал на COM-порте (тем, кто будет тестировать: сообщения типа Not enough CPU time).
Вероятно, тормозит драйвер либо чип от FTDI, так как с переходником на базе PL2303 она это успевает делать.
Собственно, это первое, что надо сделать - просто напустить программу на предполагаемый COM-порт и посмотреть на то, что она будет выдавать.

В общем, буду рад услышать о результатах экспериментов.

avk

Я не кодер, а точнее, стараюсь лет уже как 15 этого не касаться. В прошлой жизни программировал на QB, Fortran, TP 7.0. Не специалист по современным средам и ОС без прямого доступа железу, но удивлен, услышав о каких-то проблемах в Windows. Почему нельзя формировать данные и ставить их в очередь? На скоростях 1200 bps не совсем понимаю какие проблемы могут быть. Пишут же из под Windows радиостанции на скоростях вплоть до 115200 bps, и ничего. Прерываться тоже нельзя, флэш стерт. Если будет хоть какой чих, железка умрет с битой флешкой. Так ведь не умирают ведь обычно! Да и есть буферы в конце-концов. Ведь потом данных смешные с учетом ресурсов хотя бы Core i3.

Вы не смотрели код POCSAG encoder http://www.codeproject.com/Articles/13189/POCSAG-Encoder ? Его написал какой-то паренек из Ирана, просто прочитав документацию. Он этого ПОКСАГ в глаза не видел. И под Win32. Ни о каких проблемах с таймингами и прочим он не упоминает (хотя это не доказывает того, что у него все идеально работает).

Например, с переходником на базе чипа FTDI программа не успевает на скорости 1200 (т.е. каждые примерно 0.83 миллисекунды) установить соответствующий сигнал на COM-порте (тем, кто будет тестировать: сообщения типа Not enough CPU time).
Вероятно, тормозит драйвер либо чип от FTDI, так как с переходником на базе PL2303 она это успевает делать.

Ваши проблемы, полагаю, в USB2COM. Есть отдельные чипы, драйверы, режимы и прочее, когда я вижу задержку глазами при нажатии мыши на USB2COM и на конечном устройстве. То есть, речь про 300-500 мс! При переходе на железный порт ее нет вообще, все летает прямо в руках. И это при том, что у меня USB2COM только от Digi и Atten. Кстати, в пейджинге я их не использую в связи с отсутствием ПО под современные ОС. Может не зря не использую? Не хотите вернуться к аппаратному порту? Здесь же нет никаких сложностей. На авито полно приличных ноутов за 4-6 тысячи рублей. А для гурманов есть PCI2COM на чипсетах FTDI и Oxford. Работают эти порты хорошо, плата на OXFORD OX16PCI952 стояла в ПК. И я с нее и в цифре работал, и флешил, и станции программировал. Вопросов не было.

С радиостанциями я его пока не тестировал (

А PTT то есть у этого exe? Мне нужен RTS=high на передачу. По дефолту когда ПК запгружен и не гибернирует, RTS=low. Иначе попробовать будет крайне неудобно.

Полный доступ к COM порту в Windows весьма сомнительная штука, он вроде бы и полный, а вроде как нет, допустим, доступ к буферу COM порта доступен только в крайних случаях поэтому чаще всего данные прут последовательно (весьма странно ведь порт параллельный) параллельный он в основном только для своих нужд типа сверка данных CRC принял, готов (это по DTR RTS) вся проблема в том, что современные возможности Windows крайне ограничены т.к. COM уже в прошлом. А разраб имеет доступ не к COM порту а к стандартному набору функций винды. Вот тут и получается косяк если данные послать друг за другом (даже если использовать RTS DTR) то первые посланные не дойдут, а последующие вовсе не отправятся и ещё отправленные данные с устройства Виндой проигнорируется.
Конечно же, есть библиотеки с более расширенными возможностями но как правило на них нет инфы. А перебирать весь код библиотеки и разбираться в нём крайне сложно, да и никому не нужно.
Я пробывал уже с квитированием работать, но, толи устройство не выдаёт сведения о гатовности принять или отдать толи винда неразрешает.

9CXX
Не специалист по современным средам и ОС без прямого доступа железу, но удивлен, услышав о каких-то проблемах в Windows. Почему нельзя формировать данные и ставить их в очередь?

Потому что у чипов для COM-портов просто нет такой функции - заложить в них битовую последовательность, которую бы они могли проморгать с фиксированной скоростью путем поднимания/опускания DTR или RTS.
А вот буферы как на прием, так и на передачу данных, сформированных в соответствии со стандартом RS-232 (т.е. один стартовый бит, 7 или 8 бит данных, опциональный бит четности и один или два стоповых бита) есть еще со времен микросхемы 16550A, т.е. начала 90-х годов прошлого века.
Но RS-232 а) из-за наличия в передаваемых данных бит, на которые мы не можем повлиять (т.е. стартового и стопового) и б) из-за того, что чип не гарантирует отсутствие задержки между передаваемыми символами (так как является асинхронным портом), делает использование обычной линии передачи данных RS-232 для кодирования POCSAG'а неприемлемым.

Т.е. в случае POCSAG'а приходится на уровне прикладной программы и ОС выполнять функции, которые уже давно делаются на уровне железа.

В связи с этим ваша аналогия с программированием радиостанций, использующих стандартный протокол передачи данных RS-232, давно реализованный на уровне кремния в чипе, да еще с буферами минимум на 16 байт в нем же (чипы типа 8250 и 16450 без буферов уже давно нигде не ставят, практически везде используют как минимум 16550А), в данном случае некорректна.

Не хотите вернуться к аппаратному порту? Здесь же нет никаких сложностей. На авито полно приличных ноутов за 4-6 тысячи рублей.

Да есть у меня и старый ноутбук с аппаратным COM-портом еще с Windows XP, только на нем жена работает :)
Если не заладится с переходниками USB<->COM - буду тогда конечно на нем пробовать.
А пока хотелось бы все-таки исследовать возможности современного железа в этом плане, потому как аппаратный COM-порт сейчас все-таки уже раритет.

А PTT то есть у этого exe? Мне нужен RTS=high на передачу. По дефолту когда ПК запгружен и не гибернирует, RTS=low. Иначе попробовать будет крайне неудобно.

Сейчас допилю. Забыл уже в ночи про PTT :)

Сейчас допилю. Забыл уже в ночи про PTT :)

Новую версию можно скачать по той же ссылке. Ключ -b, естествено, убран, зато появился ключ -t <delay> - задержка в миллисекундах после выставления RTS и перед передачей первого бита.

Запустил pocsag2sdr с GM350 через COM-порт.
Так как подстроечного резистора под рукой не оказалось, завел DTR сразу на FlatTX.
Результат, увы, оказался печальный - девиация, согласно SDR#+USB RTL донгл, была в районе 7.5кГц.
Соответственно, пейджер ничего не принял, что неудивительно.
Попробую на неделе раздобыть где-нибудь подстроечник и продолжить эксперименты.

Попутно обнаружил и устранил багу с инверсией сигнала, которая не работала. Новая версия выложена все там же.

avk

Попробую на днях. Можете и постоянными резисторами обойтись. Типа 100к + 5к, 100к + 7,5к и так далее.

Господа, поведайте о результатах опытов. Жутко интересно...

Собственно, результаты моих опытов следующие.

Подстроечник для регулирования девиации я так и не раздобыл. Вместо этого мне пришла в голову мысль "А как же посылает сообщения Zetron M16? В нем же нет никакого подстроечника, и уровни RS-232 тоже прут сразу на Flat TX, как и с компа. Но сообщения-то однако доходят!"
В связи с этим я сдул с него пыль, поменял почему-то вышедший из строя предохранитель (а сначала было подумал - все, сдох от времени сам Zetron), подключил к GM350, и поотправлял сообщения.
Сообщения успешно принимались пейджером Motorola Advisor, а SDR# показывала все те же уровни девиации в районе 7.5кГц, как и в случае посыла моей программкой, что в целом было хоть и неправильно, но логично.
Тут мне стало ясно, что дело не в девиации.

Код генерации самого POCSAG'а у меня уже был проверен при генерации I/Q-файлов для HackRF, поэтому грешить на него было нечего.
Код управления сигналами DTR и RTS по своей сложности не сильно отличался от программ типа "Hello world!", и тут тоже все уже было проверено и перепроверено по десять раз.
Оставалось одно: сам COM-порт.
Надо сказать, что все это время я возился с USB<->COM адаптером на базе PL2303.
И вот когда я запустил свою программку на ноутбуке с аппаратным COM-портом - тут-то все сразу и заработало, и сообщения стали приходить на пейджер.

Так что резюме такое: судя по всему, при передаче сообщений об изменении служебных сигналов типа DTR поверх USB в сам чип PL2303 имеет место быть какая-то плавающая задержка, из-за чего как следствие получается плавающая длина битов в посылке.
Причем если бы задержка была постоянная, в этом не было бы ничего страшного - просто сигнал уходил бы в рацию чуть позже на величину этой задержки, и все.
А тут получается, что задержка именно непредсказуемо плавает, и из-за чего - раскопать крайне трудно, так как драйвер USB COM-порта работает не напрямую с железом, как в случае классического аппаратного COM-порта, а через целый стек драйверов, реализующий функционал USB-шины.

В общем, если кому нужна отправка сообщений на пейджеры через COM-порт - однозначно нужно искать компьютер с аппаратным COM-портом.

avk

В общем-то все логично. И от порта девиация тоже будет зависеть, напряжение единицы стандартизировано в широких пределах, а на практике - бывает еще шире.

Avk
А какой программой отправляете сообщения?

kotyara04
А какой программой отправляете сообщения?

А вы пробовали читать предыдущие сообщения хотя бы на этой странице, например вот это: Пейджинговая связь своими силами. Операторы умерли. - Страница 24 ?

Кто программировал нек 21а? Подскажите рабочий программатор схему.соединение?

Piratbyru

Вы шутите? Все выше выложили и разжевали по шагам.

9CXX
Попробую на днях.

Как, удалось попробовать pocsag2sdr в качестве POCSAG encoder'а для COM-порта?
Я тут на досуге причесал код и выложил его на https://github.com/avk-sw/pocsag2sdr/tree/master вместе с актуальной версией исполняемого модуля.

Если эксперименты успешны, то теперь остался один шаг до того, что вы хотели - автоматической переадресации e-mail на пейджер.
Для этого надо найти почтовую программу, которая бы позволяла при получении письма запускать внешнюю программу и передавать ей сам e-mail или его часть как параметр в командной строке.
Я посмотрел на Outlook в этом плане, но он, увы, умеет только запускать программу, но не передавать ей e-mail.
Сам e-mail в Outlook можно прочитать только в VB-скрипте, который можно подвесить на поступление новых сообщений.

Но, в принципе, на Outlook'е свет клином не сошелся.

avk

Увы, не было времени. Но попробую точно. А с Outlook мне было бы очень удобно.