Leaderboard

Я сейчас скажу, но ТС может воспринять меня в штыки. ТС, пожалуйста, попытайтесь вникнуть в то что я скажу. Вы когда-то написали эту программу, с виду - она похожа на ввод таблицы, применение метода наименьших квадратов и вычисление пары параметров на основе этих коэффициентов МНК. Работы по идее - почти нет. Но есть, ньюансы. Вы, когда писали, были в теме. Другие с нашего форума - не в теме. Им вникнуть в тему потребуется больше времени, чем на написание самой программы не зависимо от того, на дельфи, на ембаркадейре, на жаваскрипте или на просто любом другом языке программирования. Когда Вы видите, что человек мечется, не понимая что от него хотят, Вы воспринимаете этого человека как не специалиста, и обижаетесь на него, поэтому и удаленно у Вас ни с кем сработаться не получилось. ИМХО, из-за всего этого попробуйте, пожалуйста, посмотреть в стонону совершенно другого варианта: поиска человека, который объяснит Вам как портировать Ваш паскаль на эмбаркадейру или что-то современное, причем, чтобы само портирование фактически Вы сами осуществили, но человек Вам помог бы разобраться в современных системах и платформах, то есть поищите учителя современных систем, а не программиста. У Вас самого кода кот наплакал, но если это в техзадание превращать, там на три месяца работы по написанию техзадания будет.

Никаких дефектов "в самом начале" не было и быть не могло. На всех студиях работал ОТК. И бракованные кадры, например, с царапинами, приходилось переснимать. Дело в том, что наше телевидение работает независимо от киностудий. Для показа по телевизору брали не эталонную фильмокопию, подготовленную оператором для премьерного показа в Доме Кино, а брали фильмокопию из проката. Эта фильмокопия прошла уже 800 или более 1000 сеансов, вся зацарапана, со склейками. Возможно, она была уже приготовлена на списание. И вот с этой копии на телевидении делали перевод на магнитную ленту. То, что называется "телекино". А чаще всего фильм просто демонстрировали в эфир с помощью специальной установки без записи на видеоленту. Плёнка шла по проектору и её переснимала "объектив в объектив" видеокамера. Вот как выглядела такая установка. Поскольку экран телевизора довольно маленький, то раньше для показа фильмов по ТВ использовали 16-мм фильмокопию. Конец50-х - начало 60-х гг., демонстрация кинофильма в эфир.

Проверенный и пофикшенный вариант: https://github.com/ADElectronics/Open-Hardware/tree/master/Debug/X-Link-v11.x В v1.0 я немного перепутал резистор на TDI линии (не работал JTAG и VCOM TX поэтому), а так же не туда подключил одну подтяжку сдвоенного полевика на регулируемом +5В выходе, отчего питание на выход полностью не выключалось. В v1.1, что на гите всё поправлено уже. Схему не причёсывал особо. А так всё пашет теперь (тест на подключение к тарджету JTAG проходит), тарджет питается от отладчика, к нему же подключён VCOM и по SWD тарджет отлаживается же. Помимо этого и RTT можно тут же смотреть в браузере (правда нет поддержки окрашивания выводимых символов, лучше нативное приложение в этом случае):

Неподдельный интерес вызвала ваша вакансия. Расчитываю на некоторые пояснения, касающиеся раздела "Требования:" в части приведённого выше пункта. По-отдельности слова и большая часть словосочетаний понятны, но смысл, увы, ускользает раз за разом, несмотря на множество попыток прочтения.

Ды ) Это собственно сдутый МК с алишного jlink, зареболенный и напаянный на свою плату (и всё феном 🙂 ). Работает: Один резистор на входе ОУ был лишний только. Завтра надеюсь приедет голый МК и собственно попробую собрать уже с нуля плату, да попробовать зашить туда слитый дамп.

Уважаемый, позвольте заметить, почти 40 лет назад, будучи студентом подрабатывая на кафедре, был PSpice и меня "припахали" как раз делать модели для PSpiсe + мат. моделирование и методы оптимизации эл. схем. Так что все было.

Lazarus же

И еще в том суровом Турбо-Паскальном коде вполне себе возможно сидит какой-то баг, и в этом вся и причина. Это задача в действитеьности не для человека, а для нейросети (о чем я уже намекал). Она если ей растолковать накатает именно что

Только сегодня пришли: Сегодня если свободного времени хватит, то спаяю один. И пока они шли, статья https://habr.com/ru/articles/770454/ натолкнула меня на создание своего переходника ) Правда у себя я сделал автодетектирование io\clk и по идее можно спокойно будет любой стороной подключать, но платы ещё не заказывал, так что скорей всего около НГ только проверю в железе: USB входной используется как питание и линии данных идут напрямую к выходному USB, а JTAG (угловой впаивается, на рендере просто PBD установлен) подключается к стандартному J-Link 10-pin. Очевидные минусы такого решения: - уровни SWD зафиксированы на 3,3 В, сходу не придумал как это обойти, да и пока особо и не нужно (в основном с STM32 отладка ведётся) - отсутствие сброса, без колхоза через type-c его никак не протащить, особо не нарушая спецификацию. 😕

Вы знаете, у меня есть блог, точнее Дзен-канал, который называется "Кинооператор рассказывает". Там я написал уже 250 статей. Наверное, нужно посвятить несколько статей вопросу показа фильмов по телевизору, сканированию и пр., поскольку вопросов возникает множество. Что касается того, что "на телевидении переписанный на бетту." - то Бетакам - это очень низкое разрешение: 768 х 576. "Контратип" - это дубликат негатива. Сейчас принята большая программа - Нацпроект - по восстановлению старых фильмов. Это прежде всего сканирование в высокой чёткости, 4К и реставрация. Уже отсканировано (если не ошибаюсь) 6 тысяч фильмов (такое количество было названо на конференции по архивному хранению, на Круглом столе). После печати эталонной фильмокопии все исходные материалы (негатив, установочные ролики, световые паспорта, звуковая лента и пр..) с киностудий передаются в архив на хранение. Документальные фильмы хранятся в Красногорске, игровые - в Белых Столбах (за Домодедово). Две недели назад главный инженер Госфильмофонда сказал мне, что 70-мм (широкоформатный) негатив фильма "Война и мир" хранится в архиве в Белых Столбах.

Желтеют, а точнее буреют позитивные фильмокопии из-за выцветания голубого красителя. ВЫЦВЕТАЮТ ПОЗИТИВЫ (кинофильмы, цветные советские фотографии), а когда восстанавливают фильм, то сканируют не позитив и не поцарапанную прокатную копию, а оригинальный НЕГАТИВ. Там используется другая голубая компонента и голубой цвет в негативах не выцвел за последние 60-70 лет. Потом сканированный негатив в редакторе инвертируют в позитив. Приведите пример, какой фильм плохо восстановили по цвету, чтобы не упрекать вас в абсолютном непонимании процесса восстановления фильмов. Ведущий технолог Госфильмофонда.

Настраиваем два канала dma один на передачу по spi другой на прием. на прием можно в одну ячейку памяти без инкремента принимать. Запускаем dma по окончанию приема dma сформирует прерывание, или что-то не так в моих рассужениях?

Это потому что common symbols. В "голых" Сях такое возможно, в плюсах - нет. https://binarydodo.wordpress.com/2016/05/09/investigating-linking-with-common-symbols-in-elf/

Всё таки заставил работать этот SWV Data trace. Пришлось откатить прошивку на самом программаторе StLink c версии V3J13M45S1(3.13.4) до версии V3J12M35S1(3.12.3). Я уже всё переустановил, даже на ноуте дочки поставил CubeIde и вот когда там не заработало. я догадался что проблема в том, что в этой связке было неизменным с момента обновления Куба. Я как-то не придал значения, что куб просил обновить прошивку на программаторе, ну и обновил. Оказалось это было зря. Откатить прошивку можно скачав с сайта ST тулзу STSW-LINK007 с предыдущей версией прошивки. Версию видно в STM32CubeProgrammer, правда в немного другом виде: V3J13M45S1 -> 3.13.4. ищем предыдущую, откатываемся и работаем)))

К сожалению новее варианта нет. AN04001 Logos2 SEU Application Guide_innek.pdf Вот более актуальное ips2l_seu_v1_8.iar UG042001_Logos2_SEU_IP.pdf

rebase -- мощная штука при правильном использовании: позволяет держать историю красивой (когда она состоит из комитов слияния, где чётко видна этапность добавления фич и фиксов, по такой истории легко ориентироваться -- быстро находится добавление той или иной фичи, а по комитам слитой ветки видна локальная история разработки фичи, ничего не смешивается) при работе группой. Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками). Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния. Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов. Получается, что хотя работа участниками проекта во временном аспекте ведётся параллельно, в истории комитов результаты их работы (фичи/фиксы) добавляются строго последовательно, что убирает путаницу: вид такой, как будто все работали друг за другом по цепочке, дожидаясь результата (слияния) от предыдущего члена команды. В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

Через недельки 1,5 узнаю, насколько косячный дизайн вышел:

Вы бы сказали, чего конкретно вы ожидаете? Вас сложно понять. Вы написали "выделение части линии". Такого нет ни в одном каде, какие я знаю. Как это должно выглядеть я ума не приложу

Вышли обновления: Radiant v2023.2 (залито в ./upload/FPGA/_Lattice_/Radiant/v2023.2) Propel v2023.2 (залито в ./upload/FPGA/_Lattice_/Propel/v2023.2) Основное новшество - расширение поддержки ПЛИС семейств Avant. Release Notice прилагаю. Radiant_2023_2_Release_Notes.pdf FPGA-AN-02068-1-0-Lattice-Propel-2023-2-Release-Notes.pdf

Есть ёмкость меняется Conductive Fluid Sensing Cable

браво программа Аполлон. куча видео. описание конкретики в статьях. просто повторяем.

Лично мне приглянулся способ писать совсем уж примитивный нижний уровень драйверов периферии - в Си-стиле: просто вызов функций, сами драйверы предоставляют сухой набор экспортируемых (внешних) функций в заголовочнике. В самом файле реализации никаких глобальных переменных или объектов: внутри модуля все функции общаются через глобальные статические объекты. Т.е. я гарантирую, что на уровне линковки не будет конфликта с именами переменных или функций или еще чего-то, за исключением тех, которые предоставляют интерфейс (это само собой разумеется). В ООП-стиле я вижу разворачивание самой логики работы программы: при объявлении объектов нужных классов они "прицепляются" к необходимым драйверам и вперед. При написании кода упор стараюсь делать на золотую середину между читаемостью и производительностью. На самом деле пусть хоть 10 параметров в функции: если при чтении из контекста сразу становится понятно, о чем речь, то не считаю это зазорным. Напротив, подставляя какие-то страшно длинные имена в такую функцию, чтоб "наверняка было всем понятно", строчка вызова превращается в уже сходу врядли перевариваемую мозгом. На ней приходится фиксировать внимание, теряется мысль, рассредоточиваешься и порой идешь по новой. В примере с xTaskCreate(): эта функция вызывается крайне редко, обычно один раз за всю жизнь программы, поэтому мне плевать, что для первоначального написания ее вызова мне, возможно, придется открыть ее декларацию и посмотреть очередность аргументов и их тип. А если функция вызывается очень часто, то, возможно, она будет оформлена в inline-вызов в виде отдельной крохотной функции. Крохотные вызовы, сколько я ни смотрел листинги, всегда встраивались при оптимизации. Мне такое сочетание Си/++ видится наиболее лаконичным.

Да я пока писал, сам уже понял ) Взять и в компасе или солиде прогнать тепловой расчет

Такого не может быть от слова совсем. Разбирайтесь с ПО. Дело только в нём. Вот с прерываниями и нужно разбираться. "Лаба простая" - ни о чём не говорит. Может быть у Вас там в обработчике прерывания задержка стоит, или иные, другие команды, сильно влияющие на ход выполнения программы.

Я не специалист в ПЛИС, но... почему так? Зачем запрещать запись?

Просто оставлю это здесь ) https://git-scm.com/book/ru/v2 Вчера обновил резюме на hh.ru и вдруг обнаружил, что по тегу Git можно пройти тестирование. Так что переходить на Git или нет - пойми, даже вопрос так не стоит )) Это маст хэв скилл

Раз такой открытый обмен мнениями, то позволю себе. Оценка будет жёсткая (любителям svn не понравится), но зато правдивая: если сравнивать git vs svn в контексте именно управления версиями, то git является системой управления версиями как таковой, а svn нет. svn, cvs, Perforce и все подобные системы с центральным репозиторием являются скорее системами инкрементального архивирования с функциями менджмента кода (особенно Perforce). Главное, что отличает git от перечисленных и делает его эффективным имеено как систему управления версиями -- это способность лёгкого, быстрого создания веток и их эффективного слиния хоть методами merge, хоть rebase. Именно такие ветки (которые по сути ветками и не являются -- это традиционное, устоявшееся название, а по сути это просто перемещаемые вместе с "головой" (HEAD) метками) и позволяют бесплатно (ничего не внося в код, не плодя копий) вести отслеживание изменений кода. git позволяет делать реально атомарные комиты -- т.е. когда в комит входят изменения, касающиеся только чего-то одного. Это очень важная штука: такие комиты можно легко таскать между ветками, их можно отменять, не ломая других фич. Вот эта схема с индексом (stage) именно для этого и предназначена (когда в начале не понимал этого, тоже раздражало, что вместо просто commit надо ещё в add в индекс делать, хорошо, что хоть опция -a там была 🙂) : нередко бывает, что изменения кода в одном файле относятся к разным по смыслу фичам/фиксам, и пихать это в один комит неправильно -- потом его ни отменить (нечасто это надо, но бывает), ни перетащить изменения в другую ветку, где они актуальны уже сейчас (а другие изменения и этой ветки, где комит, пока не нужны, они ждут своего слияния в общую ветку). Так вот, git позволяет добавить в индекс выборочно правки из файла, не трогая другие. И так, накидав в индекс, изменения, связанные по смыслу, из разных файлов, можно получить, закомитив, тот самый атомарный комит. Делается это командой git add -i. Существует вполне удобный GUI инструмент для этого -- git-cola, в ней можно прямо выделять в файле нужные строки изменений и добавлять в индекс (или удалять из индекса добавленное по ошибке). Push после каждого комита тоже делать совершенно не нужно. git -- это система с локальным репозиторием, самый главный реп -- это тот, с которым вы работаете, который лежит у вас рабочем проекте. Push -- это просто способ опубликовать ваши изменения (серверов для публикации может быть сильно больше, чем один 🙂 ). Публиковать надо тогда, когда это необходимо, и не ранее. Пока всё лежит локально, можно менять историю изменений, устраняя ошибки при комитах. Это позволяет легко держать историю проекта красивой и удобной для ретроспективы. Это крайне важная штука -- по такой истории можно быстро эффективно найти практически всё (пример такой истории можно посмотреть по ссылке ниже), по ней легко разобраться, когда что происходило и быстро "вспомнить" нюансы ушедшего в прошлое процесса разработки. К сожалению, тот же svn не позволяет ничего из вышеперечисленного. Ветвление в нём -- это боль. Поэтому типовая история проекта в svn (cvs или Perforce) -- это ровная цепочка комитов, глядя на которую, не понятно, где когда что делалось -- нужно ползать по всем звеньям цепочки и искать, вчитвываясь в комментарии. И комиты там редко бывают атомарными, обычно комит в svn -- это целый список несвязанных между собой изменений. Да, конечно, и в svn можно стараться делать короткие атомарные комиты, но это технически непросто делать, когда разные по смыслу изменения присутствуют в одном файле. Есть пара моментов, где системы svn/Perfoce сильнее, чем git: связь с внешними репозиториями; работа с нетекстовыми файлами большого размера. Оба преимущества проистекают из того, что svn/Perforce основаны на нативной файловой системе: единицы слежения за изменениями -- это файлы, ветки -- это директории. Это позволяет легко цеплять сторонние репозитории как директории (хоть целиком, хоть фрагменты) через svn:externals в svn или mapping в Perforce (этот в этом вопросе вообще очень крут). В git же единицей слежения является не файл, а слепок проекта, т.к. совокупность файлов. Директории в нём вообще ничего не значат и учитываются просто в путях файлов, за счёт чего и поддерживается файловая структура с директорими (но закомитить пустую директорию не получится, т.к. для git директория не является ценностной единицей). А submodules в git -- это не самая приятная штука, особенно, когда дело доходит до того, чтобы их удалять/переносить. Уже не впервые высказываюсь на эту тему. Вот тут подробнее про использование: Исходя из вышесказанного, можно сделать определённый вывод: если требуется гибкое и удобное версионирование, то git тут вне конкуренции. Это относится в первую очередь к разработке кода. А вот, например, для схематики/PCB отлично подходит svn, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

Тем же, по тому же месту. Смотрите внимательно на приведённую Вами схему.

Серьёзно? 64 МГц-овый ARM не потянет суммирование 4 каналов АЦП с частотой 1 кГц??? Даже не представляю - насколько кривыми должны быть руки программиста чтобы он "не потянул"... PS: Очевидно тут только то, что вы не потянете диктант по русскому языку.

Эм... А как ещё? Нет, я понимаю, можно ориентируясь на датчики холла, управлять и по табличке, либо синус/трапецию подать, но я бы как раз это и назвал "китайским поделием". Тут и школьник, увлечённый темой, справится. Практически во всех более-менее серьёзных проектах в качестве датчика угла использовали ВТ + шунт на каждой фазе. Шунт можно и не на всех фазах, но и ВТ, и шунт требуют АЦП. Вообще это всё действительно флуд, я бы предложил это всё в отдельную тему вынести. За работу, к сожалению, взяться времени абсолютно нет, но вот этот спор (Управление бесколлекторным двигателем с АЦП и без) я бы с удовольствием почитал. Если он конструктивен будет, конечно.

Маловероятно. Скорее уж пытались сделать proof of concept, а руководство в итоге сказало "а давайте запустим в прошакшен" и понеслось. Судя по качеству документации и общему подходу эта гипотеза очень похожа на правду.

Нет, просто блок для шифрования произвольных данных. защиты прошивки во внешней памяти, к сожалению, нет

Если кнопки рядом, то и предложенные выше "нажиматели" в ряд не разместить..проще на принтере сделать каркас и в него "соленоидов" от автодверей поставить Humanoid robot arm + остальное, чтобы сам ездил/ходил по дому пылесосил, пыль протирал заодно

ещё с прошлого раза заметил что используете режим arm вместо штатного для armv7 thumb - с чем связано ? по-моим наблюдениям это причина тормозов, попробовал на Linux в режиме arm и показания сравнялись с вашими -O3 -marm thumb используется по умолчанию если ничего не указвыать, или явно указать -O3 -mthumb

24 бита? 7.2 разряда? Дома? Налегке? А чем налегке? Как я понимаю, речь идёт у Вас не о промышленном вольтметре, иначе не было бы смысла об этом говорить - там всё сделано профессионалами в области измерений. В нашем случае, следуя из контекста топика, речь идёт о разработке измерителя. И вот я снова повторяю, 24 бита можно измерить дома налегке? Т.е. шум ИОН, его дрейф, наличие паразитных термопар и т.д. и т.п. не вызывает у Вас никаких сложностей? Вы не путаете разрядность АЦП и действительную разрядность измерений с оговоренной линейностью, INL, шумами, дрейфом, краткосрочной и долгосрочной стабильностью таких измерений? Вас не смущает градиент температур в таком измерителе, приводящий к погрешностям, т.к. у Вас есть арсенал для борьбы с ним? Простите, но Вы погорячились, употребив термин "налегке" и "дома" и с разрешением (не точностью) 24 бита. Хотя, козырь у Вас есть - Вы всё же не назвали метрологические характеристики. Тогда "налегке" вполне возможно. Вот только от разрешения 24 бита там будет столько же пользы, сколько от козы, бьющей в барабан копытом)))

я бы пересчитал контур L102 C103 на частоту преобразователя

Аналогичная задача, только с гораздо меньшими мощностями, решалась лет 35 назад в видеомагнитофонах - там блок вращающихся головок (БВГ) имел кольцевые трансформаторы внутри БВГ для питания усилителей видеоголовок и обратной передачи сигналов.

Наверное так: https://www.google.com/search?q=remote+fingerbot+site%3Awww.aliexpress.com

Дизассемблировал прошивку от usb2any, если кому интересно. После компиляции код полностью совпадает с оригинальным. Но у меня остались вопросы. usb2any_reas.zip

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

Сегодня программная ловушка сработала, завтра - нет. А Hard Fault Вы так и не научились отлаживать. А зря.

Они есть и быстрые. Да только не в коня корм. Возни будет куда больше, чем с другими методами.

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

Коллега перевел на английский: UG050004_Titan2 Series FPGA Clock Resource (Clock) User Guide 1.0 Выложил в upload. Просьба перенести в pub.

Перенёс в /pub и добавил туда лекарство (/pub/FPGA/_PangoMicro_/Software/PDS_2022.2_sp3/license)

Интересные варианты мощных понижающих преобразователей со встроенной индуктивностью. Используются на отладках Alinx EZ8303_innek.pdf EZ8620_innek.pdf EZ8626_innek.pdf

Перевод или оригинал? Оригиналы во вложении. Часть первая: Compa_Pgc1_Pgc2_Packages_and_Pinouts.zip Часть вторая: Compa_Pgc4_Pgc7_Packages_and_Pinouts.zip

Продолжаем разматывать использование входных ресурсов для приёма быстрых последовательных потоков данных. Новости на сегодняшний день следующие. 1. IEM, созданный по заверениям производителей для работы в связке с IODELAY, оказался подключенным не к выходу последнего, а непосредственно ко входному паду. Уж не знаю, это программный баг Gowin FPGA Designer 1.9.8.08, или аппаратная фича кристалла, но в любом случае IEM становится бесполезен. Придётся от него отказаться совсем. 2. На IODELAY отсутствует сброс, что немного усложняет жизнь при перетренировке линии. Начинать придётся не с начала, а с ранее накрученной задержки. 3. Косвенно измерил задержку на один тап IODELAY. Измерения, конечно, никакой метрологической критики не выдерживают, но хоть что-то о количестве настройщиков пианино в Нью-Йорке Чикаго теперь известно. Мерял глаз для 675 Мбит/с Измерение 1 Длина от первого кроссовера до последнего - 64 тапа Измерение 2 с дополнительной ёмкостью на линии в виде пальца. Получилось, опять же, 64 тапа. При длительности битового интервала 1/675 = 1481 пс получаем, что один тап примерно равен 23 пс. Что ближе к модели (25 пс), чем к даташиту (18 пс). Хотя и не соответствует точно ни тому, ни другому.

Документация на синтезатор ADS ADS_Synthesis_User_Guide_innek.pdf

Архив с демо версией софта - https://disk.yandex.ru/d/XNkp7oSjh9lfyw Документация на софт - https://disk.yandex.ru/i/uiz4LsTRjwIY7w