Перейти к содержанию
    

framer

Свой
  • Постов

    60
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о framer

  • Звание
    Участник
    Участник

Контакты

  • ICQ
    Array

Посетители профиля

2 572 просмотра профиля
  1. Это справедливо не для всех многочленов а для многочленов в поле GF(q). Это общее правило разложения многочленов на множители. Но для поля многочленов GF(q) s(x) = 0 . Теперь если в данное разложение подставить бету то получим 0 т. е. корень.
  2. Да но есть один нюанс. Вот например хороший девайс SI5383 для подавления джиттера оптимизированный под 1PPS от GPSа. Кратковременный джиттера подавляет хорошо, но был замечен эффект джиттера с периодом 20 -30 минут. Понятно, что это зависит от многих факторов. От самого GPS, сигнала , антенны , атмосферы , и грузовиков с джамерами . И тут похоже без компромиссов. Либо делать подавление и фильтрацию с длительным периодом (несколько часов а может и день) либо при коротком периоде иметь неточную калибрацию. Но хуже всего, что при этом, не будет повторяемости.
  3. Да капитальное устройство. У мня такой вопрос. Вот там у Вас стоит GPS для калибровки. Я так понимаю, что калибровка как по частоте так и по фазе? Т.е. 1PPS получаем абсолютный? Сколько времени необходимо на калибровку и как это коррелирует с качеством сигнала от GPS? Если не секрет какой GPS? Ublox-a? И еще вопрос. Какое отклонение 1PPS в режиме holdovera?
  4. А точно Ucвх + Ul + Uc + IcR + Ucвых = 0 ? Может Ucвх = Ul + Uc + IcR + Ucвых ?
  5. Прошу сильно не пинать. Возможно скажу глупость. А как с шагом дискретизации DDS? Попробуйте дать +1 / -1 после регулятора и посмотрите как измениться результат.
  6. Роутеры это совсем другое. Все зависит от того что гоняем через роутер. Некоторые коммутаторы имеют функцию static routing L3 и могут вытягивать до 800/900M на 1G интерфейсах Но это если нет IPSec и все идёт через коммутатор. Если надо поток пропустить через хост процессор то все очень плохо. Для машин линукс какой бы не был производитель роутера, роутинг проходит через ip tables. Я измерял пропускную способность нескольких модулей SOM. Машина на SAMA5D4 на 100М интерфейсе показала производительность около 70М при чистом роутинге и 20М при IPSec. А вот такая машинка http://espressobin.net/ показала 400М при чистом и 200М при IPSec. Но они заточены под сеть. А вот на коммутаторе от Microsemi при чистом потоке 800М. Через пару дней буду иметь информацию по поводу imx8mm. Но роутинг это совсем другая тема.
  7. Предварительный концепт нода. Хотел бы спросить/обсудить следующие конструкционные вопросы . Количество входов/выходов. Гальваническая изоляция РС485 и ЦАН Питание. Размеры Корпус Почему? Это только модель для проверки некоторых идей. Это не конечное устройство. Вот выше предложение как я это вижу, Если обсудить может и что нибудь получится :) А модель будет выглядеть так,
  8. Ну во надыбал пару коммутаторов TP-Link LS105G 5x1Gb. Документация на чип есть. В целях «proof of concept» попробую сделать макетку. Для этой цели буду иметь пару вот таких https://kamami.pl/moduly-som/573098-visionsom-rt-modul-z-mikrokontrolerem-imx-rt-1062-sls12rt62528c0r4qspi0sfi.html евал боард . Управление MDIO вытягивается с коммутатора элементарно. Сигналы MDC MDI те же что идут на EEPROM. Надо только один сигнал подтянуть к земле. Подключение к евал борде будет пока отдельным портом а не через RMII но это на этом этапе не принципиально. Да вот и микротик эти коммутаторы поддерживает https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features
  9. Был один клиент. Обьект был большой. За основу был использован KNX от GIRA . Проблемы начались когда клиент хотел, чтобы на панелях интегрировать видеодомофон с системой видеонаблюдения и управления. Хотел поговорить через домофон с человеком перед калиткой. Открыть гараж или калитку, Покрутить камерой видеонаблюдения, Хотел чтобы все регистрировалось. Дубовый и дорогой homeserver https://partner.gira.com/en/systeme/knx-system/knx-produkte/server/homeserver.html от Gиры мог показывать только картинки с частотой отрисовки 1 секунду. Но надо было еще как то эти картинки с системы видеорекордера достать, Отдельно канал KNX, отдельно сеть ETH для панелей. Отдельно видеорекордер. Надо было везде тянуть свои кабели. Для видеонаблюдения свои для управления свои для видеодомофона свои. Ну если принять, что этот весь поток данных идёт одним каналом то хотя бы появляется возможность интеграции. Ещё была сигнализация периметра. Ну в данном случае можно было бы подключить через такой Нод IP камеру с PTZ для видеонаблюдения, IP камеру с микрофоном и динамиком как видеодомофон. Входа/выхода нода использовать для открытия электрозамка в калитке и кнопку вызова/звонка. Вот под такой сценарий по моему Нод и подходит. Поэтому и появилась идея одного канала. Да согласен. С рингом перебор. RSTP как раз то, что надо и топология сети получается гибкая.
  10. С POE интересно. Беру идею к анализу. Проблема будет только с тем что даже в режиме пассивного PD надо будет делать конвертер PD na PSE. По простому запитать и перебросить на другой порт не получится, Но вопрос с питанием стоит рассмотреть. Интересно мнение на счёт целесообразности применения РИНГ. Этот стандарт очень сильно променяют сетевеки на уровне L2. У меня была практика реализации этого протокола на AVR32 с похожим коммутатором. Протокол очень хорошо ложится в такие коммутаторы. Там основная проблема в возможности блокировки портов по MAC и очистки MAC таблиц при определённых условиях переключения направления. Что мы с рингом имеем, Если обрывается соединение в любой точке перебоя практически не видно и все узлы работают и видят друг друга. Утеря пакетов есть но она не превышает 50 мс. На конкретном примере. Скажем по схеме выше Нод 5 и 6 находятся на втором этаже. Если в ринге происходит обрыв между первым и вторым этажом в одном месте то для пользователей и управления это даже не заметно. На втором этаже работает интернет и все функции УД. Типа этого. Если такая функциональность избыточная то наверное не стоит запариваться. Хотя функции коммутатора оставить надо а следовательно реализация ринга это чисто программная фича . А функцию коммутатора следовало бы оставить потому что поток транковый с vlan и приоритетами. Я это позже опишу как будет выглядеть поток данных и аварии если интересно. Тут фишка такая что не все заминались сетями а из этого можно много чего вытянуть. А интересно как общая идея использовать толстый канал для всех подсистем? На счёт IEC61850 то это как показатель не обязательно его использовать но обратить внимание стоит. Можно даже руками потрогать. Об этом тоже могу написать. Тут вопрос следующий . Для realtime обмена данными лучше использовать уровень L2 чем L3. Как соберу мысли то напишу. Да это одно из решений. В похожих ценах есть много решений. Есть тяжёлые клиенты но пробивные. Я как раз имел дело с Marvell. У них конечно мох и болото. Есть варианты с SERDES. Можно ставить каналы под SFP. Если постараться то можно достать. Ну и Microsemi pod Microchip легла и открылась. В общем выбор есть. https://www.microchip.com/wwwproducts/en/KSZ9897 http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9897S-Data-Sheet-DS00002394C.pdf
  11. В очередной раз встретился с людьми которые хотят создать у себя УД. Обращаются за советом чтоб им посоветовать. И уже какой раз у меня появляется идея заняться этой темой вплотную, но не решением конкретной задачи под конкретного клиента а поиском ниши для создания базовых устройств. Пересмотрел информацию по поводу решений, пересмотрел проблемы и появилась идея. Но сначала хотел подытожить холивары по поводу решений и проблем. Холивары Системы централизованные /децентрализованные. Орган управления плк /пц. Сеть Проводная/ беспроводная. Проблемы Пропускная способность каналов связи. Если иметь толстый канал то можно пустить всю информацию через этот канал. Интернет, Аудио, звук, управление. Надежность каналов связи. Обрыв канала в одном месте обеспечивает полную работоспособность системы. Жесткий realtime. Обсуждалось. Появлялись цифры около 20мс. Была информация на счет EtherCat что это очень realtime но канал должен быть выделен только под него. Масштабируемость системы. Устойчивость функциональности к аварии части системы. Падение любого элемента системы не приводит к ступору. Возможность выхода вверх (облачные сервисы). Закрытие канала WAN не сказывается на функционале системы локально. Подумав над проблемами появилась идея создать что-то на подобии backbone сети с элементами которые обеспечивают работу и постараться использовать стандартные решения. Если присмотреться то похожие проблемы есть на цифровых подстанциях 61850. Там есть и толстый канал (process bus) с выходом вверх (goose protocol) и realtime(sv protocol) (передача до 4000 измерений на секунду от одного устройства). Также применяется технология G.8032v2 ERPS (Ethernet Ring Protection Switching ) . Так что первое что пришло в голову использовать в качестве основного канала связи 1G ETH и закольцовать в ринг. Элементом этого кольца будет Нод. Нод это такой автономный ПЛК со встроенным коммутатором на 3 порта 1G . Основные функции нода, это отработка например загруженной программы согласно с IEC 61131-3 стандартом. Обмен информации с соседними нодами если переменные выходят за пределы одного нода (sv protocol типа iec61850_9_2_LE ) и обслуживание ринга. Так как нод содержит коммутатор то без проблем можно подключить или компьютер или камеру. Это будет единая толстая бесперебойная транковая сеть в УД. Разделение vlan-ами позволяет отделить интернет от управления. С нодами похожее решение есть в KNX, там встречаются такие ноды что с одной стороны обслуживают магистраль KNX а также имеют по несколько входов/выходов а с другой имеют внутреннюю магистраль для подключения специфических актеров/сенсоров. Схема будет выглядеть приблизительно как на рисунке. Т.е. получается, что основная разводка проводов это в основном качественный кабель для сети CAT 5 / 6 и питание. Если поставить ноды в одном месте то будет система централизованная и эти ноды будут выглядеть как один ПЛК. Если разнести модули по этажам/ помещениям получается система децентрализованная. Если модуль упадет то перестанет работать только этот модуль и часть функционала с внешними состояниями. В качестве Eadge device можно использовать PC с OpenHUB. Если проблема с расстоянием можно использовать fiber (например видео домофон во дворе). Почему 1G? Ну в основном чтобы можно было гонять несколько потоков видео и работать с интернетом через эту сеть. Используя QoS i vlan можно управлять приоритетами и достигнуть realtime для канала управления даже с загруженной сетью. Это в общих чертах. Ну сколько бы это стоило? Идея появилась после предварительной грубой оценки цены. Из тяжелых элементов это шустрый MCU + коммутатор + питание. На пример rt1064 + KSZ9897 + AC/DC 5W ~ 40$ + остальная часть 40$ в сумме такой нод должен получится около 80. Ну и конечно куча работы. Хотя с большой частью технологий я работал но и так всего самому не переделать. Есть идеи и наработки. Я сторонник открытых решений так что, если идея чего то стоит, то попробую более качественно описать и прозондировать на https://hackaday.io/ и запустить на https://www.crowdsupply.com/crowdfunding . Хотелось бы услышать мнение спецов особенно AlexandrY i syoma ну и конечно всех остальных.
  12. Да KNX это архаизм и магистраль медленная и интеграция с остальными системами плохая и видео идет боком, но некоторые концепции стоят того чтобы на них обратить внимание. Минусы тут уже описывали. А вот из плюсов только распределённость. Да KNX чем то похож на CAN. Решает проблему общего доступа к каналу и не требует поолинга, но что надо сделать, чтобы принять подтверждения исполнения операции от всех заинтересованных узлов быстро не перегружая магистраль. В КНХ реализован интересный патент (групповое подтверждение с доминантным уровнем ошибки). Следующая интересная идея сегментации сети. По сути при очень маленькой скорости магистраль работает с очень маленькими задержками. Ну и еще как мне кажется способ реализации питания, устойчивость к низкому качеству проводки и длина сегмента магистрали. Если говорить о распределенных системах, то не знаю, что может быть лучше. На сколько критическое требование иметь распределенную систему при реализации УД не знаю, но проблем с такой системой появляется много.
  13. Проблема с AVR32, deadlock в macb.c .

    Возникла проблема с AVR32 (AT32UC3A0512). Точная ситуация описана http://asf.atmel.com/bugzilla/show_bug.cgi?id=3021 . Случай 1, deadlock появляется когда часто высылаю пакеты. Может кто сталкивался с подобными проблемами?
×
×
  • Создать...