Самодельный передатчик (часть 1)
Что скажет купечество ?
лично мое мнение не претендующее на истину:
писать свой кодер начал после того как общарил “нет” и понял что то не найду то чего хотелось бы,
далее перечитал всё что смог найти по теме, сформулировал для себя ТЗ и начал работать…
подобным образом здесь по моему все поступают…
отсюда вывод что существование подобной темы с несколькими вариантами устройсв вполне обосновано и достаточно полезно!
это лирика, а теперь основная часть:
согласен по поводу API но не думаю что все сломя голову “метнутся” его придумывать и реализовывать,
потому что в реализации своих проектов все наверное преследуют какието свои цели и задачи.
есть маленькое предложение… Можно сделать так, чтобы микшеры, всякие другие функции подходили друг к другу. Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
😃
НАДО!!!
давай догавариваться! 😃
как основоположник предлагай свой вариант, обсудим(у меня в этом месть на данный момент ваобщё пусто 😊, имею введу микшеры )
а ты говоришь “не метнутся”…
вот и замечательно! :)Тогда я составлю основной план. Выложу его. А потом вместе подкорректируем и переработаем.
первое, что предлагаю сделать - это надо пеоделить всю прогу на части, как собственно все и делают. Это блоки “Меню”, Генератора выходного сигнала, работы с АЦП, Математики(которая в свою очередь включает микшелы, экспоненты, кривые и т.д.). Также надо выделить отдельно подпрограмму работы с индивидуальными настройками модели.
Второе, что касается именно самой программы. Нужно стандартизировать основные процедуры и функции, имена и назначения переменных. Например те же самые графические процедуры хотя и имеют схожие имена, но все равно различны…
пока выкладываю свой изначальный вариант заготовки. Там почти ничего нету. только графический модуть. Файлы с перемеными и обозначениями… В архиве проект для кодевижна.
это было даже легче чем я думал 😃
😜
нехватает только второго джойстика и задней крышки 😎
Спасибо!
у меня кстати завтра тоже гемор-правда зачет ))
кстати есть у меня такая идея, не знаю правда насколько полезная фича получится, но все же…
есть у нас например 4 пропорциональных канала, то есть четыре выхода у приемника. Обозначим их как out0, out1, out2, out3. А положение ручек в формате in0, in1, in2, in3. Может микширование реализовать вот ТАКИМ образом:
______in0_____in1______in2______in3
out0__100_____0_______0________0
out1___0_____100______0________0
out2___0______0_______100______0
out3___0______0_______0_______100
это для случая когда по сути никакого микширования не происходит
______in0_____in1______in2______in3
out0__100_____0_______0________0
out1__20______80______0________0
out2___0______0_______100______0
out3___0______0_______0_______100
а это например когда ручка in0 влияет и на out0 и на out1
состояние канала определяется как “вклад” каждой ручки в процентах
Плата у тебя классная! заказывал где-то? а я решил пока из меги16 все выжать, а потом на 128 собрать новый передатчик (постепенно накапливаю опыт и новые идеи)
Плату я у знакомого заказывал…
А на счет микшера интереная идея… Надо подумать будет… Большая просьба к Vad64 рассказать немного о построении микшера… че-то я совсем не догоняю…я имею в виду
универсальный…
Плату я у знакомого заказывал…
А на счет микшера интереная идея… Надо подумать будет… Большая просьба к Vad64 рассказать немного о построении микшера… че-то я совсем не догоняю…я имею в виду
универсальный…
так по моему lamobot и описал упрощённый универсальный микшер?!
первое, что предлагаю сделать - это надо пеоделить всю прогу на части, как собственно все и делают.
Мысля мудрая, предлагаю такой вариант:
Интерфейс
- I/O интерфейса (кнопки, триммеры, крутилки)
- дисплей (драйвер с граф.примитивами)
- диалог (меню и страницы)
- шрифты (шрифты. ну можно объединить с “дисплеем”, если используется единственный матричный шрифт)
Модулятор - I/O модулятора (оси)
- формирователь/миксер (миксер = текущий из набора переключаемых)
- формирователь/протокол (протокол = текущий из набора переключаемых)
Общая часть - ресурсы (строки, картинки, данные)
- настройки (загрузка/сохранение глобальных настроек)
- модель (загрузка/сохранение изменяемых от модели к модели настроек)
представил бы всё это ввиде исходников, но словами понятнее.
представил бы всё это ввиде исходников, но словами понятнее.
а исходниками нагляднее 😊
вот что я имею на сегодняшний день
Большая просьба к Vad64 рассказать немного о построении микшера
Привет!
Собственно говоря, у меня микшеров-то и нет. Мне для моих моделей они были ни к чему и я не стал их реализовывать (и в то время не очень представлял, как это лучше сделать). Т.е. у меня в каждом канале (Элерон, Элеватор и т.д.) хардкодом задана единственная ручка управления. Также у канала есть признак реверса, расходы и задается кривая, по к-рой значение ручки переводится в выходное значение. Модель я здесь выкладывал и симулятор тоже. Оттуда должно быть понятно, что входит в модель и видно, как настройки влияют на выход.
В настоящее время я вижу ограниченность такого решения и вот что думаю: надо попробовать отказаться от предопределенных каналов. Т.е. в настройках канала задавать две или даже больше ручки управления с собственными кривыми. (И даже имя канала задавать в настройках). По-моему, этого должно быть достаточно для решения всех проблем. Главное - уметь строить канал из нужных ручек с собственными кривыми.
Такой подход утяжеляет работу с пультом. Но на все на это можно наложить визарды, к-рые будут создавать готовые заготовки для разных типов каналов - флапперонов там всяких, ССРМ и т.д.
а исходниками нагляднее 😊
исходники могу в личку (попусту сорить ими не хочется), но общие прЫнципы лучше все-таки обсуждать словами.
А я вот еще 4 тумблера воткнул в корпус… расходы отдельные на руддер элеватор и элероны… и еще на 3 оложения для переключения режима полета…
А я вот еще 4 тумблера воткнул в корпус… расходы отдельные на руддер элеватор и элероны… и еще на 3 оложения для переключения режима полета…
Кстати а никто не хочет попробовать датчики холла на джойстики?
будет вечная механика. Ccылок полно - любители ла-2 давно уже переделывают себе на такую.
Ccылок полно.
Ссылки в студию 😈
он “ил-2” имел ввиду, в гугле “ил-2 датчик холла” и первая ссылка 😉
не, я пока пробовать не буду датчики холла… Кстати есть мысль по поводу смесителя… Пусть in[0]-in[4] - сигнал с джостикой и еще чего-нить. он уже прошел через реверсы, экспоненты и расходы…
ch[x] - канал, который уже идет на выход…
Вот собственно как я думаю сдлать его:
ch[x]=in[0]*k0+in[1]*k1+…+in[4]*k4;
т.е. мы формируем канал из нескольких… “k” - коффициент влияния сигнала на канал… если к=0, то нет его вообще.
Затем надо сделать ограничение канала
out[x]=ch[x]*out_rates;
а в менюхе сдеать так:
mapping->
…ch1
…ch2->
…eleron 0%
…elevator 70%
…flaps 130%
…-------------------
…EPA 100% {ограничение хода}
…ch3
…ch4
…
и, как посоветовал Vad64, надо сделать визарды… Отдельные для разных типов моделей…