В том то и дело, что однозначно ответить нельзя. На искуственных линиях результаты неплохие (до +40% дальности отн. PEF22622). На кабеле (МКС 1.2, пустой) - можно сказать провал (в районе 28 - 38 каналов явно падает SigQual). На другие типы кабелей пока не ездили. Не хотелось бы вводить вас в заблуждение (ни в +,ни в -) допускаю возможность "косяка" в разводке\комплектации.

У меня встречный вопрос. Кто нибудь занимался альтернативными чипсетами SHDSL? Metallink, Globespan, LevelOne(Intel), Analog Dev. ... Если да, то есть предложение пообщаться на темы сравнительных характеристик и проблем с пуско-отладкой ( у кого, что наболело). Пусть без конкретики, в плане общего развития. Если предложение интересно открывайте тему.

Не с чем тему открывать. Из стаи SHDSL первым подвернулся именно PEF22622... Причем не потому что хороший, а потому что доставаемый (образцы, документация и т.д.) Очень хотелось именно Globespan - а в ответ от поставщиков тишина. Может конечно уже изменилась ситуация, но проект уже не переделать.
А спрашиваю насчет SDFE потому, что уже практически пора заказывать платы с этими чипами, а с оглядкой на Сократес как-то сомнения берут - может не стОит закладывать чипы от Инфинеон? Мне кажется с решениями для связи у них значительно хуже чем с памятью.

Есс-но сомнения есть. А вот выбора нет. SHDSL.bis надо делать и делать быстро. А SDFE принципиально работоспособен. Не понимаю только зачем им обмен с микросхемой на базе синхронного HDLC протокола понадобился? V2.1 заявлена с поддержкой параллельного порта. А наоборот нельзя что ли было сделать ? Сначала параллельный порт, а потом (для чиста пантовых ребят) SDI+HDLC. Реальные тормоза в замене PEF22622 на PEF24624 на мой взгляд в основном с этим и связаны. Называется "родите ребята HDLC контроллер у себя на плате".
Но это так, "лирика".
До SOCRATA делал HDSL2 на Level One-s, чипсет из 3-х микросхем. AFE грелся на 2056Кб\с (ИМХО заточен под Т1).
После SOCRATA выходили на Metallink, получили ftp account, почитали доки и поняли, что максимум у них в ближайшем будующем можно сделать 3.3 Mb\s по паре. т.е. SHDSL.bis у них желания делать нет.
По Globespan-у ничего, темная лошадка.

Мы используем версию COT15/RT15. При попытке завести pcm-master на скорости 4096 начинает дрожать с частотой 50-100 герц duti cycle REFCLK и PCLK. Причем скажем передний фронт стоит как вкопанный, а задний пляшет с 0.3 на 0,6. Зачем так было делать и нафиг это кому нужно?
Кто знает как с этим дела в следующих версиях ?.
Какие изменения в вресии 17 относительно 16 ?
И что значит по помехозащищенности ? Они что, линию хуже держат ?

Вообще устал я от Infineona с ихними граблями...
Пологаю с SDFE будут то же.
Жаль что фирма Intel скупившая в свое время Level One свернула это направление.

Мы используем версию COT15/RT15. При попытке завести pcm-master на скорости 4096 начинает дрожать с частотой 50-100 герц duti cycle REFCLK и PCLK. Причем скажем передний фронт стоит как вкопанный, а задний пляшет с 0.3 на 0,6. Зачем так было делать и нафиг это кому нужно?
Кто знает как с этим дела в следующих версиях ?.
Какие изменения в вресии 17 относительно 16 ?
И что значит по помехозащищенности ? Они что, линию хуже держат ?

Вообще устал я от Infineona с ихними граблями...
Пологаю с SDFE будут то же.
Жаль что фирма Intel скупившая в свое время Level One свернула это направление.
[/quote]

- Ну да, дрожжание есть. Я так мыслю, что это ФАПЧ так захваченную частоту (синхронный режим) или стаффинги (плезиохронный) отрабатывает (смотрите то отн. опоры, не так ли?). Для приема данных с TDM это не критично.
- Версия 17, поначалу радовала устойчивой активацией на 14 км МКС 1.2мм, а кончилось тем, что и на 11 км незаработала (т.е. та же неоднозначность от участка к участку). Причем в сравнении с 15-й версией на одном и том же участке за сутки ошибок вываливается в разы больше (уч-к вдоль ЖД).
- На генераторе шума (Noise ADSL gen. NSA-400) в принципе подтвердилось, что при одном и том же уровне шума на 17-й ошибок больше, хотя порог выключения по большим шумам у 15-й меньше.

к "Вообще устал я от Infineona с ихними граблями..." полностью присоединяюсь.

>- Ну да, дрожжание есть. Я так мыслю, что это ФАПЧ так захваченную частоту (синхронный режим) >или стаффинги (плезиохронный) отрабатывает (смотрите то отн. опоры, не так ли?). Для приема >данных с TDM это не критично.

Вопрос какой урод это сделал и зачем. Смотрим кстати не относительно опоры а просто одним лучем.
Такое впечатление что сначала 4096 они вообще не собирались в мастере делать, а когда до них дошло что 2,3мбит не получается втиснуть в 32КИ начали лепить горбатого до стенки.
Кодеки в принципе работают. Меня больше беспокоит на сколько это отразиться скажем в регенератора где будет переприем по TDM, фактически эта билиберда попадет в REFCLK ведомого сократеса со всеми вытекающими.


- Версия 17, поначалу радовала устойчивой активацией на 14 км МКС 1.2мм, а кончилось тем, что и на 11 км незаработала (т.е. та же неоднозначность от участка к участку). Причем в сравнении с 15-й версией на одном и том же участке за сутки ошибок вываливается в разы больше (уч-к вдоль ЖД).
- На генераторе шума (Noise ADSL gen. NSA-400) в принципе подтвердилось, что при одном и том же уровне шума на 17-й ошибок больше, хотя порог выключения по большим шумам у 15-й меньше.

Не думал что версия будет влиять на линейную часть. Нужно будет сравнить 15 и 16 на реальном кабеле. А где 17 взяли ? Не поделитесь для целей экспериментов ?

к "Вообще устал я от Infineona с ихними граблями..." полностью присоединяюсь.
[/quote]

В догонку.
Кто нибудь пробовал для увеличения дальности 22622 пускать по двум парам прием-передача (разорвать гибрид и поставить отдельный тр-р на прием)?
В ряде случаев думаю это решение имело бы право на жизнь.

По поводу регенераторов особо не переживайте, проблем не будет (3 года, полет нормальный). Режим плезиохронный, refclk, rclk, pclk - спина к спине. До 10-и РЛ-ов в линии (при локальном питании до 16-и).
17-ю версию ловите.

Само по себе разнесение сигнала по парам сильно дальность не увеличит (затухание то остается). Реально помочь может широкополосный усилитель на входе (такая схема используется у Shmit Telecom, в Watson3 (CAP128)). Предварительное усиление. Отключения эхокомпенсации в Socrate нет. Поэтому даже если убрать внешний hybrid чистого спорта не получится. Он и в штатном то режиме, сволочь, через раз схватывается.

Да и к чему? Возможность параллельной работы с К-60?

Не затруднит ли вас вывесить и 1.5 и 1.6? А то у меня только 1.4 и 1.7

Вопрос по регенераторам:
1. Удалось ли вам сделать автоматический выбор скорости на pef 22622 во всей цепочке регенераторов?
2. Если выбрать проведение Line Prbinga на REG-C и REG-R одновременно - они не переходят в состояние Wait-STUC, а начинают сразу синхриться. Из-за чего не неполучается работаспособной схема описанная в DataSheet и в G.991.2.
2. Объясните мне пожалуйста принцип выбора Socrates'ом скорости синхронизации после проведения PMMS. Что такое SNR в скачиваемых результатах Line Probing? Что значат отрицательные значения SNR? Какой SNRTH Надо выбирать для наших линиях?
4. Есть CL лист. Я пытаюсь передать в нем в NS-поле несколько байт своей информации, но после скачивания листа на удаленном Socrates - его длина 0x65 и соответственно никакого там NS-field нет.
5. Какой Datasheet для pef 22622 последний? Будут ли новые прошивки для этого трансивера и новые документации?
Спасибо.

О! Лишнее подтверждение того чо инфинион - глюкодром.
Забудьте о REG-C REG-R, PMMS SNR и прочей нечисти. В регенераторе грузите обычные COT и RT.
Скорость задавайте в СОТ
После синхронизации первого сегмента читайте скорость из RT и скармливайте ее в COT второго и так далее. После того как все заработает решите , стоит ли заморачиваться с "правильной схемой"....

Кстати, как то прогоняли всю сетку скоростей. Обнаружили дырку если не ошибаюсь на 33КИ(а может быть дальше но точно после 32КИ), на прямой лини не становиться на слот меньше/больше все ок....

Юзерскую информацию можно передать на ту сторону более другими способами.

2All: Кто - нибудь запустил EOC-HDLC ?

Да, EOC-HDLC работает нормально.

Ранее в топике были вопросы по поводу провалов по качеству при большом числе КИ (с 25-го по 30-й). Это лечится, мы изменили выходной фильтр, а также перешли на одну обмотку в выходном трансформаторе. Работаем на КСПП-1.2 до 12км для 32 КИ и до 24км на 20 КИ. Между модемами до 6 регенераторов (питание с каждой стороны для 3-х). Работа в парных режимах почти не ухудшает качества.

Сейчас хотим подняться выше 32 КИ. Наверное, наряду с Infineon попробуем MetaLink.

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

Вопрос: Как можно передать "Юзерскую информацию" до синхронизации? Какие методы. Может я что-то не так делаю - особенно с Message Mode в CL листе.

EOC - HDLC работает - но очень осторожно. В даташите по EOC очень много опечаток и фрагментов из старых даташитов. D - канал описан лучьше и работает увереннее.Передавать по прерыванию у меня не получилось - приходится ожидать всяких там подтверждений в основном цикле программы.


Если есть какие либо советы по PMMS и Line-Probing - поделитесь пожалуйста.

Сообщение отредактировал belax - Sep 22 2006, 09:37

Нет. В деталях: мы отказались от автоматического выбора, поскольку SOCRATES выбирает его по простому принципу: на какой _МАКСИМАЛЬНОЙ_ скорости проба SNR > SNRTH регистра. Работает очень не всегда, так как на реальных линиях зависимость SNR от скорости нелинейная.

Мое мнение - это в SOCRATES не работает. Регенератор загружается как COT и RT, в RT в CapList разрешены все скорости, а в COT устанавливается принудительно одна. PMMS не проводится.

Самая большая загадка. По идее (и основываясь на проведенных экспериментах) SNRTH это минимальное значение для пробы, которое считается SOCRATES валидным при выборе скорости.
SNR - SIGQ = PMMS с некоторой погрешностью. К таким выводам пришел после нескольких дней наблюдения процесса автовыбора скоростей.
Отрицательные значения в пробе означают, что проба не прошла или не выполнялась.
SNRTH установил в 10дБ. Подбор ничего не дал, кроме головной боли.

На второй стороне получить принятый CapList можно только в случае NOCOMMODE и _ТОЛЬКО_ стандартные поля.
Применяем следующий алгоритм:
1. Необходимую информацию заносим в поля Country Code и т.п.
2. Убираем флажки режимов PMMS и TRAIN.
3. Как результат NOCOMMODE. Вычитываем CapList.
4. Приводим параметры в соответствие и грузим правильный CapList.
5. Синхронизируемся.
Если верить документации, то SOCRATES воспринимает NS как PBO для регенераторов. Получить рабочую конфигурацию не удалось (см. п 2)

Не знаю. Я сомневаюсь, что Инфинеон вообще хоть как-то _обновляет_ документацию.

Пожалуйста.