Предложения по функциональности программы для SDR

[RA9YTJ]

Полностью согласен с RZ6FY, действительно не надо изначально ставить задачу создание конкурента SDR-1000, тот кто хочет все приемущества данного трансивера, купит или сделает его. Нужен ПРОСТОЙ и ДЕШЕВЫЙ TRX SDR, если у меня валяется lm7001 и груда 74ac микросхем, зачем мне искать и тратится на DDS? Всетаки тема SDR реально не завоевала авторитет среди большенства радиолюбителей, по простой причине, они их видели только на картинке, а покупать сие устройство за килобаксы не каждый рискнет. Я вот в своем радиоклубе проводил "призентацию" SDR, результат почти 0, все уперается в недоверие такой технике, нет аппарата в натуре, я вот не вс состоянии купить SDR1000, и даже неготов купить звуковуху для нее, и таких большенство.
Сейчас складывается ситуация:
SDR ново перспективно, но пока для большинства НЕИЗВЕСНО и НЕДОСТУПНО! Сдесь на форумах обсуждается в большенстве 3 темы: как пользоватся SDR1000, как его сделать самому, и как сделать попроще и прикрутить к PowerSDR.
Вывод, продвижение SDR в массы невозможно без создания простой, быстрой!(не у всех радиолюбителей есть крутые компы), и самое главное легко настраиваемой под железо программы SDR. Пусть она будет гораздо проще чем американская.
В конечном итоге большинство радиолюбителей имеют трансиверы типов UW3DI, UA1FA, Дружба Росса, а то и Аматор, и им ненужны супер параметры.

[Relayer]

не хотел, но чувствую прийдется не хотел т.к. сейчас совершенно нет времени заниматься этим с полной отдачей. а прийдется т.к. как ни крути а 20 лет программирования всего чего угодно за плечами имеется
теперь касательно концепций.
1) мультиплатформенност ь фтопку. я серьезно.
2) писать на дельфе. спрячте ваши тапки - я могу аргументировать цэ/цэ++ не подходит в силу своей сложности для непрофессионального программиста. васики ... умерли они - под дотнетом все. дельфа позволит во первых не парится с гуем, во вторых встроенный ассемблер позволит там где надо оптимизировать код. так что с производительностью будет все ок. с другой стороны дельфи-паскаль достаточно прост для чтения и понимания логики работы программы
3) система должна обязательно иметь плагинную архитектуру. плагины отвечают за сопряжение с железом (управление синтезатором к примеру) и дополнительные ЦОС-примочки. с проработки спецификаций такой архитектуры и надо начинать. в идеале сама прога (т.е. ядро) реализует минимум функций которые нужны всегда. все остальное - плагинами. и еще чем удобен такой подход - хочется написать какой-то супер-дрюпер фильтр или прицепить самопальный синтезатор - берем API для плагина и пишем небольшой модуль. причем писать его можно на чем угодно - хоть на цэ хоть на ассемблере. также не забываем что плагин может быть как с внешними (интерфейсными) элементами управления/визаулизации так и не иметь их.
4) open source. все должно быть доступно в исходниках.

вот такой вот набор кратких соображений. работа эта серьезная - надо будет сразу же обзаводится где-то хостингом (на том же соурсфорже к примеру). очень желательно пользовать вики-систему для параллельного документирования. и свой форум для дискуссий
а начинать надо с выработки архитектуры системы, определения функциональной нагрузки ядра/плагинов, их взаимодействия и спецификаций API плагинов.

[UR5ZQV]

To RA9YTJ:
Сергей, вот последняя версия(приложение и SHA). Может быть важно - версия HiAsm b162, компилятор Delphi4. При использовании b154 (старые версии проги) приложение дико жрало ресурс и на моем стареньком компе подкачки хватало на час работы. После перехода на b162 спокойно пашет круглосуточно. Хиасмовские гуру сказали что в той версии могли быть баги.
Теперь по миксеру, у меня забито по умолчанию открытие нулевого устройства, как правило это встроенная звуковуха, но на иных компах может быть по другому. То же самое с самой картой, открывается карта по умолчанию. Наверное для гибкости установки устройств надо добавить в сеттинги меню.
Теперь по отрывку кода, в строчке:

mixerSetControlDetails(MixerID,@MCD,MIXER_SETCONTROLDETAILSF_VALUE);*)

откуда то в конце взялось "*)" , у меня этого не было.
А вообще, если ошибки компиляции можно выловить по подсказкам отладчика, то ошибки исполнения типа "Runtime error..", "Access violation..." удавалось отловить только методом тыка, вот почему системщик крайне желателен.

[RA9YTJ]

Дык я таким образом и вылавил ошибку, всегда система сообщает где она запнулась, в данном случаи сработала защита памяти, попытка чтения с 00000+4 адреса, что нещадно было присечено системой, ну а дальше IDA и анализ, птом поис в исходнике похожую часть, а символы *) - это я забыл убрать, коммент. блоки я и выловил конкретные строки.
Приду домой испытаю новую прогу, откампилелась у меня без проблем.
To Relayer
Согласен с Вами, Кроме того что умерли basic, нет есть очень крутые версии, я вот для программирования прог использую PureBasic, у него много приемуществ, и нету недостатков отмеченных Вами. Ну раз Delphi так Delphi, кстати на какой версии остановимся? предлагаю на 7, т.к. довольно надежна, и не так объемен конечный ехе.

[Relayer]

2 RA9YTJ
смотрел я эти клоны - PureBasic, IBasic, PowerBasic, RealBasic. последний не подходит т.к. компилирует в пи-код. остальные генерируют такой машинный код что порой плакать хочется. нет, конечно на свеженьком пятитысячном двухядернике оно и в реалтайме сможет работать, но зачем? VB6 тоже не ахти какой код генерирует. вдобавок он уже списан и официально не поддерживается. а вместо VB7 идет VB.NET. а вот дотнет как раз и не хочется - слишком уж он от железа оторван далеко.
теперь по поводу дельфей. как ни странно но основная рабочая лошадка у меня 5ка последний годик медленно портируюсь на BDS2006. основные плюсы - более удобный IDE. попробуешь - назад не захочется возвращаться. опять же встроенные средства рефакторинга облегчают работу с большими проектами. а в остальном - та же дельфа.

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

[DRUID 3]

Короче, как всегда "каждый о своем".

Вобщем я не согласен ни с одним приведенным аргументом.

Во-первых о простоте:
Ну каждый мыслит в силу своей нынешней меры понимания. Вы (участники проекта) сами увидите, что не заложив "перспективность " в свой проект вы сразу же и убьете его. Через пол года вы перерастете свои нынешние представления, и проект тихонечко умрет.

И еще, из практики - время разработки радара неразрушающего контроля и импульсного блока питания к нему занял одинаковое время , люди - загадка...

Кстати, чем вам не нравиЦЦо проект который собрал ХАМский designer ??? По-моему все у него отлично, и под простые синтезаторы заточен. Человек старался, выложил исходники...

Во-вторых... кстати, об исходниках.

Под GNU я имел в виду открытые исходники, если без этого - то досвидания. В коммерческих проектах я участвую посерьезней и мне это совершенно неинтересно. "Опенсорц" проекты позволяют "сдружиться" разноплановым программистам. Ну например кто-то долго занимается алгоритмами ЦОС а кто-то написанием GUI. Длительная плодотворная работа позволяет проникнуться идеями друг друга, и быстро овладеть мастерством коллеги. Просто просмотр чужих исходников совершенно никакого результата не принесет.

В-третьих:

Я очень хочу посмотреть на открытые исходники алгоритмов ЦОС, которые "как известно известны всем" . Вы часом их не из SDR-1000 собрались вытаскивать??? Да и что собственно можно найти в инете кроме FFT (и то восновном на С++) и FIR-фильтра. Но вперед...

В-четвертых:

И главных ( :wink: ) свой проект я забрасывать не намерен (ну разве чо умру наглой смертью ) и думаю начать его в конце сентября, так что те кому будет мало "Дэлфей" и "известных всем алгоритмов" могут писать мне в ICQ...

В-пятых:

Вы (участники) путаете желание знания и созидательного творчества с потребностями человечества. Проект как его вижу я может пригодиЦЦо людям далеким от HAMрадио (создающим музыкальные инструменты, измерительные приборы и т.д.) в свою очередь такие люди могут принести в него нечто свое, не связанное с парадигмой мышления зачинателей проекта... Но это аргумент для тех, конечно, кому важен проект вообще а не выпендреж на форуме...

В-шестых:

Какое-то странное нежелание учить новое. Ну типо тот же С++. Я его сам плохо знаю, уверенно себя могу назвать С программистом, а С++ у меня всегда в стадии изучения... у Страуструпа наверное та же картина . Да и Qt я пока не знаю совсем, почему бы и не выучить, не правда ли? Та же картина и с платформами. Я вот уже вполне счастливо себя чувствую на Linuxе и дома и на работе, хотя и без "Вынь" пока не могу. А многие мои друзья стали "чувствовать себя хорошо" насильно поскольку их компании стали делать продукцию на экспорт, и "восточноевропей ский подход" там не прокатил...

В-седьмых:

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

[Relayer]

2 DRUID 3
вы наверное невнимательно читали предыдущие посты в теме. ну такое иногда случается во первых там определено что проект будет опенсорсный, во вторых грамотно продуманная плагинная архитектура за которую я ратую и есть краеугольный камень большой и расширяемой системы. причем для ее расширения не надо ковыряться и изучать пару сотен тыщ строк кода а достаточно написать модуль удовлетворяющий спецификация изложенными на одной странице А4.

теперь по поводу цэ и плюсов. на цэ я работал еще в 80х а с плюсами с начала 90х. страуструпа не читал при этом - вредная книга разрабатывать большую систему когда все участники находятся "в стадии изучения" - это знаете ли весьма непрофессионально. таким макаром эта система и за 5 лет не дойдет до альфа версий. второй аргумент против цэ - это потенциальные возможности заложенные в язык которые приводят к написанию кода с глюками. да-да. именно так. особенно непрофессионалами. и ловить баги связанные с выходом за границы массива или обращению к освобожденной памяти - занятие не из приятных. особенно когда это не программа типа "hello word".

так что давайте не будем читать страуструпа и изучать Qt - этим можно заняться на досуге

[syomin]

Для того чтобы привлечь внимание людей к теме SDR нужна конструкция, сопоставимая по сложности с шедеврами Полякова - чтобы и собрать было не сложно даже новичку, и в случае чего, потраченного времени было не жалко. Только в этом случае стоит ожидать массового всплеска интереса к SDR. Но как всегда те, кому подобная конструкция нужна, не способны ее разработать, а тем, кому эта задача по силам - она не интересна.

А какую программу использовать - это уже не столь важно.

P.S. Не нужно ссылаться на схемы YU1LM - это несколько не то - и деталей много, а самое главное еще и гетеродин нужен. Прелесть конструкций Полякова как раз и состояла в том, что приемник можно было собрать практически из ничего.

[UR5ZQV]

To Relayer
1.Мультиплатформенно сть. Тут как лентяй с удовольствием с Вами соглашусь . Мне бы хоть под винду более менее надежное приложение сварганить.
2.Насчет языка, так думаю по барабану. Все равно сколько людей столько и мнений. Главное алгоритмами обмениваться, а работа с железом все равно в основном APIшная и системно библиотечная.
По мне так лучше вообще без единой строчки (благо я визуализированную оболочку использую с набором стандартных компонент) да на все случаи жизни нет компонентов, пришлось часть из них на Делфи доделывать.
3.У меня к счастью роль плагинов выполняют сами компоненты, короткие функциональные компоненты пишуться непосредственно на Делфи, а логические связи разводятся визуально как схема, что кстати очень наглядно и по моему более понятно, чем искать эти связи в дебрях кода.
4.Коды любого компонента (по крайней мере в моей схеме ХиАсм) открыты, каждый может править.

[Relayer]

для особо ленивых на дельфи есть тоже кое-чего
DSP-worxs
SignalLab
AudioLab