Привет всем! Вопрос, в режиме АОНа некоторые экземпляры не показывают все цифры (есть прочерки) или даже идет ошибка в номере. Регулировка длительности запроса, задержек не помогает. Явно или програмный дефект или аппаратный. Кто сталкивался и как побороть. В остальном аппарат ведет себя адекватно.:confused: Была подобная проблемма с последней цифрой номера в 5ХХ серии, глоталась первая цифра при передачи ( номер передаеться задом на перед) В этой модели последняя всегда корректно отображаеться.

Подобная фигн у меня и на TCD- 540 и на TCD-825 иногда последняя цифра не определяется.
Поидде не длительностю, а количеством запросов должно вылечиться, но ждать тогда до определения немного дольше надо будет.

Не решение проблеммы. В 5ХХ серии решалось уменьшением длительности запроса до 110 мсек. Иначе наша станция уже передавала ответ, а запрос еще не закончился вот и съедалась певрая (она же последняя в номере) цифра. Здесь, вообще хреновое определение. Если номер не имеет 3 а они лезут, значит или где то не так обрезает сигнал DTMF (ограничение уровня в аналого цифровом преобразователе) цифра детектируеться кол-вом переходов через 0, такой алгоритм bли сам алгоритм страдает. Вернее первое. Так как 9 из 10 телефонов все таки не врут. Но пропай не дал результатов. Возможно номиналы пляшут.

максимум что можно сделать в телефоне -это поставить число запросов 5!
длительность,паузу ,и задержку менять бесполезно!
все сбои при определении номера в данном случае происходят из-за плохого качества соединения на атс.
аппарат здесь не причем.

Если номер не имеет 3 а они лезут, значит или где то не так обрезает сигнал DTMF (ограничение уровня в аналого цифровом преобразователе) цифра детектируеться кол-вом переходов через 0, такой алгоритм bли сам алгоритм страдает. Вернее первое. Так как 9 из 10 телефонов все таки не врут. Но пропай не дал результатов. Возможно номиналы пляшут. [/i][/QUOTE]

вот вам и доказательство !
передача номера идет с помехой , вследствие чего телефон неправильно расшифровывает эту инфу,
вот и вылазят неверные цифры, или вообще прочерки!
поставьте телефон на другую линию и все станет ясно.
удачи!

Какое качество соединения, линия идеальная. Станция электронная у меня над головой. Итальянская UT 100. Проверяем на 5 номерах сразу. Если другой панас на этой линии не врет никогда, а это врет, значит виновата станция :mad: Смотрите профайл прежде, чем давать советы. Извиняюсь за Офтоп

если станция Итальянская- заказывайте Caller ID.

русский (советский) АОН это жуткая пародия на сервис определения номера звонящего и проблема здесь не в телефоне.

данную опцию (русский АОН) рассматривайте как прибамбас, достоинством которого является возможность его отключения.

Этой станции уже 15 лет, и тогда законодательсвтво по поводу применения Caller ID было совсем другое, а теперь с этим не хотят связываться. Затратно для перехода. Согласен с VSKY, что АОН это анархаизм и меня совсем не радуют платеж за несостоявшийся разговор, особенно если он междугородний. Но заявляя, что в аппарате есть русский АОН - будьте добры обеспечить работу по стандарту. Иначе покупая телевизор, который с изображением, но без звука или с одними гласными вы не станете. Вам просто будут возвращать аппараты по закону прав потребителя. Или хотя бы прямо пишите, - АОН в подарок, правда не знаем будет ли он у Вас работать. А даренному "подарку" в зубы не смотрят.

фарэо прав - фича заявлена, значит должна работать.
дмитрик, насчёт длительностей ты не прав, очень влияют.
Длительность запроса и пауза перед выдачей запроса.
В большинстве случаев у нас ( в городе) достаточно 3-х запросов.
Ну и по теме - проверил сейчас модель 7225, определение нормуль. Если есть мануал - посмотри что написано в eerpom layot по поводу русского аон, процесс регулировки будет долгий. Вообще не думаю, что панас сменил алго определения для русского аон.

по поводу заявленой фичи- в инструкции написано, что её надо заказывать у оператора.

в Вашем случае оператор её предоставляет (берёт за это деньги)?

Да. Но она (станция) выдает все по Российским стандартам, станция прошла полную сертификацию, все временные и частотные посылки в требуемых границах, что не скажешь о телефонах. :D Представляешь если бы они вместо одной цифры выдавали другую ( в тоне) И можно конечно говорить, что это прошлый век и что есть ISDN и SIP телефония, как у нас в городе. Пожалуйста ставьте не хочу. Но это уже гламур.:D

Алёха пишет

Ну и по теме - проверил сейчас модель 7225, определение нормуль. Если есть мануал - посмотри что написано в eerpom layot по поводу русского аон, процесс регулировки будет долгий. Вообще не думаю, что панас сменил алго определения для русского аон.
Да в том то и дело, что попадеться такая одна из десятка и голову ломаешь. Этот не в ремонт, это предпродажная проверка. Аппарат нулевой. Алгоритм у этих моделей корректный, отбиваеться сразу после отбоя с другой стороны и после поднятии трубки на параллейном телефоне.
EERPROM посмотрел, теже регуллировки выведены в меню. Это в 5ХХ приходилось через сервис лазить. Ладно спасибо. Пошел 2 дня отдыхать, что и Вам всем желаю. Удачи всем.

и телефоны прошли сертификацию.

Тогда точно лучше узнать поподробнее про эту АТС через какое время распознает запрос, через сколько дает ответ,как ты и писал . Хотя если например один Панас с определенными временными параметрами видит , а другой с теми-же не видит, то ясно что дело в аппарате. Не могут ли входные и наборные цепи частотку подрезать(Хотя врядли). А как? несколько аппаратов ведут себя неадекватно? А например проверенный типа TCD-500 не глючит или тоже глючит.

Да как у нас проходят сертификацию, тем более сейчас можно только гадать. EERPROM посмотрел, теже регуллировки выведены в меню. Это в 5ХХ приходилось через сервис лазить. Ладно спасибо. Пошел 2 дня отдыхать, что и Вам всем желаю. Удачи всем.

Тоже добавлю кое-какую отсебятину.
Количество запросов конечно влияет, но не на качество определения, а на возможность определения вообще. Не берусь точно судить об этом в Панасах, т.к. детально их алгоритм по-моему еще нигде не описывался, но вот в наших местных АОНах типа Русей принцип такой - если от АТС информация в ответ на запрос не пришла в течение некоторого времени, то выдается следующий запрос, но как только пришла и номер худо-бедно определился, то больше запросов не выдается, т.к. бессмысленно, все равно на следующие запросы АТС не ответит. Другими словами, если номер определился неправильно или не полностью, то увеличение количества запросов тут не поможет.
Насчет достоверности определения номера в Панасах, может быть я ошибаюсь, но в инструкциях кажется что-то есть насчет того, что это зависит от АТС. Т.е. вроде как отмазка для клиентов есть, что функция рус. АОН в аппарате заявлена, но работоспособность зависит от АТС. И в принципе это действительно так. Хуже когда клиент видит, что один аппарат определяет без проблем, а другой той же модели в тех же условиях врет. О чем собсно Фарэо и спрашивает. Как лечить, даже не представляю, не сталкивался. В качестве эксперимента я бы попробовал поставить в базу eeprom от аппарата, который не ошибается, а также проводами завести на проц сигналы тоже от исправной базы. Тогда будет ясно, сам проц больной или что-то внешнее.
"не так обрезает сигнал DTMF (ограничение уровня в аналого цифровом преобразователе) цифра детектируется кол-вом переходов через 0, такой алгоритм или сам алгоритм страдает. Вернее первое." Об этом можно только гадать, но если дело в ограничении, то уровень на входе проца задавить не проблема, можно проверить. Хотя мне кажется вряд ли. Это в наших АОНах, у которых нет АЦП, и всю информацию после оцифровки несет в себе только фаза момента перехода через ноль, даже небольшие искажения и ограничения сигнала до компаратора могут существенно повлиять. А в АЦП-шных схемах преобразование Фурье, которое используется при программном анализе, гораздо менее чувствительно к искажениям. Я думаю алгоритм у Панасов все-таки недостаточно хорошо отработан, по разному ведет себя от модели к модели и может быть чувствителен к параметрам цепочек на входе АЦП. Об этом сужу еще и по тому факту, что на имитаторе ТТА у российских АОНов нет никаких проблем с определением, а половина моделей Панасов определяет через раз. ТТА выдает поочередно два номера: 1234567, категория 1 и 5678900, категория 9. Многие Панасы же для второго номера выдают ----009. Налицо явная нестыковка по времени, слишком рано начинают принимать относительно начала посылки от ТТА. Но как ни странно при этом первый номер определяет нормально и временнОго сдвига нет. Похоже алгоритм плохо детектирует момент начала посылки и имеет недостаточно возможностей для корректировки ошибок. Кстати, это доказывает, что увеличение количества запросов тут не поможет, Панас тоже если уж что-то принял, то больше запросов не выдаст.

bvj пишет
ТТА у российских АОНов нет никаких проблем с определением, а половина моделей Панасов определяет через раз. ТТА выдает поочередно два номера: 1234567, категория 1 и 5678900, категория 9. Многие Панасы же для второго номера выдают ----009. Налицо явная нестыковка по времени, слишком рано начинают принимать относительно начала посылки от ТТА. Но как ни странно при этом первый номер определяет нормально .

тоже иногда наблюдаю такую же ситуацию

ТТА выдает поочередно два номера: 1234567, категория 1 и 5678900, категория 9. Многие Панасы же для второго номера выдают ----009. Налицо явная нестыковка по времени, слишком рано начинают принимать относительно начала посылки от ТТА
Проверил ТТА-4, мда вообще гонит. Выдает при первом прогоне 34567 для 1 кат. при втором 78200 для 9 категории.
А ТСD296 который на линии вообще не ошибаеться, с ТТА - выдал только две цифры 67. А это все таки тестрер для проверки правильности работы АОНов и телефонов. Кстати тоже прошедший сертификацию.
:D