вы обратили внимание, что схема в симуляторе не соответствует той, что приведена на скриншоте
Классика. Схему я не пересобирал с нуля, а скопировал из какой-то своей старой симуляции, а потом удивляюсь, почему ничего не работает. Там как раз я решил посмотреть, что будет если сигнала снимать с коллектора. Если откорректировать схему, то коэффициент усиления становится около 10, как и должно быть.
Действительно, не понятно в чём суть претензий. Такую систему обозначений для токов и напряжений используют все симуляторы основанные на SPICE. В MicroCAP, например, тожно так же обозначаются сигналы и ни у кого претензий не возникает. Там по-моему ещё и надписи нельзя было редактировать. Движок моделирования никаких данных о единицах измерений не предоставляет. Если требуется, например, подготовить графики для публикации, то можно легко отредактировать надписи по осям и написать там всё, что угодно. Поддерживаются даже греческие буквы. Соответствующие настройки есть в свойствах диаграммы. В статье я не стал подписывать оси вручную намеренно и оставил дефолт, иначе будет непонятно, какие именно переменные там построены.
Программа использует стандартный синтаксис SPICE. Если v(), то это напряжение, если i(), то это ток. S-параметры исключение, но там из названия понятно, что это такое. По оси Х тоже всё понятно (frequency или time).
2.5e7 на оси частот удобства считывания тоже не добавляет.
Можно сделать отображение 25M, в статье указано как.
углубить публикации до различных линий передачи, согласования их с антеннами, фильтрами, усилителями.
Если в Qucs-S мы всё-таки добавим модели МПЛ и прочих длинных линий, то сделаю статью. Про старый Qucs, который базируется на Qt4, я писать не вижу смысла.
Да, технически это сделать возможно и не очень сложно. Но трудоёмкость примерно равна написанию генератора нетлиста для SPICE. К тому же сейчас более приоритетна задача с реализацией моделей МПЛ в Ngspice, чтобы моделирование S-параметров работало полноценно. И ещё в планах восстановление поддержки цифровых компонентов.
Некоторые попытки уйти от компонентов захардкоженных на С++ предпринимаются. Пока их было 10 это было не критично, а когда стало 100, то стало представлять проблему. Но это не только в open-source, мало где задумываются об архитектуре на начальных стадиях разработки. С другой стороны пользователю всё равно что там у программы внутри: компоненты захардкожены на C++ или сделаны на XML и какой там фреймворк. Главное чтобы симуляция работала. Старый Qucs на Qt4 (который EOL в 2015 году) до сих пор имеет по 1000 скачиваний в неделю на SF.
Технически сделать экспорт схемы в KiCAD возможно, но требует времени. Пока есть более важные задачи, напрямую связанные с моделированием. Ещё планируется в каком-то виде реализовать импорт библиотек LTSpice, так как сейчас библиотеки это узкое место.
Ещё существует вот такая утилита https://github.com/Valber/qucs2kicad , но она обновлялась последний раз в 2011 году. За это время кикадовцы сменили формат файла схемы.
У меня схемы начинающего: усилители, генераторы, смесители, демодуляторы.
Понятно. Я например вот такой аппарат https://github.com/ra3xdh/TRX_RA3XDH_v2/blob/master/TRX_RA3XDH_v2.png моделировал по частям, так как там имеется много повторяющихся блоков и запихивать схему в симулятор целиком нет смысла. И обычно что-то всё равно приходится перерисовывать с даташитов и т.п.
Насчёт примитивности не понял: там ровно тот же ngspice используется
Я имел в виду, что интерфейс примитивный, многих типов диаграмм пока нет и т.п. Моделирование в KiCAD как будто сделано для галочки, чтобы было. Может быть потом они его доработают, тем более что разработчик этой подсистемы работает в CERN.
Сменить лицензию софт под GPL (чтобы закрыть исходники) может только с согласия всех его контрибуторов, которые когда-либо присылали патчи. Даже если поставить цель сменить лицензию, собрать со всех согласие невозможно, так что Qucs останется под GPL вечно.
Qucs-S имеет открытый исходный код и запускается нативно под Linux. Как показала практика, проприетарщики могут изменить условия использования своего ПО и, например, сделать его по подписке как Eagle. Поэтому открытые САПР важны. Основная аудитория Qucs -- это радиолюбители, также имеются академические пользователи, которые используют Qucs для отладки Verilog-A моделей. Пока ещё не все SPICE-модели распространяются зашифрованными. Также Qucs-S предоставляет GUI для движка моделирования XYCE, используемого в академических кругах. Google выпускает открытый SkywaterPDK для микроэлектроники. Для разработки топологии ИМС предлагается использовать KLayout, а для моделирования рисовать схему в xcircuit и запускать Ngspice в консоли. Вместо этого для симуляции вполне можно использовать Qucs-S+Ngspice.
В KiCAD, насколько знаю, моделирование до последнего момента было экспериментальной функцией и не включено в дефолтной сборке. Реализовано оно довольно примитивно.
Четыре раза подряд я перерисовывал готовые схемы из QUCS в KiCAD
В моём случае совершенно не вижу проблем. Всегда моделировал только отдельные маленькие куски от большой схемы. MicroCAP и LTSpice тоже не имеют редактора ПП и нормально существуют. Всё же симулятор должен быть отдельно. На полной схеме часто имеется множество компонентов, которые не подлежат симуляции. Если не секрет, то какое именно у вас было устройство, что его можно было промоделировать 1:1 как на схеме в Кикаде?
Если бы функционал QUCS каким-то образом перенесли в KiCAD я был бы счастлив
Это сделать невозможно. Код KiCAD и Qucs слишком сильно отличается и объединить их нельзя.
Отделить редактор схемы от всего остального проблематично. К тому же там УГО компонентов захардкожено на C++, что не очень хорошо. Существует ещё симулятор Caneda https://github.com/Caneda/Caneda (похоже теперь скорее мёртвый), может быть оттуда отделить редактор схемы будет проще. Там к тому же компоненты представляются в виде XML.
Да, про Proteus знаю, пользовался им когда студентом был и потом работал на заводе схемотехником. Сейчас для моделирования схем на МК существует открытый SimulIDE https://www.simulide.com/
Да, из-за сходимости и кривых встроенных моделей перешел на Micro-Cap
С переходом на Ngspice в качестве движка теперь проблемы со сходимостью решились. Qucsator я поддерживаю в основном для обратной совместимости со старыми версиями Qucs и некоторых специфичных задач, как моделирование микрополосковых линий, которых в Ngspice нет.
Надеюсь, когда-нибудь вы запилите загрузку моделей из гуя
Симуляцию поправил. Теперь всё более-менее соответствует теории из книги Рэда.
Классика. Схему я не пересобирал с нуля, а скопировал из какой-то своей старой симуляции, а потом удивляюсь, почему ничего не работает. Там как раз я решил посмотреть, что будет если сигнала снимать с коллектора. Если откорректировать схему, то коэффициент усиления становится около 10, как и должно быть.
Действительно, не понятно в чём суть претензий. Такую систему обозначений для токов и напряжений используют все симуляторы основанные на SPICE. В MicroCAP, например, тожно так же обозначаются сигналы и ни у кого претензий не возникает. Там по-моему ещё и надписи нельзя было редактировать. Движок моделирования никаких данных о единицах измерений не предоставляет. Если требуется, например, подготовить графики для публикации, то можно легко отредактировать надписи по осям и написать там всё, что угодно. Поддерживаются даже греческие буквы. Соответствующие настройки есть в свойствах диаграммы. В статье я не стал подписывать оси вручную намеренно и оставил дефолт, иначе будет непонятно, какие именно переменные там построены.
Программа использует стандартный синтаксис SPICE. Если v(), то это напряжение, если i(), то это ток. S-параметры исключение, но там из названия понятно, что это такое. По оси Х тоже всё понятно (frequency или time).
Можно сделать отображение 25M, в статье указано как.
Если в Qucs-S мы всё-таки добавим модели МПЛ и прочих длинных линий, то сделаю статью. Про старый Qucs, который базируется на Qt4, я писать не вижу смысла.
Формулу поправил.
Интересный обзор. Узнал про RXCalc из этой статьи.
Да, технически это сделать возможно и не очень сложно. Но трудоёмкость примерно равна написанию генератора нетлиста для SPICE. К тому же сейчас более приоритетна задача с реализацией моделей МПЛ в Ngspice, чтобы моделирование S-параметров работало полноценно. И ещё в планах восстановление поддержки цифровых компонентов.
Некоторые попытки уйти от компонентов захардкоженных на С++ предпринимаются. Пока их было 10 это было не критично, а когда стало 100, то стало представлять проблему. Но это не только в open-source, мало где задумываются об архитектуре на начальных стадиях разработки. С другой стороны пользователю всё равно что там у программы внутри: компоненты захардкожены на C++ или сделаны на XML и какой там фреймворк. Главное чтобы симуляция работала. Старый Qucs на Qt4 (который EOL в 2015 году) до сих пор имеет по 1000 скачиваний в неделю на SF.
Но лучше всё же не заниматься пиратством, а использовать открытый аналог, тем более Arduino в SimulIDE поддерживается.
Технически сделать экспорт схемы в KiCAD возможно, но требует времени. Пока есть более важные задачи, напрямую связанные с моделированием. Ещё планируется в каком-то виде реализовать импорт библиотек LTSpice, так как сейчас библиотеки это узкое место.
Ещё существует вот такая утилита https://github.com/Valber/qucs2kicad , но она обновлялась последний раз в 2011 году. За это время кикадовцы сменили формат файла схемы.
Понятно. Я например вот такой аппарат https://github.com/ra3xdh/TRX_RA3XDH_v2/blob/master/TRX_RA3XDH_v2.png моделировал по частям, так как там имеется много повторяющихся блоков и запихивать схему в симулятор целиком нет смысла. И обычно что-то всё равно приходится перерисовывать с даташитов и т.п.
Я имел в виду, что интерфейс примитивный, многих типов диаграмм пока нет и т.п. Моделирование в KiCAD как будто сделано для галочки, чтобы было. Может быть потом они его доработают, тем более что разработчик этой подсистемы работает в CERN.
У нас уже был Multisim, причём лицензионный.
Сменить лицензию софт под GPL (чтобы закрыть исходники) может только с согласия всех его контрибуторов, которые когда-либо присылали патчи. Даже если поставить цель сменить лицензию, собрать со всех согласие невозможно, так что Qucs останется под GPL вечно.
Qucs-S имеет открытый исходный код и запускается нативно под Linux. Как показала практика, проприетарщики могут изменить условия использования своего ПО и, например, сделать его по подписке как Eagle. Поэтому открытые САПР важны. Основная аудитория Qucs -- это радиолюбители, также имеются академические пользователи, которые используют Qucs для отладки Verilog-A моделей. Пока ещё не все SPICE-модели распространяются зашифрованными. Также Qucs-S предоставляет GUI для движка моделирования XYCE, используемого в академических кругах. Google выпускает открытый SkywaterPDK для микроэлектроники. Для разработки топологии ИМС предлагается использовать KLayout, а для моделирования рисовать схему в xcircuit и запускать Ngspice в консоли. Вместо этого для симуляции вполне можно использовать Qucs-S+Ngspice.
В KiCAD, насколько знаю, моделирование до последнего момента было экспериментальной функцией и не включено в дефолтной сборке. Реализовано оно довольно примитивно.
В моём случае совершенно не вижу проблем. Всегда моделировал только отдельные маленькие куски от большой схемы. MicroCAP и LTSpice тоже не имеют редактора ПП и нормально существуют. Всё же симулятор должен быть отдельно. На полной схеме часто имеется множество компонентов, которые не подлежат симуляции. Если не секрет, то какое именно у вас было устройство, что его можно было промоделировать 1:1 как на схеме в Кикаде?
Это сделать невозможно. Код KiCAD и Qucs слишком сильно отличается и объединить их нельзя.
Отделить редактор схемы от всего остального проблематично. К тому же там УГО компонентов захардкожено на C++, что не очень хорошо. Существует ещё симулятор Caneda https://github.com/Caneda/Caneda (похоже теперь скорее мёртвый), может быть оттуда отделить редактор схемы будет проще. Там к тому же компоненты представляются в виде XML.
Да, подсхемы есть. С помощью них можно решить подобную задачу.
Да, про Proteus знаю, пользовался им когда студентом был и потом работал на заводе схемотехником. Сейчас для моделирования схем на МК существует открытый SimulIDE https://www.simulide.com/
С переходом на Ngspice в качестве движка теперь проблемы со сходимостью решились. Qucsator я поддерживаю в основном для обратной совместимости со старыми версиями Qucs и некоторых специфичных задач, как моделирование микрополосковых линий, которых в Ngspice нет.
Автоматическая загрузка SPICE-моделей уже есть https://qucs-s-help.readthedocs.io/en/latest/SubLib.html#usage-of-the-whole-spice-library Можно положить библиотеку в $HOME/.qucs/user_lib и оно будет видно в менеджере библиотек, но с УГО квадратиком. Если модель, совместима с Ngspice, то всё будет работать.