OSD на ATmega1281
У Вас бюджет не ограничен…
???
search.digikey.com/scripts/DkSearch/dksus.dll?Deta…
от 100 по 8 баксов, это 12 головок всего. В минус ОУ, кучка пассива, кое что из которого должно иметь хотя бы 1% допуск, плата уже односторонняя. Примерно тож на тож.
Посмотрите на второй автопилот от FMA - они тоже цифру поставили и судя по всему эти search.digikey.com/scripts/DkSearch/dksus.dll?Cat=…
поэтому была робкая надежда конденсатором прямо на ножке операционника ее прибить
А шунтирование сенсоров кондёром помогло?
Я бы поставил 0,1 и что-то около 470пФ в параллель.
Перепаять цепочку на ОУ не пробовали? Хотя бы ради эксперимента.
Я и надеялся, что наводки идут на термодатчики,
ИМХО проблема не в наводке, и 1 ГГц прекрасно душится ёмкостью входа ОУ, а проблема в свободной энергии. Той, которой раньше питались детекторные приёмники с детекторами из угля 😃 Она создаёт потенциал на входе. Т.к. природа у неё переменная, то задушить можно капацитором. Только ёмкость надо подобрать, в GPS приёмниках обычно ставят параллельно 33 пФ и 470 пФ, там 1,5 ГГц. Вместе с ёмкостью входа режет наводку на раз.
Колечки не помогают, вообще мне показалось, что на гГц ферриты не эффективны.
Надо просто брать фербиды, настроеные на опр. частоту среза, а не простые колечки. Тем более, что советские достаточно низкочастотны, а китайские ориентированы на домегагерцовые частоты импульсников.
Например, для того же ЖПС есть BLM15HD102SN1, наверняка есть и на другие частоты. Надо порыть у мураты и ей подобных производителей.
Вдруг обнаружил, что при включении передатчика начинают подзуживать все сервы.
А вот тут достатиочно зарубить добротность антенны (провода) включив последовательно с сигналом резистор. Я до 47к вставлял, серва сигнал принимает. Но достатчно 470-510 ом. Разумеется лучше у самой сервы.
Более радикальный метод - 510 впослед и 100к к земле. У самой сервы. Чтобы рассосать потенциал более чем достаточно.
Наконец, если серва управляется АВРкой, можно прям на плате телемерии поставить резюк 510ом (или больше, определить экспериментально пороговое значение) к земле . Чтобы снизить выходное сопротивление.
Но даже тут причина не в частоте передатчика, а в его мощьности. Свободная энергия поднимает порог КМОП входа сервы.
В общем, победимо, надо просто попробовать разные варианты.
Не стал взрывать себе моск в попытках связать термодинамику (свободная энергия вроде-бы оттуда?) с электромагнитной наводками… Убедился что уже на расстоянии 30см передатчика от всего остального оборудования все барабашки пропадают и буду в крыло передатчик монтировать. Фильтр-пробку, как и хотел, сделал простой катушкой, работает хорошо.
Не, это то, что остаётся после детектирования радиосигнала. Ток, который возникает в антенне. Чтобы наловить достаточно энергии для запитки наушников антенна должна быть несколько десятков метров в длину, но т.к. у вас передатчик рядом, то длины проводов хватает.
Вот, по теме:
electroscheme.org/498-radiopriemnik-s-pitaniem-ot-…
freeenergyengines.ru/svobodnaya-energiya-v-sovreme…
Вспомнил, что этой ветке последнее видео так невесело закончилось. Можно подумать, что не этом проект и закончился… Ан- нет! Давно уже летаю, правда далеко и высоко пока не рискую… Вот крайний полет:
До этого регулятор автопилота был только с “П”-ветвью. Выводил на базу довольно точно, но как-то раздражало, что все время недоворачивает на цель. Добавил “И”-ветвь и появилась вполне предсказуемая раскачка. Инерция самолета, запаздывание GPS-данных, время интеграции И-ветви… Что-то не соображу как все это увязать, и демпфировать раскачку.
Люди, а кто как борется с дрожанием камеры? Камера у меня поворачивается только по вертикали прямым приводом от сервы. Во первых у сервы небольшой люфт, и от вибрации двигов камеру потряхивает. Во вторых серва сама в некоторых положениях зудит. Причем если механически пытаться демпфировать для уменьшения дрожания от первого пункта, то растет проявление второго…
Или это лечится только какой-нибудь дорогучей цифровой сервой?
msv
Расскажите, плз, как у Вас устроен видеовывод - в частности те самые “золотые” три инструкции 😃 и сопряжение ассемблера с Си
Кста, схему можно немного удешавить/упростить - видеозахват замечательно работает со встроенным в Мегу компаратором.
Код вывода строки сделан “в лоб” и не отличается особым изяществом:
;
;gNumLine++
MOV R26,gNumLineL
MOV R27,gNumLineH
ADIW R26,1
MOV gNumLineL,R26
MOV gNumLineH,R27
;if(gNumLine>=TOPLINE_SCR && gNumLine<TOPLINE_SCR+VSIZE_SCR)
CPI R26,LOW(TOPLINE_SCR)
LDI R16,HIGH(TOPLINE_SCR)
CPC R27,R16
BRLT _end1
CPI R26,LOW(TOPLINE_SCR+VSIZE_SCR)
LDI R16,HIGH(TOPLINE_SCR+VSIZE_SCR)
CPC R27,R16
BRLT _con1
BRNE _end1
LDI R16,1
MOV f_work,R16
_end1:
RJMP _USART_RX
; pause
_con1:
LDI R16,WAIT_START_OUT
_pause:
DEC R16
BRNE _pause
; out string
MOV R27,gScrBuffPointH
MOV R26,gScrBuffPointL
LDI R16,BYTES_FROM_STRING
LD R18,X+
_out_ch:
MOV R17,R18
OUT V_PORT,R17 ;1
NOP
NOP
LSR R17
OUT V_PORT,R17 ;2
NOP
NOP
LSR R17
OUT V_PORT,R17 ;3
NOP
NOP
LSR R17
OUT V_PORT,R17 ;4
NOP
NOP
LSR R17
OUT V_PORT,R17 ;5
NOP
NOP
LSR R17
OUT V_PORT,R17 ;6
LD R18,X+
LSR R17
OUT V_PORT,R17 ;7
LSR R17
DEC R16
NOP
OUT V_PORT,R17 ;8
brne _out_ch
LDI R17,0
NOP
OUT V_PORT,R17 ;8
SBIW R26, 1
MOV gScrBuffPointL,R26
MOV gScrBuffPointH,R27
Пасиб.
Если здесь:
LDI R16,BYTES_FROM_STRING
LD R18,X+
убрать плюс, то в конце можно будет убрать всю инструкцию:
SBIW R26, 1
Мелочь, а приятно )
Пишу в IAR, и всю голову поломал - как красиво передать ассемблерной части адрес на видеобуфер.
Как у вас это получилось - так и не понял. Или gScrBuffPoint задан вручную? (как и размещение видеобуфера в опертивке)
Сорри, ошибся, не все так просто.
…как красиво передать ассемблерной части адрес на видеобуфер
Не уверен, что это красиво, но у меня так:
register unsigned char* gScrBuffPoint @5;
#asm (".def gScrBuffPointL=R5")
#asm (".def gScrBuffPointH=R6")
Инициализация в прерывании от КСИ:
interrupt [INT0] void ext_int0_isr(void)
{ // КСИ
gNumLine=0;
gScrBuffPoint=gScrBuff;
}
Что-то и топикстартер молчит и окружающие не интересуюццо…
Появилась мысля как увеличить точность измерения тока - ставим в меге источником опорного внутренние 2.56 вольта - и при нулевом токе (через датчик) считываем значение порядка 950.
И работаем на отрицательной ветви токового датчика - т.е. при растущем токе значение с АЦП будет падать до нуля.
Даст повышение точности в два раза.
/*
еще немного мыслей просто из записной книжки:
Ток и напряжение лучше мерить тинькой в режиме ADC noise reduction, с полной обвязкой АЦП и как можно ближе к датчику - результат будет чище и лучше.
Работаем на пониженной частоте АЦП.
Имеет смысл вставить RC фильтр от помех между датчиком и мегой
Датчик чувствителен в магнитному полю - ставим рядом катушку, включаем, измеряем ток, отключаем, измеряем ток, усредняем два измерения - это неопробовано, неизвестно что из этого получится, неоправданно…
*/
Да, народ не слишком активен… Может по результатам сезона выложу hex (от НАСA похоже не дождусь предложения на приобретение проекта 😃). Может активность увеличится… Хотя финальной печатки нет (то что у меня, уже можно считать макеткой+кучка платок апгрейда, слишком много поменялось, от начальной идеи), поэтому на повальный интерес по повторению не рассчитываю…
Сейчас играюсь с управляющими алгоритмами автопилота. Правда пока чем мудренее алгоритм, тем обычно хуже все в реале, хотя в модели на ПК, все отрабатывается идеально. Видать слишком “хороша” модель, но сделать ее более правдоподобной, задачка посложнее чем саму управляющую программу… 😃
Добавил режим, похожий на настоящий АП- если в режиме стабилизации щелкнуть доп. тумблер- АП начинает удерживать текущий курс и высоту (такого вроде бы нет у “конкурентов”). При выключении этого режима, устанавливаются нули сенсоров горизонта (для этого, автокалибровки, чес. говоря этот режим и задумывался).
Еще не испытал…
внутренние 2.56 вольта - и при нулевом токе (через датчик) считываем значение порядка 950.
И работаем на отрицательной ветви токового датчика
Именно так у меня и сделано. Правда не столько ради увеличения разрешения, а больше ради упрощения схемы (не нужен свой источник напряжения, и даже ставить делитель напряженияне надо).
Имеет смысл вставить RC фильтр от помех между датчиком и мегой
Практика показала, что это обязательно. Датчик слишком быстродействующий и выдает все пульсации на силовом проводе.
Остальное, по вкусу… 😃 Надо считать какую точность хотите получить, достаточно ли мала погрешность самого датчика, дабы ее обеспечить, ну и нужна ли она…
Да, народ не слишком активен…
Лето, жара, отпуска, ДАЧА!!😛
поэтому на повальный интерес по повторению не рассчитываю…
…
IMHO, большинству из тех, кто следит за этой темой интереснее направление по развитию, чем простой повтор конструкции. Поэтому куски исходников( раз уж нет желания выложить полный проект), наверное, будут более интересны, чем HEX…
как красиво передать ассемблерной части адрес на видеобуфер.
Обычно так и делают - вешают буфер по известному адресу (только не в самом начале:
signed char array [BUFFER] @0xC0;
И обращаются хоть из Си по указателю, хоть из асма. Если буфер небольшой, можно упихать в регистры как у автора. Будет ещё быстрее. Но тут надо в ассме посмотреть, сколько регистров компилер сохраняет. ИАР вообще ассм недолюбливает, и склонность к гонянию регистров из ОЗУ и обратно имеет. То есть разместив буфер в регистрах можно всё равно получить лишнее сохранение/вызов.
У меня были ошибки в получении адреса, поэтому спрашивал
Сейчас без указания конкретного адреса все работает прекрасно.
Но все равно спасибо.
Если буфер небольшой, можно упихать в регистры как у автора.
Какая разница какой размер буфера? У меня в регистрах указатель на него, хоть все ОЗУ адресуй.
Сейчас без указания конкретного адреса все работает прекрасно.
Так поделитесь, как решили задачку?..
Вобсчем вот основа всего OSD. Может кому интересно будет:
narod.ru/disk/24027327000/OSD_demo.rar.html
писал в IAR
Глянул Вашу заготовку OSD. Попиксельный вывод строк символов скорее всего получится слишком тормозной. Можно не успеть обновить все надписи за межкадровый интервал. Мне пришлось оптимизировать вывод строки сразу в одной функции и на асме. Использовать встроенный компаратор для определения синхроимпульсов, мысль хорошая. А в железе уже проверили работу?
Да, скриншоты в архиве это кадры с уже реального железа. Картинку захватывал такой железякой: nix.ru/…/STLab_M320_Grabber_USB2.0_SVideo_86320.ht…
Кстати, телевизор, на котором я проверял качество картиники надежно устранял все факелы - так что “удешевленное” подмешивание тоже жизнеспособно.
Насчет обновления - некоторые данные нет смысла перерисовывать в каждом кадре , можно делать это чуть реже. Я разбил такие фрагменты кода на несколько частей, и в зависимости от счетчика кадров вызывается только один фрагмент:
if (task++>T) task=0;
if (task==0) {compass(ang);}
if (task==1) {alt_ruler(); speed_ruler();}
if (task==2) {discharge(cap);}
Примерно так. Мой GPS приемник отдает данные вообще раз в секунду - поэтому смысла перерисовывать координаты/высоту/скорость/etc в каждом кадре нет.
Уже писАл выше, что у меня вывод графики в каждом условно нечетном полукадре (25Гц, реже -не будет плавности), а вывод текстовой информации в четном, тоже как у Вас, поочередно группами. Хоть GPS у меня 5-ти герцовый, но для получения плавных движений шкал пришлось интерполировать получаемые значения на 25Гц, иначе картинка стробит.
Проблема с факелами у меня началась, когда начал пытаться рисовать тени…
Я поражаюсь с этого чувака: www.rowlhouse.co.uk/main.html 😮
На странице конечно много всего, но больше мне понравился RC-симулятор с автопилотом! Более того, этот товарищ выложил все исходники! (I’ve written a flight simulator for R/C model gliders)
Если посмотреть остальные проекты, остается сказать только “Во дает!” ибо это действительно сильно!
Не удивлюсь если он уже работает в НАСА…